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
    Commented Sep 28, 2017 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
    Commented Sep 30, 2017 at 19:03

3 Answers 3

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
    Commented Mar 8, 2018 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. Commented Mar 13, 2018 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
    Commented Oct 11, 2021 at 19:28
0

Another option would be to use ERC-1165, issuing NFTs with an expiry metadata filed. Using the block number as an approximate expiration date.

Then if the current block number is greater than the expiry block number, you can disable the transfer function (or send all subsequent transactions to the burn address)

0

old answer
Possible to create so you need to apply UTXO style to ERC20 token check my repository here.

https://github.com/MASDXI/ERC20-Expriable

The idea is you need to create a fungible token which is each token is the same in form but also contains a data field for the expiration date, ERC1155 look like to be a great solution but ERC1155 the meta-data of each tokenId group are stored off-chai, while in ERC721 each token is unique and pretty much same with ERC1155 the meta-data is stored off-chain moreover ERC721 not allowing you to split the token

the UTXO model should be the answer to the problem because each UTXO can be used to store additional data alongside the token amount, and the data can inherits from previously spend

2
  • Can you describe the working mechanism of the token? Link only answers are discouraged. It is better to include the main ideas in the answer itself and only use the link to expand the details.
    – Ismael
    Commented Apr 18, 2023 at 17:11
  • Thanks, I have edited my answer.
    – MASDXI
    Commented Apr 20, 2023 at 1:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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