Staking and Un-staking Mechanisms

What happens behind the scenes when a user stakes or unstakes with Kintsu

Staking Mechanism

Staking on Kintsu involves the following order of operations:

1. HYPE Deposit: User deposits HYPE into the StakedHype contract by initiating a deposit() transaction.

2. Receipt Token Issuance: The StakedHype contract calculates the number of new shares (sHYPE) to create, using the current Redemption Ratio, and transfers them to the user. These sHYPE serve as a receipt entitling the holder to their share of the Total Pooled. The sHYPE tokens are fungible, can be traded and used elsewhere on the network, and can be used to redeem HYPE during the unstaking process. The number of new sHYPE created, denoted here as newShares, is as follows:

   $newShares = newStake * (totalShares/totalPooled)$

   where newStake is the number of newly deposited HYPE, totalShares is the Total Shares and totalPooled is the Total Pooled.

3. Request is added to Current Batch: The user's deposit request is added to the current batch, to be submitted to validators.

To see how this translates into a user's experience staking on Kintsu, see our docs on Staking with Kintsu.

Unstaking Mechanism

Unstaking on Kintsu involves a two step execution by the user - Request Unlock and Redeem Request. The complete lifecycle of unstaking is as follows:

1. Initiation: User calls requestUnlock(), during which they submit their sHYPE to the Vault.

2. Spot value is determined: The StakedHype contract calculates the number of HYPE to return to the user, using the current Redemption Ratio after applying a nominal exit fee (unless exempted).

3. Request is added to Current Batch: The user's unlock request is added to the current batch, to be submitted to validators.

4. Cooldown Period: User must wait until Cooldown Period is over so that Validators are able to unbond the HYPE tokens.

5. Tokens returned to Vault: Once the cooldown period has ended, Anyone can call sweep() to transfer all the newly unbonded HYPE held in the HyperCore back to the Vault (on HyperEVM).

6. Token redemption: This is where the user can redeem their HYPE, including accrued yield. User makes a redeem() call to the Vault, which sends the user's newly unstaked HYPE to their wallet.

To see how this translates into a user's experience staking on Kintsu, see our docs on Unstaking with Kintsu.

Note: Users can cancel their unstaking request anytime before their batch is executed by calling cancelUnlockRequest()

---

Batch submission

The vault aggregates the deposit and unlock requests added in the current batch and then uses the Constant Retargeting Algorithm to calculate how many HYPE to stake with each validator (in the case of net-inflow) OR how many HYPE to unstake from each validator (in the case of net-outflow). Finally, the request is sent to the Hyperliquid staking module on HyperCore using the CoreWriter.

Anyone can initiate the submitBatch() call to the StakedHype contract.

Bonus: When the net outflow is zero, The unlocked requests of that batch does not need to wait for the network induced cooldown period and they can immediately redeem their unlock request 🪄✨

Constant Retargeting Algorithm

As the Vault accepts new HYPE for staking, it must delegate them across the participating Validators in such a way that aims to keep the amount delegated to each Validator consistent with the Target Weights stored in the Registry. In order to do this, the Vault retrieves the Target Weights from the Registry and compares them to the current percentages of the Total Pool held by each of the participating Validators at that time. The Vault then calculates how much of the newly added HYPE should be delegated to each Validator in order to bring the current weights closer to the Target Weights stored in the Registry.

During the unstaking process, the Vault again uses the Target Weights from the Registry to decide how many HYPE to redeem from each Validator such that the current weights converges to the Target Weights stored in the Registry.