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 in which he laid the foundations of that protocol with that phrase. In Satoshi's own words, electronic cash entails 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 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 that sense, Bitcoin Cash (BCH) has a process for presenting, discussing, and standardizing ideas called “CHIP” ( which stands for: cash improvement proposals) that, similar to the “BIPs” 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 ability to transfer other assets through the Bitcoin Cash blockchain. Assets that in the world of cryptocurrencies are often referred to as “tokens”, 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 gained independence 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 consists of 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 the requirement to wait 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 do not match 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 posed 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 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 worth less than $200 as good without confirmations.
• 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-custody 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 their 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” appears as the formal name. This expression may be a bit confusing for a Spanish-speaking audience, as one might erroneously think 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 made as Bitcoin Cash native tokens (BCH) allow the use of 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 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=“”> as <tokens primitivos=“”> has been corrected. The correct translation is <primitivas de=“” token=“”> or alternatively, to convey the same idea, <tokens nativos=“”>.