> ## Documentation Index > Fetch the complete documentation index at: https://docs.starknet.io/llms.txt > Use this file to discover all available pages before exploring further. # Staking ## Overview While Starknet is currently still centralized, it is [gradually](#roadmap) moving towards employing a [staking protocol](#protocol), handing over the responsibilities of producing, attesting, and proving blocks to validators. To facilitate this gradual implementation, the protocol's architecture is divided into several [components](#components), ensuring maximum flexibility and ease of upgrades. However, anyone holding STRK or BTC can already stake their tokens and earn rewards based on their level of participation by following [a few simple steps](#procedures). If you are only interested in learning how to stake on Starknet, feel free to skip straight to [Procedures](#procedures). Starting Q3 2025, Starknet's staking protocol enables BTC holders to lock their assets on Starknet and earn staking rewards in STRK, by supporting a curated selection of tokenized BTC representations ("wrappers") for direct BTC staking on Starknet. To review all BTC wrappers, use the staking contract's [`get_active_tokens`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#get_active_tokens) function. Additional resources * Staking dashboards by [Endur](https://dashboard.endur.fi/), [Voyager](https://voyager.online/staking-dashboard), [AlignedStake](https://www.aligned-stake.com/), and [Staking Rewards](https://www.stakingrewards.com/stake-app?input=starknet) * [Staking](https://www.starknet.io/staking) on starknet.io * [`starknet-staking`](https://github.com/starkware-libs/starknet-staking/tree/%40staking/contracts-v1.0.1-dev.510) on GitHub (deployed tag) * [Starknet launches phase 1 of its staking initiative on mainnet](https://www.starknet.io/blog/staking-phase-1/) on the Starknet blog * [SNIP 28: Staking V2 proposal](https://community.starknet.io/t/snip-28-staking-v2-proposal/115250) on the Starknet community forum * [SNIP 31: Bitcoin staking on Starknet](https://community.starknet.io/t/bitcoin-staking-on-starknet/115696) ## Roadmap Naturally, handing over the responsibility for maintaining and securing Starknet to validators in one day is neither feasible nor desirable. Instead, the staking protocol is implemented in incremental phases, with each phase bringing additional requirements from validators until they fully maintain and secure the network. The protocol is currently in the second of four phases, illustrated in following figure: The staking protocol is currently in its second phase on both Sepolia and Mainnet. ## Protocol The following sections describe the details of Starknet's staking protocol. The parameters used in the protocol are summarized in the following table: | Parameter | Mainnet | Sepolia | | ------------------------------------------- | ------------ | ------------ | | Minimum stake for validators | 20K STRK | 1 STRK | | Effective inflation coefficient ($\hat{C}$) | 4% | 2.13% | | Withdrawal security lockup | 7 days | 5 minutes | | Epoch length ($E$) | 1132 blocks | 231 blocks | | Epoch duration | 3600 seconds | 1200 seconds | | Attestation window ($W$) | 50 blocks | 30 blocks | | Number of epochs used for latency ($k$) | 1 epoch | 1 epoch | | Weight of BTC in staking power ($\alpha$) | 0.25 | 0.25 | ### Roles Starknet's staking protocol features two options for participation: * Staking directly as validators: Staking a minimum of 20,000 STRK and earning rewards by handling any responsibilities the protocol requires * Staking indirectly as delegators: Delegating STRK or BTC to validators who allow delegation and sharing in their rewards without handling any of their responsibilities Validators can choose whether to allow delegation or not. ### Epochs Starting from its second phase, the staking protocol introduces the notion of *epochs* (similarly to many other protocols). Epochs represent checkpoints, such that changes made in epoch $i$ are applied in epoch $i+k$, where $k$ is a new latency parameter. For example, the following figure illustrates a scenario where in epoch $i$ validator $A$ has 50K STRK staked and someone delegates an additional 10K STRK to them, and in epoch $i+1$ someone undelegates 30K STRK from $A$: ### Validator power The staking power of a validator staking $s$ amount of STRK and $b$ amount of BTC is defined as follows: $$ (1 - \alpha) \cdot \frac{s}{S} + \alpha \cdot \frac{b}{B} $$ where: * $\alpha = 0.25$ is a parameter determining BTC's weight in the staking power * $S$ and $B$ are the total STRK and BTC staked, respectively ### Validator responsibilities Starting from its second phase, the staking protocol requires validators to attest to blocks by running one of the followings: * The [Juno](https://juno.nethermind.io/hardware-requirements) full node with [Nethermind's attestation tool](https://github.com/NethermindEth/starknet-staking-v2/blob/main/README.md) * The [Pathfinder](https://eqlabs.github.io/pathfinder/getting-started/hardware-requirements) full node with [Equilibrium's attestation tool](https://github.com/eqlabs/starknet-validator-attestation/blob/main/README.md) How does the block attestation mechanism work? In each epoch, each validator is assigned a single block whose relative number within the epoch is defined as follows: $$ h(\text{staked amount},\text{epoch id},\text{validator address}) \mod (E-W) $$ where: * $E$ is the number of blocks in an epoch, termed *epoch length* * $W$ is the number of blocks applicable for attestation submittal, termed *attestation window* During each epoch, validators have the opportunity to attest to their assigned block by submitting an `attest` transaction, which must be included within the attestation window. For example, if $W = 20$ and $N$ is the relative block number assigned to validator $A$, then $A$ must submit an `attest` transaction between the blocks whose relative number within the epoch are $N+1$ and $N+20$. In the second phase of the protocol, each Validator is required to perform only one attestation per epoch. The `attest` transaction includes the block hash of the attested block, ensuring validators actively use full nodes, as they need to continuously track block hashes. Additionally, the attestation is publicly verifiable, ensuring validators' reliability is publicly tested — a crucial prerequisite before handing them any core responsibilities. ### Rewards Staking rewards are issued in newly minted STRK tokens, based on a minting curve. The minting curve balances participation and inflation by adjusting the distributed rewards according to the total STRK locked in the protocol. The total minting rate percentage ($M$) is defined as follows: $$ M = \frac{\hat{C}}{10} \cdot \sqrt{\sigma} $$ where: * $\hat{C}$ is the effective inflation coefficient * $\sigma$ is the percentage of STRK staked out of the total STRK supply Annual reward percentages (APR) can therefore be calculated using the following formulas: * For STRK: $100 \cdot \frac{M}{\sigma} \cdot (1-\alpha)$ * For BTC: $(\alpha \cdot T \cdot \frac{M}{100} \cdot \frac{\text{STRK price}}{\text{BTC price}}) / B$ where: * $B$ is the total BTC staked * $T$ is the total STRK supply Rewards are distributed per epoch to validators in proportion to their staking power only if they performed their attestations in the epoch, on an "all or nothing" basis (i.e., validators that submitted a transaction during the epoch that proves they tracked the network will receive all the rewards for the epoch based on their staked amount, while validators that didn't will get no rewards for the epoch's entire duration). Rewards that go directly to the validator will accumulate in their account, and the rest will accumulate for delegators according to their share in the pool. [As previously described](#epochs), stakers that enter the protocol on epoch $i$ will start getting rewards only on epoch $i+k$, and stakers that signal an intent to exit the protocol on epoch $i$ will still get rewards until epoch $i$. ### Commissions The staking protocols enables validator to set a commission that is deducted from their delegators' rewards. Starting from its second phase, the staking protocol allows validators to increase their commission. To avoid an unexpected increase in commissions, validators must commit to a certain maximum commission $M$ and the last date (in epochs) that this commitment is relevant for. Until this date arrives, validators cannot increase their commission beyond $M$, but can freely change their commission in the range $[0,M]$. ### Latencies The following latencies are set in place: * To disincentivise sudden large withdrawals that could destabilize the network, funds are subject to a 7-day lockup after signaling an unstake intent, during which no rewards are earned and funds cannot be withdrawn. * Starting from the second phase of the protocol, to prevent delegator from switching too quickly between validators while still promoting a competitive delegation market, a switch intent that is signaled on epoch $i$ takes effect only on epoch $i+1$. ### Addresses To reduce exposure to threats and enhance security, multiple addresses are defined for both validators and delegators: * Validator addresses: * Staking address: Used for staking, adding stake, and unstaking. This address is only needed when entering or exiting the protocol and handles large amounts of STRK, and therefore is best kept by a cold wallet with minimal activity. * Rewards address: Used for receiving rewards. This address is only needed when receiving rewards, and therefore is best kept by a cold wallet. * Operational address: Used for operational purposes, such as block attestations (starting from the protocol's second phase), block proposing (starting from the protocol's third phase), etc. This address is used frequently and doesn't handle large amounts of funds, and therefore is best kept by a hot wallet. Starting from the protocol's second phase, however, hacking the operational address can lead to a lose of yield for the validator and its delegators. * Pools addresses: Used for pooling stake delegations for a specific token. For each token that a Staker is open to receiving delegations in, a unique delegation pool contract (with its own address) is created for users to delegate funds to. These pool contracts are automatically deployed for the Staker when they invoke the staking contract’s `set_open_for_delegation` function. If your operational address uses local signing, the account associated with it must be deployed and unprotected (e.g., no Ready Wallet Guardian or Braavos hardware signer). * Delegator addresses: * Staking address: Used for delegating stake, adding stake and unstaking. This address is only needed when entering or exiting the protocol and handles large amounts of STRK, and therefore is best kept by a cold wallet with minimal activity. * Rewards Address: Used for receiving rewards. This address is only needed when receiving rewards, and therefore is best kept by a cold wallet. The protocol uses a hierarchical approach between the staking and rewards addresses, and both validators and delegator can also use their staking address whenever their rewards address is required. ## Components The implementation of Starknet's staking protocol is divided into several contracts, summarized in the following figure: This modular architecture allows for targeted upgrades and improvements without affecting the entire system. Access control mechanisms are also in place to ensure that only authorized parties can make critical changes, further enhancing the security of the staking process. The following table details the key components of the protocol: | Contract | Description | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Staking | The staking contract is the core of the staking system, managing the entire lifecycle of staking, from initial staking to claiming rewards and unstaking.
The staking contract also stores the `StakerInfo` data structure, which holds detailed information about each validator, including their staked amount, unclaimed rewards, delegation details, and operational parameters, and helps to ensure that validators' information is accurately tracked and updated. | | Delegation pooling | All delegation interactions, such as entering or exiting a pool, are enabled through the delegation pooling contract, which tracks each delegator's contribution, calculates their rewards, and manages the delegation lifecycle.
The delegation pooling contract also stores the `PoolMemberInfo` data structure, which holds information about each delegator's contributions, rewards, and status within the pool, and helps manage and calculate the delegation and reward distribution processes for pool members. | | Reward Supplier | The reward supplier contract is responsible for calculating and supplying the staking rewards based on the minting curve, ensuring the rewards are distributed fairly and in accordance with the protocol's economic parameters. | | Minting Curve | The minting curve contract defines the economic model that governs reward distribution, ensuring that the network's inflation is managed while incentivizing participation of stakers. | | Attestation | The attestation contract manages the tracking of successful validator attestations, by verifying whether the validator has correctly attested to their assigned block within a designated attestation window. | ## Procedures The following tables detail the procedures enabled by the staking protocol for both [validators](#staking_as_validators) and [delegators](#staking_as_delegators), along with the instructions to perform them. To invoke onchain contracts, use [`Starknet Foundry's sncast`](https://foundry-rs.github.io/starknet-foundry/starknet/sncast-overview.html), [Starkli](/learn/cheatsheets/tools/), or a [block explorer](/learn/cheatsheets/integrations/). To get the onchain addresses of the staking and STRK contracts, see [Important addresses](/learn/cheatsheets/chain-info/#staking). ### Staking as validators | Procedure | Instructions | Notes | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Staking | Invoke the staking contract's [`stake`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#stake) function | • You should make sure you are [running a fully synchronized node](#validator-responsibilities) before staking
• You must first approve the transfer of the amount of STRK tokens to be staked to the staking contract by invoking the STRK contract's `approve` function
• `operational_address` should have sufficient funds to pay for attestation transactions
• `amount` should be equal or greater than the [minimum stake for validators](#protocol) and denominated in FRI (i.e., 1\*1018 = 1 STRK)
• Attesting to blocks is only possible starting from the epoch following a successful stake | | Initializing or updating commission | Invoke the staking contract's [`set_commission`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#set_commission) function | • `commission` should be entered as a percentage with precision, where 10,000 represents 100% (e.g., to set a 5% commission, you enter 500)
• Commissions can be increased only after [setting a commission commitment](#commissions) using [`set_commission_commitment`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#set_commission_commitment) | | Opening delegation | Invoke the staking contract's [`set_open_for_delegation`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#set_open_for_delegation) function | Opening delegation is is only possible after initializing the commission using `set_commission` | | Claiming rewards | Invoke the staking contract's [`claim_rewards`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#claim_rewards) function | | | Increasing stake | Invoke the staking contract's [`increase_stake`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#increase_stake) function | • `amount` should be denominated in FRI (i.e., 1\*1018 = 1 STRK)
• You must first approve the transfer of STRK tokens to the staking contract by invoking the STRK contract's `approve` function | | Changing reward address | Invoke the staking contract's [`change_reward_address`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#change_reward_address) function | | | Changing operational address | Invoke the staking contract's [`declare_operational_address`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#declare_operational_address) and [`change_operational_address`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#change_operational_address) functions | `declare_operational_address` should be invoked by your new operational address and `change_operational_address` should be invoked by your staking address | | Unstaking | Invoke the staking contract's [`unstake_intent`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#unstake_intent) and [`unstake_action`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#unstake_action) functions | • Once an unstake intent is signaled:
• Funds are removed from the total balance and are no longer part of the staking protocol
• The same staking address cannot be used to "restake" (i.e., `unstake_action` is **irreversible**)
• `unstake_action` should be invoked only after the appropriate [waiting period](#latencies) has ended | ### Staking as delegators The following procedures are only intended for developers who are either interested (for whatever reason) in staking as delegators without using a [staking dashboard](#overview), or are building one. | Procedure | Instructions | Notes | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Entering a delegation pool | Invoke the delegation pool contract's [`enter_delegation_pool`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#enter_delegation_pool) function | • `amount` should be denominated in the token's base unit (e.g., FRI for STRK)
• You must first approve the transfer of STRK tokens to the delegation pool contract by invoking the STRK contract's `approve` function | | Claiming rewards | Invoke the delegation pool contract's [`claim_rewards`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#claim_rewards-1) function | | | Adding to a delegation pool | Invoke the delegation pool contract's [`add_to_delegation_pool`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#add_to_delegation_pool) function | • Adding to a delegation pool is only possible after entering it using `enter_delegation_pool`
• `amount` should be denominated in the token's base unit (e.g., FRI for STRK)
• You must first approve the transfer of STRK tokens to the delegation pool contract by invoking the STRK contract's `approve` function | | Switching delegation pools | Invoke the delegation pool contract's [`switch_delegation_pool`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#switch_delegation_pool) function | To prevent delegator from switching too quickly between validators while still promoting a competitive delegation market, a switch intent that is signaled on epoch $i$ takes effect only on epoch $i+1$. | | Changing reward address | Invoke the delegation pool contract's [`change_reward_address`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#change_reward_address-1) function | | | Exiting a delegation pool | Invoke the delegation pool contract's [`exit_delegation_pool_intent`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#exit_delegation_pool_intent) and [`exit_delegation_pool_action`](https://github.com/starkware-libs/starknet-staking/blob/main/docs/spec.md#exit_delegation_pool_action) function | `exit_delegation_pool_action` should be invoked only after the appropriate [waiting period](#latencies) has ended |