# Staking and Un-staking Mechanisms

## **Staking Mechanism**

Staking on Kintsu involves the following order of operations:

1. **MON Deposit:** User deposits MON into the [`StakedMonad`](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/stakedmonad-contract#the-vault-contract) contract by initiating a `stake` transaction.
2. **Validator Forwarding:** During stake, `delegateBondingto` is called, retrieving the current [Target Weights](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/stakedmonad-contract#target-weights). It then checks all participating Validators to see how many MON are currently allocated to each. These sums are then used to calculate the Current Weights (the percentage of the Total Pool held by each Validator). Finally the [Constant Retargeting Algorithm](#constant-regargeting-algorithm)  is triggered to calculate how many of the newly submitted MON to forward to each of the Validators, and forwards them accordingly.
3. **Receipt Token Issuance:** The `StakedMonad` contract calculates the correct number of new shares (sMON) to create, using the current [Redemption Ratio](https://docs.kintsu.xyz/the-kintsu-protocol/definitions), and transfers them to the user. These sMON serve as a receipt entitling the holder to their share of the [Total Pooled](https://docs.kintsu.xyz/the-kintsu-protocol/definitions). 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:<br>

   $$newShares = newStake  \* (totalShares/totalPooled)$$ <br>

   where *newStake* is the number of newly deposited MON, *totalShares* is the [Total Shares](https://docs.kintsu.xyz/the-kintsu-protocol/definitions) and *totalPooled* is the [Total Pooled](https://docs.kintsu.xyz/the-kintsu-protocol/definitions).

To see how this translates into a user's experience staking on Kintsu, see our docs on [Staking with Kintsu](https://docs.kintsu.xyz/staking-and-unstaking-with-kintsu#staking-with-kintsu).

### Constant Retargeting Algorithm

As the [Vault](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/stakedmonad-contract#staked-monad-contract-functions) 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 [Target Weights](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/stakedmonad-contract#target-weights) stored in the [Registry](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/stakedmonad-contract#registry-interface-variables). 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 unstaking 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 [Daily Unbonding Request Limits](#daily-unbonding-request-limits).&#x20;

### Unstaking Order of Operations

Unstaking on Kintsu involves the following order of operations:

1. **Initiation:** User calls [Request Unlock](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/contract-interface-abi-and-functions#unstaking-functions), during which they submit their sMON to the Vault.&#x20;
2. **Request added to Current Batch**:  The uses unlock request is added to the current batch of unlocks, to be submitted to validators.
3. **Batch Unlock Requests sent:** After the two era period for the current batch, the unlock requests are sent to validators. These requests leverage the [Constant Retargeting Algorithm](#constant-retargeting-algorithm) to keep withdraws as evenly as possible.
4. **Cooldown Period:** User must wait until [Cooldown Period](#cooldown-period) is over so that Validators are able to unbond the MON tokens.
5. **Tokens returned to Vault:** Once the cooldown period has ended, the first user who calls `redeem`, also triggers the `withdrawUnbonded` method on the `StakedMonad` contract (a.k.a. the Vault). This forwards all newly unbonded MON held by the Validators back to the Vault.
6. **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:
   1. If the newly unbonded MON are still held by Validators when a user tries to redeem theirs, the `withdrawUnbonded` method is called under the hood, during which the `Vault` collects the unbonded MON from each of the Validator, and then executes the [`redeem`](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/contract-interface-abi-and-functions) call, which forwards the user's entitled portion of those MON from the `Vault` to the user's wallet.
   2. If the Vault already has custody of the MON, the user can make a [`redeem`](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/contract-interface-abi-and-functions) call to the `Vault`, which sends the user's newly unstaked MON to their wallet.

To see how this translates into a user's experience staking on Kintsu, see our docs on[ Unstaking with Kintsu](https://docs.kintsu.xyz/staking-and-unstaking-with-kintsu#unstaking-with-kintsu).

### Request Routing

In order for the user to receive MON from the protocol, the Vault must make requests to each of the Validators to "[unbond](https://docs.kintsu.xyz/the-kintsu-protocol/definitions)" (unstake) MON from network staking. These requests are enforced by the network and by the protocol, but they don't happen immediately.&#x20;