CashTokens: the native tokens come to 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 foundation for this protocol with that phrase. In Satoshi's own words, electronic cash enables 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 when 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 of 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 jeopardize 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 “BIP” or “Bitcoin Improvement Proposals” of Bitcoin-BTC, allows the community to discuss and evaluate 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 possibility of transferring other assets through the Bitcoin Cash blockchain. Assets that in the world of cryptocurrencies are commonly referred to as “tokens” or “tokens”, very popular in many crypto ecosystems, which provide extra economic activity to the networks on which they run, 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 transferred amount, 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 having to wait for at least 1 confirmation to deem 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 feature, 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, differing 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 their validity.
• SLP token transactions are not compatible with 0-conf, so it can be risky to accept transactions without waiting for the first confirmation. Transactions with CashTokens are compatible with 0-conf, so it is reasonable to consider transactions valid without confirmations under $200.
• 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 implies 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 the 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 may be somewhat confusing for a Spanish-speaking audience, since it could be mistakenly thought to refer 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 made because the native tokens of Bitcoin Cash (BCH) allow the use of <<token aware=“”>> (token aware) addresses that can receive both BCH and CashTokens, and normal format addresses that only receive BCH. The use of two formats is intended to prevent users from sending 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>