[TPP-12] ZKnomics Token Staking

[cliffton.eth]

This proposal passed with a majority of 905.63M ZK in-favor of the proposal. See final results here.

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-12] 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)

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

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.

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.

• See also Obol’s staking UI on Tally as a reference.

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

• ZKsync roadmap on decentralization
• ZK tokenomics vision
• Staker GitHub
• Staker Audit
• Contract Implementation Spec

[SEEDGov]

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!

[cliffton.eth]

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.

[SEEDGov]

We did some further research on the available data so sharing some insights that should be useful to assess the proposal. We have a dedicated Dune dashboard that you can check.

Current governance participation shows a significant gap between delegated voting power and active voting power. Out of a circulating supply of 7.1B ZK, about 2.83B is delegated, which represents roughly 40% of supply. However, only ~920M is active, meaning it has been used in at least 2 of the last 5 proposals. This is just 13% of supply and 33% of delegated voting power.

Importantly, this number has been trending downwards, and participation rates continue to fall. The pilot proposal sets ambitious targets: 400M ZK staked in Season 1 and 1B ZK in Season 2, which would represent 14% and 35% of today’s delegated power. For active voting power, the goal is 1.6B, which would require nearly doubling the activity ratio from today’s 33% to 57%.

When looking at recent proposals, average participation has been around 800M VP, consistent with the current level of active voting power. However, the distribution of this power is highly concentrated. Fifty-six delegates each control over 10M VP, yet 60% of them are inactive, meaning they have not participated in at least two of the last five votes. In this large-holder segment alone, there is ~850M VP sitting idle. This illustrates that the challenge is not only about increasing staking, but about shifting stake to active delegates or incentivizing dormant delegates to consistently participate. Without that, additional staking may grow headline numbers while leaving active participation stagnant.

The staking targets themselves appear achievable. Season 1’s 400M is just 5.6% of circulating supply, and Season 2’s 1B represents about 15%. With a 10% APY incentive, these figures are realistic, especially since over 2.8B is already delegated. What is far more uncertain is the growth in active voting power. While an additional 200M or 500M in AVP could theoretically be reached by reactivating large delegates, the reliance on delegate behavior makes this more difficult. Many tokens could be staked and delegated but still remain in the hands of inactive delegates, which would mean the program fails to achieve its core governance goals.

Finally, it should be noted that quorum thresholds are being reached easily today, with progress averaging around 120%, but this depends on a shrinking base of active participation. If AVP continues to decay, quorum could become a bottleneck unless the rules are adjusted. Moreover, cohort retention data shows declining participation, with fewer users consistently voting and fewer new participants entering governance. This trend echoes experiences in other DAOs like Arbitrum and Optimism, where distributing voting power was insufficient; long-term growth required aligning incentives with contributors and organizations that are directly invested in the protocol’s success. Without this alignment, staking rewards risk becoming a drain on the treasury, especially if network usage and user adoption continue to weaken.

[rafso]

Hi all, the audit report of smart contracts that the staking program is now available.

• The deploy scripts for the ZK staking contracts are available on this branch of the zkstaker repo.
• The deploy scripts and code were audited by Offbeat Security. The audit did not find any security issues. Their report is available here.
• The underlying staker contract library was audited last year several times: by a Sherlock private audit, a Sherlock public audit, and Offbeat Security audited some of the modules and extensions. Those audits are available in the github repo.

Please let me know if you have questions about the implementation details and smart contracts of the proposed staking program.

-Raf, CTO at Tally

[admin]

This proposal has been submitted onchain. Voting will start in 7 days.

Tally | ZKsync | [TPP-12] ZKnomics Token Staking

[Curia]

Thank you, @cliffton.eth and the Tally team for this thoughtful proposal, and a special thanks to @SEEDGov for the delegated voting power data analysis.

We strongly support this initiative and agree that starting Season 1 with a simple, onchain “active” definition (voting in 2 of the last 5 proposals) is a pragmatic and secure way to launch this critical infrastructure.

While this is a great start, our feedback focuses on the long-term success of the program and ensuring this pilot is best positioned to achieve its core objective: “increasing active voting power in governance from ~1B to ~2B.”. To achieve the ambitious goal of increasing Active Voting Power (AVP), we must proactively address the current trends in governance participation.

We also want to echo the point raised by @SEEDgov, and see the downward trend in voter participation as a main challenge. The average voting power cast across the last 10 proposals is only ~850M VP, and the number of unique voters is falling even faster.

The current lenient participation bar (40%) may not be enough to reverse this trend or meet the ambitious Season 2 goal of +500M AVP, which is ~59% increase from the average voting power of ~850M casted on the latest 10 proposal. The main risk is that the 40% bar incentivizes delegators to stake with delegates who meet only this minimum threshold. While this might increase the “Total ZK Staked” metric, it fails to guarantee this new AVP will translate into consistent voting power cast on all proposals. We risk spending treasury funds to grow a headline metric without solving the underlying issue of declining trend and low, consistent participation needed for long-term governance security.

Season 2

Looking forward, Season 2 presents a crucial opportunity to iterate and raise the bar. To truly increase AVP, we think the definition of “active” delegates should evolve. The goal should be to create a system that incentivizes delegators to support delegates who provide high-quality, consistent contributions that align with the ZK Credo.

To help the program succeed, we believe the community should begin researching and discussing a more robust framework for Season 2 as soon as possible. We need to define what a “high-quality delegate” is and how to measure contributions that strengthen the ecosystem. To that end, we wanted to start discussion as a community-wide effort to answer these key questions:

1. How can we use the staking incentive to motivate the redelegation of dormant VP to delegates with a proven track record of high-quality participation?
2. Beyond voting, what specific contributions (e.g., proposal feedback, technical contribution, ecosystem growth) does the community value most?
3. How can we design a fair, objective, and game-resistant framework to measure these contributions for potential integration into future seasons?

We are excited about this staking initiative and want to help it succeed. To move the conversation forward, we will begin reaching out to other ZKsync stakeholders and conducting interviews to gather community input on this topic. This process will help us collectively define a better, more holistic definition of an “active delegate,” ensuring future seasons of this program successfully increase active, value-aligned, and informed voting power, not just staked VP.

[kaereste]

The following reflects the views of L2BEAT’s governance team, composed of @krst and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.

We voted FOR.

Although we are generally cautious about staking programs, we see this proposal as a thoughtful experiment allowing us to validate certain assumptions before we rely on token staking for more critical infrastructure.

The program’s structure resembles initiatives we have supported in the past, such as Uniswap’s Event Horizon IDV, which used incentives to encourage consistent, informed participation without compromising decentralization. We believe this pilot follows the same philosophy: measured, reversible, and focused on governance health.

Our primary concern is that the pilot’s six-month timeline may be too short to yield meaningful outcomes or to provide sufficient data to evaluate its long-term impact properly. Governance participation patterns often take longer to stabilize, and more time might be needed to understand whether staking had a significant long-term impact.

Even with this limitation, we believe the program is a worthwhile experiment. Its capped structure, built-in oversight, and focus on rewarding active delegates make it a safe and valuable step toward deeper alignment between governance and protocol decentralization.

One thing that we would request though is to establish a regular reporting cadence from the Program Administrator to present and discuss results and conclusions on the ongoing basis.

[Curia]

Following our Governance Call last Oct 22, we wanted to share a summary of the different viewpoints discussed. We’re posting these notes, captured by our AI notetaker, in the hope that they provide some helpful context and can serve as a jumping-off point for the conversation here:

@rafa: Interjects to say Catherine’s feedback is good and explains that the current eligibility criteria is intentionally a starting point. He says the goal is to start with a very tangible reality, like active voters, to see if the model actually works. He speculates they might find people self-delegate to get 100% certainty of rewards versus the risk of a delegate not voting. He notes that he told the Tally team not to overcomplicate this right now because, as Catherine said, “we want data to inform the right eligibility criteria in the future.” He points out the criteria is somewhat arbitrary and could change to something else entirely, but it’s a good place to start and an interesting incentive game. He concludes that the data will help them make much better-informed decisions and agrees they shouldn’t stop there.

@cliffton.eth: Reinforces Rafa’s point that the criteria put is really simple because this is ultimately a pilot and that the hypothesis is to keep it simple for Season 1 and then iterate. He confirms they are testing the hypothesis whether token holders will actually self-delegate and are excited to work with the community to refine the criteria moving forward.

@theshelb Asks the delegates on the call if they have any metrics from other staking programs they’ve participated in that they found helpful or useful. She mentions the Tally team is thinking about what analytics to include for Season 1 and is curious to hear if anybody had any ideas.

@lex_node: Says he hasn’t really participated in any but has observed some of the dialogue. He recalls Arbitrum’s [staking] was wound down because participation led to people posting random AI stuff on forum to get credit for it. He says he personally dislikes participation trophies and prefers the idea of futuarchy, which is to reward people for voting for the correct outcomes as opposed to just for activity. He suggests a system combining an algorithm like Twitter Community Notes, where if you have uncorrelated people voting the same way, it’s seen as a potential badge of quality with a discretionary assessment period like three months, by a committee to see what proposals actually were successful and reward those who voted for them.

@theshelb Asks Gabe for clarification on whether those programs he referenced were focused more on forum posts and social media vehicles or if he knew other details.

@lex_node: Clarifies that he thinks they measured if you actually voted and also measured forum activity as part of multivariate assessments.

@404Gov (Rika): Wants to point out that we are talking about two different things — there’s staking and then there’s delegate rewards. She explains that Arbitrum never actually implemented staking but has a delegate reward system that is being somewhat wound down. In contrast, she says, ecosystems like Uniswap have a robust reward system that is simple, predictable and, consistent.

@theshelb Says that it’s a good point to highlight and sees how it might get confusing with the crossover of staking rewards being eligible only to those delegating to active delegates but also found it interesting how you could tie those together more closely.

@SEEDGov (Ivey): Agrees with Rika, adding that the issue in Arbitrum was not that much about the requirements but more that there wasn’t consensus on the redelegation strategy, (i.e., what happens to a delegate’s VP if they don’t meet participation criteria). He gives Obol as an example of a protocol that has a redelegation strategy and notes the Arbitrum situation was also delayed by the launch of an LST. He also notes that for Uniswap, what Rika was mentioning, there is a required amount of UNI to participate. He concludes that requirements change within each protocol and it’s up to us to figure out what’s the best way.

@SEEDGov (Ivey): Responds that if the goal is a purely economic mechanism, then he thinks it just shouldn’t have anything to do with delegation and should be a simple lockup. He speculates that delegation is only included for some sort of legal reason, where a lawyer told them they’re only allowed to do economic rewards if they have a ‘utility.’ He questions what stakers are being rewarded for, arguing it should be for either locking tokens (good for price) or for good, effective governance participation. He concludes that this Tally ‘thing’ doesn’t make any sense to him because there’s no lockup and it’s not truly tied to any sort of quality of governance participation.

@theshelb Reminds everyone it’s a pilot program testing things out and that its purpose is also to test out the infrastructure that will be necessary to support staking for ZK’s future decentralized sequencer.

@cliffton.eth : Says this is a pilot and ultimately the whole concept is to test infrastructure. He says the contracts were designed to be compatible with ZKsync decentralized sequencing and that this trial of rewarding governance is just step one, but the whole spirit is just making sure that the contracts actually work.

@rafa: Adds that staking does need to find a home with protocol security and utility and that the timeline does need to line up there. He gives a recommendation that if we don’t see a successful transition to protocol utility, then we need to go back to the drawing board and probably put a pause on the work.

@theshelb Thanks everyone for the really great discussion and suggests we make some time for a deeper discussion on the next delegate call.

[nanostrategy.eth]

Hello, do you have any updated timeframe for the launch of season 1 of the staking program? In the proposal you set it for october, but as I understand it there’s a delay since the vote was held about a month later than initially expected.

[404Gov]

We voted FOR this staking pilot. By aligning the interests of tokenholders with a healthy governance system, staking helps strengthen the protocol’s security and the token’s value. Staking is positioned to be a foundational element of the ZK token, as described in Part 1 of the ZK token proposal and elaborated further in the ZKnomics Roadmap vision.

That said, it’s important to ensure that every actor in the system is properly incentivized — including active delegates. With this in mind, we would like to highlight the value of configuring a portion of staking rewards to flow to delegates.

Tokenholders sharing staking rewards with delegates serves as a programmatic mechanism to ensure that those who consistently participate in governance—voting on proposals, voting, contributing context and ideas, and shaping long-term direction—are also rewarded.

If rewards accrue only to tokenholders, active delegates are left without any economic alignment. While tokenholders can choose to self-delegate, experience across other DAOs shows that large holders often do not have the bandwidth or sustained interest required for ongoing governance participation.

We are excited about this staking pilot and are happy to provide feedback and support along the way!

[Mike]

@cliffton.eth

Operational Timeline Estimate

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

The voting period was delayed by about a month. Will we launch ZK staking in November?
It would be great if we could confirm the launch date, as many users have already started asking about this. Thank you very much.

[cliffton.eth]

Hey everyone, I’ve shared an update on this new thread linked below on timelines.

ZKnomics Token Staking Pilot - Update on Timelines

Hey everyone! I wanted to provide an update on the ZK staking timeline. We’ve experienced approximately a one-month delay in creating and voting on the onchain TPP proposal compared to our initial operational estimates. Given this delay, the DevConnect schedule, and the typical slowdown in activity during Q4, we’ve coordinated with the ZKsync Association to revise our launch timeline: Season 1 is now targeted for Q1 2026, with Season 2 following in Q2 2026 . This adjusted timeline aligns well …

Will continue to share further updates on this thread. Thank you!