CashTokens

CashTokens is a scripting and transaction format modification plan for Bitcoin Cash, proposed by Jason Dreyzehner in February of 2022. It has since been widely promoted, intensely debated over in public among many BCH developers and interested community members, and is in final stages of testing and implementation before commitment for network-wide activation in May 2023 per the CHIP process.

Due to the proposal's name, it was widely expected to be a straightforward "consensus tokenization" proposal for BCH, comparable to colored coins and SLP protocols that came before it. CashTokens, however, is designed with UTXO smart contract interactions as a priority, and it should be viewed as powerful, message-carrying general computing "tokens" instead of limited-function tradable asset-carriers. At General Protocols, we believe we are in a position to take full advantage of the proposal once it is activated.

There are several specific design choices we like about CashTokens, that are especially relevant to our goals as a company:

1. Non-fungible tokens and contract abstraction

General Protocol's current and planned product lineup are all P2SH-based smart contract derivatives that lock up BCH as backing. One difficulty we face is the fact that contracts are mostly static once formed. Transferring ownership of contracts permissionlessly is necessary for liquid markets to form trading these contracts, which enables much more efficient service.

As of 2022, transferability is possible with proper covenant setups. These setups, however, are both cumbersome - they consume significant space within unlocking scripts - as well as difficult to standardize, as wallets will need to recognize, integrate scripting libraries and support each new contract in order to transfer and trade them.

With the CashTokens proposal, the contracts themselves do not need to be transferred, but can instead pay out to non-fungible tokens that can themselves be transferred. Wallets can be configured to support sending and receiving NFTs with minimal effort, and in one step enable transferability of all future contract permutations.

NFT capabilities such as commitments (allowing localized state on a token), minting (allowing duplication) and mutability (allowing changing of state, likely encumbered by covenants) as specified in the CashTokens proposal further augment transferability by enabling more complex setups. While these capabilities can likely also be emulated using complex covenant setups, having explicit capabilities in the protocol again should greatly lower barriers of entry for both contract and wallet builders. We will explore these interactions in future posts.

2. Preserving the BCH design philosophy: Self-contained transactions

Bitcoin-like UTXO chains, including BCH, derive much of their advantages over account-based chains like Ethereum from their design. In UTXO chains, each transaction is self-contained for evaluation with minimal input from the global state (which generally only includes the UTXO set). One can either spend the outputs, or one cannot. This self-contained design enables better scalability and less complexity on UTXO chains.

Unlike some other prior proposals, CashTokens transactions are entirely self-contained. There are no additional global state or encumbrances like metadata and global covenants to refer to while evaluating a CashTokens-enabled transaction, keeping execution localized. We believe this is important for preserving BCH scalability, which is a fundamental value proposition of the coin.

3. Backwards compatibility

We cannot overstate how important it is for both our company and the BCH ecosystem as a whole that upgrades preserve existing software assumptions as much as possible. Not only are breaking upgrades detrimental to adoption as companies weigh costly retooling against benefits of continuing operations on BCH, these breakages have also acted as triggers for community and eventually chain fragmentation in the past.

CashTokens, as far as we understand, does not break existing software. Services that do not want to deal with tokens can simply ignore the scheme's existence, and would only need to invest work-hours if they wish to recognize and participate in CashTokens transactions.

Contrary to certain previous token schemes like SLP where unaware wallets can accidentally burn tokens, it is nigh impossible for an unupgraded wallet to ruin a CashTokens output, spending would simply be unavailable. This is a long-requested trait from the community that should further increase the proposal's appeal.

4. Non-genesis category ID

One interesting CashTokens design choice is the use of txids of input transactions to Genesis as category IDs of generated tokens. This setup enables generation of covenants that use tokens generated in the same transaction in its clauses.

A possible alternative setup, as discussed by community members at the design phase, may have the category ID locked to the txid of the Genesis transaction. A covenant including the generated tokens will, under this setup, have to be generated separately or in subsequent transactions. We believe the atomicity made possible by CashToken's design will enable easier design of complex covenant setups with less trust assumptions in the future.

P2SH32

Scripting on BCH is generally done as P2SH (pay-to-scripthash) contracts, which is the lifeblood of GP's current and future business plans. As outlined in the P2SH32 proposal, P2SH suffers from a cryptographic weakness that affects security assumptions among multiple trustless parties at high amounts. While sophisticated mitigations are sometimes available, designing them can be challenging, and may introduce further difficulties down the line. This weakness not only makes it difficult for GP to accommodate very large amounts, it can even affect our day-to-day operations as a BCH company, such as multisig spending.

The solution brought forth by the P2SH32 proposal is straightforward, does not break existing software, and we believe will provide a solid foundation for GP to build our business upon.

And for these reasons, as well as the very well explored rationale sections, General Protocols will like to declare our support for the CashTokens and P2SH32 proposals. We understand that minor bugs/insufficiencies may still be discovered, and we'll encourage the ecosystem to put opinions up as we approach commitment.

Version Restriction and Relaxing Transaction Size Restrictions

Also on the table for commitment are two more proposals: Transaction Version Restriction and Relaxation of Transaction Size Lower Bounds. We at General Protocols do not directly benefit from these changes, but do view them as necessary and straightforward cleanups that should simplify upgrades and mining on BCH going forward. We support both of these proposals.

General Protocols Blog

This article forms part of the General Protocols Blog, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings.