CHIP-2026-06 CashTokens FT+NFT Ambiguity Fix

Consensus
#1

This is a maintenance CHIP that removes an annoying wart in the Script introspection API that’s been left from CashTokens, see here for background: https://github.com/cashtokens/cashtokens/issues/29

Summary

Under the current CashTokens Script introspection API, a UTXO holding both a fungible token (FT) amount and an immutable NFT with a zero-byte commitment is indistinguishable from a UTXO holding only the FT.
This proposal adds a consensus rule prohibiting new outputs from carrying that combination.
Existing UTXOs already in the ambiguous state remain spendable but must be split into separate FT and NFT outputs when spent.
Blockchain scan shows that this exotic combination appeared only a few times and closing the gap is unlikely to cause grief to anyone.

3 Likes
#2

NACK

This breaks userspace in surprising ways. Imposes extra cost on apps out there that will now surprisingly break if this activates… previously valid txns become invalid, etc.

Live with the wart – or devise a new op-code that disambiguates – we can create an “extended opcode space” for new refined opcodes, if need be.

Breaking userspace is bad. We should avoid it as much as possible.

#3

I guess it’s not good that Calin doesn’t like it.

But at a first glance this seems like a sensible fix to me.

The tiny number of UTXOs affected do not become unspendable, and it closes the gap so more aren’t created in the future.

I think the suggestion to design a new OP_code might be overkill in the other direction. But worth a discussion I suppose.

1 Like
#4

This immediately imposes a cost on every wallet out there to remember this corner case exception.

EC right now would need to be updated else randomly when sending tokens you get unexpected errors that txn is invalid.

All because 1 op-code out there is ill-specified.

Rather than fix the op-code we push the “ugliness” up to userspace / apps.

This is just the epitome of a bad idea.

Why? Because it’s legitimate to want to pack UTXOs with as much stuff as possible (wallets sometimes want to do this) → it’s legitimate to have empty NFTs live alongside >0 FT. This is a common case in EC if you just use the wallet and you happen to create empty NFTs for yourself.

Now EC has to remember not to do this. EC breaks. Right away.

This is just a bad idea. Pushing ugliness that was inherent in a mis-specified op-code – up to where everybody can see it – is not good.

The root of the problem is that the OP_*COMMITMENT op-codes do not properly distinguish between empty commitment and missing commitment. This is the op-code’s specification’s fault.

A new op-code that allows disambiguation is the solution. Not this.

#5

Is that true? If it’s handled at the node/consensus level, then wallets don’t need to know about it (if they don’t have token minting capability)? For instance in Selene afaik it’s not possible to make this kind of transaction yet (we don’t support token minting within the app just yet) so it’s not a problem for us.

And that’s Selene. Binance still on send/receive BCH on legacy addresses or the rest of the laggard BCH ecosystem isn’t going to notice.

For the few users that are impacted by this change, it seems like a recovery tool could be made that helped do the splitting so they weren’t affected. In fact perhaps if such a tool was created and published alongside the CHIP itself @bitcoincashautist then it would improve the case for this solution. Virtually no-one is affected, and people who are affected have the tool to fix their problem (which they only need fixed once, and then it won’t occur again) provided.