Issue #21 closed like this: “The deadline is 06:44:51 on the morning of September 2, Japan time.”
That deadline came. And the two proposals that closed at the very same instant ended differently.
The Constitutional Committee update passed. DReps came in at 71.95%, SPOs at 56.54%. The thresholds were 67% and 51%, so both were cleared. At the time of issue #21 the figures were 64.24% and 35.47%, and we wrote that the gaps were “2.76 points and 15.53 points.” Those gaps closed in the four days that remained.
The proposal to lower minPoolCost to 75 ada expired. But look at *how* it fell. On the DRep side it reached 68.57%, above the 67% threshold. The side that did not clear was the SPO side alone, which stopped at 34.5%. Ratification requires both, so one side is not enough.
This week we look at how those two came apart — including the exact times at which the votes landed.
Executive Summary
- The Constitutional Committee update passed: DRep 71.95% (165 votes, threshold 67%), SPO 56.54% (302 pools, threshold 51%). Koios
proposal_listshowsratified_epoch: 653. minPoolCostexpired:expired_epoch: 653. DReps reached 68.57%, above the 67% threshold, but SPOs stopped at 34.5%, short of 51%.- It did not fall because of opposition: exactly one pool voted No on the Committee update, right to the end. Opposition to
minPoolCostgrew from 28 pools to 59, but abstentions and non-voters remain far larger than that. - The last vote landed 69 seconds before the deadline: the final vote on the Committee update was recorded at 21:43:42 UTC on September 1 — 69 seconds before the 21:44:51 cut-off. For
minPoolCostit was 44 seconds. Votes recorded after the deadline: zero, on both. - Half the votes arrived in the final epoch: of the 521 votes on the Committee update, 262 (50.3%) landed during the five days of epoch 652.
- Enactment is on the morning of September 7: ratification is done, but
enacted_epochis still null. Enactment happens at the start of epoch 654 — 06:44:51 on September 7, Japan time. - The committee stays at seven: three removed, four seated with terms to epoch 799 (two of them renewals). Together with the three whose terms run to epoch 726, that makes seven, satisfying the minimum size of five.
- Three numbers did not change:
minPoolCoststays at 170 ada. The transaction memory limit stays at 16,500,000 and the block limit at 72,000,000. - Midnight merged MIP-0016 “NIGHT Staking”: merged on September 1. The MIP count went from 15 to 16.
- Hydra disclosed a critical vulnerability: on September 2,
GHSA-cg83-6w6r-6hx3(severity: critical) and the fix, 2.4.1, were published together. The release states plainly: “All operators running 2.3.0 or 2.4.0 must upgrade immediately.“ - The tools in your hands were all updated at once: Daedalus 11.3.0 (DRep directory; support moved to Se7en Labs), Lace 2.2.3 (fixes DRep data signing in governance tools), Amaru’s second public beta, and cardano-cli 11.2.3.0 / 11.2.3.1 (the Dijkstra era subcommands are now a full set). All between September 1 and 4.
- The market ran the other way from last week: ADA +4.49% on the week, NIGHT +9.08%. BTC +2.54%, ETH +0.59%.
1. Market Pulse
Our fixed morning observation, August 29 to September 5.
| Asset | 8/29 | 9/5 | Week |
|---|---|---|---|
| ADA | $0.202420 | $0.211514 | +4.49% |
| BTC | $77,696 | $79,667 | +2.54% |
| ETH | $2,438.85 | $2,453.16 | +0.59% |
| NIGHT | $0.0193916 | $0.02115339 | +9.08% |
The four September 5 figures were taken together at 07:07 Japan time.
Issue #21 read: “BTC and ETH are roughly flat, and only ADA and NIGHT are down double digits.” This week that shape is simply inverted. All four are up, and ADA and NIGHT rose more than BTC and ETH. The two that fell hardest last week recovered the most this week.
The same caution as last week applies here. A recovery does not tell you why. Cardano had a large piece of news this week — a governance deadline and its outcome — but a proposal that passed and a proposal that expired were confirmed on the same day. Price cannot tell you which of the two it was responding to.
NIGHT’s market-cap rank moved from 126 at the time of issue #21 to 120.
2. The Deadline Arrived
First, what exactly closed.
As established in issue #21, the deadline for both proposals was “the instant epoch 653 begins.” Koios returns 1788299091 as the start of epoch 653, which converts to 21:44:51 UTC on September 1, 2026 — 06:44:51 on September 2 in Japan.
Whether that timestamp actually functioned as the cut-off can be checked against the voting record itself. We pulled every vote on both proposals and compared each recording time (block_time) against 1788299091.
Zero votes were recorded at or after the deadline, on either proposal.
The deadline worked exactly as written.
This timestamp also appears in Cardano’s own official posts. Two of them, on August 26 and August 28, give the voting deadline as 21:44 UTC on September 1, and explain that if it passes it “will be ratified by the epoch 653 boundary (September 1)” and “enacted at the 653-to-654 boundary (September 6).” The “the deadline is September 6” phrasing we rejected in issue #21 now reads naturally as the enactment date mistaken for the deadline.
3. The Committee Update Passed
Koios proposal_list returns ratified_epoch: 653 for Update Constitutional Committee 2026. It was ratified.
Here are the final numbers (taken 07:03 JST, September 5, 2026).
| Side | Final | Threshold | Margin | Issue #21 (8/29) |
|---|---|---|---|---|
| DRep Yes | 71.95% | 67% | +4.95 pt | 64.24% |
| SPO Yes | 56.54% | 51% | +5.54 pt | 35.47% |
In vote counts, that is 165 DRep votes and 302 pools. Issue #21 had 129 and 179, so the final four days added 36 DRep votes and 123 pools.
The strongest point in issue #21 was that the missing share was not opposition but non-voting: 24.45% of unvoted SPO delegation would carry the SPO side, and 8.46% would carry the DRep side.
In the end, it was exactly that unvoted share that moved.
Exactly one pool cast a No vote, right to the end. DRep No votes came to eight (0.28%). This proposal was never “split.” The only question was whether people would take their seats.
4. The Last Vote Landed 69 Seconds Before the Deadline
Looking at *when* the votes arrived sharpens the picture.
There were 521 votes on the Committee update in total. Here is how their recording times fall.
| Committee update | minPoolCost et al. | |
|---|---|---|
| Total votes | 521 | 444 |
| Last vote | Sep 1, 21:43:42 UTC = 69 s before the deadline | Sep 1, 21:44:07 UTC = 44 s before |
| Second-to-last | 21:35:27 UTC (564 s before) | 21:28:52 UTC (959 s before) |
| After the deadline | 0 | 0 |
| Cast during the final epoch (652) | 262 (50.3%) | 141 (31.8%) |
| Final 24 hours | 69 | 44 |
| Final 6 hours | 26 | 15 |
Half of all votes on the Committee update arrived in the final five days. And the last one arrived one minute and nine seconds before the cut-off.
This is also the concrete case behind what issue #21 said: “do not design around the boundary.” The vote that landed 69 seconds out did make it, but a vote has to be included in a block. Given block intervals, 69 seconds is inside the range where luck matters. That it made it does not mean there was room.
The distribution says one more thing. Of the 262 votes in the final epoch, 176 were SPO Yes and 46 were DRep Yes. What arrived in volume was support: even in the final epoch, opposition was one SPO vote and four DRep votes. What happened before the deadline was not a clash of views. It was a concentration of participation.
5. minPoolCost Fell on the SPO Side Alone
The other proposal on the same deadline, Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2), shows expired_epoch: 653. It expired.
But the way it fell needs to be split in two.
| Side | Final | Threshold | Verdict | Issue #21 (8/29) |
|---|---|---|---|---|
| DRep Yes | 68.57% | 67% | Cleared | 61.73% |
| SPO Yes | 34.5% | 51% | 16.5 pt short | 26.11% |
The DRep side was over the line. A parameter-change action requires both DReps and SPOs to clear their thresholds. So this proposal expired in the specific shape of “supported by DReps, stopped at the SPOs.”
The SPO breakdown also differs from the Committee update.
- SPOs voting No: 59 pools (28 at the time of issue #21)
- SPOs explicitly abstaining: 41 pools
- Pools delegated to “always abstain”: 548
- Constitutional Committee: 5 Yes, 0 No, 2 not voted
Of the 141 votes in the final epoch, 51 were SPO Yes and 36 were SPO No. Where the Committee update saw a single opposing vote in its final epoch, here support and opposition piled up side by side.
Toward the same deadline, one proposal gathered support, and the other gathered support and opposition together. That is how the two came apart.
One note on the DRep figure appears in the transparency section below. The percentages agree across our two sources, but a one-vote discrepancy remains in the counts, so we do not print a DRep vote count for this proposal.
6. The Numbers That Did Not Change
When an action expires, the values it proposed stay as they are. Here is specifically what stayed.
| Parameter | Current (epoch 653) | Proposed | Difference |
|---|---|---|---|
minPoolCost | 170 ada | 75 ada | −95 ada (−55.9%) |
| Transaction memory limit | 16,500,000 | 17,500,000 | +1,000,000 (+6.06%) |
| Block memory limit | 72,000,000 | 77,500,000 | +5,500,000 (+7.64%) |
| Execution step limits (tx / block) | 10,000,000,000 / 20,000,000,000 | unchanged | none |
Current values come from Koios epoch_params; proposed values from the action’s own param_proposal.
minPoolCost is the fixed minimum a pool receives per epoch. Cutting it from 170 ada to 75 ada bears directly on what small pools effectively keep. With this proposal expired, it remains 170 ada in the epochs ahead.
The memory limits deserve a second look, because the proposed increases are smaller than the framing suggests: 6.06% on the transaction side and 7.64% on the block side. It is called “Part 2,” but the increment is single-digit.
7. The Committee Stays at Seven
It is worth reading what the passed action actually does. Comparing the action body (proposal_description) with Koios committee_info makes it concrete.
Before enactment there are eight registered members, one of whom is resigned. That leaves seven effective members.
| Term expiry | Count | Note |
|---|---|---|
| Epoch 653 | 5 | one resigned; four effective |
| Epoch 726 | 3 | not touched by this action |
The action does the following.
- Removes three, including the member who had already resigned.
- Seats four with terms to epoch 799, of whom two are renewals (members whose terms ran to 653) and two are new.
- Leaves the quorum at 2/3.
So after enactment: the three with terms to epoch 726 plus the four to epoch 799 — seven. The committee_min_size protocol parameter is 5, so this satisfies it.
This also confirms the Intersect statement quoted in issue #21, that failure would take the committee “from seven to three.” Had the four effective members with terms to 653 simply lapsed, only the three running to 726 would remain. Three is below the minimum of five.
Note that we do not print the names of the two new and two renewed members. Koios returns only key hashes, and we could not confirm a primary source tying those hashes to names this week.
8. Enactment Is at 06:44:51 on the Morning of September 7
Ratification and enactment are separate stages.
Koios returns ratified_epoch: 653 and enacted_epoch: null. Ratification is done; enactment has not happened yet.
On Cardano, a ratified action is enacted at the following epoch boundary. Epoch 653 ends at 1788731091, which converts to 21:44:51 UTC on September 6, 2026 — 06:44:51 on September 7 in Japan.
In other words, the new committee composition begins to take effect two days after this article is published.
9. About the “September 6” Reading
Issue #21 noted that some accounts placed the deadline on September 6, and that the primary source gives 21:44:51 UTC on September 1. This week the outcome settles it.
The deadline was September 1. No vote entered either proposal after 21:44:51 UTC on September 1, and both were resolved — one ratified, one expired — on the tally as of that moment.
So what is September 6? It is the day epoch 653 ends. Reading only the date, it is easy to take a record of expiration: 653 to mean “through the end of epoch 653.” It actually means “up to the instant epoch 653 begins.” The difference is five days.
This time, that misreading was the kind of error that costs the opportunity to vote at all. Anyone preparing against a September 6 deadline would not have had a vote counted.
10. Hydra Disclosed a Critical Vulnerability
Outside governance, this was the most operationally consequential primary source of the week.
On September 2, Hydra security advisory GHSA-cg83-6w6r-6hx3 was published. Severity: critical. Four minutes later, the fix — Hydra 2.4.1 — was released.
The advisory title is “An invalid transaction entertaining reapplyTransactions can be used to steal funds.” The release notes put it this way:
All operators running 2.3.0 or 2.4.0 must upgrade immediately. A malicious participant in your head could craft a layer 2 transaction spending your funds with an invalid signature (or a failing script) and trick honest nodes into signing a snapshot containing it.
The cause is stated as well. When confirming a snapshot, hydra-node re-applied the requested transactions through an optimized path that skipped signature verification and Plutus script evaluation, on the assumption that they had already been validated on receipt. An unvalidated transaction could reach that path. 2.4.1 removes the optimization: when processing a snapshot request, transactions are always fully validated.
The upgrade procedure depends on your current version.
- From 2.4.0: a drop-in replacement. No changes to the Hydra scripts, the snapshot signature, or the persisted
hydra.dbformat. - From 2.3.0 or earlier: all of 2.4.0’s breaking changes apply. You must close and fan out any open heads before upgrading.
Two things are worth noticing. First, 2.4.0 itself had shipped only the day before, on September 1 — and it is among the affected versions. It was published as a separate security fix (around incremental commit). A day later, something deeper turned out to be critical.
Second, this advisory does not appear in the same week’s development report. The weekly report covers Hydra’s specification migration and image publishing, but says nothing about the vulnerability. If you actually run Hydra, the primary sources are the release and the advisory.
11. The Tools in Your Hands Were All Updated at Once
Between September 1 and 4, the software that users and operators touch directly was updated across the board. Lined up, it says something about the week.
Daedalus 11.3.0 (September 1). The Governance Center now has a DRep directory. You can search DReps by name or ID, filter by activity status and share of voting power, and sort by voting power or name. Delegation now runs through a confirmation flow that shows the fee, the deposit, and the epoch timing. DRep detail pages show off-chain metadata, anchor verification status, and on-chain provenance. Inactive DReps are visually distinguished from active and retired ones.
The same release moves Daedalus support from IOG to Se7en Labs. In-app help and support links now point to daedalus.support.se7enlabs.com, and the IOG Zendesk portal is no longer the place for Daedalus support. Internally, background process management was rewritten in Rust, with a watchdog supervisor replacing the previous TypeScript cardano-launcher.
Lace extension 2.2.3 (September 1). Described as “a maintenance release focused on data signing for governance dApps.” Signing a comment, a rationale, or a dApp login as a DRep now works with GovTool, dreptalk and Tempo. Because Trezor devices do not support signing plain data, Lace now tells the dApp so up front.
Amaru v10.11.20260903 (September 3, beta). The milestone is “Minimum viable Block producer,” and this is the second public beta. It states that most features of a full relay node are present, and then names two caveats: (1) one of the ledger rules introduced in van Rossem, regarding VRF key uniqueness, is not yet enforced (discrepancies with the Haskell implementation are under investigation), and (2) connections are not yet full-duplex — inbound and outbound run over separate TCP bearers, though they are multiplexed. Minimum requirements are 2+ cores at 2GHz or more, 2GiB RAM, and 20–300GiB of SSD.
cardano-cli 11.2.3.0 (September 3) / 11.2.3.1 (September 4). The dijkstra era subcommand now provides the full command set. Previously only the node commands were available; address, key, genesis, governance, query, stake-address, stake-pool, text-view and transaction now match the other eras. You can also now create protocol-parameter update proposals in the Dijkstra era, including the parameters the era introduces: maximum reference-script size per block and per transaction, and the reference-script cost stride and multiplier. Bugs affecting query kes-period-info and query tip were fixed as well.
Put together, the governance path (Daedalus and Lace) and the groundwork for the next era (Amaru and cardano-cli) each moved forward in the same week, for separate reasons. That the Lace fix addressed a bug which had been blocking DRep signing outright is worth reading alongside this week’s deadline.
12. The Two Proposals Still Open
Two actions remain in flight with a deadline at epoch 656 (06:44:51 on September 17, Japan time).
| Action | DRep Yes (threshold 67%) | Voted No | Committee |
|---|---|---|---|
| Reimburse Ikigai Info Governance Action Deposit (103,000 ada) | 51.14% (102 votes) | 0.06% (4 votes) | 2 Yes, 0 No, 4 not voted |
| Governance Incentives Framework 2026 (4,207,967 ada) | 1.27% (11 votes) | 42.96% (75 votes) | 0 Yes, 3 No, 4 not voted |
The Ikigai action is the one we could not put a number on in issue #21. Our sources diverged beyond tolerance, so we cited Intersect’s 44.47% rather than publish our own figure. This week the fetch went through, and we can report 51.14%. It remains 15.86 points below the 67% threshold.
Governance Incentives Framework 2026 has a clearer direction. DRep support is 1.27%, while voted opposition is 42.96% (75 votes), up from 58 votes last issue. On top of that, the Constitutional Committee has cast three No votes. Among the four actions in view, this is the only one where the committee has voted against.
One more dated item. Applications for Intersect Board Elections 2026 opened at 12:00 UTC on August 31. They close at 12:00 UTC on September 11, voting runs from 12:00 UTC on September 14 to 12:00 UTC on September 25, and results come on September 28. Two member-elected seats, two-year terms. Eligibility includes having served at least one term on an Intersect committee or the board.
13. Development
The primary source is the Essential Cardano weekly development report of September 4. Three areas this week.
Node. The performance and tracing team benchmarked Cardano node v11.1.0. The result: process CPU usage came down, but resident set size went up — and that increase “is being addressed in the v.11.1.1 patch release.” The team also split its beacon benchmark metrics (separating ledger-tick time from disk-access time for UTXO lookups) and replaced the Cairo-based plotting backend with gnuplot to reduce dependencies.
From an SPO’s point of view, the Leios line stands out. They delivered on-disk LedgerDB transaction validation benchmarks, and are continuing work on a self-contained benchmark package that can run on SPO hardware without Nix or network access. The work of making this measurable on your own machine is underway.
Hydra. The specification moved from LaTeX to Typst and was formalized in Agda. They added differential testing between the Hydra node and the validator, along with a machine-checked reference. On the operational side, native Linux ARM64 Hydra node images are now published alongside AMD64.
Research. The second Cardano Vision 26 technical workshop covered data availability — requirements, use cases, and specifications — along with preparing a CPS, roadmap discussion, and implementation handover. It was hosted by IOG’s Fergie Miller and Giorgos Panagiotakos.
Note that Intersect weekly update #127 had not been published as of our retrieval (07:00-ish JST on September 5). The news index and sitemap both top out at #126 (August 28), and the expected URLs return 404. So this issue carries no Intersect primary source for this week.
14. Midnight Watch
This week Midnight moved in the repository rather than on the blog.
MIP-0016 “NIGHT Staking”
On September 1, MIP-0016 “NIGHT Staking” was merged (PR #290). That brings the improvement proposals in mips/ from 15 at the time of issue #21 to 16.
The repository runs two tracks: MIPs (how to change something) and MPSs (what the problem is). On NIGHT staking, the problem-statement side already existed as mps-0034-night-staking.md. With MIP-0016 in, one theme now has both the problem definition and the proposed change.
The same week brought MPS-0038 “Operational Cost of Cardano Observation” (September 2, PR #296), which addresses the operational cost of Midnight continuously observing Cardano — a point that goes to the partner-chain structure itself.
Newly opened and still pending: MPS-035 “Introduce Shielded Note V2” (filed August 31, PR #289).
The official blog
The blog’s only post this week was “Inside Aliit: Everything you want to know” on August 31, introducing the Aliit Fellowship. There are no September posts yet. The most recent substantive piece remains the August 26 “State of the Network — August 2026” covered in issue #21.
So on DUST, the Glacier Drop, or the plan for the next phase, there is no primary source newly confirmable this week. That is why this issue prints no new figures for them.
What can be said about the next phase, “Mōhalu”
Mōhalu is circulating as the name of Midnight’s next phase. It is a real, official phase name: the primary source is the Dev Diary “Testnet-02 Transition & The Roadmap to Mōhalu” in Midnight’s developer documentation (January 27, 2026, by Stevan Lohja of Developer Relations). It positions Mōhalu as the “Incentivized Mainnet” phase, with SPO onboarding beginning, distribution moving off Docker-only to pre-compiled midnight-node binaries, and a full documentation refresh.
We could not, however, confirm any primary statement of timing. Formulations such as “Q2–Q3 2026” did not resolve to a primary source in our search. On August 30 a community forum post appeared titled “Mohalu — when can it be expected?” The existence of a post asking for the date is itself a fair measure of how much is known. This issue gives no timing.
One correction to add on DUST. Sundae Labs’ Capacity Exchange is already running in a limited form. August’s state-of-the-network report states that the Sundae Labs Capacity Exchange “now enables users to settle transaction fees on supported Midnight applications using USDM instead of DUST.” It is not an unimplemented feature waiting on the next phase.
On “RealFi hits mainnet on October 1”
A date circulated this week: RealFi arriving on Cardano mainnet on October 1. Within the range we searched, we found no official statement of that date from either RealFi or Input Output. The origin is a community account’s post on September 2, which subsequent articles cite.
What is confirmable as primary is the official Cardano Forum announcement of August 11, “The RealFi Testnet is officially live – Phase 1 starts now.” This issue does not treat October 1 as an official date.
15. Risk Dimensions
- Hydra (highest priority).
GHSA-cg83-6w6r-6hx3is critical and the impact is theft of funds. If you run 2.3.0 or 2.4.0, you need 2.4.1. Upgrading from 2.3.0 or earlier requires closing and fanning out heads first. Because this is the class of vulnerability that works if a single malicious participant is in your head, being an honest operator yourself is not where the analysis stops. - Technical. The resident-memory increase in node v11.1.0 is stated as being addressed in v11.1.1. Until the patch lands, that is a reason to check your memory headroom. If you are trying Amaru, note that the VRF key uniqueness rule being unenforced is now officially documented as a beta caveat.
- Governance. A vote landing 69 seconds before the deadline looks like success if you only read the outcome, but as a procedure it has no margin. The next dated actions (the two at epoch 656) close at 06:44:51 on September 17, Japan time.
- Structure.
minPoolCostfell in the shape of “DReps over, SPOs under.” That shape implies a resubmission of the same content could stop in the same place. If one comes, the question is how the SPO side’s 51% gets assembled. - Committee. Enactment is September 7. Until then the committee runs in its old composition, still including members whose terms expire at 653.
- Information. With no Intersect weekly update out yet, there is no official summary to read. It is worth checking how the next update frames both the ratification and the expiry.
16. What to Watch Next Week
- Enactment of the committee — 06:44:51 on September 7, Japan time. Check that
enacted_epochfills in with 654 just after the epoch boundary. - The names of the four seated members — this week we could only get key hashes. A primary roster from Intersect would let us print them.
- Intersect weekly update #127 — the official summary of the pass and the expiry, and whether it addresses a
minPoolCostresubmission. - A
minPoolCostresubmission — an action DReps carried and SPOs did not. Resubmitted as-is, or restructured for the SPO side? - The constitutional amendment for Dijkstra — cardano.org wrote on July 10 that submission is “targeted before epoch 655.” Epoch 655 begins at 06:44:51 on September 12, Japan time. The committee taking effect this week is the body that will confirm its constitutionality.
- The two actions at epoch 656 — whether Ikigai (51.14%) reaches 67%.
Governance Incentives Framework 2026already has three committee No votes, so its direction is set. - node v11.1.1 — the patch for the resident-memory increase.
- 2.4.1 adoption, if you run Hydra — how the advisory plays out, and whether further notices follow.
- The Intersect board election application deadline — 12:00 UTC on September 11. How many candidates for two seats.
- What follows MIP-0016 — whether the NIGHT staking proposal moves past Review.
Closing
Issue #21 ended with: “The deadline is 06:44:51 on the morning of September 2, Japan time.”
The votes made that deadline. The Committee update passed at DRep 71.95% and SPO 56.54%, and the final vote landed 69 seconds before the cut-off. 262 of the 521 votes arrived in the last five days.
What issue #21 said — that what was missing was not persuasion but delegation taking its seat — held up. Exactly one pool voted No on this action, right to the end. It was not a divided proposal. It was a late one.
But the other proposal on the same deadline fell differently. The minPoolCost reduction cleared its threshold on the DRep side at 68.57%. Only the SPO side did not. And SPO opposition had grown from 28 pools to 59. That one was not late. It was divided.
Put the two side by side and “SPO turnout is low” stops being a sufficient description. The same low turnout produced one action where support simply had not arrived, and another where opposition accumulated. They are not the same thing. The first responded to outreach. The second, most likely, will not.
And 170 ada is still 170 ada. The transaction memory limit is still 16,500,000. What an expired action leaves behind is the numbers that did not change.
Away from governance, the week held one more deadline: Hydra’s critical. There is nothing to vote on there. If you run 2.3.0 or 2.4.0, move to 2.4.1. That is all it is — but the clock started the moment the advisory went out.
The new committee begins to take effect at 06:44:51 on the morning of September 7, Japan time.
References
- Koios REST API —
tip/epoch_info/epoch_params/totals/proposal_list/proposal_votes/proposal_voting_summary/committee_info(epoch boundary times, ratification and expiry states, vote recording times, current parameters, committee composition): https://api.koios.rest/api/v1 - AdaStat (delegation-weighted approval rates and ratification denominators): https://adastat.net
- Cardano governance actions: https://gov.tools/governance_actions
- Essential Cardano — Weekly development report as of 2026-09-04 (node v11.1.0 benchmarks and v11.1.1, the SPO-runnable Leios benchmark package, Hydra’s Typst/Agda specification and ARM64 images, the Cardano Vision 26 data availability workshop): https://www.essentialcardano.io/development-update/weekly-development-report-as-of-2026-09-04
- Intersect MBO — Intersect weekly update #126 (2026-08-28; the committee going from seven to three on failure. #127 was unpublished as of our retrieval): https://www.intersectmbo.org/news/intersect-weekly-update-126-aug-28-2026
- Intersect MBO — Announcing Intersect Board Elections 2026 (applications open 8/31 12:00 UTC, close 9/11, voting 9/14–9/25, results 9/28, two seats): https://intersectmbo.org/news/announcing-intersect-board-elections-2026
- Cardano — Preparing the Constitution for Dijkstra (2026-07-10; submission “targeted before epoch 655” and the scope of the amendment): https://cardano.org/news/2026-07-10-preparing-the-constitution-for-dijkstra/
- Hydra — security advisory
GHSA-cg83-6w6r-6hx3(2026-09-02, severity critical): https://github.com/input-output-hk/hydra/security/advisories/GHSA-cg83-6w6r-6hx3 - Hydra — release 2.4.1 (2026-09-02; “all operators running 2.3.0 or 2.4.0 must upgrade immediately,” cause, fix, and upgrade notes): https://github.com/input-output-hk/hydra/releases/tag/2.4.1
- Hydra — release 2.4.0 (2026-09-01): https://github.com/input-output-hk/hydra/releases/tag/2.4.0
- Daedalus 11.3.0 (2026-09-01; DRep directory, support migration to Se7en Labs, Rust watchdog): https://github.com/input-output-hk/daedalus/releases/tag/11.3.0
- Lace extension 2.2.3 (2026-09-01; DRep data signing fixed for GovTool / dreptalk / Tempo): https://github.com/input-output-hk/lace/releases/tag/lace-extension%402.2.3
- Amaru v10.11.20260903 (2026-09-03; second public beta, two named caveats, minimum requirements): https://github.com/pragma-org/amaru/releases/tag/v10.11.20260903
- cardano-cli 11.2.3.0 / 11.2.3.1 (2026-09-03 / 09-04; Dijkstra era subcommands, parameter update proposals,
query tipfixes): https://github.com/IntersectMBO/cardano-cli/releases - Cardano Dev Updates — Mithril Team Update (2026-09-02): https://updates.cardano.intersectmbo.org/2026-09-02-mithril
- Midnight Improvement Proposals repository (MIP-0016 NIGHT Staking, MPS-0038, MPS-035 filing, 16 MIPs): https://github.com/midnightntwrk/midnight-improvement-proposals
- Midnight — official blog (2026-08-31 “Inside Aliit”; no September posts yet): https://midnight.network/blog
- Midnight developer documentation — Dev Diary “Testnet-02 Transition & The Roadmap to Mōhalu” (2026-01-27; Mōhalu as the Incentivized Mainnet phase, SPO onboarding, binary distribution): https://docs.midnight.network/blog/testnet-02-transition
- Midnight — State of the Network, August 2026 (2026-08-26; the Sundae Labs Capacity Exchange settling fees in USDM): https://midnight.network/blog/state-of-the-network-august-2026
- CoinGecko (ADA / BTC / ETH / NIGHT values for August 29 and September 5): https://www.coingecko.com
Transparency Note
Where judgment went one way rather than another this week, and what we left out.
- How we confirmed the deadline held. We pulled every vote on both proposals and verified that zero were recorded at or after the deadline (1788299091). We did not infer dates from epoch records alone.
- Why there is no DRep vote count for
minPoolCost. Our canonical retrieval path stopped on a vote-count reconciliation for this action alone (AdaStat 148 votes vs. Koios itemized 149 — a one-vote difference, on two attempts). The approval percentages, however, agree exactly at 68.57% across both sources, and the SPO side differs by 0.03 points (34.5% vs 34.53%). So we print percentages only, and no DRep vote count. - The names of the four seated committee members. Koios returns only key hashes, and we could not confirm a primary source tying them to names this week, so we do not print names.
- Intersect weekly update #127. Unpublished as of our retrieval (07:00-ish JST on September 5). The news index and sitemap top out at #126 and the expected URLs 404. We have not written “according to this week’s Intersect” about something that does not yet exist.
- Midnight’s next phase, DUST markets, and the Glacier Drop unlock schedule. The material we consulted as a structural draft contained figures for these, but we could confirm none of them in the official blog or in any primary source this week. They are not covered here.
- “RealFi mainnet on October 1.” As written above, we could not confirm an official statement. The origin is a community account’s September 2 post, which articles then cite. What is confirmable as primary runs only to the August 11 testnet launch. We are not asserting the date is wrong — we are saying we found no basis for treating it as official.
- Mōhalu’s timing. The phase name and its positioning (Incentivized Mainnet) are confirmed in the official Dev Diary of January 27, 2026, but no primary statement of timing was found. So we give none.
- Cardano Foundation’s output this week.
cardanofoundation.orgcould not be retrieved (429, access control), so we have not checked it. We are not claiming CF published nothing this week; we checked Intersect, cardano.org and iog.io. - The date of the Intersect board election article. The August 31 12:00 UTC application opening is stated in the announcement, but the article itself was published on August 19. It is not a piece of this week’s news.
- The Hydra advisory and the weekly report. That the advisory does not appear in the same week’s development report is a measured fact, but we have not judged whether that is an omission or a matter of scope. We only place the two side by side.
- Why votes concentrated near the deadline. The record tells us how many votes arrived and when. We have not written about the effect of outreach or about individual reasoning.
- Why 59 pools voted against
minPoolCost. The votes themselves do not say, so we record only the counts. - Price and the proposals. We do not connect this week’s recovery in ADA and NIGHT to the ratification or the expiry. Outcomes pointing in different directions were confirmed on the same day, and price cannot separate them.
- Continuity with issue #21. Issue #21’s “2.76 points and 15.53 points” is consistent with this issue’s final figures (71.95% / 56.54%). Those were measured at 08:17 JST on August 29; these at 07:03 JST on September 5.
This is not investment advice. For information and research purposes only.
