# Introduction Welcome to Kintsu! {% hint style="info" %} This documentation will regularly be updated to represent the current state of the project. This version was last updated November 2025. {% endhint %} Kintsu is a Composable Liquid Staking Protocol. Our mission is to boost the GDP of DeFi by allowing users to participate in on-chain activities while also benefitting from the yield-bearing staking that secures the blockchain. Kintsu solves a number of challenges faced by Proof-of-Stake blockchains around liquidity, accessibility, and more. No longer does on-chain liquidity need to compete with L1 staking & security. Traditional staking methods on Proof-of-Stake (PoS) blockchains can hinder participants from engaging in the broader realm of decentralized finance. Once tokens are staked, they become locked and inaccessible for other purposes, limiting users' ability to actively participate in the dynamic DeFi landscape. In PoS networks, security competes with the use cases built on the network such as leveraging decentralized exchanges, diverse lending and borrowing platforms, participating in governance mechanisms, gaming, and exploring other innovative decentralized applications. # Proof-of-Stake Blockchains ## Background Many modern blockchains incentivize users to secure the blockchain via a consensus mechanism called Proof-of-stake (PoS). The native currency of these blockchains is called their native Gas Token, and they are used to execute transactions on the blockchain. For example, on Monad, MON is the gas token that powers the network. The native staking of MON is what creates a decentralized and secure network. As with any blockchain, all transactions have to be validated by a decentralized network of third party participants in a way that incentivizes all parties involved to uphold the integrity of those transactions ### Staking and Validators In the Proof-of-stake paradigm, users can lock their own Gas Tokens up and use them as collateral while they validate transactions on the blockchain. This process is known as transaction ***validation***, and those who practice validation are called ***validators***. In order to qualify to validate transactions, one must put up their own Gas Tokens as collateral - a process known as ***staking***. These participants provide a critical role in securing the integrity of the blockchain. In return for this service, validators are rewarded with new Gas Tokens that are created by the blockchain as transactions are validated. Validators can therefore earn yield on their tokens that they’ve staked. However, if other participants on the network detect that the validator has asserted a transaction incorrectly or disingenuously, that validator forfeits the Gas Tokens that they staked. This mechanism keeps the validators honest. This is an over-simplified explanation, and more information on Proof-of-stake can be found [on Wikipedia](https://en.wikipedia.org/wiki/Proof_of_stake). ## Proof-of-Stake Inefficiencies Staking provides a native mechanism for earning yield on the network’s native Gas Token. As a result, it provides one of the lowest risk ways for network participants to earn yield. This makes native staking yield the effective “risk-free rate” of the network with respect to the network’s Gas Token. This presents a few challenges: 1. **Staking minimums:** 1. Many Proof-of-stake networks require a minimum staked amount for validators to participate in validating transactions. This creates a barrier to entry for those who hold smaller amounts of Gas Tokens, as many participants don’t have enough Gas Tokens to qualify to earn staking yield. 2. Even when participants do have enough Gas Tokens to participate in theory, in many cases, there is an opportunity cost to staking, as locking up Gas Tokens precludes them from use in other network activities such as DeFi. 2. **Liquidity:** Any Gas Token locked up in consensus staking is unavailable for simultaneous use in other activities on the network. Thus, the network’s native consensus mechanism creates a powerful incentive for participants to leave their Gas Tokens staked, which limits the circulating quantity of the Gas Token available for use in network activity. ## Delegated Proof of Stake (DPoS) Delegated Proof-of-Stake (DPoS) networks allow any user to delegate their tokens to one or more Validators on-chain. The user can request that the validator un-stake and return the tokens to them. The blockchain itself enforces the integrity of this mechanism. This mechanism is known as "Delegation". ## Staking at the Network Level Each [era](/the-kintsu-protocol/definitions) on the blockchain, yield rewards in the form of new Gas Tokens are paid out to Validators. These rewards must be claimed, and sit in an unclaimed state on the blockchain until a Validator claims them. At any given time, there can only be a certain number of Validators that participate in staking validation, so the era’s yield is distributed equally to those Validators. Each Validator distributes its yield pro-rata to all Delegation Pools (Nomination Pools) who delegated (nominated) to it. This is done at the network level, so Validators don’t have a choice in whether they distribute the proceeds back to the Nomination Pool. Validators can take a commission fee for their service. Each Validator sets their own commission. Delegation Pools (Nomination Pools) may delegate (nominate) to certain Validators over others due to a more competitive commission fee. Gas Tokens sit in an unclaimed state at the network level until someone claims them and re-invests (re-delegates, or re-nominates) them. ### Cooldown Period Blockchain networks may enforce a delay between the time that a Validator themself executes an [`unbonding`](/the-kintsu-protocol/definitions) call, and when the network releases the tokens to that Validator. This is called a "Cooldown Period", and serves to, among other things, disincentivize Validators from constantly bonding and unbonding (staking and unstaking) Gas Tokens, which may clog up the network. This cooldown period may vary from network to network. You can find information about each network's Cooldown Period, if applicable, in that network's page in Kintsu's docs. ### Daily Unbonding Request Limits Furthermore, the network itself may limit the number of unbonding (unstaking) requests that a Validator can make per day, for similar reasons behind the Cooldown Period. # Liquid Staking ## Introduction to Liquid Staking Liquid Staking is the process by which users can pool their Gas Tokens together for network staking, thereby collectively surpassing the minimum required amount of tokens to participate in staking. At the same time, those users can participate in other network activities such as DeFi, gaming, and more. ## Benefits of Liquid Staking ### Increased access Traditional staking often requires a minimum staking amount, which can be prohibitive for users with limited capital. Liquid Staking Tokens (LSTs) enable fractional ownership of staked assets. LSTs allow users to stake any portion of their Gas Tokens, even if they don't have enough to meet the minimum requirement of a particular staking protocol. Users can do this by pooling their tokens together with other users in order to meet the minimum staking requirements of the blockchain. By doing this, users earn staking rewards proportionally to their contribution. ### Simplified staking Participation in network staking & validation traditionally requires users to have the extensive technical knowledge and infrastructure setup capabilities required to set up a Validator. Liquid Staking Protocols allow any user to access staking services simply by interacting with contracts on the blockchain. This shortens, simplifies, and abstracts the process of staking. This is achieved by leveraging providers that offer Staking-as-a-Service. These providers take care of the technical complexities of running Validators. ### Mutual benefits This is a symbiotic relationship. The Liquid Staking Protocol provides Validators with access to mass amounts of Gas Tokens to use for staking. In return, the Validators facilitate network staking and take a commission fee on the yield generated before passing it back through the protocol to users. ### Simultaneous liquidity and yield LSTs represent direct ownership of staked Gas Tokens. Because of this, they can be considered "fully backed" by the Gas Tokens of the network. LSTs themselves are also fungible, so they can be used to participate in other network activities such as DeFi, gaming, lending, and more while simultaneously accruing value from the yield generated by the staked Gas Tokens they represent. #### Composable Yield Because LSTs are liquid representations of yield-bearing staked Gas Tokens, they can themselves earn yield when used for DeFi activities such as lending. Thus, holders of LSTs have the potential to earn yield twice on the same underlying assets. # Kintsu on Monad The Kintsu Liquid Staking protocol automates the process by which users can pool their MON tokens together for network staking via non-custodial smart contracts. By leveraging a decentralized Registry of Validators controlled by the DAO, Kintsu creates sMON, a liquid version of the core MON gas token. As a ERC-20 token, sMON can be used in DeFi and other on-chain uses cases, while the underlying MON is natively staked to earn rewards and secure the Monad network while simultaneously empowering the community to Stake & Use. In addition to being liquid, unlike native staking, the super power of Kintsu and other Liquid Staking protocols is in their composability. This means that developers of novel on-chain use cases and the community as a whole can hold sMON to stake, or collateralize it in other protocols so you don't need to forgo staking rewards while you DeFi. Further, collectively the Kintsu protocol surpasses the minimum required amount of tokens to participate in staking, so there is no minimum stake to participate. No more "you must be this tall to ride." At the same time, those users can participate in other network activities such as DeFi, gaming, and more. # Kintsu on Hyperliquid The Kintsu Liquid Staking protocol automates the process by which users can pool their HYPE tokens together for network staking via non-custodial smart contracts. By leveraging a decentralized Registry of Validators controlled by the DAO, Kintsu creates sHYPE, a liquid version of the core HYPE gas token. As a ERC-20 token, sHYPE can be used in DeFi and other on-chain uses cases, while the underlying HYPE is natively staked to earn rewards and secure the Hyperliquid network while simultaneously empowering the community to Stake & Use. In addition to being liquid, unlike native staking, the super power of Kintsu and other Liquid Staking protocols is in their composability. This means that developers of novel on-chain use cases and the community as a whole can hold sHYPE to stake, or collateralize it in other protocols so you don't need to forgo staking rewards while you DeFi. Users can participate in other network activities such as DeFi, gaming, and more. # How It Works Protocol Architecture & Functionality ## Mission Kintsu is a [Liquid Staking Protocol](/overview/liquid-staking). Our mission is to boost the GDP of Proof-of-Stake blockchains by allowing users to participate in on-chain activities while also benefitting from the yield-bearing staking that secures the blockchain. We do this by providing stakers with a liquid token which is backed by the blockchain's staked native gas tokens. We call this a Liquid Staking Token, abbreviated as `LST` . {% hint style="info" %} **Note:** Kintsu refers to its LSTs as "sTokens". For example, the Gas Token of Monad is MON, and the LST of Kintsu on Monad is sMON. {% endhint %} ## How it works Kintsu improves on [Delegated Proof-of-Stake](/overview/proof-of-stake-blockchains#delegated-proof-of-stake-dpos) by allowing users to participate without themselves having to find and choose a validator to which to delegate. To accomplish this, Kintsu pools users’ Gas Tokens together and delegates them across a set of participating network [Validators](/overview/proof-of-stake-blockchains#staking-and-validators) for staking, and gives those users sTokens (the collateral) that can be used to redeem their staked Gas Tokens at any time. The protocol maintains a decentralized list of participating validators, routes staking requests to them, and facilitates redemption requests on behalf of the user. # Staking and Unstaking with Kintsu How to Stake, Un-stake, and earn yield with Kintsu ## Staking with Kintsu When a user stakes tokens with the Kintsu protocol, the experience is as follows: 1. User initiates a `stake` transaction, in which they submit Gas Tokens (e.g. MON or HYPE, depending on the connected network) to the Kintsu staking pool (a.k.a. the Vault). 2. User receives sTokens as receipt tokens. The amount received depends on the current [Redemption Ratio](/the-kintsu-protocol/definitions), which can be seen on the Kintsu website beforehand. {% hint style="info" %} For example, if the current Redemption Ratio is 1.1 GAS for every sGAS, then a user who stakes 11 GAS will receive 10 sGAS from the Vault. {% endhint %} sTokens tokens are fungible, and can be traded on [DEXes](/the-kintsu-protocol/definitions) or used as a proxy for Gas Tokens in other activities on the blockchain, such as DeFi applications, Gaming, NFTs, and more. For more technical information on how staking works behind the scenes, see Kintsu's docs on the [**Staking Mechanism**](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/staking-and-un-staking-mechanisms#staking-mechanism). *** ## Unstaking with Kintsu Users can exchange their sTokens (e.g. sMON or sHYPE) for Gas Tokens (e.g. MON or HYPE) tokens from the protocol. The number of Gas Tokens received depends on the [Redemption Ratio](/the-kintsu-protocol/definitions) at that time, with respect to the number of sTokens they submit for redemption. {% hint style="info" %} For example, if the current Redemption Ratio is 1.1 GAS for every sGAS, then a user who submits 10 sGAS will receive 11 GAS from the Vault. {% endhint %} It's important to note that when using Liquid Staking, there will be a delay between the time that a user requests to unstake sTokens and when they actually receive the Gas Tokens. There are a few reasons for this, including native unstaking delays built into, and enforced by, the blockchain itself. The user experience is as follows: 1. **Initiation:** User executes an unstaking request, specifying *either* how many sTokens they'd like to submit, *or* how many Gas Tokens they'd like to receive. 2. **Cooldown Period:** Once the unbonding request is sent to the Validators, the users must wait for the [Cooldown Period](/overview/proof-of-stake-blockchains#cooldown-period). This is enforced by the blockchain itself, and there is no way around it. 3. **Redemption:** Once the Cooldown Period is over, the user can redeem their Gas Tokens to their wallet. For more detailed technical information on how this process works, see Kintsu's docs on the [**Unstaking Mechanism**](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/staking-and-un-staking-mechanisms#unstaking-mechanism)**.** # Earning Yield How Kintsu's reward-bearing sMON token facilitates yield back to stakers. ## Kintsu LSTs' reward-bearing design Liquid Staking Tokens (LSTs) distribute staking rewards through two main approaches: **reward-bearing tokens** and **rebasing tokens**. {% hint style="success" %} sMON and sHYPE are both reward-bearing tokens. {% endhint %} Reward-bearing tokens maintain a fixed supply while their value grows through earned rewards. As staking rewards accumulate, each sToken token's value increases while your sToken token balance remains unchanged. **Key Characteristics**: 1. **Fixed Supply**: Your token balance remains unchanged 2. **Value Growth**: Each sToken's value increases relative to its corresponding Gas Token with accumulated rewards 3. **Composability:** Since the supply is fixed, sTokens offer superior integration capabilities with DeFi protocols across the ecosystem. ### Rebasing Tokens Rebasing tokens automatically adjust their total supply to reflect earned rewards and market conditions. When the protocol earns staking rewards, it increases the token supply proportionally, automatically crediting additional tokens to holders' wallets without requiring new deposits. The downside of this is that rebasing tokens cannot be easily integrated into DeFi protocols, because their supply is not fixed. Kintsu therefore does not use this model. ## sMON Yield Example Each [Era](/the-kintsu-protocol/definitions), there is a certain fixed amount of yield generated by the network in the form of newly generated MON tokens. The rate of yield is set by the network. The yield accrues to the Validators, which must return it back to the Vault. This part is enforced by a mixture of Kintsu's smart contracts and blockchain-native mechanisms. However, while the number of MON in the Kintsu staking pool (the Vault) increases, the number of outstanding sMON does not. Remember, sMON represent a share of the Total Pool of MON ([`totalPooled`](/the-kintsu-protocol/definitions)) controlled by the Vault. So, when the user redeems their sMON for MON, they will receive more MON than they originally deposited. {% hint style="info" %} Here's a \**very\** simple example: 1. At the beginning the Vault contains 0 MON (`totalPooled` = 0) and there are 0 sMON outstanding (`totalShares` = 0) 2. A user deposits (stakes) 10 MON. The Vault mints 10 sMON and transfers them to the user. 3. Now, the user waits. Over a period of time, the staked MON accrue yield in the form of additional MON. 1. Let's say for simplicity that the tokens accrued a 10% yield over that time.Comment 2. Let's also say for simplicity's sake that no other users deposit any MON for staking, and of course no other user redeems any tokens. 4. At this point, the `totalShares` still = 10 sMON. However, due to the 10% yield accrued, the `totalPooled` now equals 11 MON. 5. Now, the user redeems all 10 of their sMON for MON. They receive 11 MON in return. 1. Note that after this step, the Vault's `totalShares` = 0 again and `totalPooled` = 0 again as well. {% endhint %} This was a very simplified example. It doesn't account for any Protocol fees, and it doesn't account for other users staking and unstaking their tokens over time. However, it illustrates well the mechanism by which Kintsu helps users generate yield on their tokens. The example shows how yield came from the network's natural rate of MON inflation, and Kintsu helped the user access it easily. ## Composable Yield Kintsu's sTokens are fungible, and therefore allow users to participate in other network activities, such as DeFi. Many DeFi products allow users to earn additional yield through processes of lending, trading, and more. So, users who use sTokens to earn yield in DeFi can *also* take advantage of the network's natural staking yield at the same time. This is what we call composable yield. # Definitions Terminology for the Kintsu Protocol * **Gas Token:** The native token for a given blockchain. For example, the Gas Token on Monad is MON. For more info, please review the page on [Proof-of-Stake Blockchains](/overview/proof-of-stake-blockchains). * **sToken**: A general form for Liquid Staking Tokens. sTokens are fungible, can be traded and used elsewhere on the network, and can be used to redeem Gas Tokens during the unstaking process. * **sMON**: Kintsu's Liquid Staking Tokens on Monad. sMON serve as a receipt entitling the holder to their share of the `Total Pool` in the `Vault`. sMON tokens are fungible, can be traded and used elsewhere on the network, and can be used to redeem MON during the unstaking process. * **sHYPE:** Kintsu's Liquid Staking Tokens on Hyperliquid. sHYPE serve as a receipt entitling the holder to their share of the `Total Pool` in the `Vault`. sHYPE tokens are fungible, can be traded and used elsewhere on the network, and can be used to redeem HYPE during the unstaking process. * **Validator**: an entity on the blockchain that stakes Gas Tokens (MON), validates transactions on behalf of the network, and is rewarded with yield on their Gas Tokens in return for the service. For more information, see [Proof-of-Stake Blockchains](/overview/proof-of-stake-blockchains#staking-and-validators). * **DEX:** Abbreviation for a [Decentralized Exhange.](https://en.wikipedia.org/wiki/Decentralized_finance#Decentralized_exchanges) * **Bonding / Unbonding:** A process by which tokens can be "frozen" in exchange for some other benefit. This is commonly used to refer to the process by which the blockchain locks tokens up, or unlocks them, during the staking process. It can sometimes be used interchangeably with the terms "staking" and "unstaking". * **Delegation (aka Nomination):** Also sometimes referred to as "nomination", this is the process by which a user "delegates" another entity to do something on their behalf. In the case of Liquid Staking, users can "delegate" a "Delegation/Nomination Pool" to stake their tokens on their behalf with a Validator. Note that Kintsu does not use Nomination Pools, but rather nominates directly yo Validators. * **Total Pooled:** The sum of all Gas Tokens currently deposited in a Kintsu [`Vault`](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract#the-vault-contract), plus all yield that has been compounded during network staking. * **Total Shares:** Denotes the total outstanding supply of sTokens plus the number of Virtual Shares eligible to be claimed by the DAO. * **Total Virtual Shares:** This represents the revenue entitled to the DAO. It denotes the number of sTokens that are eligible to be minted during the **DAO Revenue Redemption Process**. These are tracked on the `Vault`. * **Total Shares Minted:** The total outstanding supply of sTokens on a given network. sTokens are minted during the [staking process](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/staking-and-un-staking-mechanisms#staking-mechanism) and are burned during the [unstaking process](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/staking-and-un-staking-mechanisms#unstaking-mechanism). * **Redemption Ratio:** This is the ratio of `totalPooled` / `totalShares`. This ratio can be calculated at any time and is used to inform how many Gas Tokens can be redeemed by a user for each sTokens token they submit during the [un-staking ](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/staking-and-un-staking-mechanisms#unstaking)process. This ratio can also be used by market makers to keep exchange rates honest on [DEXes](/the-kintsu-protocol/definitions). Note: the Redemption Ratio is not stored as a variable, however the `Vault` contract contains methods to calculate it in both directions (e.g. from sMON to MON, or sHYPE to HYPE, and vice versa). * **Era:** A blockchain-native construct denoting the period that the Validator set (and each Validator's active delegator or nominator set) is recalculated and where staking rewards are paid out to Validators. * **Batch**: A lump sum of unlock requests that are sent to to validators according to current stake imbalances. On Hyperliquid, batching is used for both bonding and unbonding. # Architecture & Integration Technical architecture, core pieces, and system processes of Kintsu on Aleph Zero ## Protocol Architecture {% content-ref url="/pages/3ODbPdykiH3W0vgnOyRs" %} [Monad LST Architecture](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture) {% endcontent-ref %} {% content-ref url="/pages/CylA5UcmjXSCihoeNr5Q" %} [Hyperliquid LST Architecture](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture) {% endcontent-ref %} # Monad LST Architecture ## Protocol Architecture on Monad The Kintsu Protocol operates as a series of interconnected Smart Contracts deployed on the blockchain. Each of these contracts serves a specific function of the protocol. ## Core Protocol Smart Contracts The core smart contracts that make up the Kintsu protocol are the [`Vault Contract`](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract#the-vault-contract) and the [`Registry Contract`](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract#the-registry-contract). The function of each of these are detailed in the following page: {% content-ref url="/pages/q5mo56VdNtqsxdVxJ6Fb" %} [StakedMonad Contract](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract) {% endcontent-ref %} ## **Staking and Un-staking** These are the mechanisms behind the core actions available to protocol users. In addition, the protocol itself executes certain processes behind the scenes in order to fulfill the desired functionality. {% content-ref url="/pages/aEoP22K7X91V8gtxh7HI" %} [Staking and Un-staking Mechanisms](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/staking-and-un-staking-mechanisms) {% endcontent-ref %} ## **Community Actions** These are actions that are necessary for the protocol to function as designed, and any community member can execute them. They may offer incentives to community members to assist in running the protocol. They do not require staking or un-staking of individual tokens. {% content-ref url="/pages/0abwSlOZlFU6RYxNGLn1" %} [Community Actions](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/community-actions) {% endcontent-ref %} # StakedMonad Contract This is the core contract for the protocol, and implements the Vault (a.k.a. the Kintsu stake pool). ## Overview The `StakedMonad` contract - also known as the "vault" or the "Kintsu stake pool" - sits at the heart of the Kintsu Liquid Staking process. This contract is the user-facing entry point to the Kintsu Protocol, and serves a number of functions: 1. **Core functionality:** The `StakedMonad` contract is the core contract of the sMON token. It is an ERC-20 token contract with extended functionality. 2. **User entry point:** The `StakedMonad` contract is the user-facing interface to the protocol. Users who want to participate in staking yield can deposit MON to the `StakedMonad` contract and receive sMON tokens in return. Users can also request to redeem their sMON for staked MON along with their pro-rata share of the yield accrued by the protocol. 3. **Orchestrates staking delegation & redemption:** The `StakedMonad` contract delegates staking tokens to, and interfaces with, [Validators](/overview/proof-of-stake-blockchains#staking-and-validators), according to the [Target Weights](#target-weights) . This is done using Kintsu's [Constant Retargeting Algorithm](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/staking-and-un-staking-mechanisms#constant-regargeting-algorithm). 4. **Calculates Protocol Fees:** The `StakedMonad` contract calculates and stores [Virtual Shares](/the-kintsu-protocol/definitions) used to facilitate protocol Management Fees. For more information, see the docs on Governance & Management Fees. 5. **Inherits the Registry Interface:** The `Registry` interface maintains a list of [Validators](/overview/proof-of-stake-blockchains#staking-and-validators) that are actively participating in the Kintsu protocol, along with a set of Target Weights for allocation of staked MON to those Validators. {% hint style="info" %} Note: the Redemption Ratio is not stored as a variable, however the `StakedMonad` contract contains methods to calculate it in both directions (from sMON to MON, and vice versa). {% endhint %} ### Registry Interface Variables #### Target Weights These weights represent the target percentage of the total amount of staked MON allocated to each Validator. These target weights are meant to uphold decentralization of the protocol, and will be controlled by Governance in a decentralized way. # 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. **MON Deposit:** User deposits MON into the [`StakedMonad`](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract#the-vault-contract) contract by initiating a `stake` transaction. 2. **Validator Forwarding:** During stake, `delegateBondingto` is called, retrieving the current [Target Weights](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/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](/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](/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:
$$newShares = newStake \* (totalShares/totalPooled)$$
where *newStake* is the number of newly deposited MON, *totalShares* is the [Total Shares](/the-kintsu-protocol/definitions) and *totalPooled* is the [Total Pooled](/the-kintsu-protocol/definitions). To see how this translates into a user's experience staking on Kintsu, see our docs on [Staking with Kintsu](/the-kintsu-protocol/staking-and-unstaking-with-kintsu#staking-with-kintsu). ### Constant Retargeting Algorithm As the [Vault](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/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](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract#target-weights) stored in the [Registry](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/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). ### Unstaking Order of Operations Unstaking on Kintsu involves the following order of operations: 1. **Initiation:** User calls [Request Unlock](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/contract-interface-abi-and-functions#unstaking-functions), during which they submit their sMON to the Vault. 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`](/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`](/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](/the-kintsu-protocol/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](/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. # 3rd Party Integration Guide ## Depositing and Redeeming sMON Tokens Interacting with the Kintsu Staked Monad (sMON) contract involves two primary actions: depositing native MON to receive sMON shares and redeeming sMON shares to receive MON back. This process incorporates a staking mechanism, a fee structure, and a batched unbonding process for redemptions. ### Depositing MON Users can deposit native MON into the [`StakedMonad`](https://docs.kintsu.xyz/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/pages/q5mo56VdNtqsxdVxJ6Fb#staked-monad-contract-a.k.a.-the-vault) contract to obtain sMON shares, which represent their proportional ownership of the total pooled MON within the protocol. There are two functions available for depositing: `deposit` and `mint`. Both are one-step processes which will immediately exchange MON for sMON tokens. * **`deposit(uint96, address receiver)`**: This is the standard deposit function adhering to the ERC7535/ERC4626 standard. When calling this function, the amount of MON to deposit is specified via `msg.value`. The `assets` parameter is present for standard compliance but is not directly used for the deposit amount (which comes from `msg.value`). The `receiver` address will receive the newly minted sMON shares. A crucial requirement is that the deposited amount (`msg.value`) must be greater than or equal to `MINIMUM_DEPOSIT`. * **`mint(uint96 shares, address receiver)`**: This function allows users to specify the *number of sMON shares* they wish to receive. The required amount of MON to send with the transaction (`msg.value`) is calculated based on the desired `shares` and the current redemption ratio (`convertToAssets`). The user must send at least this calculated amount of MON. Any excess MON sent will be refunded to the caller so 3rd parties must handle this refund. Similar to `deposit`, the required MON amount must meet the `MINIMUM_DEPOSIT`. Both deposit functions trigger an internal `_updateFees()` call to ensure the protocol fees are accounted for before calculating the redemption ratio and minting shares. A `Deposit` event is emitted upon successful completion. ### Redeeming sMON Redeeming sMON shares for native MON is a two-step process designed to manage the unbonding of staked assets from the underlying protocol. This process involves requesting an unlock, a waiting period, and then finally redeeming the MON. #### **Requesting an Unlock (`requestUnlock(uint96 shares)`)**: 1. Users initiate the redemption process by calling `requestUnlock`, specifying the amount of sMON `shares` they wish to redeem. 2. The specified sMON shares are transferred from the user to the StakedMonad contract. 3. The unlock request is added to a batch based on the current batch interval. The contract determines the `currentBatchUnlockId` based on the block timestamp and the `BATCH_INTERVAL_DELAY` from the `CREATION_TIME`. 4. The requested shares are added to the `batchUnlockRequests` mapping for the corresponding `batchId`. 5. Each user's unlock requests are tracked in the `userUnlockRequests` mapping, allowing a user to have multiple pending unlock requests. {% hint style="warning" %} **Important:** Shares requested for unlock are put in escrow and cannot be transferred or used for further staking. {% endhint %} #### **Sending Batch Unlock Requests (`sendBatchUnlockRequests(uint40[] calldata batchIds)`)**: 1. This function can be called by anyone, but is intended to be automated to process completed unlock request batches. 2. It takes an array of `batchIds` that are ready to be processed. These batch IDs must be in ascending order and must belong to past batch intervals (i.e., `batchId < currentBatchUnlockId`). 3. The function iterates through the provided batch IDs, calculates the total MON value (`aggregateSpotValue`) corresponding to the aggregated shares (`aggregateShares`) in those batches at the time of processing, based on the then-current redemption ratio. 4. The `batchUnlockRequests` for these batches are updated with the `spotValue` and `submissionTime` (the timestamp when the batch was sent for unbonding). 5. The total aggregated shares from the processed batches are burned from the contract's total supply. 6. The `_doUnbonding` function is called with the `aggregateSpotValue` to initiate the unbonding process with the underlying nodes, reducing the `totalPooled` amount. {% hint style="info" %} **Note:** This step continues the unbonding process but does not immediately return MON to the users. {% endhint %} #### **Redeeming Unlocked MON (`redeem(uint256 unlockIndex, address payable receiver)`)**: 1. Users can call this function to claim their unlocked MON after the `COOLDOWN_PERIOD` has passed since the `submissionTime` of the batch containing their unlock request. 2. The user specifies the `unlockIndex` corresponding to their specific unlock request within their `userUnlockRequests` array.\ The function checks that the specified `unlockIndex` is valid and that the batch associated with the request has been submitted (`batch.submissionTime > 0`) and the cooldown period has elapsed (`block.timestamp > batch.submissionTime + COOLDOWN_PERIOD`). 3. The amount of MON to redeem (`assets`) is calculated proportionally based on the user's shares in the batch and the `spotValue` recorded for that batch when it was sent for unbonding. 4. If the contract's current balance is less than the amount to be redeemed, the `_doWithdrawUnbonded()` function is called to attempt to claim unbonded MON from the nodes. 5. The user's specific unlock request is deleted from their `userUnlockRequests` array. 6. The calculated `assets` (MON) are transferred to the specified `receiver` address. #### Cancelling Unlock Requests (`cancelUnlockRequest(uint256 unlockIndex)`) Users have a limited window to cancel an unlock request. * A request can only be cancelled within the *same batch interval* in which it was originally sent. * The user specifies the `unlockIndex` of the request they wish to cancel. * The function verifies that the request exists and that the current batch ID matches the batch ID of the request. * The shares from the cancelled request are removed from the corresponding `batchUnlockRequests`. * The unlock request is deleted from the user's `userUnlockRequests` array. * The sMON shares are transferred back to the user. ## Key Considerations for Users * **Minimum Deposit:** Deposits must meet the `MINIMUM_DEPOSIT` requirement. * **Redemption is Two-Step:** Unlike some staking mechanisms, redemption is not instant. It requires requesting an unlock and then waiting for a cooldown period after the batch is processed. * **Batching:** Unlock requests are processed in batches. The timing of when a batch is sent for unbonding depends on external calls to the `sendBatchUnlockRequests` function. * **Cooldown Period:** After a batch is sent for unbonding, there is a `COOLDOWN_PERIOD` before the redeemed MON can be claimed. * **Cancellation Window:** Unlock requests can only be cancelled within the same batch interval they were initiated. The active batch can be found via the `getBatchUnlockIdAtTime` function. * **Slippage:** The value of sMON relative to MON can change between the time an unlock is requested (and the batch is sent) and the time it is redeemed, as the `spotValue` for the batch is fixed when the batch is sent. * **Node Performance:** The ability to redeem MON after the cooldown period is dependent on the underlying staking nodes successfully unbonding and returning the MON to the contract. The `_doWithdrawUnbonded` function is called during redemption if necessary to pull unbonded funds. {% hint style="success" %} Make sure to check out the `StakedMonad` [contract interface](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract#stakedmonad-contract-interface) for more details on how to interact with it. {% endhint %} # Contract Interface, ABI, & Functions Details on select functions, including previous versions when relevant. ## Contract Addresses {% content-ref url="/pages/ChnZYQvW2t24Ldq57dsX" %} [Official Contract Addresses](/the-kintsu-protocol/official-contract-addresses) {% endcontent-ref %} {% hint style="warning" %} Full ABIs can be found in our published npmjs package. These condensed interfaces contain the most important functions for integrating with the Kintsu core protocol. {% endhint %} ## StakedMonad Condensed Interface ```solidity // SPDX-License-Identifier: BUSL-1.1 pragma solidity 0.8.26; interface StakedMonad { struct Node { uint64 id; uint96 weight; uint96 staked; } struct UnlockRequest { /// @dev Number of shares the user will receive if the request is cancelled uint96 shares; /// @dev Value of the underlying asset that will be received upon redemption uint96 spotValue; /// @dev When this batch is submitted, redemption is available after withdraw delay uint40 batchId; /// @dev Store the exitFee (expressed in basis points) used for processing uint16 exitFeeInBips; } /** * @notice View all unique node ids in their current order * @dev The order is not guaranteed to remain constant between calls * @dev The order is not guaranteed to correlate to a position in `getNodes()` */ function getNodeIds() external view returns (uint256[] memory); /** * @notice View all nodes in their current order * @dev The order is not guaranteed to remain constant between calls */ function getNodes() external view returns (Node[] memory); /// @notice View a node by its unique node id function viewNodeByNodeId(uint64 nodeId) external view returns (Node memory node); /** * @notice Converts MON into LST shares at the current block timestamp * @dev `totalShares()` accounts for both minted and mintable shares */ function convertToShares(uint96 assets) external view returns (uint96 shares); /** * @notice Converts LST shares into MON at the current block timestamp * @notice Does not apply exit fee * @dev `totalShares()` accounts for both minted and mintable shares */ function convertToAssets(uint96 shares) external view returns (uint96 assets); /** * @notice Shares that could exist at the current block timestamp * @notice Includes both minted and mintable shares */ function totalShares() external view returns (uint96); function getAllUserUnlockRequests(address user) external view returns (UnlockRequest[] memory); function getExitFeeBips() external view returns (uint16); function getManagementFeeBips() external view returns (uint16); /// @notice Shares that could be minted by the protocol at the current block timestamp function getMintableProtocolShares() external view returns (uint96 shares); function calculateStakeDeltas(uint96 newTotalStaked) external view returns ( uint96 totalExcess, uint96 totalDeficit, uint96[] memory nodeExcesses, uint96[] memory nodeDeficits ); /** * @notice Deposit asset into the protocol and receive shares to represent your position * @notice Deposit amount must be specified by `msg.value` * @param minShares - Minimum quantity of shares that must be minted to prevent front running * @param receiver - Recipient of the minted shares * @return shares - Quantity of shares minted */ function deposit(uint96 minShares, address receiver) external payable returns (uint96 shares); /* * @notice Step 1 of 2 in process of withdrawing assets * @notice Transfers `shares` to the vault contract * @notice Unlock is batched into current batch request * @notice Applies exit fee if present */ function requestUnlock(uint96 shares, uint96 minSpotValue) external returns (uint96 spotValue); /** * @notice Allow user to cancel their unlock request * @notice Most users will have 1 concurrent unlock request (`unlockIndex` == 0) but advanced users may have more * @notice Must be done before the associated batch is submitted * @dev Order of unlock requests is not guaranteed between cancellations */ function cancelUnlockRequest(uint256 unlockIndex) external; /** * @notice Step 2 of 2 in process of withdrawing assets * @notice Associated batch must have been submitted and the cooldown period elapsed * @dev Might need to first call `sweep()` to make funds available * @dev Deletes the caller's unlock request */ function redeem(uint256 unlockIndex, address payable receiver) external returns (uint96 assets); /** * @notice Processes deposit and withdrawal requests and allocates MON according to Registry weights * @dev Might need to first call `sweep()` * @dev For a net ingress batch, the amount bonded may be less than the requested amount due to integer arithmetic. * The remaining amount, or 'dust' is scheduled to be bonded in the next batch. * @dev For a net egress batch, the amount unbonded may be less than the requested amount due to integer arithmetic. * The remaining amount, or 'dust' is scheduled to be unbonded in the next batch. * In this scenario, `totalPooled` is temporarily increased by this dust amount to account for the assets * that were requested to be unbonded but were not unbonded from nodes, ensuring they remain trackable * in the pool for the next attempt. */ function submitBatch() external; /** * @notice Withdraws MON from completed un-delegations * @notice Stores withdrawn funds in the contract to fund redemptions * @dev Required number of epochs must have passed since calling `undelegate` * @dev All withdrawals must be valid and complete or none will */ function sweep(uint64[] memory nodeIds, uint8 maxWithdrawsPerNode) external; /** * @notice Withdraws MON from completed un-delegations of disabled nodes * @notice Adds withdrawn funds into the current batch to be redelegated * @dev Required number of epochs must have passed since calling `undelegate` * @dev All withdrawals must be valid and complete or none will */ function sweepForced(uint64[] memory nodeIds) external; /** * @notice Claims all claimable rewards and adds them to the next batch * @dev Specifying an invalid node id will revert */ function compound(uint64[] memory nodeIds) external; /** * @notice Allows external funds to be added without minting shares * @dev Restricts usage when total pooled is below a threshold to prevent share inflation attacks * @param benefactor - Address used for tracking who is responsible for the contribution */ function contributeToPool(address benefactor) external payable; } ``` ## StakedMonad contract ABI {% file src="/files/Z3ZnJhfOkRUv6IS5My7n" %} # Community Actions ## Compounding As staking rewards are generated by Validators, the newly created MON tokens sit in an unclaimed state at the network level until the Validator claims them and re-bonds them. Any community member can execute a [`compound`](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/contract-interface-abi-and-functions#community-functions) transaction with the [`StakedMonad`](/the-kintsu-protocol/architecture-and-integration/monad-lst-architecture/stakedmonad-contract) contract. This tells all of the participating Validators to claim then re-bond the claimed MON. This enables Kintsu to benefit from compounding yield rewards, and can happen at most once per [Era](/overview/proof-of-stake-blockchains#staking-at-the-network-level). # Hyperliquid LST Architecture ## Protocol Architecture on Hyperliquid The Kintsu Protocol operates as a series of interconnected Smart Contracts deployed on the blockchain. Each of these contracts serves a specific function of the protocol. ## Core Protocol Smart Contracts The core smart contracts that make up the Kintsu protocol are the `StakedHype` Contract (manages the Vault and the Validator registry) and the `sHYPE` contract (ERC-20 token). The function of the `StakedHype` contract is detailed in the following page: {% content-ref url="/pages/HA0wH1vUUpcPBFW9TIDR" %} [StakedHype Contract](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/stakedhype-contract) {% endcontent-ref %} ## **Staking and Un-staking on Hyperliquid** These are the mechanisms behind the core actions available to protocol users. In addition, the protocol itself executes certain processes behind the scenes in order to fulfill the desired functionality. {% content-ref url="/pages/PjBKbcv6lOto8t63RdOe" %} [Staking and Un-staking Mechanisms](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/staking-and-un-staking-mechanisms) {% endcontent-ref %} ## Integration Guide {% content-ref url="/pages/AYXu8hFwy6MScPBp9yKR" %} [3rd Party Integration Guide](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/3rd-party-integration-guide) {% endcontent-ref %} ## StakedHype Interface A condensed interface containing the most important functions for integrating with the Kintsu core protocol on Hyperliquid. {% content-ref url="/pages/zRzNEIv1AZY2SPf8JHfg" %} [Contract Interface, ABI, & Functions](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions) {% endcontent-ref %} ## **Community Actions** These are actions that are necessary for the protocol to function as designed, and any community member can execute them. They may offer incentives to community members to assist in running the protocol. They do not require staking or un-staking of individual tokens. {% content-ref url="/pages/NGwUOCKli2hwgD30Tnti" %} [Community Actions](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/community-actions) {% endcontent-ref %} # StakedHype Contract This is the core contract for the protocol on HyperEVM, and implements the Kintsu Vault (a.k.a. the Kintsu stake pool on Hyperliquid). ## Overview The `StakedHype` contract - also known as the "vault" or the "Kintsu stake pool" - sits at the heart of the Kintsu Liquid Staking process. This contract is the user-facing entry point to the Kintsu Protocol, and serves a number of functions: 1. **User entry point:** The `StakedHype` contract is the user-facing interface to the protocol. Users who want to participate in staking yield can deposit HYPE to the `StakedHype` contract and receive sHYPE tokens in return. Users can also request to redeem their sHYPE for staked HYPE along with their pro-rata share of the yield accrued by the protocol. 2. **Orchestrates staking delegation & redemption:** The `StakedHype` contract delegates staking tokens to, and interfaces with, [Validators](/overview/proof-of-stake-blockchains#staking-and-validators), according to the [Target Weights](#target-weights) . This is done using Kintsu's [Constant Retargeting Algorithm](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/staking-and-un-staking-mechanisms). 3. **Calculates Protocol Fees:** The `StakedHype` contract calculates and stores [Virtual Shares](/the-kintsu-protocol/definitions) used to facilitate protocol Management Fees. For more information, see the docs on Governance & Management Fees. 4. **Inherits the Registry Interface:** The `Registry` interface maintains a list of [Validators](/overview/proof-of-stake-blockchains#staking-and-validators) that are actively participating in the Kintsu protocol, along with a set of Target Weights for allocation of staked HYPE to those Validators. {% hint style="info" %} Note: the Redemption Ratio is not stored as a variable, however the `StakedHype` contract contains methods to calculate it in both directions (from sHYPE to HYPE, and vice versa). {% endhint %} ### Registry Interface Variables #### Target Weights These weights represent the target percentage of the total amount of staked HYPE allocated to each validator. These target weights are meant to uphold decentralization of the protocol, and will be controlled by Governance in a decentralized way. # 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`](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/stakedhype-contract) 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](/the-kintsu-protocol/definitions), and transfers them to the user. These sHYPE serve as a receipt entitling the holder to their share of the [Total Pooled](/the-kintsu-protocol/definitions). 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](/the-kintsu-protocol/definitions) and *`totalPooled`* is the [Total Pooled](/the-kintsu-protocol/definitions). 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](/the-kintsu-protocol/staking-and-unstaking-with-kintsu#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()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface), 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](/the-kintsu-protocol/definitions) after applying a nominal exit fee of `0.05%` (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](/overview/proof-of-stake-blockchains#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()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/community-actions#transfer-spot-balance-from-hypercore-to-vault) 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()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface) 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](/the-kintsu-protocol/staking-and-unstaking-with-kintsu#unstaking-with-kintsu). {% hint style="info" %} Note: Users can cancel their unstaking request anytime before their batch is executed by calling [cancelUnlockRequest()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface) {% endhint %} *** ### Batch submission The vault aggregates the deposit and unlock requests added in the current batch and then uses the [Constant Retargeting Algorithm](#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` precompile. Anyone can initiate the [submitBatch()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface) call to the `StakedHype` contract. {% hint style="info" %} Bonus: When the net outflow is zero, The unlock request(s) of that batch does not need to wait for the network induced cooldown period and they can immediately redeem their unlock request 🪄✨ {% endhint %} ### Constant Retargeting Algorithm As the [Vault](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/stakedhype-contract) 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](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/stakedhype-contract#target-weights) stored in the [Registry](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/stakedhype-contract#registry-interface-variables). 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. # 3rd Party Integration Guide ## Depositing and Redeeming sHYPE tokens Interacting with the Kintsu Staked HYPE contract involves two primary actions: depositing native HYPE to receive sHYPE shares and redeeming sHYPE shares to receive HYPE back. This process incorporates staking/unstaking using a batch mechanism and a fee structure. ### Depositing HYPE Users can deposit native HYPE into the [`StakedHype`](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/stakedhype-contract#overview) contract to obtain sHYPE shares, which represent their proportional ownership of the total pooled HYPE within the protocol. It is a one-step process which will immediately exchange HYPE for sHYPE tokens. * **`deposit(address receiver)`**: When calling this function, the amount of HYPE to deposit is specified via `msg.value`. The `receiver` address will receive the newly minted sHYPE shares. A crucial requirement is that the deposited amount (`msg.value`) must be greater than or equal to `MINIMUM_DEPOSIT` (= 0.01 HYPE). It triggers an internal `_updateFees()` call to ensure the protocol fees are accounted for before calculating the redemption ratio and minting shares. A `Deposit` event is emitted upon successful completion. ### Redeeming sHYPE Redeeming sHYPE shares for native HYPE is a two-step process designed to manage the unbonding of staked assets from the underlying protocol. This process involves requesting an unlock, a waiting period, and then finally redeeming the HYPE. #### **Requesting an Unlock (`requestUnlock(uint96 shares)`)**: 1. Users initiate the redemption process by calling `requestUnlock`, specifying the amount of sHYPE `shares` they wish to redeem. 2. The specified sHYPE shares are transferred from the user to the `StakedHype` contract. 3. The amount of HYPE to redeem (`assets`) is calculated based on the current redemption ratio post applying a nominal exit fee of `0.05%` (unless exempted). 4. The unlock request is added to the current batch. 5. The requested shares along with the spotValue are added to the `batchWithdrawRequests` mapping for the corresponding `batchId`. 6. Each user's unlock requests are tracked in the `userUnlockRequests` mapping, allowing a user to have multiple pending unlock requests. {% hint style="warning" %} **Important:** Shares requested for unlock are put in escrow and cannot be transferred or used for further staking. {% endhint %} #### **Redeeming Unlocked HYPE (`redeem(uint256 unlockIndex, address payable receiver)`)**: 1. Users can call this function to claim their unlocked HYPE after the `COOLDOWN_PERIOD` has passed since the `submissionTime` of the batch containing their unlock request. 2. The user specifies the `unlockIndex` corresponding to their specific unlock request within their `userUnlockRequests` array.\ The function checks that the specified `unlockIndex` is valid and that the batch associated with the request has been submitted (`batch.submissionTime > 0`) and the cooldown period has elapsed (`block.timestamp > batch.submissionTime + COOLDOWN_PERIOD`). 3. If the contract's current balance is less than the amount to be redeemed, `sweep()` needs to be called first to transfer spot balance from HyperCore to the Vault. 4. The user's specific unlock request is deleted from their `userUnlockRequests` array. 5. The pre-determined (at the time of unlock request) HYPE is transferred to the specified `receiver` address. #### Cancelling Unlock Requests (`cancelUnlockRequest(uint256 unlockIndex)`) Users have a limited window to cancel an unlock request. * A request can only be cancelled before its batch is send for execution. * The user specifies the `unlockIndex` of the request they wish to cancel. * The function verifies that the request exists and that the current batch ID matches the batch ID of the request. * The shares from the cancelled request are removed from the corresponding `batchUnlockRequests`. * The unlock request is deleted from the user's `userUnlockRequests` array. * The sHYPE shares are transferred back to the user. ## Key Considerations * **Minimum Deposit:** Deposits must meet the `MINIMUM_DEPOSIT (0.01 HYPE)` requirement. * **Redemption is Two-Step:** Unlike some staking mechanisms, redemption is not instant. It requires requesting an unlock and then waiting for a cooldown period after the batch is processed. * **Batching:** Deposit and Unlock requests are processed in batches. The timing of when a batch is sent for execution depends on external calls to the `submitBatch()` function. * **Cooldown Period:** After a batch is sent, there is a `COOLDOWN_PERIOD` before the redeemed HYPE can be claimed (NO cooldown period for a batch when its net outflow is zero). * **Cancellation Window:** Unlock requests can only be cancelled before its batch is send for execution. The current batch can be found via the `currentBatchId` function. {% hint style="success" %} Make sure to check out the `StakedHype` [contract interface](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface) for more details on how to interact with it. {% endhint %} # Contract Interface, ABI, & Functions Details on select functions, along with the full StakedHype contract interface. ## Contract Address {% content-ref url="/pages/ChnZYQvW2t24Ldq57dsX" %} [Official Contract Addresses](/the-kintsu-protocol/official-contract-addresses) {% endcontent-ref %} ## Condensed StakedHype Contract Interface {% hint style="warning" %} The full interface can be found in our published package. This condensed interface contains the most important functions for integrating with the Kintsu core protocol. {% endhint %} ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity 0.8.30; interface IStakedHype { struct UnlockRequest { /// @dev Number of shares the user will receive if the request is cancelled uint96 shares; /// @dev Value of the underlying asset that will be received upon redemption uint96 spotValue; /// @dev When this batch is completed, redemption is available uint40 batchId; /// @dev Store the exitFee (expressed in basis points) used for processing uint16 exitFeeInBips; } /// @notice Converts HYPE into LST shares at the current block timestamp /// @dev `totalShares()` accounts for both minted and mintable shares function convertToShares(uint96 assets) external view returns (uint96 shares); /// @notice Converts LST shares into HYPE at the current block timestamp /// @dev `totalShares()` accounts for both minted and mintable shares function convertToAssets(uint96 shares) external view returns (uint96 assets); /// @notice Deposit HYPE into the protocol and receive LST shares to represent your position /// @notice HYPE must be greater than the minimum stake (= 0.01 HYPE) /// @dev Deposit amount must be specified by `msg.value` /// @param receiver - Recipient of the minted shares /// @return shares - Quantity of shares minted function deposit(address receiver) external payable returns (uint96 shares); /// @notice Step 1 of 2 in process of withdrawing HYPE /// @notice Transfers LST specified in `shares` argument to the vault contract /// @notice Unlock is batched into current batch request function requestUnlock(uint96 shares) external; /// @notice Allow user to cancel their unlock request /// @notice Most users will have 1 concurrent unlock request (`unlockIndex` == 0) but advanced users may have more /// @notice Must be done before the associated batch is submitted /// @dev Order of unlock requests is not guaranteed between cancellations function cancelUnlockRequest(uint256 unlockIndex) external; /// @notice Step 2 of 2 in process of withdrawing HYPE /// @notice Returns original deposit amount plus interest /// @notice Transfers HYPE to the caller /// @notice Associated batch must have been submitted and the cooldown period elapsed /// @dev Might need to first call `sweep()` if liquidity on the EVM side is low /// @dev Deletes the caller's unlock request function redeem(uint256 unlockIndex, address payable receiver) external returns (uint96 assets); /// @notice Processes deposit and withdrawal requests and allocates HYPE according to Registry weights /// @notice When deposits outweigh withdrawals, no delay is enforced /// @notice When withdrawals outweigh deposits, a delay from `cooldowns` in enforced function submitBatch() external; /// @notice Bridges all available HYPE from HyperCore:Spot to HyperEVM function sweep() external; /// @notice Syncs the HyperEvm storage state with HyperCore staking values /// @dev Cannot be called immediately after submitting a batch /// @dev Updates `totalPooled` and `Registry.node[].staked` function syncStaking() external; /// @notice Shares that could exist at the current block timestamp /// @notice Includes both minted and mintable shares function totalShares() external view returns (uint96 shares); /// @notice Shares that could be minted by the protocol at the current block timestamp function mintableProtocolShares() external view returns (uint96 shares); function getAllUserUnlockRequests(address user) external view returns (UnlockRequest[] memory); } ``` ## StakedHype Contract ABI {% file src="/files/QyjihX2ICj8s7fTUY3BU" %} # Community Actions ## Compounding Hyperliquid staking protocol auto-compounds the accrued yield on HyperCore. To reflect this change in the Vault (on HyperEVM) and thereby update the [Redemption Ratio](/the-kintsu-protocol/definitions), Anyone can execute the [syncStaking()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface) call to sync the state with HyperCore. {% hint style="info" %} The Vault uses the `L1Read` module to read HyperCore state from the HyperEVM. {% endhint %} ## Submit Batch Anyone can execute the [submitBatch()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface) call to send the pending stake/unstake request(s) stored in the Vault to the HyperCore for processing. {% hint style="info" %} The Vault uses the `CoreWriter` module for HyperCore <> HyperEVM interaction. {% endhint %} ## Transfer spot balance from HyperCore to Vault Anyone can execute the [sweep()](/the-kintsu-protocol/architecture-and-integration/hyperliquid-lst-architecture/contract-interface-abi-and-functions#condensed-stakedhype-contract-interface) call to transfer the unstaked funds that have completed the unbonding cooldown period from HyperCore to the Vault (on HyperEVM). # DAO & Governance ## History & problem We've achieved strong product-market fit for liquid staking. The market capitalization of leading liquid staking providers now represents a significant portion—approaching 10%—of total gas in TVL. However, as Lido and Jito became dominant, concerns about centralization have risen. Traditional LSP DAO tokens lack control over stake delegation to validators, which poses risks of network centralization and compromised security. Instead, validator stake is delegated by a small centralized group of decision makers. Kintsu aims to solve this. ## Kintsu’s solution Kintsu’s governance features an on-chain validator registry that is fully controlled by the DAO. This decentralization creates a marketplace for validators to compete for stake delegation by offering the best rewards profiles. This ensures that: 1. **Insiders cannot centralize stake** delegation to a small group of validators. 2. **Validators compete for stake delegation** by offering the best yield and building trust with the community. ## Validator Registry as a marketplace There is no hand-picked favoritism on Kintsu. The Kintsu core protocol’s Liquid Staking Vault is an ERC-4626 style structure that delegates MON stake to each validator, targeting the overall weights reflected in Registry contract. Validator weights on the Registry are determined by DAO participants assigning their voting power to validators on the Registry. Staking deposits and withdrawals are routed to validators in a way that makes the Vault's delegation percentages gradually align with the allocations set by the Registry, using Kintsu's Constant Rebalancing Algorithm. The system avoids automatically unstaking and rebalancing percentages whenever weights change, as this would reduce total staked assets below 100% TVL and lower staking APRs. Instead, the vault gradually achieves target percentages from the Validator Registry by allocating new deposits to understaked validators and removing stake from over-allocated validators during withdrawals. This system allows all token stakers to control delegation weights in real-time, rather than relying on a multisig. As a result, Kintsu creates a marketplace where the DAO can select the most efficient node operators, turning the protocol into a true platform for validators. ## Voting power Governance participants’ voting power is based on the number of KSU tokens they have. One token equals one vote. This voting power is used in two ways: 1. **To vote on governance proposals** 2. **To assign validator registry weights:** The amount of stake each validator receives is proportional to their share of the total voting power allocated on the Registry. These weights are “live”, so they are reflected on the Registry contract immediately after a DAO participant updates their preferences. ## Dual-token solution ### The KSU Token KSU is the native governance token of Kintsu. ### The DAO NFT The DAO NFT acts as a user’s ticket to all things governance on Kintsu. A user can acquire KSU tokens and stake them into governance. When they do this, a new DAO NFT is created and the KSU tokens are staked into it. Users can unstake their KSU tokens by burning the NFT at any time. Governance participants (holders of a DAO NFT) can participate in governance activities including: 1. Voting on proposals 2. Assigning registry weights (controlling MON stake delegated to validators) 3. Making proposals 4. Earning yield on their staked KSU tokens ### KSU Staking Rewards Users earn yield on their KSU tokens when they’re staked into a Kintsu DAO NFT. ## DAO Treasury The DAO Treasury accumulates protocol management fees from staking rewards generated on Kintsu. The Treasury is owned by the governance contract on-chain. Governance can make proposals to use Treasury funds for things like grants, incentives, PoL, or any other reason they so choose, so long as the proposal passes a vote. ### Management fees The Kintsu protocol charges a small Management Fee for providing liquid staking services. This fee takes the form of sMON inflation. Each time a user stakes or unstakes, the [Virtual Shares](/the-kintsu-protocol/definitions) are updated on the `Vault`. These Virtual Shares are minted periodically, and go to the DAO's treasury. ## Governance Council Kintsu has a Governance Council that can act swiftly when needed. This council holds limited but crucial powers—including the ability to immediately disable validators on the Registry if they are found to be malicious actors. ## Governance Activities & Participation {% content-ref url="/pages/rJ3aYBsfIIvVHTfkpLSQ" %} [Governance Activities & Participation](/the-kintsu-protocol/dao-and-governance/governance-activities-and-participation) {% endcontent-ref %} # Governance Activities & Participation ## Decentralized Voting and Validator Stake Allocation Since governance participants control registry weights through their voting power, validators must earn delegation by offering competitive APYs and building trust with the community. Governance participants can exercise their voting power directly by voting on proposals and allocating their voting power to validators on the Registry. For proposals, one token equals one vote. For registry allocation, one token equals one vote as well. These are not mutually exclusive. For example, if a DAO participant holds 10,000 KSU tokens, they can allocate those 10,000 votes among up to 10 validators on the registry. They can also vote on proposals, with their choice carrying a weight of 10,000 votes. ## Delegation & Representation Certain DAO participants may choose to delegate their voting power to another, who acts as a Representative, to vote and allocate registry weights on their behalf. When this happens, a delegator will continue to earn staking rewards on their staked KSU tokens, but their chosen Representative will allocate their registry weight voting power and vote on proposals on the delegator’s behalf. For example, let’s say we have a delegating participant D who holds 10,000 KSU, and a representative participant R who holds 10,000 KSU. Participant D will earn staking rewards on their KSU, but won’t be able to vote on proposals or assign registry weights directly. Instead, participant R will vote on proposals, with their choice carrying a weight of 20,000 votes (the sum of their own 10,000 votes and the 10,000 votes that D delegated to them). Participant R will assign the full 20,000 weight across their chosen validators on the Registry. ## Representation rewards DAO NFT holders who choose to delegate their voting power to other representatives share a small slice of their KSU staking rewards with the representative that acts on their behalf. This provides a revenue incentive for Representative NFT holders to perform well, thus earning delegation from others. # Official Contract Addresses ## Monad {% tabs %} {% tab title="Mainnet" %}
ContractAddress
StakedMonad Vault0xA3227C5969757783154C60bF0bC1944180ed81B9
sMON (ERC20 Token)(same as above)
{% endtab %} {% tab title="Testnet" %}
ContractAddress
StakedMonad Vault0xe1d2439b75fb9746E7Bc6cB777Ae10AA7f7ef9c5
{% endtab %} {% endtabs %} ## Hyperliquid {% tabs %} {% tab title="Mainnet" %}
ContractAddress
StakedHype Vault0xDDC126c12F9F8DF5a6fC273f6D43C1E21b4d2945
sHYPE (ERC20 Token)0xBeF0142A0955a7d5dcCe5C2A13Fb84E332669D2d
{% endtab %} {% endtabs %} # Points Points leaderboard and user points data ## Get Points Leaderboard > Returns points leaderboard data with wallet addresses and their corresponding points.\ > \ > Can be filtered to specific addresses or return all addresses with pagination support.
```json {"openapi":"3.0.3","info":{"title":"Kintsu Public API","version":"1.0.0"},"tags":[{"name":"Points","description":"Points leaderboard and user points data"}],"servers":[{"url":"https://kintsu.xyz","description":"Production API server"}],"paths":{"/api/public/points":{"get":{"summary":"Get Points Leaderboard","description":"Returns points leaderboard data with wallet addresses and their corresponding points.\n\nCan be filtered to specific addresses or return all addresses with pagination support.\n","operationId":"getPointsLeaderboard","tags":["Points"],"parameters":[{"name":"addresses","in":"query","description":"Comma-separated list of wallet addresses to filter. \nFor a single address, provide one value. If omitted, returns all addresses.\n","required":false,"schema":{"type":"string"}},{"name":"limit","in":"query","description":"Maximum number of results to return per page","required":false,"schema":{"type":"integer","minimum":1,"maximum":1000,"default":100}},{"name":"page","in":"query","description":"Page number for pagination","required":false,"schema":{"type":"integer","minimum":1,"default":1}}],"responses":{"200":{"description":"Successful response","content":{"application/json":{"schema":{"type":"object","properties":{"data":{"type":"array","items":{"type":"object","properties":{"address":{"type":"string","description":"Wallet address (lowercase)"},"points":{"type":"number","description":"Total points for this address"}}}},"meta":{"type":"object","properties":{"total":{"type":"integer","description":"Number of results in this response"},"page":{"type":"integer","description":"Current page number"},"limit":{"type":"integer","description":"Results per page limit"},"filtered":{"type":"boolean","description":"Whether address filtering was applied"}}}}}}}},"400":{"description":"Bad request - Invalid address format","content":{"application/json":{"schema":{"$ref":"#/components/schemas/Error"}}}},"429":{"description":"Rate limit exceeded","content":{"application/json":{"schema":{"$ref":"#/components/schemas/Error"}}},"headers":{"X-RateLimit-Limit":{"description":"Request limit per window","schema":{"type":"string"}},"X-RateLimit-Window":{"description":"Time window for rate limit","schema":{"type":"string"}},"Retry-After":{"description":"Seconds to wait before retrying","schema":{"type":"integer"}}}},"500":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/Error"}}}}}}}},"components":{"schemas":{"Error":{"type":"object","properties":{"error":{"type":"string","description":"Error message"},"message":{"type":"string","description":"Additional error details"}},"required":["error"]}}}} ``` # APY sMON APY historical data ## Get sMON APY History > Returns historical APY (Annual Percentage Yield) data for Kintsu's sMON token.\ > \ > APY is calculated daily based on staking ratio changes. Data is sorted newest first.
```json {"openapi":"3.0.3","info":{"title":"Kintsu Public API","version":"1.0.0"},"tags":[{"name":"APY","description":"sMON APY historical data"}],"servers":[{"url":"https://kintsu.xyz","description":"Production API server"}],"paths":{"/api/public/apy":{"get":{"summary":"Get sMON APY History","description":"Returns historical APY (Annual Percentage Yield) data for Kintsu's sMON token.\n\nAPY is calculated daily based on staking ratio changes. Data is sorted newest first.\n","operationId":"getApyHistory","tags":["APY"],"parameters":[{"name":"days","in":"query","description":"Number of days of historical APY data to return","required":false,"schema":{"type":"integer","minimum":1,"maximum":365,"default":30}}],"responses":{"200":{"description":"Successful response","content":{"application/json":{"schema":{"type":"object","properties":{"data":{"type":"array","items":{"type":"object","properties":{"date":{"type":"string","format":"date","description":"Date in YYYY-MM-DD format"},"apy":{"type":"number","description":"APY as a decimal (e.g., 0.1254 = 12.54%)"},"apyFormatted":{"type":"string","description":"APY formatted as a percentage string"}}}},"meta":{"type":"object","properties":{"total":{"type":"integer","description":"Number of days of data returned"},"days":{"type":"integer","description":"Number of days requested"},"latestApy":{"type":"string","description":"Most recent APY value (formatted)"},"chainId":{"type":"integer","description":"Chain ID (always 143 - Monad Mainnet)"}}}}}}}},"404":{"description":"Insufficient data","content":{"application/json":{"schema":{"$ref":"#/components/schemas/Error"}}}},"429":{"description":"Rate limit exceeded","content":{"application/json":{"schema":{"$ref":"#/components/schemas/Error"}}},"headers":{"X-RateLimit-Limit":{"description":"Request limit per window","schema":{"type":"string"}},"X-RateLimit-Window":{"description":"Time window for rate limit","schema":{"type":"string"}},"Retry-After":{"description":"Seconds to wait before retrying","schema":{"type":"integer"}}}},"500":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/Error"}}}}}}}},"components":{"schemas":{"Error":{"type":"object","properties":{"error":{"type":"string","description":"Error message"},"message":{"type":"string","description":"Additional error details"}},"required":["error"]}}}} ``` # Community & Social Media We believe in building strong connections and fostering collaboration within our community. At Kintsu, we value the insights, contributions, and ideas from our users, partners, and supporters. There are several ways to connect with us, get involved, and stay up-to-date with the latest updates and developments in the Kintsu ecosystem. ## **Join our Community** Engage in meaningful discussions, share your thoughts, and stay connected with like-minded individuals who are passionate about the future of decentralized finance and liquid staked tokens. Join the discussion on our [Discord](https://discord.gg/kintsu)! ## Follow us on Social Media * **Twitter:** * **Discord:** * **Medium:** ## Contact our Team The following directory will provide you with the appropriate email for you to reach out to our team directly. We are eager to connect and our team will get back to you as soon as possible!
PurposeContact MethodEmail
General Inquirieshello@kintsu.xyz
# Contribute to Open Source Before going live with our open sourced code, we are building out the initial iteration of the Kintsu protocol using private repositories. Please check this page again once Kintsu goes live as open source contributions will then be possible. In the meantime, if you would like to be a part of the selective few who are building the foundation of Kintsu before going live, please fill out the following form for our team to review. We look forward to hearing from you! # Hackathons and Meetups We at Kintsu aim to foster a vibrant and collaborative community that thrives on innovation, learning, and networking. Join us to engage with like-minded individuals, expand your skills, and contribute to the exciting world of decentralized finance (DeFi). ### Hackathons Participating in hackathons is a fantastic way to showcase your creativity, problem-solving abilities, and passion for blockchain technology. Our hackathons are designed to encourage developers, designers, and enthusiasts to explore the possibilities of Liquid Staked Tokens (LSTs) and build groundbreaking applications that leverage their power on Kintsu. ### Meetups Our meetups bring together individuals who are passionate about blockchain, DeFi, and the potential of Liquid Staked Tokens. These events provide a platform for networking, knowledge-sharing, and thought-provoking discussions. Whether you're a blockchain enthusiast, a developer, an investor, or simply curious about the technology, our meetups offer something for everyone. # Our Philosophy The team, mission, and values The following statements have been adopted by the Kintsu team and act as a driving force in all we do. Every decision that is made by the Kintsu team considers whether it helps achieve our mission & vision and if it is in line with our values. ## Mission Statement Our mission at Kintsu is to drive the next phase of decentralized finance, starting by developing liquid staked token (LST) protocols across zk-blockchain networks. Summarized well in his post titled, [The Three Transitions](https://vitalik.ca/general/2023/06/09/three_transitions.html), Vitalik talks about how blockchain will need to evolve to have trustless scalability, privacy, and a better user experience if we are going to achieve the lofty goals that make up the web3 movement as a whole. We build core infrastructure. With a strong focus on building, monetizing, and decentralizing open-source infrastructure, we are able to maximize our impact and continue doing the work we've set out to do. ## Vision Statement At Kintsu, our vision is to provide innovative solutions that enable users to seamlessly unlock the value of their staked assets and empower them to freely navigate between diverse blockchain networks, to access a wide range of DeFi applications, services, and opportunities. By expanding the reach of Liquid Staked Tokens and pioneering its interoperability, we envision a world where users can unlock the full potential of decentralized finance, fostering financial empowerment and inclusion on a global scale. ## Value Statement * **Innovation:** We are driven by a culture of innovation, continuously exploring new frontiers in blockchain technology and DeFi. We embrace novel concepts, push boundaries, and challenge the status quo to deliver cutting-edge solutions that transform the way users engage with decentralized finance. Our commitment to innovation fuels our pursuit of groundbreaking advancements and ensures that we remain at the forefront of the industry. * **Interoperability:** We recognize the importance of interoperability as the key to unlocking the true potential of decentralized finance. We are dedicated to building an interoperable protocol that facilitates seamless cross-chain interactions among LSTs, enabling users to transfer and utilize their staked assets across multiple blockchain networks. Our focus on interoperability aims to create a cohesive and interconnected DeFi ecosystem, where users can seamlessly access a myriad of opportunities regardless of the underlying blockchain. * **Empowerment:** We believe in the power of decentralized finance to empower individuals and communities worldwide. Our solutions are designed to provide users with greater control over their financial assets, enabling them to participate in DeFi activities, earn yields, and access financial services with ease. By expanding access to DeFi and fostering financial inclusion, we aim to empower individuals to take control of their financial future. * **Security and Trust:** The security and trust of our users are of paramount importance to us. We are committed to implementing robust security measures and industry best practices to ensure the safety of users' assets and data. We strive to create a high level of trust within the Kintsu community and the broader DeFi ecosystem, promoting transparency, accountability, and reliability in all our endeavors. * **Community Collaboration:** Our community is at the heart of everything we do. We value the input, engagement, and expertise of our community members and actively seek their involvement in shaping the future of Kintsu. We foster a collaborative environment that encourages open communication, feedback, and the co-creation of ideas. Together, we are building a strong and vibrant community-driven ecosystem that drives the advancement of DeFi. # Why We Build The motivation We are driven by a bold vision to revolutionize the way individuals engage with blockchain networks, staking protocols, and the broader decentralized finance (DeFi) ecosystem. Our passion lies in the creation of interoperable liquid staked tokens (LSTs) that transcend the boundaries of single blockchain networks and traditional staking limitations. Through this transformative approach, we aim to empower individuals, enhance financial accessibility, and shape a more inclusive and decentralized financial landscape. To achieve this, we engage in the following approaches: 1. **LST Research and Development:** Our team of experts is relentlessly exploring innovative solutions to unlock the value of staked assets and create a more dynamic and accessible staking experience. Through extensive research, rigorous testing, and constant iteration, we are pioneering advancements in staking protocols, liquidity mechanisms, and yield generation strategies. 2. **Community Engagement:** Community lies at the heart of Kintsu, and we believe in the power of collective action to drive positive change in the DeFi space. We actively engage with our community of innovators, builders, and enthusiasts in various ways, including hackathons, community meetups, and social platforms. We foster an inclusive and collaborative environment where ideas are shared, feedback is valued, and collaborations thrive. 3. **Education and Awareness:** By demystifying complex concepts and promoting best practices, we strive to equip our community with the knowledge they need to actively participate in the growing DeFi ecosystem. We engage in community discussions, host informative events, and collaborate with industry experts to facilitate a deeper understanding of the intricacies of cross-chain interoperable LSTs. 4. **Partnerships and Collaborations:** We recognize that collaboration is key to driving innovation and expanding the possibilities of DeFi. Kintsu actively seeks strategic partnerships with leading projects, platforms, and protocols that share our vision and values. Through these partnerships, we aim to foster interoperability, expand the reach of our solutions, and create synergies that unlock new opportunities for our users. ## Harnessing the Power of Liquid Staked Tokens Liquid Staked Tokens (LSTs), which are liquid tokens that represent a user's stake, have emerged as a powerful innovation in the blockchain space, revolutionizing the traditional concept of staking and unlocking new possibilities for token holders. With their unique features and advantages, these liquid tokens offer a range of benefits that enhance the user experience and enable broader participation in the decentralized finance (DeFi) ecosystem. Whether it's maximizing yield, enhancing liquidity, lending, gaming, or managing risk, Kintsu empowers users to navigate liquid staking with efficiency, flexibility, and security. Here are the advantages of LSTs and how Kintsu facilitates their utilization: 1. **Maximizing Yield:** Staking traditionally involves locking assets, and limiting their use in other financial activities. With LSTs, users can stake their tokens while simultaneously accessing the benefits of DeFi. Kintsu allows users to generate yield through lending, liquidity provision, yield farming, and other DeFi applications, maximizing their earning potential. 2. **Enhanced Liquidity:** Staked assets are typically illiquid, and it also has very limited risk. LSTs solve this challenge by creating a liquid representation of staked assets. Through Kintsu, users can obtain LSTs that maintain a 1:1 ratio with the staked tokens, allowing for seamless transfer, trading, and utilization across different platforms. Offering an elegantly decentralized base yield into the DeFi ecosystem allows the ecosystem to have the best of both worlds 3. **Security:** without staking, there is no network security. We need a significant token supply staked to efficiently process transactions, having a booming DeFi ecosystem shouldn't detract from that 4. **DeFi Accessibility:** Kintsu brings staked assets into the DeFi realm, enabling users to participate in a wide range of decentralized financial activities. Users can leverage their LSTs for lending, borrowing, providing liquidity on decentralized exchanges (DEXs), participating in yield farming, and engaging in other DeFi protocols. This opens up a world of opportunities for users to diversify their strategies and optimize their financial positions. 5. **Interoperability:** One of the key advantages of Kintsu is its ability to facilitate interoperability between different blockchain networks. By bridging the gaps between chains, Kintsu enables users to stake their tokens on one network and access DeFi opportunities on another. This seamless interoperability expands the reach and scope of LSTs, allowing users to leverage the strengths of multiple networks and tap into a wider range of DeFi services. 6. **Capital Efficiency:** With LSTs, users can unlock the value of their staked assets without sacrificing their staking rewards. Kintsu enables users to collateralize their LSTs and access lending markets, borrowing against their staked tokens to obtain additional liquidity. This capital efficiency empowers users to utilize their staked assets in productive ways while maintaining their staking positions. 7. **Risk Management:** The Kintsu protocol incorporates risk management mechanisms to protect users' assets. By diversifying staked assets across validators, Kintsu mitigates the risk associated with a single validator having poor uptime or high fees. Additionally, the protocol incorporates security measures and rigorous audits to ensure the safety of user funds and interactions with the DeFi ecosystem. 8. **Privacy Preservation:** Kintsu recognizes the importance of privacy in decentralized finance. The protocol incorporates privacy-preserving measures, safeguarding user information and transactional data. This allows users to engage in DeFi activities without compromising their privacy or exposing sensitive information to the public domain. 9. **Modularity:** products in web3 are more like hardware. Once deployed, they are very permanent. Upgradability is in itself a form of strong modularity, but the goal shouldn't ever be to replace the whole system. With plugin architectures, we are capable of designing systems that are intended to be built into and on top of. This provides both users and developers with a consistent platform to build with. Modularity of risk is also of paramount importance. It is important to note the specific crypto-economic factors that LSTs enable for broader access and utilization of the decentralized financial space. Unlike traditional staking models, the following features are made possible by adopting a liquid-staked model such as Kinstu protocol provides. 1. **Fractional Ownership:** LSTs enable fractional ownership of staked assets. Traditional staking often requires a minimum staking amount, which can be prohibitive for users with limited capital. LSTs allow users to stake any portion of their tokens, even if they don't have enough to meet the minimum requirement of a particular staking protocol. This fractional ownership model opens up staking opportunities to a broader range of users, regardless of their capital limitations. 2. **Pooling Mechanisms:** LSTs can leverage pooling mechanisms to aggregate smaller individual stakes into a larger collective stake. By pooling their resources together, users with limited capital can collectively meet the minimum staking requirements and participate in staking. Pooling mechanisms allow users to pool their tokens with others, combining their staking power and earning rewards proportionally to their contribution. This cooperative approach enables smaller holders to access the benefits of staking that would have otherwise been challenging to achieve individually. 3. **Staking Providers and Services:** LSTs are often facilitated by staking providers or platforms that offer staking-as-a-service. These providers cater to a wide range of users, including those with limited capital. They simplify the staking process, handle the technical complexities, and manage the infrastructure required for staking. By utilizing the services of these providers, users with smaller capital can benefit from staking without the need for extensive technical knowledge or significant capital investment. 4. **Lower Entry Barriers:** LSTs reduce the entry barriers for users with less capital to participate in staking. It is worth noting that this changes a lot from blockchain to blockchain. Traditional staking methods may require users to lock up a significant amount of tokens for an extended period, which can be financially burdensome for smaller holders. LSTs offer more flexibility in terms of staking duration and allow users to access their staked assets more easily. This lower entry barrier makes staking more accessible and attractive to users with limited capital, enabling them to participate and benefit from the staking rewards. ## The Future of LSTs with Kintsu As the Kintsu protocol continues to evolve and push the boundaries of liquid staked tokens (LSTs), the future holds exciting possibilities for users to unlock the full potential of their staked assets. Here are some envisioned use cases of what you will be able to do with Kintsu LSTs in the near future: 1. **Trading with LSTs** * With Kintsu LSTs, users will have the ability to trade their staked assets seamlessly and efficiently on decentralized exchanges (DEXs) and traditional cryptocurrency exchanges, allowing for increased market accessibility and potential trading opportunities. 2. **Providing Liquidity on a DEX** * Kintsu LSTs will enable users to participate in liquidity provision on decentralized exchanges. By providing their LSTs to liquidity pools, users can contribute to the depth and stability of trading pairs, earning fees in the process. This presents an opportunity for users to earn additional rewards while their staked assets remain actively participating in the staking process, maximizing their earning potential and overall capital efficiency. 3. **Lending Markets** * Kintsu LSTs will be instrumental in unlocking opportunities in lending markets. Users will be able to collateralize their LSTs and access lending platforms, borrowing against their staked tokens to obtain additional liquidity. This empowers users to utilize their staked assets as collateral without compromising their staking positions. Through lending markets, users can explore various financial strategies, such as leveraged trading or funding other investments, while their staked assets continue to earn staking rewards. 4. **Gaming** * The integration of Kintsu LSTs into gaming platforms opens up a whole new dimension of possibilities for gamers and blockchain enthusiasts. By utilizing LSTs, gamers can stake their assets to earn rewards and enhance their in-game experiences. Additionally, LSTs can serve as a bridge between gaming ecosystems and the broader DeFi space, enabling users to access decentralized financial services directly within gaming environments. This fusion of gaming and finance brings new incentives, monetization models, and economic opportunities to the gaming community. \ These envisioned use cases demonstrate the transformative power of Kintsu LSTs, where users can seamlessly trade, provide liquidity, participate in lending markets, and engage in gaming activities while their assets remain staked and actively earning rewards. As Kintsu continues to innovate and expand its ecosystem, even more diverse and exciting use cases for LSTs are expected to emerge, enabling users to shape the future of finance and redefine the possibilities within the decentralized ecosystem. 5. Rollup Services & Restaking * More to come... # FAQs ## Liquid Staking #### **What are Liquid Staked Tokens (LSTs)?** Liquid Staked Tokens (LSTs) represent ownership of staked assets, typically cryptocurrencies like Monad (MON). LSTs let users earn staking rewards while keeping their tokens liquid—meaning they can still use these tokens across the decentralized finance (DeFi) ecosystem. #### **What are the benefits of LSTs compared to traditional staking?** LSTs offer three key advantages over traditional staking: * Liquidity: Unlike traditional staking where tokens are locked up, LSTs let users freely transfer and use their tokens while earning staking rewards. * DeFi Integration: Users can stake their tokens and participate in DeFi activities like lending and trading at the same time, maximizing potential returns across platforms. * Capital Efficiency: Users can put their staked assets to work as collateral for borrowing or providing liquidity, making their capital work harder. #### How sMON earns yield sMON earns yield because it represents a share of the protocol’s pool of staked MON. When MON is staked with validators on the Monad blockchain, the staking rewards earned are added back to this pool. As the pool grows relative to the total supply of sMON, the value of each sMON increases. Additionally, sMON can be used in DeFi to earn extra yield beyond the staking rewards. #### Why is sMON not 1 MON? sMON represents staked MON and earns yield over time, which causes its value to increase relative to MON. The protocol uses an Exchange Rate to reflect the difference in supply, as MON staking rewards are added to the total pool of staked MON. This means that holding sMON gives users access to both their initial MON and the yield earned #### What do we mean by Composable Yield? Composable Yield means that sMON tokens, while earning staking rewards, can also be used across various DeFi protocols for activities like trading, lending, and gaming. Because sMON is fungible and fully backed by staked MON, it retains its value while being integrated into other protocols, allowing users to benefit from both staking rewards and additional DeFi returns. Holders can redeem sMON for MON at any time (subject to the network’s built-in redemption delay) or swap them for MON on a DEX. #### Can I unstake my MON at any time? Yes, you can unstake your MON at any time, but there is a built-in redemption delay period that you need to be aware of. This delay is a security feature designed to protect the network. During this period, your unstaking request is processed, and once completed, you'll receive your MON tokens back. Alternatively, if you need immediate liquidity, you can trade your sMON directly on supported DEXs without waiting for the unstaking period. ## Governance #### Governance tokens vs. DAO NFTs Kintsu’s governance system uses both KSU tokens and DAO NFTs. Users stake their KSU tokens into a DAO NFT, which grants them the ability to participate in governance. DAO NFTs add a layer of security against double voting and serve as a mechanism for delegation in representative-based voting. This model ensures that governance remains decentralized, secure, and flexible for participants. #### How governance delegation works If you hold KSU tokens but don’t want to vote directly on every proposal, you can delegate your voting power to someone else who will vote on your behalf. You’ll still own your KSU tokens and keep earning rewards, while the representative you choose manages your votes. This is a great way to stay involved in governance without needing to actively participate in every decision. Representatives may also earn a small portion of the rewards as an incentive for acting on behalf of delegators. #### How proposals work If you want to create a proposal, you’ll need to have a minimum amount of KSU staked in your DAO NFT. Once you submit a proposal, other participants vote on it using their staked KSU. If the proposal reaches the required approval threshold, it gets implemented. Proposals can cover a wide range of topics, from protocol upgrades to fee changes, allowing the community to help shape the future of the protocol. ## Validators #### Becoming a validator To become a validator, you’ll need to deposit both KSU and MON as collateral. Once you’ve done that, you can permissionlessly add yourself to the validator registry. After being added, KSU holders can allocate their registry voting weight to you. As they do, the protocol will start delegating stake to you based on the amount of voting weight you receive. This process ensures that only validators trusted by the community receive significant stake, helping maintain network security and decentralization. #### How are validators held accountable? Validators are held accountable through a combination of economic incentives, governance oversight, and swift action by the Governance Council. To join the validator registry, validators must deposit KSU and MON as collateral, which can be slashed (partially or fully seized) if they act maliciously or fail to meet performance standards. Governance participants can also monitor validators and adjust their voting weight allocation if a validator underperforms or violates protocol rules. Additionally, the Governance Council has the authority to quickly disable a bad-acting validator to protect the network, ensuring the protocol remains secure and reliable. #### Offboarding a validator You can offboard a validator intentionally. When you do this, the Vault will start to direct stake away from your validator as over time as tokens are staked and unstaked from the Vault. Once your validator reaches 0 stake allocation, you can remove it and redeem the collateral you put up for it. If you are honorably discharged as a validator by the Governance council, the same process applies. However, if you are dishonorably discharged by the Governance Council, you will forfeit the collateral. ## Community #### **How can I get involved with Kintsu?** There are several ways to get involved with Kintsu: 1. Stake MON: Participate in liquid staking by depositing your MON tokens to earn staking rewards while maintaining liquidity through sMON tokens. You can then use your sMON across various DeFi protocols for additional yield opportunities. 2. Participate in governance: Get involved in shaping the future of Kintsu by staking KSU tokens, voting on proposals, or delegating your voting power to trusted representatives. You can also create your own proposals once you meet the minimum staking requirement. 3. Become a Validator: Help secure the network by running a validator node. You'll need to deposit KSU and MON as collateral, and maintain high performance standards to earn rewards and build trust within the community. 4. Join the [Community](https://www.notion.so/o/sGUTtLVKgAG50kA2PBp3/s/MdICYXISKGqWUQXbHV5x/~/changes/102/community/community-and-social-media): Engage with the Kintsu community by participating in discussions, sharing ideas, and providing feedback. Connect with us through our official communication channels and stay up to date with the latest updates and announcements. 5. Contribute to [Development](https://www.notion.so/o/sGUTtLVKgAG50kA2PBp3/s/MdICYXISKGqWUQXbHV5x/~/changes/102/community/contribute-to-open-source): If you are a developer or have technical skills, you can contribute to the development of the Kintsu protocol. Check out our GitHub repository and explore opportunities to contribute code, provide feedback, or suggest improvements. #### **How can I report issues with the Kintsu platform?** Kintsu welcomes feedback and encourages community contributions to improve the platform. Join the official Kintsu [community](https://www.notion.so/o/sGUTtLVKgAG50kA2PBp3/s/MdICYXISKGqWUQXbHV5x/~/changes/102/community) forums and participate in discussions. #### **How can I stay updated with Kintsu's latest developments?** To stay informed about the latest news, updates, and developments from Kintsu, we recommend: 1. Following our official social media channels, such as Twitter, Discord, and Medium 2. Tracking our Gitbook 3. Checking our [Documentation](https://www.notion.so/o/sGUTtLVKgAG50kA2PBp3/s/MdICYXISKGqWUQXbHV5x/~/changes/102/), which is regularly updated. ## Security #### **Is Kintsu open-source?** Yes, Kintsu is an open-source project. We believe in the power of community collaboration and transparency. You can find our codebase and relevant documentation on our GitHub repository. #### While staking and using LSTs can provide various benefits, it's important to be aware of the potential risks involved. Some common risks include: 1. Volatility: The value of staked assets and LSTs can be subject to price fluctuations, which may result in gains or losses. 2. Security: As with any blockchain-based activity, there are inherent security risks. It's crucial to use secure wallets and follow best practices to protect your funds. 3. Smart Contract Risks: LSTs rely on smart contracts, and vulnerabilities or coding errors in these contracts can lead to financial losses. However, thorough security audits and best development practices mitigate these risks. #### **Is Kintsu's code audited for security?** Yes, ensuring the security of our users' funds and the integrity of our protocol is of utmost importance to us. Kintsu used pre-audited code from smart contract libraries such as Open Zeppelin. Additionally, the code will be open-sourced so the community is able to both [audit and contribute](https://www.notion.so/o/sGUTtLVKgAG50kA2PBp3/s/MdICYXISKGqWUQXbHV5x/~/changes/102/community/contribute-to-open-source). # Bug Reports If you have encountered a bug, we invite you to join the [Kintsu Discord](https://discord.gg/kintsu) and visit the "Feedback" channel. # Feature Requests We value the input and ideas of our community members, and we believe that collaboration is key to driving innovation in the decentralized finance (DeFi) space. We encourage you to share your thoughts on how we can enhance the Kintsu protocol and make it even more powerful and user-friendly. If you have suggestions for us, we invite you to join the [Kintsu Discord](https://discord.gg/kintsu) and visit the "Feedback" channel. # Support We value the input and ideas of our community members, and we're here to help anyone having with issues or questions about the protocol. If you need assistance, we invite you to join the [Kintsu Discord](https://discord.gg/CDG7sfVR) and visit the "Support" channel.