BEP24: Improvements to Freeze Function

[jpthor]

Abstract

Some dApps require token holders to lock up tokens that can only be released after a certain time delay, before granting premium features. This is also known as "staking" but the tokens will stay on the user's address. For example, a dApp with a certain premium feature set may require token holders to freeze a certain quantity of tokens on their address for a rolling period of 30 days (bond period). Note: BEP9 sets restrictions on when tokens can be unlocked (after a certain date), whilst BEP24 sets restrictions on how long the unlocking takes.

BEP-24 Proposal describes the functionality to improve BEP9:

• BondPeriod: Freeze the token with a specified bond period for the token after which they can be claimed (in seconds).
• Unfreeze: Unfreeze the tokens and begin the unbonding period. A second unfreeze call after tokens are unbonded is necessary to then claim.
• QueryBondPeriod: QueryBondPeriod will return the set bond period of the token freeze.
• QueryUnlockTime: QueryUnlockTime will return the unlock time when the token begins unlocking.

[darren-liu]

looks some duplication with BEP9

[jpthor]

Hi @darren-liu this is different, but certainly can be built on BEP9.

BEP9 refers to timelocking of tokens that can be reclaimed after a certain date.

BEP24 refers to bonding of tokens, that are locked indefinitely, after which the user can try to claim. At this point an unbonding period begins, such as 30 days. This is more similar to the process of staking.

BEP24 can be built on the fundamentals of BEP9. Without BEP24, users will have to keep coming online to re-lock their tokens.

[darren-liu]

Hi @darren-liu this is different, but certainly can be built on BEP9.

BEP9 refers to timelocking of tokens that can be reclaimed after a certain date.

BEP24 refers to bonding of tokens, that are locked indefinitely, after which the user can try to claim. At this point an unbonding period begins, such as 30 days. This is more similar to the process of staking.

BEP24 can be built on the fundamentals of BEP9. Without BEP24, users will have to keep coming online to re-lock their tokens.

but the feature required in your motivation can be done via BEP9 fully: in the example of "a dApp with a certain premium feature set may require token holders to freeze a certain quantity of tokens on their address for a minimum of 30 days (bond period). ", this sounds a timer lock of 30 days is good enough.

[jpthor]

Hi @darren-liu - this will not work.

The user must come online every 30 days and a re-lock transaction for another 30 days. If they miss this, then the dApp will kick them out of their ecosystem.

BEP9 is a TimeStamp (such as vesting tokens), BEP24 is for staking and entering dApp ecosystems because the bonding time creates an opportunity cost.

[jpthor]

Hi @darren-liu I have made some changes to simplify how this is explained.

[onggunhao]

@jpthor Would it be wiser to adopt a different analogy that is easier to communicate?

1. "Freezing" (i.e. as implemented in BEP-9)
2. "Thawing" (i.e. your unbonding period)

Or maybe this should have a separate nomenclature, i.e. "staking" based.

I see your point, that BEP-9 time locks are not able to support an indefinite "freezing" that is not time based

I do wonder whether this is part of a larger functionality, i.e. indefinite "freezing" or "collateralizing" where the release can be programmatically controlled.

e.g. MakerDAO-style collateralization, where the rights of who can unlock and claim are programmatic.

[brilliant-lx]

outdated, archive it.