There will be ICO with multiple cycles... Here, investors can purchase tokens and after a fixed window of 270 days, they can redeem it back. But within this window period, they can transfer tokens to each other and the world.

For example, if user purchases 1000 tokens in 1st cycle, those tokens can only be redeemed after 7th cycle.

If someone purchased 1000 tokens in 3rd cycle and transferred 500 to other user, both should only be able to redeem after 9th cycle...

Can we bind "token purchase timestamp" with each token which never changes irrespective of transfers?

What will be the best solution according to you?

  • 1
    Can we bind "token purchase timestamp" with each token which never changes irrespective of transfers? - of course, but ERC20 does not support this (all tokens are minted "equally"), so you'll have to implement it yourself. Jan 21, 2019 at 14:34

2 Answers 2


The approach will differ depending on your precise use-case.

If you are going for securities regulation compliance then that topic is too complex for a quick answer, so let's just set that aside. There are two other cases.

If the nature of the tokens is actually different then you need non-fungible tokens. Here's a quick way to consider if this is the case. After all the lock-in periods have expired, would it ever be feasible and valid to add two sums together and track it as a single balance? That is, if Alice has 100 unrestricted tokens and receives 50 more unrestricted tokens, is it enough to know that Alice has 150 unrestricted tokens? Yes, if they are all entirely the same. No, if they have other unique properties such as serial numbers.

If "No", they are not the same and cannot be pooled like that, then look into ERC721 and variants.

If "Yes", they are "fungible" and you have conflated the sale process with the nature of the tokens. That will lead to confusion.

You can have fungible tokens with lock-in periods. In this case, you would use ERC20 which does not (nor should it) cover the lock-in concern. Instead, you would create a sale contract and a lock-in contract. The lock-in contract would function similarly to a term deposit, holding funds (tokens) on behalf of a depositor and stubbornly refusing to release them to anyone else, or to the depositor prematurely. Integration of the sales process and deposit contract would ensure that tokens sold are automatically sent to the deposit contract per the terms of the sale.

Hope it helps.


Depends on your number of cycles and what you want investors to be able to do with your tokens apart from trading and redeeming them. In case it's 10 cycles, I believe it's best to just launch 10 ERC20 contracts, distribute the tokens, and then accept them back depending on the contract launch date.

For that you can take an existing implementation of ERC20 and enjoy the safety of well-crafted code.

In case you want investors redeeming tokens handled by a single smart-contract defined before they buy from your 10 separate contracts, you can use this solution too.

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.