Token Burning

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

Make tokens, states, and smart contracts on the blockchain unusable when they are no longer required.

Context

In the context of blockchain-based payments – Once the sellers receive tokens from the buyers, they need to redeem the tokens for fiat currency (e.g., US Dollars). Once the tokens are redeemed in return for a fiat currency payment, they should not be further usable (i.e., prevent double-spending).

In the context of data migration – The source blockchain is public and not decommissioned after the data migration. Therefore, any state and smart contracts left in the source blockchain could be misused (e.g., double spending). The list of states and smart contracts to be migrated is given in the snapshot or application-level reference to the blockchain identifier mapping database.

Problem

How to ensure tokens, states, and smart contracts are unusable when they are no longer required?

Forces

Immutability – The state of accounts and smart contracts on a blockchain is immutable.
Consistency – A token should be redeemed only once. If the source blockchain is not decommissioned, states and smart contracts could be used in both the blockchains leading to misuse, such as double-spending attacks. Any transformation of data to prevent misuse must not violate consistency properties.
Accountability – Any data transformation to prevent misuse must be recorded with proof.
Complexity – There are a large number of states and redeemed tokens that need to be maintained and tracked.
Vulnerability – Vulnerability might exist if a smart contract is not appropriately managed or contains bugs, e.g., the private key is stolen.

Solution

Potential misuse of a token, state, and smart contract can be prevented by either destroying or locking them when they are no longer needed. This process is referred to as token burning and could be achieved in several ways. The following sequence fiagram illustrates three ways of achieving this. In the first approach, the seller can transfer the tokens to an unusable/invalid address (aka., burn address). Such an address should not have a corresponding private key that can control the tokens it receives. The second way is to delete a token by calling the delete/burn function on the token contract used to create it or the token registry that keeps track of balances. The third method is to deploy a smart contract that immediately self-destructs as soon as it receives a token. For archiving, burned tokens could be moved to the token owner’s read-only token wallet that any party cannot operate on the seller side.

While transferring states/assets, it is vital to ensure that the recipient address (aka., burn address) is invalid, i.e., there will not be a corresponding private key that can control the states sent to that address. Therefore, it is essential to use the burn address recommended by the chosen blockchain platform.

Another alternative is to deploy a smart contract that immediately self-destructs as soon as it receives a transaction. However, it is more costly as smart contract deployment and execution are relatively expensive. A smart contract and its state/tokens can be made unusable using the self-destruct function, e.g., selfdestruct function in Ethereum. Users holding the private keys need to sign the transactions that burn their states/tokens or trigger relevant smart contract functions. In case a self-destruct function is not built into the smart contract, a carefully crafted transaction(s) may be attempted to set the state to a terminating state, e.g., similar to in Augur. However, this approach is not guaranteed to work or may fail in the future once vulnerabilities are found.

In blockchain migration, the burned state/token is typically verified before recreating the state/token on the target blockchain (aka., proof of burn). If a custodial wallet maintains aggregated state, a user trying to establish proof of burn for his/her state needs to transfer the state to a non-custodial wallet before burning the state. If the source and target blockchains are different instances, the service of an oracle could be used to attest the state from one blockchain to another. The migration tool may also work as an oracle, as it has access to both the blockchains. However, when transaction fees are charged, the burned state may not be an accurate representation of the original state. Sometimes token burning is performed after the migration, where they are retained as a rollback option in case of a failed migration. The risk of maintaining states on two blockchains needs to be carefully evaluated based on the permission type of blockchains, migration window, and the ability to prevent users from issuing transactions within the migration window. The risk could also be reduced by burning only one state at a time and recreating that on the target blockchain.

Benefits

Immutability, consistency, and accountability – Are preserved as all state changes are performed within the source blockchain. When recreating states on the target blockchain, proof of burn should be verified.
Redeem once – Double spending is alleviated as the state/token is no longer spendable or even exist.
Integrity – The blockchain ensures the integrity of states and tokens.
This pattern works on all blockchains.

Drawbacks

Cost – On a public blockchain, transaction fees need to be paid to make the tokens, states, and smart contracts unusable.
Traceability – The burned states and tokens cannot be tracked. On the seller side, this can be tracked by moving to the read-only wallet.
Planned – A smart contract should either implement a self-destruct function or it should be possible to generate a specific transaction sequence that sets a smart contract’s state as terminated.

Related patterns

Once a token is redeemed, token template and token registry patterns can use the burned token pattern to mark a token as unspendable.
Snapshotting and state aggregation patterns could be used before token burning. Moreover, the set of states and smart contracts to burn can be found using the snapshotting pattern.
State and transaction load patterns such as exchange transfer, establish genesis, and state initialisation can verify proof of burn before initializing a new state on the target blockchain.
The service of an oracle could be used to attest the state from one blockchain to another

Known uses

Perth Mint Gold token holders can redeem their tokens to either get Perth Mint gold or fiat currency. Before redeeming, the token owner needs to call the burn function on the smart contract to burn the token. Once the burned token is confirmed, the mint issues the gold or fiat currency.
Smart Money developed by TietoEVRY maintains burned tokens in a separate wallet.
In Making Money Smart project, sellers can redeem smart tokens for payment in Australian Dollars.
While migrating from Ethereum or Bitcoin to their own instances, Binance, Bitizens, KARMA, Kin, Safex, and Storj asked users to burn their tokens by transferring them to a designated address.
Whereas EOS, Qubicle, and Vechain asked users to burn a small number of tokens to confirm the ownership of their accounts, and the remaining tokens were burned by the respective smart contracts that created them. Qubicle’s token burning followed the EOS inter-blockchain communication protocol.
While tokens are typically burned before the migration, Binance, KARMA, and Storj tokens were burned after the migration. This pattern is also used while bootstrapping alt-coins in Bitcoin and sidechains in Horizen.