[TPP-DRAFT] ZKnomics Token Staking

Title ZKnomics Token Staking
Proposal Type TPP
One Sentence Summary This proposal activates a capped minter with 37.5M ZK (~$1.9M USD) to trial ZK token staking rewards over 6 months with up to 10% reward rate for participation in the pilot.
Proposal Author Dennison / Cliffton (Tally)
Proposal Sponsor Dennison (Tally)
Date 2025-09-01
Version v1
Summary of Action Activate a ZK Token staking program in support of ZKnomics vision using Tally’s Staker contract, fund it autonomously over 2 seasons (6 months total) with two capped minters of 10M ZK and 25M ZK respectively. Staking is forward compatible with ZKsync decentralized sequencing.
Link to forum post [TPP-DRAFT] ZKnomics Token Staking
Link to contracts GitHub - withtally/staker

Simple Summary

This proposal activates a capped minter with 37.5M ZK (~$1.9M USD) to pilot ZK token staking rewards over 6 months with up to 10% return for pilot participants. Rewards are distributed autonomously upon the funding of staking contracts. Reward eligibility is limited to tokenholders delegating to active Delegates, those that have voted a minimum of 2 out of last 5 votes.

Motivation

In alignment with the ZKnomics vision published in June 2025, this proposal trials ZK Token Staking infrastructure by deploying Tally’s audited Staker contract system.

As mentioned in the ZKnomics Vision, this staking contract design enables programmatic distribution of rewards, with governance controlling key parameters, including reward amounts and staking rules.

The Staker contract allows ZK token holders to stake their tokens without any predetermined locking period, while simultaneously delegating their voting power. Moreover, delegation persists when stake is withdrawn. Over time, this framework could enable tokenholders to easily engage in any additional token utility opportunities like participating in DeFi with the ZK token.

Participation in this pilot will be limited to a predefined staking cap, with rewards funded by a 37.5M ZK capped minter divided over two seasons lasting ~3 months.

Th proposal trials infrastructure necessary to support staking related to ZKsync’s future decentralized sequencer, while contributing to protocol sustainability via delegation. The system is non-custodial and integrated with Tally’s delegation interfaces.

Key design choices include capped deposits, a reward emission stream over 30-day epochs, and a frontend hosted on Tally (stake.zknation.io).

ZK Token Staking will ensure staking works seamlessly and include recommendations for future versions. Tally and the Program Administrator will evaluate the traction of staking, its impact on voting power, and additional configuration options to align participation to protocol liveness. Additional configuration examples include integration with ZKsync decentralized sequencing, sharing rewards with selected Delegate, contributing to protocol-owned liquidity, and crowdfunding conditional funding markets.

This program ensures security via completed audits, fund distribution pause and cancellation controls, and a framework that allows the Token Assembly to revoke or replace contract administration and operational teams via ZKsync governance proposals. Rewards will be distributed autonomously to eligible ZK token stakers over time.

Impact

ZK Token Staking builds towards a seamless tokenholder experience for the ZKnomincs Vision. Through staking, it deepens alignment between ZK holders and protocol design needs, distributing rewards to those supporting ZKsync’s long-term success. Most importantly, the program trials staking infrastructure necessary for the future decentralized sequencer supporting Stage 1 decentralization for ZKsync.

Pilot Strategic Objectives

  • Trial secure and reliable staking infrastructure in preparation for ZKsync’s decentralized sequencer, contributing to the ZKnomincs Vision.
  • Increasing active voting power in governance from ~1B to ~2B. Active voting power is currently defined as participating in 2 or more of the most recent 5 votes.

Pilot Operational Goals

  • Deployment of staking infrastructure, ready for ZKsync decentralized sequencing and a modular design supporting ZKnomics.
  • Season 1 : 400M ZK staked in total, with a maximum of 10M ZK distributed over 3 months (2.5% for 3-months or 10% annualized), 0 incidents.
    • Net increase of +200M active voting power (50% of staked ZK)
  • Season 2 : 1B ZK staked in total, with a maximum of 25M ZK distributed over 3 months (2.5% for 3-months or 10% annualized), 0 incidents, and integration with decentralized sequencing.
    • Net increase of +500M active voting power (50% of staked ZK)

:information_source: 1B ZK is ~15% of circulating supply (~7.1B).

Example Benchmarks Across Ethereum

  • ~29% of ETH is staked
  • stkAAVE peaked at ~20% of circulating supply

:warning: If there is not sufficient impact on the strategic objective during each season, as measured by a the increase in active voting power via staked ZK tokens, then the program may be cancelled by the Program Administrator.

Mechanic

ZK Token Staker Contract by Tally: Pilot Configuration

Parameter name Param value Description
stakeToken ZK Users will stake ZK
rewardToken ZK Rewards will be denominated in ZK
REWARD_DURATION 30 days Each tranche of rewards is distributed pro-rata continuously over 30d window, to give stakers time to respond to changes in yield.
admin Season 1: Program Administrator Multisig

Season 2: ZKsync Governance (Planned)
The admin can pause minting, set the rewardNotifier , set the EarningPowerCalculator , and change the maxBumpTip.
RewardNotifier MintRewardNotifier The notifier will call mint() on the ZK token contract, then send the minted tokens to the staking system
EarningPowerCalculator IdentityEarning PowerCalculator The IdentityEarning PowerCalculator makes every staker eligible.

For future staking programs, earning power is calculated based on reward eligibility e.g. active participation in governance.
maxBumpTip 0.00005 ETH The amount of ETH paid to searcher bots who update user’s earning power when it changes.

(The IdentityEarning PowerCalculator does not change users’ earning power, but future calculators might)
Governance compatibility Yes Staked ZK can delegate its voting power.
Upgradeability Yes, via Token Governor Staking contracts can be upgraded to support decentralized sequencing and other token utility upgrades

Whenever rewards enter the staking system, they are streamed out continuously over the next 30 days. That prevents discontinuities and race conditions. The turned-off staking system is planned to be deployed a minimum of 14 days prior to initial rewards start. As a result, all token-holders have the opportunity to stake with decreased time constraints.

In the pilot’s season 1, the annualised reward will be a maximum of 10% annualized. This assumes the staking cap of 400M ZK tokens is met, and rewarded a total of 10M ZK over the three-month period. This is equivalent to 2.5% for the 3 months of the season.

In season 2, the maximum reward would be ~10% annualized. This assumes the staking cap of 1B ZK tokens is met, and rewarded a total of 25M ZK over the three-month period. This is equivalent to ~2.5% for the 3 months of the season.

At the contract level, stakers can delegate their staked ZK’s voting power to any address. The Program Administration Team will have the ability to adjust reward eligibility such that staking rewards depend on the Delegate participating in governance.

The staking contracts are, like most smart contracts, open to anyone to call directly from any frontend. Tally will work with staking aggregators, wallets and custodians to integrate the system.

Capped Minter Configuration

Program minters are secured by a program-level rate-limiter:

Capped Minter Smart-Contract Admin Role Smart-Contract Minter Role Smart-Contract Pauser Role Minting Start Minting End Token Configuration Parameters
Zk_StakingPilot_2025 (Parent Capped Minter) Token Governor Zk_StakingPilot_RateLimit_2025 ZKsync Security Council Oct 1, 2025 Dec 31, 2026 Cap: 37.5M ZK
Zk_StakingPilot_RateLimit_2025 (Rate Limit Modifier) Program Administrator Multisig Zk_StakingPilot_Season1_2025
Zk_StakingPilot_Season2_2025
Zk_StakingPilot_Operations_2025
n/a n/a n/a Rate Limit: 10M ZK per month
Zk_StakingPilot_Season1_2025 (Child Capped Minter) Program Administrator Multisig Tally Staker ZKsync Security Council Oct 1, 2025 Dec 31, 2026 Cap: 10M ZK
Zk_StakingPilot_Season2_2025 (Child Capped Minter) Program Administrator Multisig Tally Staker ZKsync Security Council Oct 1, 2025 Dec 31, 2026 Cap: 25M ZK
Zk_StakingPilot_Operations_2025 (Child Capped Minter) Program Administrator Multisig Child Capped Minters and Rate Limiters for Service Providers. ZKsync Security Council Oct 1, 2025 Dec 31, 2026 Cap: 2.5M ZK
  • Capped Minters will be subject to an overall rate limit of 10M ZK per month. This rate limit is designed to accommodate variations in spending and potential token volatility.
  • Minting rights allow service providers to mint at their discretion within the minting window. All capped minters are subject to the aggregate global rate limit.

ZK Token Staker: Reward Management

Rewards will be incrementally increased by the Program Administrator over the course of each season. This will optimize the reward in such a way that the cap is met at the lowest level of distributed award. For example:

  • Season Launch: Set at an initial 3% return.
  • Each week: The reward return is increased by an absolute 1% if cap is not met.
  • The maximum return is capped at 10%, which is the full deployment of rewards.
  • Rewards may also be decreased to fully quantify change in demand.

Reward eligibility is limited to tokenholders delegating to active Delegates, those that have voted a minimum of 2 out of last 5 votes.

:information_source: Please note the exact initial return and weekly increases will be defined by the Program Administrator during the program based on ongoing analysis. The exact methodology may vary based on guidance to ensure efficient use of pilot rewards.

ZK Token Staker: User Interface

Click to view demo of how the staking page would appear on Tally and on zknation.io. Staking would be available on stake.zknation.io.

To participate in staking, tokenholders are required to delegate their ZK voting power.

Stakers earn rewards over time. Rewards are proportional to their share of the total staked amount. For example, Alice stakes 600 ZK and Bob stakes 400 ZK, for a total of 1000 staked ZK. No one else stakes. If there is a reward of 10 ZK emitted over one day, 6 of it would go to Alice and 4 of it to Bob. Additionally, stakers can choose to split their voting power to more than one Delegate, and each staking position has its own eligibility to rewards.

Click to View Demo Video

Staking contracts are upgradeable with the Token Governor Timelock set as owner. For future seasons, the ZKsync Token Assembly can choose, via ZKsync Governance, to upgrade the staking contracts include expanded token utility options, such as supporting decentralized sequencing.

Delegate selection is customizable on Tally and guided by the ZKsync Governance Team, in collaboration with the Program Administrator. Delegates eligibility will be refined over time.

Delegate eligibility criteria will also be adapted based on and program performance. Operator selection (e.g. such as sequencers) may become available depending on protocol development progress. Stakers will be able to view their annualized return. For example, 10M ZK rewards over 3 months for 400M staked = ~10% APY annualized.

Operational Timeline Estimate

  • September 2025: Governance approval, parameter tuning, UI integration + frontend testing
  • October 2025 : Season 1 launch
  • January 2026 : Season 2 launch

Accountability

  • Token Allocation Tracking: Token minting will be available for public review using the ZKsync Capped Minter Dune Dashboard, or alternative interface if applicable.
  • Governance Forum Posts: The Program Administration Team will publish updates on the ZKsync Governance Forum at the start and end of each season. Should a period extend beyond three months, an intermediate update will be included.
  • Token Assembly Oversight: The Token Assembly may cancel the parent capped minter at any point via a Token Program Proposal and revoke any further disbursements.
  • Security Council Oversight: The Security Council may pause any of the capped minters at any point if deemed necessary.
  • KYC/KYB : Required for Program Administration Team and service providers.
  • Audit Requirements : Contracts fully audited and published.
  • Excess Tokens: Any excess tokens not used for the program should remain unminted. If excess tokens are minted, they will be returned to the control of the Token Assembly.
  • Impact: If there is not sufficient impact on the strategic objective during the first season, as measured by increase in active voting power via staked ZK tokens, the Program Administration Team will provide a recommendation to continue or pause the program.

Service Provider Token Allocation

Service provider token allocations are designed to align with program objectives. For ZK Token Staking, token allocations are locked for 6-months, ensuring the Program Administration Team can confirm completion of services prior to unlock.

Service Provider Tally
Token Allocation Up to 2.5M ZK tokens, with minting rate limited to ~416,667 ZK per month.
Services Description Staker Smart Contract Deployment: Secure deployment and initialization of the staking contract, customized to meet network-specific requirements. [Supported by ScopeLift Engineering]

Frontend Activation & Customization: Integration with the Tally interface, including branding, UI/UX adjustments, Delegate eligibility and discovery, and user onboarding configuration.

Analytics & Reporting: Public dashboards and periodic reports to monitor staking activity, program objectives, and participation trends.

Continuous Contract Configuration: Ongoing adjustment of staking parameters, reward logic, and utility integrations in accordance with program objectives.

Staker Smart Contract Audit: Complete audit of network-specific related customizations to Tally Staker contract. [Supported by Offbeat Security]

Continuous Contract Security Review: Ongoing security monitoring of staking contract, and security review of contract changes and additional modules. [Supported by Offbeat Security]

Operational Support: Assistance for program execution throughout the program, including troubleshooting, comm

Service providers will complete a contract with ZKGPS in alignment to the services scope and payment as defined in this proposal.

Program Administrator

The Program Administrator, overseeing Tally’s operational execution and contracts, will be composed by a 3/5 multisig 0x123...456 :

  • 1 ZKsync Foundation representative: Marco Cora
  • 1 Matter Labs Representative: Steven Correll
  • 1 technical partner: Alex Keating, ScopeLift (Confirmed)
  • 1 independent delegate: Areta (Confirmed)
  • 1 security partner: Assigned Security Council Member

Compensation for independent participants, set at 100,000 ZK for the program (approximately 7-9 months), will be covered by ZKGPS.

The ZKsync Security Council will be granted the Pauser role on program Capped Minters.

Participants

  • Tally: Proposal development, staker contracts, frontend, and analytics. Day to day operations.
  • Program Administrator: Responsible for overseeing program and admin role of contracts.
  • Marketing Support : The ZKsync Foundation will coordinate efforts with current service providers to support the proposal if necessary.
  • ZKGPS: Serves as legal counterparty for program service providers.
  • Token Assembly: Oversees minting and retains final authority to halt program.

Other Information

1 Like

Hi everyone,

Certainly one of the most auspicious proposals so far and excited to see the ZKSync version of the Staker contract system. We are overall supportive of the initiative in it’s aim to adress ZKsync’s future decentralized sequencer while enhancing governance.

As we take a more detailed look there are some early thoughts on the proposal. In the attempt to activate dormant VP it is reasonable to set a rather low bar to consider delegates as active. But is there an ongoing requirement of delegate activity in order for the delegator to be able to accrue rewards?

Thinking in that sense of the Obol Delegate Reputation Score as well as some of the insights discussed in this thread on which reputational considerations regarding delegate activity where vastly discussed.

Also, and in order to contribute to the discussion, curious to hear on some key differentiators with the Arbitrums Staking proposal.

Thanks!

1 Like

Thank you for your thoughtful questions and engagement with the ZK staking proposal.

On Delegate Activity Requirements and Scoring

The primary focus on on-chain actions for qualifying delegates as “active” is indeed intentional for this pilot phase ZKnomics Roadmap Vision. We’ve deliberately scoped delegate activity metrics to require continuous on-chain voting rather than implementing scoring systems based on offchain activity volume, and this is drawn from lessons learned from other ecosystems like Arbitrum and Obol as you pointed out.

At the end of the day, ZK is set to be a protocol utility token.

For ZK Staking’s initial implementation, keeping the activity threshold focused on verifiable on-chain actions serves multiple purposes:

  • Objectivity: On-chain voting is binary and verifiable, eliminating subjective interpretation
  • Simplicity: Reduces operational complexity and administrative overhead during the pilot
  • Gaming resistance: Harder to manipulate than low-quality forum posts or artificial engagement metrics
  • Progressive enhancement: Allows us to establish baseline participation before layering in more sophisticated metrics

This approach aligns with ZKnomics’ principle of “Gradual Implementation,” where each stage is dependent on successful delivery and governance approval ZKnomics Roadmap Vision. Once we validate the core staking mechanism works effectively, we can iterate eligibility to align with protocol utility requirements, and review any changes regarding protocol security and upgrade reliability requirements.

On the Differentiation from Arbitrum’s Staking Proposal

While the structural implementation shares similarities with Arbitrum’s approach, the strategic intent and long-term vision differ significantly.

Arbitrum’s staking proposal focuses primarily on governance security and participation, stopping short of distributing fees to tokenholders. The proposal addresses challenges including limited demand driven primarily by governance participation, declining voter participation, and potential governance attacks on their treasury.

ZKsync, however, has progressively increased governance participation, as measured by active voting power – which will also be boosted by the initial eligibility requirements. In contrast to Arbitrum, staking supports the broader ZKnomics vision of a ZK token integrated into protocol-wide sustainable economics. Over time, the aim is to uncover the best design where network usage drives protocol revenue, and that revenue is programmatically directed toward protocol participants which strengthen the protocol security and growth, while managing token supply.

The key differentiators of the ZKnomics vision include:

  1. Protocol Revenue Integration: ZKnomics opens up the opportunity for ZKsync governance to collect fees autonomously at the protocol level via Gateway, the Shared Bridge, and other core contracts. This creates a flywheel between network activity, security, governance sustainability, and token value accrual.

  2. Programmatic Distribution Framework: Once staking infrastructure is tested and in place, ZKsync Governance could enable an autonomous mechanic where fees are split between a burn function to manage supply, and rewards to support decentralized liveness, creating a comprehensive tokenomics loop rather than just governance incentives.

  3. Continuous Ecosystem Alignment: This staking mechanism is explicitly designed as part of a long-term vision for how ZK can secure the network, reward meaningful participation and drive the growth of the ecosystem. This works particularly well as technical infrastructure like Gateway, Airbender, and ZKsync OS come online – and new token programs create investment flows into product development and ecosystem growth incentives.

  4. Progressive Utility Expansion: The roadmap includes authorizing permissionless staking, upgrading the token contract with a public burn mechanism, enabling sequencer and interop fee switches, and finalizing allocation rules—all through transparent governance. More so, the opportunity is to expand what staking enables: new utility and rewards without sacrificing governance liveness.

In essence, while Arbitrum’s staking focuses on solving immediate governance participation challenges without yet turning on fee distribution, ZK staking is architected as the foundational layer for a comprehensive protocol economy that aligns network usage with token value, a critical distinction towards sustainable, usage-driven tokenomics.

Looking forward to continued discussion as we refine these mechanisms together.

1 Like