Financial Use Case
FED has two main purposes for its currency ($USD):
Grow the size of USD based economy.
Establish price stability.
It has two fundamental instruments:
Emission/Quantitative Easing: Purchasing securities from the open market to reduce interest rates and increase the circulating supply. This lowers the interest rates while introducing new money supply, which causes whales towards riskier investments rather than parking in the safest place next to FED.
Quantitative Tightening: This does the opposite and causes the interest rates rise and circulating supply shrink.
Sometimes QE causes excessive inflation, risking price stability and organic economy. Then, FED actually increases interest rates through QT. The net effect is attracting USD whales to park a greater deal of their money in the safest place (near FED) with a better interest. This sustains pulling money from circulation. Less USD tokens in circulation stops devaluation of the currency and eases inflation. In this use case the whale William needs to deposit his money under a secure contract, regarding the terms and conditions of this transaction involving a relatively higher interest (APR).
We call this scheme "token staking" in web3. Let GemHunter be a Web3 Gaming project that has a cryptocurrency utility token. It has a roadmap of token emission. The plan is to emit tokens with respect to the growing economy of the game. This emission increases circulating supply and has a pressure on token value when it is faster than the growth of the game economy. Speculations get in the way. If this project team is sincerely trying to build a sustainable economy based on their crypto-currency they would use FED's tightening mechanism to stop too much inflation (and hence extreme devaluation), which hurts gamers and true believers that use the token. They would do so by issuing a staking contract with some interest rate (APR). What FED does is the same staking mechanism in classical terminology. With QT, FED is indirectly asking whales to stake their USD tokens in return for a high interest rate. In both cases depositors/lenders/buyers/stakers have to send their money to the issuer’s account/contract. These are sensitive transactions changing the state of the system drastically. Therefore, it is understandable that consensus is required to commit these transactions in Web3.
Let the Web3 Game GemHunter decide to do staking on its Lockable Token $Loco implemented on TON. If you stake your Loco tokens for three months you will get 3% interest.
Alice loves the game and has 150 $Loco. She decides to stake 100 $Loco to get 3 $Loco interest. She is lucky because Loco is a Lockable Token (LT). Let's see the flow and the state:
Let Initial State be {Balance: 150 $Loco, Lock: 0 $Loco}
She locks 100 $Loco with the end_time = now() + 3 months => Balance: 50 $Loco, Lock: 100 $Loco
She sends interest request message to the staking contract.
The staking contract calls the get_lock() getter function to verify 100 $Loco locked for three months.
The staking contract sends Alice 3 $Loco, immediately.
The staking contract owner, which is the issuer of $Loco is happy because it has removed 100 $Loco from circulation. The locking mechanism is impossible to reverse. Therefore, it can release the interest rate immediately to enchance user trust and loyalty. Alice is happy because she receives the interest rate immediately and her money did not leave her account. She is not scared of staking contract vulnerabilities, or did not have to trust third party contracts. The blockchain is happy because it did not need the heavy load of sophisticated consensus mechanisms for sophisticated smart contracts and trransaction request messages among contracts; and attracts mass adoption.
What happens if Alice uses this same locked amount to vote on a proposal on a DAO which uses the same $Loco token. In this use case the game developer team could be happier as they are the issuer of $Loco. They reached their goal of removing tokens from circulation and see it being used in governance further motivating the DAO and user to choose their $Loco.
What if GemHunter wants the locked amount to be used for its staking contract exclusively?
It is possible to cover such use cases by adding app_id to the lock state: The storage line in the lockable-jetton-wallet.tlb file is as follows:
Then, you can lock your tokens for a specific contract which demand exclusive staking. You can increase lock_amount and/or end_time as the app_id remains constant till the end_time. This is a constraint to prevent double lock. It gives limitations to flexibility for the sake of avoiding the consensus requirement. The DAOs using the same Lockable Token would not care about exclusivity since they use it for eligibility to vote for a proposal. If Alice has staked 100 $Loco with enough end-time, she is more than welcome to vote for a proposal and even create a proposal. Proposals are how members in the DAO can contribute to its governance. Therefore, the DAO using $Loco may not want exclusive staking and not check the app_id, where as those who demand exclusive staking will check the app_id. This scheme has its own scope of use cases, where it provides incredible speed, cost-effectiveness, and security.
The scheme can be further advanced to make Lock State a dictionary where the nullable app_id is the key and [{end_time, lock_amount}] is the value. The previously introduced set of constraints that lock is capped at balance and that user can only increase locking; helps us keep robustness in Lock Dictionary State scheme as well.
We are working on TEP-X as an extension to TEP-74 Fungible Token Standard. TEP-X includes minor changes in TVM implementation to introduce a class of transactions that do not require consensus. Note that this is a revolution on web3, and it is needed for mass adoption.
Last updated