LogoLogo
  • Overview
    • Introduction
    • Proof-of-Stake Blockchains
    • Liquid Staking
  • Monad Blockchain
    • Liquid Staking on Monad
  • The Kintsu Protocol
    • How It Works
    • Staking and Unstaking with Kintsu
    • Earning Yield
    • Definitions
    • Architecture
      • Core Smart Contracts
      • Smart Contract Functions
      • Staking and Un-staking Mechanisms
      • Community Actions
    • Official Contract Addresses
  • Community
    • Community & Social Media
    • Contribute to Open Source
    • Hackathons and Meetups
    • Partnerships
  • Development Team
    • Who We Are
    • Why We Build
  • Resources
    • FAQs
    • Bug Reports
    • Feature Requests
    • Support
Powered by GitBook
LogoLogo
On this page
  • Staking Mechanism
  • Constant Retargeting Algorithm
  • Unstaking Mechanism
  • Unstaking Order of Operations
  • Request Routing
  1. The Kintsu Protocol
  2. Architecture

Staking and Un-staking Mechanisms

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

PreviousSmart Contract FunctionsNextCommunity Actions

Last updated 4 months ago

Staking Mechanism

Staking on Kintsu involves the following order of operations:

  1. MON Deposit: User deposits MON into the contract by initiating a stake transaction.

  2. Validator Forwarding: Vault contract checks the contract to retrieve the current . Vault contract checks all participating Validators to see how many MON are currently allocated to each. The Vault uses these sums to calculate the Current Weights (the percentage of the Total Pool held by each Validator). Vault contract uses the to calculate how many of the newly submitted MON to forward to each of the Validators, and forwards them accordingly.

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

    newShares=newStake∗(totalShares/totalPooled)newShares = newStake * (totalShares/totalPooled)newShares=newStake∗(totalShares/totalPooled)

    where newStake is the number of newly deposited MON, totalShares is the and totalPooled is the .

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

Constant Retargeting Algorithm

As the accepts new MON 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 stored in the . In order to 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 MON should be delegated to each Validator in order to bring the current weights closer to the Target Weights stored in the Registry.

During the un-staking process, the Vault again uses the Target Weights from the Registry to decide how many MON to redeem from each Validator.


Unstaking Mechanism

Kintsu involves some clever mechanisms to enable unstaking at scale, despite network-level constraints such as the Cooldown Period and .

Unstaking Order of Operations

Unstaking on Kintsu involves the following order of operations:

  1. Token redemption: This is where the user can redeem their MON, including accrued yield. In order for this to happen, the Vault must have custody of the unbonded MON. There are two scenarios here:

Request Routing

Initiation: User calls , during which they submit their sMON to the Vault.

Vault Sends Unlock Requests: The Vault automatically sends unlock requests to the Validators based on the .

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

Tokens returned to Vault: Anyone on the network can execute the call, which forwards all newly unbonded MON held by the Validators back to the Vault, which can return them to users.

If the newly unbonded MON are still held by Validators when a user tries to redeem theirs, the user must call . This first executes a call, during which the Vault collects the unbonded MON from each of the Validator, and then executes the call, which forwards the user's entitled portion of those MON from the Vault to the user's wallet.

If the Vault already has custody of the MON, the user can make a call to the Vault, which sends the user's newly unstaked MON to their wallet. This scenario would happen when someone else has already executed the call for this era.

Note: when a user uses the Kintsu GUI to redeem their claimable MON after the Cooldown Period, the GUI will intelligently decide whether to call or whether to simply call .

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

In order for the user to receive MON from the protocol, the Vault must make requests to each of the Validators, who in turn make requests to the Validators, to "" (unstake) MON from network staking. These requests are enforced by the network and by the protocol, but they don't happen immediately.

delegateWithdrawUnbonded
redeemWithWithdraw
delegateWithdrawUnbonded
redeem
redeem
delegateWithdrawUnbonded
redeemWithWithdraw
redeem
unbond
Constant Retargeting Algorithm
Cooldown Period
Redemption Ratio
Total Pooled
Total Shares
Total Pooled
Constant Retargeting Algorithm
Daily Unbonding Request Limits
Unstaking with Kintsu
Staking with Kintsu
Vault
Registry
Target Weights
Vault
Target Weights
Registry
Request Unlock