CashTokens: the native tokens arrive at Bitcoin Cash

Introduction and Background

In late 2008, the idea of Bitcoin was presented as “a peer-to-peer electronic cash system”; in fact, Satoshi Nakamoto titled the technical document that laid the foundations of this protocol with that phrase. In Satoshi's own words, electronic cash means direct payments between people “without having to go through a financial institution,” a premise that served as the foundation for Bitcoin-BTC until 2017, the year in which supporters of “Bitcoin as cash” had to migrate to a separate network called Bitcoin Cash (BCH) --“Bitcoin cash” in English–. Thus, the concept of digital money is the starting point for all Bitcoin technology, especially in the case of BCH, which claims this quality as non-negotiable.

This quality is not incompatible with the incorporation of other use cases, as long as integrating them does not put at risk the ability to use BCH as money, or to scale its system so that more and more people can adopt it as such.

In this sense, Bitcoin Cash (BCH) has a process for presenting, discussing, and standardizing ideas called “CHIP” ( which stands for: cash improvement proposals ) that, similar to “BIPs” or “Bitcoin Improvement Proposals” of Bitcoin-BTC, allows the community to discuss and assess the suitability of ideas to be developed to add new functions to applications, and even to the protocol on which the currency runs.

One of the functions that has been pursued for years is the ability to transfer other assets through the Bitcoin Cash blockchain. Assets that in the world of cryptocurrencies are often referred to as “tokens” or “chips”, very popular in many crypto ecosystems, which provide extra economic activity to the networks they run on, and which, accompanied by functions such as the ability to implement smart contracts, can be exchanged on decentralized exchanges or used on DeFi platforms.

When BCH had just become independent from BTC, there were several proposals to incorporate tokens based on the concept of “colored coins,” which refers to transactions ( sending a very small amount of Bitcoin Cash, for example ) that contain metadata to transfer a token. In other words, it involves using BCH transactions as a vehicle for other assets, requiring a protocol that can interpret those attached metadata as a token, the amount transferred, etc.

This idea was implemented on the Bitcoin Cash network (BCH) through various protocols, the most well-known and long-lasting being the “Simple Ledger Protocol” or “SLP tokens.”

However, the “colored coins” model has certain limitations, such as the need to run additional software to validate the information they contain, as well as waiting for at least 1 confirmation to consider those transactions valid. Due to these weaknesses, “colored coins” represent a viable alternative for sending and receiving tokens, but without matching the qualities of payments with the base currency.

New standard: a better model

On May 15, 2023, Bitcoin Cash (BCH) will incorporate, through an update, among other new features, the ability to transfer tokens without the limitations imposed by “colored coin” protocols. This new function, which has been assigned the technical specification identifier “CHIP-2022-02”, is named “CashTokens: token primitives for Bitcoin Cash”. In simple terms, CashTokens represents a superior solution compared to the “Simple Ledger Protocol” of SLP tokens, distinguishing itself among other things by the following characteristics:

• The infrastructure supporting “SLP tokens” required running “SLP nodes”, that is, additional software to validate transactions of that type based on the metadata included in them. In the case of CashTokens, its support only requires a Bitcoin Cash node, so miners and full node operators can attest to its validity.
• SLP token transactions are not compatible with 0-conf, so it can be risky to accept transactions without waiting for the first confirmation. CashToken transactions are compatible with 0-conf, so it is reasonable to consider transactions without confirmations less than $200 as valid.
• Although the Bitcoin Cash network is based on the “UTXO” model, SLP token transactions are verified using the “DAG” model. CashTokens transactions are based on the UTXO model, which means greater efficiency in validating transactions of this standard.

These advantages, among many others, allow CashTokens to provide a better user experience and reduce the friction of expanding the compatibility of self-custodied wallets and trading platforms with the sending and storage of tokens. On the other hand, transactions with CashTokens pay fees to miners denominated in Bitcoin Cash, so eventual popularization will contribute to the maintenance of the system.

CashTokens: token primitives

In the technical specification of CashTokens, the expression “Token Primitives for Bitcoin Cash” is listed as the formal name. This expression can be a bit confusing for a Spanish-speaking audience, as it may be mistakenly thought that it refers to something “primitive,” unsophisticated, or limited in its compatibility with DeFi.

However, CashTokens is not only compatible with smart contracts written in the Bitcoin Cash scripting language, but the term does not seek to evoke simplicity. The expression “primitives” in this context refers to a fundamental function of a protocol; a native function of the protocol, so a much clearer translation of the concept could be “Native Tokens for Bitcoin Cash.”

Update: originally the article stated that CashTokens ( unlike SLP tokens ) did not require the use of two address formats. A correction has been incorporated because native Bitcoin Cash tokens (BCH) allow the use of <<token aware=“”>> (token-aware) addresses that can receive both BCH and CashTokens, and normal format addresses, which only receive BCH. The use of two formats is intended so that users do not send tokens to wallets that do not reflect this type of asset. On the other hand, the translation of <<token primitives=“”>> has been corrected to <<tokens primitivos=“”>>. The correct translation is <<primitivas de=“” token=“”>>, or alternatively, to convey the same idea, <<tokens nativos=“”>>.</tokens></primitivas></tokens></token></token>