# Staking and Un-staking Mechanisms

## **Staking Mechanism**

Staking on Ike involves the following order of operations:

1. **AZERO Deposit:** User deposits AZERO into the [`Vault`](https://docs.ike.xyz/the-ike-protocol/core-smart-contracts#the-vault-contract) contract by initiating a `stake` transaction.
2. **Validator Forwarding:** `Vault` contract checks the [`Registry`](https://docs.ike.xyz/the-ike-protocol/core-smart-contracts#the-registry-contract) contract to retrieve the current [Target Weights](https://docs.ike.xyz/the-ike-protocol/core-smart-contracts#target-weights). `Vault` contract checks all participating Validators to see how many AZERO 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 [Constant Retargeting Algorithm](#constant-regargeting-algorithm) to calculate how many of the newly submitted AZERO to forward to each of the Validators, and forwards them accordingly.
3. **Receipt Token Issuance:** `Vault` contract calculates the correct number of new shares (sA0) to create, using the current [Redemption Ratio](https://docs.ike.xyz/the-ike-protocol/definitions), and transfers them to the user. These sA0 serve as a receipt entitling the holder to their share of the [Total Pooled](https://docs.ike.xyz/the-ike-protocol/definitions). The sA0 tokens are fungible, can be traded and used elsewhere on the network, and can be used to redeem AZERO during the unstaking process. The number of new sA0 created, denoted here as *newShares,* is as follows:<br>

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

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

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

### Constant Retargeting Algorithm

As the [`Vault`](https://docs.ike.xyz/the-ike-protocol/core-smart-contracts#the-vault-contract) accepts new AZERO 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.ike.xyz/the-ike-protocol/core-smart-contracts#target-weights) stored in the [`Registry`](https://docs.ike.xyz/the-ike-protocol/core-smart-contracts#the-registry-contract). 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 AZERO 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 AZERO to redeem from each Validator.

***

## Unstaking Mechanism

Ike involves some clever mechanisms to enable unstaking at scale, despite network-level constraints such as the [Cooldown Period](https://docs.ike.xyz/aleph-zero-network/liquid-staking-on-aleph-zero#cooldown-period) and [Daily Unbonding Request Limits](#daily-unbonding-request-limits).&#x20;

### Unstaking Order of Operations

Unstaking on Ike involves the following order of operations:

1. **Initiation:** User calls [Request Unlock](https://docs.ike.xyz/the-ike-protocol/smart-contract-functions#unstaking-functions), during which they submit their sA0 to the Vault.&#x20;
2. **Vault Sends Unlock Requests:** The Vault automatically sends unlock requests to the Validators based on the [Constant Retargeting Algorithm](#constant-retargeting-algorithm).&#x20;
3. **Cooldown Period:** User must wait until [Cooldown Period](#cooldown-period) is over so that Validators are able to unbond the AZERO tokens.
4. **Tokens returned to Vault:** Anyone on the network can execute the [`delegateWithdrawUnbonded`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions) call, which forwards all newly unbonded AZERO held by the Validators back to the `Vault`, which can return them to users.&#x20;
5. **Token redemption:** This is where the user can redeem their AZERO, including accrued yield. In order for this to happen, the `Vault` must have custody of the unbonded AZERO. There are two scenarios here:
   1. If the newly unbonded AZERO are still held by Validators when a user tries to redeem theirs, the user must call [`redeemWithWithdraw`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions). This first executes a [`delegateWithdrawUnbonded`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions) call, during which the `Vault` collects the unbonded AZERO from each of the Validator, and then executes the [`redeem`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions) call, which forwards the user's entitled portion of those AZERO from the `Vault` to the user's wallet.
   2. If the Vault already has custody of the AZERO, the user can make a [`redeem`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions) call to the `Vault`, which sends the user's newly unstaked AZERO to their wallet. This scenario would happen when someone else has already executed the [`delegateWithdrawUnbonded`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions) call for this era.

{% hint style="info" %}
Note: when a user uses the Ike GUI to redeem their claimable AZERO after the Cooldown Period, the GUI will intelligently decide whether to call [`redeemWithWithdraw`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions) or whether to simply call [`redeem`](https://docs.ike.xyz/the-ike-protocol/architecture/smart-contract-functions)`.`
{% endhint %}

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

### Request Routing

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