--- title: IPP-001: Initial Ciphernode Rewards Program date: 2026-10-14 --- # IPP-001: Initial Ciphernode Rewards Program## 1\. Summary A time-boxed FOLD reward for ciphernode operators. 12,000,000 FOLD (1.0% of the 1.2B supply) from the Foundation treasury, paid in six biweekly batches on a backloaded Fibonacci schedule (pools 600,000 → 4,800,000 FOLD across the six epochs), in proportion to each **node operator's** ticket-block accrual (credited tickets × blocks; max 8 credits per operator, with a Foundation common-control determination so registrations under common control accrue as a single operator). Paid as VE-locked FOLD (`createLockFor()` on the Vote Escrow contract), so rewards immediately count as voting power and carry a 30-day unlock. Tracking is manual: no new contracts, no new emissions. ## 2\. Motivation The network — including its own CRISP governance rounds — needs ciphernodes online. E3 requests are currently paused or minimal, so the existing fee-share rewards (`BondingRegistry.distributeRewards`) pay almost nothing. This program closes that availability gap bounded in time and budget. The motivation is also honest about the concentration problem this proposal has to absorb without new machinery: a single operator recently stood up 28 nodes (5 tickets each) — at the time of writing, roughly half of all ciphernode registrations and about 60% of ticketed stake. Those bonds are reward-farming posture, not additional capacity. The accrual rules below are written against exactly this: rewards accrue per **node operator**, with a per-operator cap and a Foundation common-control determination. ## 3\. Design **Program window.** 12 weeks from T0 — the protocol's mainnet launch, i.e. the deployment block of the Interfold mainnet contract, verifiable on-chain (the earlier FOLD mint/TGE block is not the reference) — in 6 epochs of 14 days. The program is retroactive by design, to reward operators who stood up ciphernodes at launch with no subsidy promised. Epochs already elapsed at execution settle in sequence at the start, each as a distinct, separately published event; remaining epochs then run on the normal biweekly cadence. **Epoch schedule (Fibonacci backload).** The 12,000,000 FOLD pool is split across the six epochs by Fibonacci weights `1 : 1 : 2 : 3 : 5 : 8` (20 units; 1 unit = 600,000 FOLD). | Epoch | 1 | 2 | 3 | 4 | 5 | 6 | | ----------- | ------- | ------- | --------- | --------- | --------- | --------- | | Weight | 1 | 1 | 2 | 3 | 5 | 8 | | Pool (FOLD) | 600,000 | 600,000 | 1,200,000 | 1,800,000 | 3,000,000 | 4,800,000 | The early epochs reward the operators who stood up ciphernodes before any subsidy was promised; the later epochs backload the pool to pull in new capacity as the program becomes known. **Eligibility ("active").** An operator is *active* at a given block if it is registered in the CiphernodeRegistry; bonded at or above the active-maintenance floor (`isCiphernodeBonded`); holds the minimum sortition tickets; and is not banned by the SlashingManager. Predicate failures at a given block cost 0 for that block's accrual. **Accrual (ticket-days, per operator, per-block, capped at 8 credits).** The **node operator** is the unit of accrual. At every block, an operator's *credited ticket balance* is the lesser of (i) **8** and (ii) the sum of the on-chain ticket balances of the nodes it operates that pass the "active" predicates in that block. The epoch's pool is split in proportion to each operator's **ticket-block** total — the sum, over every block of the epoch, of its credited balance. A credited ticket held the whole epoch earns that epoch's full block count; one present only at the epoch's final block earns 1, so a last-block snipe is exactly priced, not approximated. (At the network's 30-second block time, a 14-day epoch is 40,320 blocks.) The cap is per operator, not per node: the 28-node group in §2 accrues at 8 — the same as a single node holding 8 tickets — while an operator with 3 nodes × 3 tickets accrues at 8 (3+3+3 = 9, capped). Once an operator's credited balance hits 8, further tickets or further nodes buy lottery weight only, not program income. Tickets above the cap keep their full protocol role (Draw/committee lottery weight is unchanged); only program accrual is capped. Settlement remains manual: a straightforward script over on-chain state plus the operator attribution — recomputable by anyone with an archive node. **Node operator and common control.** The default operator identity is the bond owner of record. The Interfold Foundation may, at its discretion and on the balance of the available evidence, treat two or more registrations as a single node operator where they are under common control, so that the 8-credit cap applies to the group in aggregate. The determination may consider, among other evidence: on-chain relationships (bond owners, funding flows, registration timestamps and ordering), infrastructure and network evidence (shared infrastructure, host signatures, geographic consistency), operational patterns, and public information. The Foundation records each determination, with a concise explanation, in the applicable public settlement sheet before that epoch's 48-hour dispute window; the existing dispute process applies to these determinations as to all sheet contents. The consequence of a common-control determination is only the cap: a farming cluster accrues no faster than any other 8-credit operator — the same 8 credits a single honest node holding 8 tickets would earn — while carrying the bond and slashing cost of every registration in the cluster. This determination is specific to IPP-001. It creates no permanent protocol-level operator limit and does not alter node registration, ticket balances, Draw or committee-lottery weight, protocol rewards, or slashing. It exists because IPP-001 is a one-off program tracked manually, and its distortion was introduced ex post — new registrations reacting to an announced subsidy, not to the protocol's intended availability economics. **Transparency.** Each epoch the Foundation publishes a settlement sheet on IPFS and posts its CID to Foundation channels: epoch start/end blocks; the node→node-operator attribution (defaulting to bond owner, with any common-control determination and its concisely stated basis); each operator's per-block credited balance series (or, at minimum, its ticket-block total and the state at each 24-hour boundary); the pool total; and each operator's entitlement. A per-block series is recomputable by replaying the chain, so the sheet's job is to make that recomputation cheap. Corrected sheets are allowed before settlement; disputes about network state are settled by the on-chain record. **Settlement.** Six batches — that epoch's Fibonacci-weighted pool — each after that sheet's 48h dispute window. Payouts are delivered as **VE-locked FOLD**: the treasury calls `createLockFor()` on the Vote Escrow contract for each recipient (lock term 30 days). Immediately on distribution the locked FOLD counts as the recipient's voting power (delegated to the recipient), and no recipient can sell the rewards until their 30-day unlock elapses — which defers and stretches all program-driven supply out of the distribution date. There is no claim flow to miss and no new contract to maintain. **Why biweekly batches** (and not one lump sum, or weekly): the 30-day VE lock is the primary sell-pressure control — no reward can be sold on its distribution date, and unlock dates are staggered as recipients claim. Batching addresses what the lock doesn't: keep the *events* themselves (six sheets, six payments) small and individually legible rather than compressed, and bound the treasury's operational steps. Finer cadence (e.g. weekly) doubles settlement cost while each operator's income per period is unchanged, so the cost-benefit favors biweekly. If per-batch impact still bothers the community, the schedule (window length, batch size) is a parameter tweak — the accrual rule is not. ## 4\. Budget and funding Total pool: 12,000,000 FOLD = 1.0% of the 1.2B total supply. Source: Foundation treasury — no new emissions, no mint. It will be necessary for the foundation to purchase ~$250k-$300k worth of FOLD from the open market, to ensure it has sufficient liquid FOLD to allocate to the ciphernode rewards program. The foundation treasury holds 39.06% of supply with linear unlock from Sep 1, 2026, the remaining FOLD requirement will be allocated from this supply as it becomes available. Indicative economics — per-credited-ticket payout for a credited ticket held the full epoch (a ticket staked for a fraction earns that fraction), illustrated at the 2M FOLD average epoch pool. Actual per-ticket payout scales with that epoch's pool — 600,000 FOLD in the early epochs up to 4,800,000 in the last, so the per-ticket rate rises with each epoch. | Credit ticket pool (credited at min(share, 8) per operator, held full epoch) | Payout per credited full-epoch ticket | | ---------------------------------------------------------------------------- | ------------------------------------- | | 10 credited tickets | 200,000 FOLD | | 100 credited | 20,000 FOLD | | 1,000 credited | 2,000 FOLD | | 10,000 credited | 200 FOLD | The cap means the denominator is the *credited* ticket pool, which grows with the number of **distinct operators** — not with registrations, and not with sUSDS parked in one. A 28-node, 140-ticket registration cluster is 8 credited tickets; the same 140 tickets across 140 operators would be capped at 1,120. At 1,000 sUSDS per ticket, an operator crediting its full 8 accrual-position tickets has 8,000 sUSDS at risk on top of the 32,000 FOLD bond per operated node; going beyond 8 credits buys lottery weight only, not program income. The 30-day VE lock means a settlement's rewards cannot be recycled into tickets before their unlock (~2 epochs later), so compounding is possible across the program but deliberately cascade-limited. ## 5\. Risks and mitigations | Risk | Mitigation | | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 12M FOLD sold in one window | 30-day VE lock (rewards can't be sold on distribution date) plus six scheduled batches (600k → 4.8M FOLD), each with a public settlement sheet ahead of its payout | | Reward economy farmed by ticket sybils | Per-operator 8-ticket cap + Foundation common-control determination: a registration cluster accrues at 8 credits max (the 28-node group accrues as one operator, exactly what a single 8-ticket node would earn), while paying the bond and slashing cost of every registration. Protocol Draw/lottery weight of those nodes is unaffected — only program accrual is | | Last-minute register/unregister | Credits tickets only from the block they exist — a last-block snipe earns 1/40,320 of a full-epoch share per ticket (30-second blocks); fully on-chain, retroactively verifiable | | Manual bookkeeping error | IPFS-pinned sheet (CID posted) recomputable from per-block on-chain state; 48h dispute window; payout txs recorded against the CID | | Rewards funding new voting power | Expected and intended: rewards are VE-locked FOLD and count as voting power on distribution (delegated to the recipient, per the locked-FOLD voting rules). 12M of new committed FOLD is a deliberate incentive this program aims to create | | Slow vote collapses epochs into one week of payments | Acceptable for a first iteration and no pool or rule changes; if it happens, publish the compressed batch schedule with dates so the sell events stay individually visible | | Slashing during the program | Unchanged — a slashed or banned operator accrues 0 from the block of the ban onward; prior accruals stand | ## 6\. The proposal Approve the **Initial Ciphernode Rewards Program** under these parameters: | Parameter | Value | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Window | 12 weeks from T0 (the Interfold mainnet deployment block) in 6 × 14-day epochs | | Pool | 12,000,000 FOLD (1.0% of total supply), from the Foundation treasury | | Per epoch | Fibonacci-weighted pool (1:1:2:3:5:8 → 600k / 600k / 1.2M / 1.8M / 3M / 4.8M FOLD), split in proportion to ticket-blocks per node operator (credited tickets × blocks) | | Cap | Max 8 credited tickets per node operator per block (credits above 8 do not accrue; Draw/lottery weight unaffected) | | Common control | Foundation may treat common-controlled registrations as one operator, so the 8-credit cap applies to the group in aggregate. Recorded in the settlement sheet; 48h dispute window applies | | "Active" | Registered, bonded ≥ active-maintenance floor, minimum tickets, not banned | | Settlement | Manual: IPFS-pinned sheet per epoch → 48h dispute window → treasury calls `createLockFor()` for each recipient (30-day VE lock) | | Timeline | Overdue epochs settle in sequence at execution; remaining epochs on cadence | | End | Program ends after Epoch 6; any change after execution requires a new proposal | ## 7\. Future iterations (out of scope) * Mechanized on-chain delivery (claimable pool or settled credits). * Continuous or duty-weighted accrual (uptime, DKG, decryption shares), ahead of where fee-share economics are heading. * Concentration controls beyond the per-operator cap: protocol-level de-sybilization, sustained capacity floors, or bond-owner identity requirements, if the 28-node pattern persists or recurs. * Automatic sunset criteria (e.g., ends when sustained E3 throughput crosses a threshold). ## 8\. Conclusion The network needs ciphernodes online now, and usage revenue can't pay for that yet. This proposal spends 1% of supply over 12 weeks, run on existing tooling and on-chain reads, with audit via IPFS-pinned settlement sheets. Parameters are fixed at execution; changes go through the normal governance path.