GIL Token Burning

Summary

Make GIL 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 GIL 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 GIL 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.