Proposal: Allocate Remaining Ecosystem Grants to Community Contributors, Operator Roles, and Testnet Validators

Governance
1

Proposal: Execute TGE Payload to Unlock $AZTEC Token Transfers

Abstract

This proposal allocates the remaining tokens in the Ecosystem Grants pool to (1) keep funding builders as intended, (2) recognize community contributors (Discord role holders including moderators), (3) reward testnet validators based on objective activity metrics. The proposal does not change the total Ecosystem Grants allocation or any other tokenomics category; it only sub-allocates the undistributed remainder.

Motivation

  1. Make contributor recognition explicit and governance-controlled, using a transparent snapshot + reproducible methodology.
  2. Reward community operations (moderation, localization, content) that sustained the ecosystem during the pre-TGE period.
  3. Reward infrastructure operators and testnet validators with objective, Sybil-resistant criteria.
  4. Preserve long-term runway for builder grants (projects building on Aztec).

Current Grants Accounting (Inputs)

The following accounting is the basis for this proposal:

Item Amount (AZTEC)
Total Ecosystem Grants allocation (unchanged) 1,111,000,000
Granted out (locked for 4-5 years) 570,285,000
Assigned but not distributed 103,500,000
Still in grant pool (scope of this proposal) 437,215,000

This proposal allocates only the Still in grant pool amount and leaves the rest unchanged.

Specification

30 / 30 / 40 Split of the Remaining Grant Pool

Let G = 437,215,000 AZTEC (still in grant pool). The proposed sub-allocation is:

Bucket Purpose % of G Amount (AZTEC
A Builder grants / projects (standard grants program) 30% 131,164,500
B Community contributors: Discord roles + Operator roles 30% 131,164,500
C Testnet validator rewards (KYC + activity threshold ) 40% 174,886,000
Total 100% 437,215,000

Bucket A (30%): Builder Grants / Projects

Amount: 131,164,500 AZTEC.

This bucket remains reserved for grants to teams building on Aztec, following the existing grants program processes (application, diligence, milestone-based disbursement, and vesting as appropriate).

Bucket B (30%): Community Contributors + Operator Roles

Amount: 131,164,500 AZTEC.

Bucket B is split 70% / 30% between (1) Discord community roles and (2) Operator roles, to keep the process simple and to avoid over-fitting to any single snapshot of role counts.

Sub-bucket % of Bucket B Amount (AZTEC)
B1 - Discord community roles 70% 91,815,150
B2 - Operator roles 30% 39,349,350

No-Staking Rule & Priority Order (Bucket B)

B1 (Discord Community Roles): only one role per wallet is counted — the role with the highest priority (MAX by priority). Any additional roles held by the same wallet within B1 do not increase the payout.

** B2 (Operator / Noder Roles):** by default, MAX by priority is also applied (one role per wallet) to avoid compounding multipliers from holding multiple operator roles.

If the same wallet is both a community contributor (B1) and an operator/noder (B2), it may be eligible for both parts of Bucket B, since these categories reflect different types of contribution. The No Stacking rule still applies separately within B1 and within B2.

B1 - Discord Community Roles (70% of Bucket B)

Amount: 91,815,150 AZTEC.

This sub-bucket recognizes ongoing community operations and contribution. Distribution is based on curated Discord role assignments at a fixed snapshot time (see ‘Snapshot and Deduplication’). If a user holds multiple Discord roles, only the highest-weight role applies.

Role group Count (given) % of B1 Pool (AZTEC)
AzMod 8 10% 9,181,515
Language Ambassadors 20 10% 9,181,515
Cypherpunk Chad 20 10% 9,181,515
Aztec OG 819 70% 64,270,605

Included in Aztec OG: Initiated (544) , Archivist (116), Paragon (54), Illuminated (18), Content Chronicler (15), Meme Lord (16), Maestro (56).

Per-wallet formula: each role pool is divided equally among the eligible wallets in that role group at the snapshot.

B2 - Operator Roles (30% of Bucket B)

Amount: 39,349,350 AZTEC.

This sub-bucket rewards infrastructure operators. The term ‘Operator roles’ is used to avoid confusion with testnet validator rewards (Bucket C). If a wallet holds multiple operator roles, it is counted once; the exact rule is defined in ‘Snapshot and Deduplication’.

Roles (counts provided): Homestaker Sentinel (14), Proposer Commander (15), High Attester (14), Queue Master (21), Prover (44), Gnosis Sequencer (317).

Rule Pool (AZTEC) Distribution
Gnosis Sequencer role group 19,674,675 Receives 50% of B2; equal per wallet (count = 317).
Other 5 operator role groups 19,674,675 Share remaining 50% equally across role groups; equal per wallet within each role group.
Other operator role group Count (given) Role group pool (AZTEC)
Homestaker Sentinel 14 3,934,935
Proposer Commander 15 3,934,935
High Attester 14 3,934,935
Queue Master 21 3,934,935
Prover 44 3,934,935

Bucket C (40%): Testnet Validator Rewards

Amount: 174,886,000 AZTEC.

This bucket rewards testnet validators based on objective criteria and is designed to be Sybil-resistant. Eligibility requires: (1) passing KYC (or an equivalent identity verification flow approved by the Foundation), and (2) exceeding an activity threshold of more than 100 validator-relevant transactions/actions during the measurement window. Rewards are distributed equally across eligible wallets.

Per-wallet formula: payout = 174,886,000 / N, where N is the number of eligible validator wallets at the snapshot.

Vesting and Lockups

To balance contributor recognition with market impact, all distributions in Bucket B and Bucket C follow the same schedule. Bucket A (builder grants) remains discretionary and can keep milestone-based vesting as per grant agreements.

Schedule for Bucket B and Bucket C:

  • Cliff: 1 month (30 days) with 0% claimable before the cliff.
  • At cliff: 15% unlocks immediately.
  • Remaining 85% vests linearly over 365 days after the cliff.
  • Claimable(t) = 0 for t < cliff; Claimable(t) = 15% + 85% * min(1, (t - cliff) / 365d) for t >= cliff.

Snapshot, Wallet Binding and Deduplication

  • A single snapshot timestamp/block is used for each list (Discord roles, Operator roles, Testnet validators). The snapshot time is published before voting.
  • Wallet binding: each Discord account must bind exactly one wallet (signed message or official verification flow).
  • Discord roles: if a user holds multiple Discord community roles, apply the highest-weight role only (no stacking).
  • Operator roles: if a wallet holds multiple operator roles, count it once (no stacking).
  • Cross-bucket eligibility: the same wallet may receive from Bucket B and Bucket C if it qualifies independently under each bucket’s rules.

Sybil Resistance and Anti-Gaming Measures

  • KYC gating for Bucket C: only wallets that pass KYC (or an approved identity verification provider) are included in the validator merkle tree.

  • Activity threshold for Bucket C: >100 validator-relevant transactions/actions in the measurement window; exclude pure spam transactions by filtering for protocol-specific validator calls where possible.

  • Time-spread requirement (recommended): require activity on at least 7 distinct days to reduce bursty spam behavior.

  • Role assignment is curated: Discord roles and Operator roles are non-trivial to obtain and are assigned/verified by community governance/moderation processes.

  • Publish methodology and raw lists (or privacy-preserving hashes) prior to voting to allow community review.

Implementation Approach (On-chain)

To keep execution safe and scalable for hundreds or thousands of recipients, the recommended approach is to deploy a governance payload that funds one claim contract (Merkle-based) per distribution list (Discord, Operator, Testnet). Users claim individually, amortizing gas across claimants. The claim contracts may either transfer tokens directly or create token vault positions that encode the vesting schedule.

Funding source: the payload should pull from the Ecosystem Grants treasury or the Foundation-controlled grants factory, mirroring the execution pattern used for prior governance payloads.

Governance lifecycle and voting parameters should follow the precedent and format used in the reference TGE proposal (payload deployment, sequencer signaling, proposal creation, voting, execution delay, execution).

Rounding and Leftovers

All calculations must be implemented in wei. Any remainder dust from integer division should be explicitly handled in the payload. Recommended policy: send remainder to Bucket A (builder grants) to avoid unallocated dust.

References

4 Likes
2

Spending millions of tokens on Discord role grinders? Come on mate, it’s not 2021 anymore. That meta has long come and gone. I could maybe see an argument for paying moderators if there was a prior agreement about this.

Testnet operators I can see some small argument for that. However as far as I know it was never said to be rewarded then or now - what’s the rationale for retroactively changing this? The reward, as far as I saw it, was that you learned to be comfortable with the tech stack and had the opportunity to be be a genesis validator.

This entire proposal is a lot of work, potentially affecting thousands of users, lots of calculations and methodologies etc. What does Aztec, the protocol, stand to gain from this expense both in token and person-hours?

I appreciate the detail and care in the proposal, but in the current market conditions I would vote for guarding token emissions very carefully. This proposal is straight up a loyalty reward scheme, which really seems at odds with the care and rigor taken in the genesis sale, public sale, team vesting and so on.

8 Likes
3

sorry for the lack of text, but all of this makes very little sense. thats it. thats the text. and i dont mean literally. the words make sense. its just doesnt make sense in any other way. none of it

3 Likes
4

This feels like a fair and well-deserved allocation of the remaining grants - recognizing the people who actively contributed to the ecosystem and supported the testnet while still preserving resources for future builders is exactly how it should be handled.

1 Like
5

I think this proposal is a good and timely step for the Aztec Network ecosystem. Over the past months, many people in the community have spent real time helping the project grow in different ways. Some ran nodes and participated in the testnet, others built tools or tested the network, and many helped by answering questions, making guides, or staying active enough to earn roles in the community. All of these efforts helped Aztec become more known and more welcoming to new users.

Because of that, allocating a portion of the remaining ecosystem grants to contributors, operators, and validators makes sense. A lot of people supported the project early on, and recognizing that effort can help keep the community motivated and involved as the project continues to develop.

I also hope the team continues to carefully consider this proposal and look at different angles, especially ways to distribute rewards that won’t easily affect the token price in the market. If handled well, this can both reward genuine contributors and help maintain long-term stability for the ecosystem.

Overall, recognizing the people who helped Aztec grow from the early stages can strengthen the community and encourage more people to invest, explore, and be part of the ecosystem.

6

this is actually a brilliant proposal. Thanks guys! dont pay attention to bots

7

Guys, according to this proposal we would actually be allocated a nice amount of tokens. And we would probably stake most of them with our own nodes. But can you imagine the selling pressure this will cause on such a market? It would be insane! This is why im not understanding it

2 Likes
8

As someone who would benefit greatly from this one passing, we would never support it. As mentioned, this is an airdrop repackaged as a “grant”.

9

Simple and fair: people should be rewarded for their time and effort. Moderators, testnet validators, and active community members(OG) kept this place alive pre-TGE — this proposal makes sure they’re not forgotten.

To those asking “what does Aztec gain from this”: you gain a motivated community that feels valued. The vesting schedule (1-month cliff + 1-year linear) is designed specifically to avoid market dumps. Real contributors will hold. This isn’t 2021 airdrop farming, it’s fair recognition.

Also appreciate the attention to detail — the no-stacking rule for roles, separate buckets for Discord vs operators, and the 30/30/40 split. Reserving 30% for future builders keeps the grants program alive. Clean execution. Support this take.

1 Like
10

add a 36 month cliff release to this and see if people still up for it =)

3 Likes