2

There are certain tokenizable assets (e.g. tokenized frequent flier reward points or product discounts) that might be well served by the concept of "expiration." Ideally, these assets (pre-expiry) could be listed and traded on exchanges, with the addition of expiration metadata.

Is it possible to build a token on the Ethereum blockchain that "expires" after a preset amount of time? Is anyone known to be working on this? I'm familiar with Freicoin which uses demurrage to disincentivize HODLing, but true expiration is a different concept.

Alternatively, is there a different way to functionally enable token expiration to serve the use cases mentioned above on the Ethereum blockchain, short of creating a new blockchain?

2
  • 1
    This comment will self-destruct in 5 seconds.
    – kkurian
    Sep 28 '17 at 18:27
  • A problem with this approach and ERC-20 is that tokens are fungible. If you have 1 token that expires this month, and another that expires in two months, when you transfer it you have no way of choosing which one you want to transfer. Surely it can be done but it will not be an ERC-20 token, it will be closer to Bitcoin's UTXO model.
    – Ismael
    Sep 30 '17 at 19:03
2

Since Tokens are in fact state of smart contract is should be possible. What needs to be done is to:

  • Update state of this contract and "expire" tokens by calling transaction (e.g. every day). This transaction would be quite expensive (in therms of used gas) since it will change state of many records on blockchain
  • Test if token is expired when operation on it is being performed e.g. somebody is trying to send it from one account to the other. You may also provide method to check balance of active tokens for address, that will be used by wallets.

The solution would be to write your own smart contract Token that will store expiration date/block. Just have in mind that block.timestamp is provided to the contract by the miner, so it might be risky to trust it. Maybe it would be better to relay on block number.

http://solidity.readthedocs.io/en/latest/units-and-global-variables.html?#block-and-transaction-properties

Both the timestamp and the block hash can be influenced by miners to some degree. Bad actors in the mining community can for example run a casino payout function on a chosen hash and just retry a different hash if they did not receive any money.

3
  • Why would it be risky? The point of the blockchain is that you can't give it fake data, or the block you send would not be included. The blocktime has an error margin of a few seconds, so although a miner could fudge it a little, you can rely on it being accurate to the nearest... 15 minutes, looks like.
    – Benubird
    Mar 8 '18 at 17:31
  • Nearest 15 minutes might be a big difference in some cases. I don't say it will be risky, but it might be in some cases. Don't trust the miner provided values is the rule of thumb, unless you are aware of how those could be manipulated and you are fine with it. Mar 13 '18 at 21:44
  • I am faced with a similar issue. I am thinking of using ERC1155 to issue say multiple tokens of a certain type e.g. 100 tokens of token type 0. Each of these tokens would point to metadata that would be located at ipfs:.../0.json.. and inside that json there would be a name/description of the reward and also an expiry timestamp
    – 1977
    Oct 11 '21 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.