Key points
- Cardano is preparing a small, purely technical update to its Constitution ahead of the Dijkstra era, so the network's newest capabilities are fully governable from day one.
- Dijkstra introduces major upgrades, including Ouroboros Leios and nested transactions, each bringing new updatable protocol parameters.
- The Constitution only lets governance adjust parameters that are explicitly listed in its Guardrails, so the new parameters need to be added there to stay tunable.
- The update is deliberately narrow: it adds the new parameters and their Guardrail ranges and changes nothing else, including no tenets, roles, thresholds, or rights.
- The plan is one cohesive proposal covering all Dijkstra parameters, developed with the Parameter Committee, with DReps ratifying and the Constitutional Committee confirming constitutionality.
- The target is to submit no later than epoch 655 (11 September 2026), and the community is invited to shape the proposal now, well before any vote.
The Dijkstra era will bring major upgrades to Cardano, including Ouroboros Leios and nested transactions, with further features still being evaluated as the scope is defined. Before those features can be governed the way they are designed to be, Cardano needs a small but essential update to its Constitution.
Why the update is needed
Each of these new features introduces new updatable protocol parameters. Cardano's Constitution follows a strict rule: any protocol parameter that is not explicitly listed in the Constitution's Guardrails cannot be changed by governance at all. That is a deliberate safety property, but it means that if a feature ships parameters the Constitution does not yet recognize, those parameters would be frozen the moment they go live.
This is exactly the case the Constitution is built to handle. Features like Leios are designed to be tunable, so the network can respond to changing transaction demand, and so governance has a lever to act quickly if something needs adjusting. The Constitution itself anticipates this: it requires that any new parameters introduced by a hard fork be added to the Guardrails, with sensible ranges defined for each. Our job is simply to do exactly what the Constitution asks, before the hard fork rather than after.
This amendment is purely technical, and we are keeping it strictly limited to the new protocol parameters and their Guardrails, nothing more. It does not change any of the Constitution's tenets; the roles of DReps, SPOs, or the Constitutional Committee; voting thresholds; or any existing rights. Keeping the proposal this focused is deliberate: a narrow, technical change is one the community can evaluate clearly and ratify on its own merits, without unrelated matters riding along and complicating what should be a straightforward step.
The process and who is involved
The work proceeds in stages. First, the Dijkstra scope is finalized, specifying exactly which parameters are involved. Our intent is to introduce the parameters for all Dijkstra features in a single Constitution change: one cohesive proposal, rather than several, to keep things clear and keep the decision clear for DReps. Next, Intersect’s Parameter Committee works out the Guardrails for each parameter. Then the Plutus team produces the updated Guardrails Script that is submitted alongside the Constitution, while we prepare the proposal rationale in parallel. Ultimately, DReps vote to ratify, with the Constitutional Committee confirming constitutionality.
Timelines
Our target is to submit this governance action no later than epoch 655 (which begins 11 September 2026, 21:44 UTC), and the earlier the better. Ratifying well ahead of Dijkstra ensures the hard fork itself proceeds with full constitutional clarity, and that the new parameters are governable from the very first block after activation.
Get involved
We are starting this conversation now, on purpose. This is an open process, and it belongs to the whole community, not just the teams doing the drafting. Long before any governance action is submitted, we want everyone to understand why the update is needed, what it contains, which parameters it introduces, and why each Guardrail is set the way it is. We want your questions, opinions, and contributions to shape the proposal as it takes form, so that by the time it reaches a vote, it reflects a genuine community consensus rather than a finished document handed down for approval.
Watch for the draft, join the discussion, challenge our reasoning, and help us get Cardano ready for Dijkstra together.
