Staking

​

Overview

While Starknet is currently still centralized, it is gradually moving towards employing a staking 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, 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. Additional resources

• Staking dashboards by AlignedStake, Ednur, Staking Rewards, Starkscan, and Voyager
• Staking on starknet.io
• starknet-staking on GitHub (deployed tag)
• Starknet launches phase 1 of its staking initiative on mainnet on the Starknet blog
• SNIP 28: Staking V2 proposal on the Starknet community forum
• SNIP 31: Bitcoin staking on Starknet

​

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:

​

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}$)	1.6%	1.6%
Withdrawal security lockup	21 days	5 minutes
Epoch length ($E$)	120 blocks	231 blocks
Epoch duration	3600 seconds	1200 seconds
Attestation window ($W$)	30 blocks	30 blocks
Number of epochs used for latency ($k$)	1 epoch	1 epoch
Weight of BTC in staking power ($\alpha$)	N/A	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 full node with Nethermind’s attestation tool
• The Pathfinder full node with Equilibrium’s attestation tool

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$. 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 total STRK supply

Annual reward percentages (APR) can therefore be calculated using the following formulas:

• For STRK: $100 \cdot \frac{M} / {\sigma}$
• 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.

​

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 21-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.
  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 and delegators, along with the instructions to perform them. To invoke onchain contracts, use Starknet Foundry’s sncast, Starkli, or a block explorer. To get the onchain addresses of the staking and STRK contracts, see Important addresses.

​

Staking as validators

Procedure	Instructions	Notes
Staking	Invoke the staking contract’s stake function	• You should make sure you are running a fully synchronized node 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 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 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 using set_commission_commitment
Opening delegation	Invoke the staking contract’s 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 function
Increasing stake	Invoke the staking contract’s 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 function
Changing operational address	Invoke the staking contract’s declare_operational_address and 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 and 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 has ended

​

Staking as delegators

Procedure	Instructions	Notes
Entering a delegation pool	Invoke the delegation pool contract’s 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 function
Adding to a delegation pool	Invoke the delegation pool contract’s 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 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 function
Exiting a delegation pool	Invoke the delegation pool contract’s exit_delegation_pool_intent and exit_delegation_pool_action function	exit_delegation_pool_action should be invoked only after the appropriate waiting period has ended