Cardano Reward System

Build Estimation / Scoping

Scoping what it would take to implement the solutions this report recommends

This page sizes the work that building the report's recommended reward-system change would involve — the engineering, data-format, and governance tasks it would touch — so the community can weigh the size of the job before deciding whether to take it forward.

Everything before this page explained what is wrong with today's staking rewards and what to change. This page asks the next question: what would it cost to build that change? It names every task the work would require, gives a first-pass estimate of the team size and time the build would take (§10), and leaves precise costing to the engineering teams who would carry it out.

Stage 01 The Intended Game Design intent · baseline Stage 02 Mainnet evidence Observations & Findings Stage 03 Induced problem proto-CPS Stage 04 Solution Design Directions & milestones Stage 05 CIPs (Evaluation) IntersectMBO governance
Stage 06 Build Estimation / Scoping Build sizing · this page

Table of Contents

1. What we are building

The problem. Today a pool's reward comes from two things added together: a size reward (bigger pools earn more — the larger part) and a pledge reward (a bonus for operators who stake their own ADA). The report shows the pledge-reward formula is broken: it punishes small pools, and it perversely pays some operators more for pledging less. As a result, small honest pools can't earn a living, and the pledge bonus mostly goes unspent.

The fix — four moves. The report recommends a "gradual repair" made of four steps, applied in order. In plain terms:

  1. Fix the pledge-bonus formula. Replace the mis-shaped formula with a better one that stops punishing small pools and stops rewarding under-commitment. (A rule change — needs a hard fork.)
  2. Turn the dial toward pledge. Nudge the balance setting a₀ so commitment counts for more and raw size counts for less. (Just turning an existing dial — a governance vote, no hard fork.)
  3. Add a survival slice for small pools. Carve out a third part of the reward — λ_viability — reserved to keep small but genuine pools financially viable. It is paid for by trimming the size reward, not by printing new ADA, and a pool only receives it if its operator actually pledges. (A new part of the formula — needs a hard fork and a new protocol parameter.)
  4. Put the idle pledge budget to work. Today about 95.6% of the money set aside for pledge bonuses is never paid out — it just flows back to the reserve. Moves 1 and 2 fix this automatically; there is nothing extra to build, only a result to confirm.

The slightly more precise version (for the technically inclined): the reward envelope is E = λ_size·ν + λ_pledge·A(ν, π). Move 1 redesigns the pledge-bonus function A. Move 2 shifts the λ_size / λ_pledge balance via a₀. Move 3 turns the two-part split into a three-part split λ_size + λ_pledge + λ_viability (still totalling 100%), where λ_viability is conditional on the operator's pledge. Move 4 is the automatic consequence of 1 and 2 — the dormant λ_pledge budget finally gets distributed. All four act on the reward formula before the operator/delegator split, i.e. on how the total pool reward is calculated, not on fees.

What is not part of this build (each is a separate, later piece of the Solution Design):

About the fee-related CIPs (CIP-0023 and CIP-0082 stage 2). The report's CIP review credited CIP-0023 for correctly spotting a real problem — that the flat per-pool fee (minPoolCost) hits small pools hardest — and even found its mechanism partly helps (it narrows the unfairness between small and large pools from 38× to 13×). So it is worth being clear how that fits here:

2. Why this needs a hard fork

A quick definition: a hard fork is a change to the network's rules, as opposed to a parameter update, which only changes a setting within limits the rules already allow. Every node must adopt a hard fork together at an agreed time; a parameter update just needs a governance vote.

The reward formula is a rule. Every node recalculates rewards the same way at the end of each epoch — that agreement is the consensus. Moves 1 and 3 change how rewards are computed (a new pledge-bonus shape, and a new third slice), so they change the rule and therefore require a hard fork. If some nodes used the old formula and others the new one, they would compute different rewards and the network would split. This is not a detail that can be reduced or worked around; it is the nature of the change.

Two specifics worth flagging up front:

3. The ledger

The ledger is the core software (cardano-ledger) that computes rewards each epoch. This is where the heart of the change lives. All of the following ship together in a new "ledger era" (the versioned rule-set a hard fork switches the network into).

4. CDDL

CDDL (Concise Data Definition Language) is the schema describing exactly how on-chain data is encoded as bytes. Adding a new protocol parameter means teaching this schema (and the read/write code) about it.

5. Constitution & guardrails

A reminder: guardrails are limits, written into the Cardano Constitution, on how far each parameter can be moved; they are enforced on-chain by the Guardrails Script. Reference text of the Constitution: https://raw.githubusercontent.com/IntersectMBO/cardano-constitution/refs/heads/main/cardano-constitution-2/cardano-constitution-2.txt.md.

The Constitution's Appendix I already sets guardrails for the existing reward parameters — for example a₀ (codes PPI-0104, limited to 0.1–1.0) and minPoolCost (codes MPC-0103, limited to 0–500 ADA). The new dial slots into the same machinery.

6. Surrounding software

The ledger does the calculation, but a lot of other software displays, queries, or re-implements it. Each needs a matching update once the new rules ship.

7. Specification & testing

Cardano's rules are also written down in a precise, machine-checked formal specification; it and the test suite must move in step with the code.

8. Rollout order

The steps are sequenced so the network never runs an untested reward rule:

  1. Agree the design, write the CIP, get it ratified. Lock down the repaired formula, the survival slice and its pledge condition, and the a₀ target. (The repaired formula must be settled now, because it goes live at the fork — it can't be tuned afterwards.)
  2. Set the guardrails. A guardrails-update action defines the legal range for the new dial and any reworded a₀ rule.
  3. Ship the hard fork. It carries the new formula and the new dial — with the survival slice defaulted to off, so rewards are unchanged on day one.
  4. Turn the dials on, by vote. Governance gradually raises a₀ (move 2) and the survival slice (move 3) toward their target values — visible on the monitoring dashboard once that exists.
  5. Watch and adjust. Later votes fine-tune the dials as evidence comes in.

A bonus lever that needs no building. Separately from all of the above, governance can lower minPoolCost (the flat per-pool fee, currently 170 ADA, legal range 0–500) by an ordinary vote. This is the simple step that CIP-0023 was pointing at for small-pool fairness. It pairs naturally with the four moves but requires no ledger, data-format, or Constitution work — which is why it sits here in the rollout rather than in the build list.

9. Work-item summary

Every build item, with where it lives and whether it requires a hard fork. "Follows era" means the item isn't itself a rule change but has to ship alongside the new rules.

# Work item Where (software / document) Kind Needs a hard fork?
3.1 Replace the pledge-bonus formula (move 1) cardano-ledger Reward rule ✅ Yes
3.2 Add survival slice + its new dial + pledge condition (move 3) cardano-ledger Reward rule ✅ Yes
3.3 Re-wire the size/pledge balance (move 2) cardano-ledger Reward rule ✅ Yes (the dial itself is turned later, by vote)
3.4 Confirm idle pledge budget now pays out (move 4) cardano-ledger Verification ✅ Yes
3.5 Wire into epoch reward calc + reporting cardano-ledger Reward rule ✅ Yes
4.1–4.3 Data-format (CDDL) slot for the new dial cardano-ledger Data format ✅ Yes
5.1 Guardrail for the new dial (Appendix I) Constitution Constitution ✅ Yes (via the fork's guardrail action)
5.2 Re-word the a₀ guardrail for the 3-way split Constitution Constitution ✅ Yes (via the fork's guardrail action)
5.3 Update the Guardrails Script Constitution (on-chain program) Constitution ✅ Yes (via the fork's guardrail action)
5.4 Run the hard-fork + guardrail governance actions Governance Governance ✅ Yes
5.5 Document that no core-Constitution amendment is needed CIP / governance Documentation
6.1 Node adopts the new rule-set cardano-node Surrounding software ✅ Yes
6.2 CLI: propose + read the new dial cardano-cli Surrounding software Follows era
6.3 Chain database columns for new dial + rewards cardano-db-sync Surrounding software Follows era
6.4 Reward calculators / analytics reward-calculator + community Surrounding software Follows era
6.5–6.6 Wallet/explorer display + operator docs ecosystem Surrounding software / docs Follows era
7.1 Update the formal specification formal-ledger-specifications Specification ✅ Yes
7.2 Old-formula baseline + new-formula correctness tests cardano-ledger tests Testing ✅ Yes
7.3–7.4 Targeted rule tests + data-format tests cardano-ledger tests Testing ✅ Yes
7.5 Update the written design document reward-system-spec Documentation
8.4 Votes to turn on a₀ + survival slice Governance Governance ❌ No (after the fork)

The only steps that are not part of the hard fork are the votes that turn the dials on afterwards. Everything else is the build.

10. Effort, team, and timing

The sections above name the work. This one sizes it and places it in the calendar: a team estimate, a duration, and a recommendation on when to do which part.

Team and duration. The work in §3 through §7 — the ledger change, the data-format work, the Constitution and guardrails code, the surrounding software, and the specification and tests — is a six-month project sized at 4–6 full-time-equivalent (FTE) engineers. An FTE is a unit of sustained effort: one person working full-time for the period. The actual roster is larger — specialists in the formal specification, the data format (CDDL), the Constitution guardrails, and the chain database (db-sync) rotate in for the stage that needs them and back out — and their combined load across the six months averages 4–6 full-time engineers. That span covers preparation, implementation, and testing: the engineering build, end to end.

Two things sit outside that six months, because they run on the network's clock rather than the team's: the time governance actions take to be approved, and the scheduling and coordination of the hard fork that ships the change (§8).

On costing. This estimate is in people and months. A figure in money depends on who staffs the work and at what rate — which the engineering teams that would carry it out are best placed to set. The 4–6 FTE over six months is the unit a budget can be built from.

Timing — write the CIP in 2026, build it after Dijkstra. 2026 is the year to write the CIP and carry it through ratification. The build comes later. Two reasons set this order:

So the build targets a ledger era following Dijkstra: the CIP ratified in 2026 becomes the specification that a later era's hard fork implements. This matches the rollout sequence in §8 — agree and ratify the design, then ship the fork — and places the six-month build in the window where the engineering capacity for it is free.

Question Answer
How much effort? 4–6 FTE engineers; a larger roster rotating through stages
How long? ~6 months — the build alone (§3§7)
Outside that estimate Governance approval time; hard-fork scheduling and coordination
When to write and ratify the CIP? 2026
When to build and ship it? A ledger era following Dijkstra

11. Open design choice

There is a genuine fork in the road that the CIP must settle before building, because it changes part of the work above.

Both need the same core work (the repaired formula, a new dial, data-format and guardrail changes, a hard fork). They differ mainly here:

Recommended: slice inside the formula Alternative: separate channel
The new dial a "viability-influence" dial (b₀) a single share dial (μ)
Constitution work new dial plus re-wording the a₀ guardrail (item 5.2) just the new dial; a₀ left alone
Can it ship fully "off"? only the slice can; the repaired formula is live at the fork the whole channel can default to off
Effect on delegator rewards the slice and delegator rewards share one budget kept separate — survival support never competes with delegator yield

Why it matters for this page: if the project ever switches to the channel design, items 3.2 and 5.2 are the ones that change. Which design is the real intention is best confirmed with the report's authors — see the note in the project's review state.

Glossary

The terms this page uses, grouped by topic. Each is also defined inline the first time it appears in the text.

The staking system

The reward formula (how each pool's pay is calculated)

How Cardano changes its rules (the "change machinery")

Status: First-pass scope, 2026/06/10. Sizes the report's recommended four-move reform (Solution Evaluation §4 / Solution Design Milestone 1). Lists the build, with a first-pass team-and-duration estimate (§10); leaves precise costing to the engineering teams. To be refined as the CIP takes shape.

Reader Feedback

Comments and reactions are anchored to this page. Sign in with GitHub to post — threads live in the project Discussions.