LogoLogo
  • Overview
    • Introduction
    • Proof-of-Stake Blockchains
    • Liquid Staking
  • Monad Blockchain
    • Liquid Staking on Monad
  • The Kintsu Protocol
    • How It Works
    • Staking and Unstaking with Kintsu
    • Earning Yield
    • Definitions
    • Architecture & Integration
      • Staking and Un-staking Mechanisms
      • StakedMonad Contract
      • 3rd Party Integration Guide
      • Contract Interface & Functions
      • Community Actions
    • Official Contract Addresses
  • Community
    • Community & Social Media
  • Development Team
    • Our Philosophy
    • Why We Build
  • Resources
    • Bug Reports
    • Feature Requests
    • Support
Powered by GitBook
LogoLogo
On this page
  • Overview
  • Registry Interface Variables
  1. The Kintsu Protocol
  2. Architecture & Integration

StakedMonad Contract

This is the core contract for the protocol, and implements the Vault (a.k.a. the Kintsu stake pool).

PreviousStaking and Un-staking MechanismsNext3rd Party Integration Guide

Last updated 1 day ago

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, , according to the . This is done using Kintsu's .

  4. Calculates Protocol Fees: The StakedMonad contract calculates and stores 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 that are actively participating in the Kintsu protocol, along with a set of Target Weights for allocation of staked MON to those Validators.

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).

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.

Virtual Shares
Target Weights
Constant Retargeting Algorithm
Validators
Validators