Hyperlane Asset Drain and Network Halt: Day-by-Day Record

This is the day-by-day record of the ten days Radix mainnet spent halted after the Hyperlane asset drain of 31 August 2026, from the first official update on 1 September to the restart at 11:35 UTC on 11 September. The article it belongs to carries the incident, the cause and a summary of the repair; this is the working record underneath it.

Every entry states what was read, from where, and at what hour, and the readings are left as they were taken rather than edited to agree with what came later. One correction is worth knowing before reading them. The halt boundary cited throughout below, state version 557,840,622 at epoch 339,896 round 102, is the Gateway status endpoint's reading; after the restart the transaction stream showed the ledger had run five state versions further, to epoch 339,897 round 4 at 21:19:48.939 UTC. The entries still carry the Gateway's number, because what each day could be checked against at the time is the point of keeping them.

Day two: the first official update

Re-read at 11:04 UTC on 1 September 2026, the Gateway status endpoint returns the same ledger for the third consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is thirteen hours and forty-five minutes without a committed round.

The first official word since 22:02 UTC the previous night came at 09:10 UTC, in an update posted to the Radix Accountability Council's channel. It says a team assembled by the Foundation, the council and community members is working on a fix, that there is “absolute convergence and solid certainty on what caused the bug to be there and where it came from”, and that there are “no expectations or timelines at this stage”. It also settles what the stopped network now is: the halt is a control being held on purpose, not a failure still in progress. “The current halting status of the network is our best defense and will stay on as long as we need it.” The council closed by asking the community to keep working on the Governance Framework ratification, which it said had not lost its importance.

The clearest sign that a fix is being staged came from the developer channel rather than from an announcement. Radix's public test network, Stokenet, is running: read live at 11:07 UTC its Gateway returns epoch 1,111, round 2,487, proposer round timestamp 11:07:22.546 UTC, so it is producing rounds while mainnet is not. Its developer console is not; stokenet-console.radixdlt.com answered 530 to a request at the same minute, which is what a developer reported at 09:54. Daffy, who runs the network's community infrastructure, answered at 10:32 that Stokenet itself “is up” and would be “taken down for planned maintenance for reasons you probably understand”, adding that he would say when. A test network taken offline deliberately in the middle of a mainnet halt is where a patched Engine gets tried before any validator is asked to run it.

The forensic work continued in parallel and is separate from the fix. 0xOmarA wrote at 05:43 UTC that he already had the data he needed from the Core API and the Gateway, and that he was looking for a trace the attacker left in an earlier attempt, on Stokenet or in a failed run on mainnet, rather than for anything further in the successful transactions.

The silence in the official channels was explained the night before. At 21:17 UTC on 31 August, two minutes before the last round, the Foundation said it was in contact with bridges, exchanges and security partners, that it was “reaching out to relevant authorities and taking advice on next steps”, and that it “may be limited in the updates we can provide”. Measured against the repositories, that is what has happened: re-read at 11:07 UTC, babylon-node's newest release is still v1.3.0.5 of 1 June 2026, the default branch of radixdlt-scrypto still last moved on 27 March 2026, the Foundation's blog carries no post about the incident, and the DAO's notice feed still ends on 29 August. Fourteen hours in, everything anyone outside the repair knows about it was said in a Telegram channel.

Day two, afternoon: the shape of the fix

Re-read at 15:04 UTC on 1 September 2026, the Gateway status endpoint returns the same ledger for the fourth consecutive reading, and the read endpoints put a number on it without any epoch arithmetic: a request to /state/entity/details answers HTTP 500 with current_sync_delay_seconds 63,936 and the sentence “it is currently 17 hours, 45 minutes, 36 seconds behind”.

At 12:16 UTC the Radix Accountability Council published the first description of what the repair actually consists of, posted by projectShift as the morning update was. It names four steps in order: code fixes to the Radix Engine; updates to the node software together with a protocol upgrade; a coordinated deployment of those across nodes; and a coordinated return to liveness. It says the work involves people who were previously with the Foundation or are still with it, alongside volunteer developers and engineers from the ecosystem, and that it is “not just coding a fix” but review, testing, deployment and recovery. There is still “no timetable for when a solution will be available”; the council said to expect the next regular update around the same time the following day.

That list matters to a reader outside the repair because its middle two steps are not private. A protocol upgrade on Radix is adopted by validators signalling readiness for a named version in an ordinary transaction, which is how the three updates the rebuilt Stokenet ledger had to retake in August are readable on it today. Read at 15:05 UTC, the Stokenet transaction stream against its validator set carries no readiness signalling later than the Cuttlefish signal of 29 August: no new protocol version has been proposed on the test network. Stokenet itself is still producing rounds — epoch 1,175, round 124, state version 3,512,563, proposer round timestamp 15:05:29.054 UTC, continuous from the 3,322,913 read four hours earlier — so the planned maintenance Daffy announced at 10:32 had not begun, and a developer was still deploying a component to it at 14:47. Eighteen hours after the halt, the fix has not reached a network.

Nothing else has moved either. babylon-node's newest release is v1.3.0.5 of 1 June 2026, the default branch of radixdlt-scrypto last moved on 27 March 2026, the Foundation's blog carries no post about the incident, and the DAO's notice feed still ends on 29 August. The markets, meanwhile, spent the day repricing what they could not move: Gate.io's XRD/USDT book read 0.000658 USDT at 15:06 UTC, down 20.2% over twenty-four hours on 114,272,110 XRD of volume, and MEXC's read 0.0006521, down 20.8% on 248,959,959 XRD — roughly 162,000 US dollars of turnover in a token that cannot currently leave an exchange.

Day two, evening: a halt with no lever to throw back

Re-read at 19:04:16 UTC on 1 September 2026, the Gateway status endpoint returns the same ledger for the fifth consecutive reading — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — twenty-one hours and forty-five minutes without a committed round. Four minutes later /state/validators/list and /state/entity/details both answered HTTP 500 with NotSyncedUpError and stated the gap themselves: current_sync_delay_seconds 78,372 against max_allowed_sync_delay_seconds 720, in the words “it is currently 21 hours, 46 minutes, 12 seconds behind”.

Nothing has appeared in any of the places a fix would surface. babylon-node's newest release is still v1.3.0.5 of 1 June 2026 and its main branch's last commit is from the same day; develop has not moved since 12 March 2025 and release/cuttlefish since 7 May 2025. The default branch of radixdlt-scrypto still ends at 858c70f1 on 27 March 2026. The DAO's notice feed carries nothing after 29 August, the Foundation's blog nothing at all about the incident, and the Council has posted nothing since the four-step account recorded in the section above. Twenty-two hours in, the repair described that morning has left no public trace in any repository.

The halt is a standing decision, not a switch

What the main channel worked out this evening is that there is no lever to throw back. In two messages at 18:49 and 18:53 UTC, projectShift — the account that has posted the Council's updates through the outage — set out what the stop actually is: “The network's not halted, it's just refusing to produce TX because it lost quorum on stake power, as it is coded to do.” It happened because enough independent node runners, holding enough cumulative stake between them, each accepted the plan; and, he added, “Some didn't and their nodes are up, for whatever reasons.” Had the stake behind the stop fallen short, the network would have kept working, “maybe just a tad slower”.

The consequence is that ending it requires no coordinated act either. “Any node-runner is free to reverse their decision and boot the node back up and start regular operations. If enough of them do that, the network regains quorum and liveness and restarts normal operations.” There is no switch in the protocol to unset and no signed release to wait on; the halt is a position that a set of operators re-takes every minute it lasts, and it lifts the moment enough of them individually stop taking it. That is a different object from the one the outside reading assumes. The validators are not obeying an instruction, and no party can rescind one.

It also means the network's other constituency has no move. Delegated stake is the counterweight to node runners in Radix's design — unhappy delegators redirect it — and here it cannot be used, because redirecting a delegation is itself a transaction and transactions are exactly what has stopped. projectShift stated the asymmetry plainly, that delegators “cannot change their stake into other nodes, even if they don't agree with node runners”, adding that “that asymmetry is by design and was always there. And it would take them 7 days to enact anyway”: the unstaking delay would run only after a ledger existed to record the request on. So a decision reversible by any one of a hundred operators is, for everyone who delegated to them, not reachable at all. It is the sharpest illustration the network has produced of what the stake-delegation model does and does not give a holder, and it arrived on the day it mattered.

Day three: the instruments that did not notice

Re-read at 03:04:16 UTC on 2 September 2026, the Gateway status endpoint returns the same ledger for the seventh consecutive reading — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — twenty-nine hours and forty-five minutes without a committed round. The read endpoints state the gap themselves: /state/entity/details, /state/validators/list, /stream/transactions and /transaction/construction all answer HTTP 500 with current_sync_delay_seconds 107,377 against a max_allowed_sync_delay_seconds of 720, in the words “it is currently 1 day, 5 hours, 49 minutes, 37 seconds behind”.

One layer above that, the ecosystem's own read surfaces are answering normally, and what they are answering with is the halt. Ociswap's token API returns HTTP 200, and XRD's circulating market capitalisation reads 7,945,385.587233559518230284332481276342396505 US dollars at the 1-hour window, at the 24-hour window and at now — the same figure to the last of its thirty-six decimal places. Only the 7-day window differs, at 11,811,840.45. A twenty-four-hour period with nothing in it looks, to an aggregator, exactly like a very quiet market.

Astrolescent's price feed returns 876 tokens, ninety-nine of them reporting a twenty-four-hour volume of exactly zero, and it still quotes the assets the drain removed. hUSDC reads 0.7467 US dollars and hUSDT 0.4470 — dollar stablecoins priced a quarter and a half below par — alongside hETH at 1,295.09, hWBTC at 58,302.64 and hSOL at 57.74. Those are the last prices the pools produced before the network stopped, held for a day and a quarter and served as current, for tokens whose remaining supply on Radix is the residue the article records: 1,092.79 hUSDC and 0.036292 hUSDT. Nothing in this layer is wrong, exactly. It is the halt, cached.

The frontends divide on the same line. Static shells serve: ociswap.com, astrolescent.com, app.weft.finance, surge.trade, defiplaza.net, dex.reddicks.meme, radquest.io, radixscan.io and radixplanet.com all returned 200 through their own redirects. Pages that need a live read do not: an astrolescent.com/token/<resource> page answers HTTP 500 and stats.defiplaza.net times out after twenty seconds. app.caviarnine.com refuses connections, which belongs to CaviarNine's own wind-down rather than to the halt.

Nothing official has been added since the previous reading. The Council's four-step account of the fix at 12:16 UTC on 1 September is still its last word, fifteen hours later; babylon-node's newest release remains v1.3.0.5 of 1 June 2026 and its default branch's newest commit 12919a01 of 12 March 2025; the default branch of radixdlt-scrypto still ends at 858c70f1 on 27 March 2026; the DAO's notice feed still ends on 29 August; and the Foundation's blog carries no post about the incident. A patch for a live vulnerability is the last thing anyone would push to a public branch before it ships, so the absence is not evidence of inaction — but none of the places a reader can check has moved.

Day three, morning: the Foundation speaks, and claims the halt

Re-read at 11:06:14 UTC on 2 September 2026, the Gateway status endpoint returns the same ledger for the eighth consecutive reading — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — thirty-seven hours and forty-seven minutes without a committed round. The read endpoints put the same gap in their own words: /state/entity/details answers HTTP 500 with current_sync_delay_seconds 136,028 against a max_allowed_sync_delay_seconds of 720, “it is currently 1 day, 13 hours, 47 minutes, 8 seconds behind”.

Eight minutes past nine, thirty-five hours into the stop, the Foundation said something for the first time since two minutes before the last round. The statement went out on the Radix DLT Official Announcements channel at 08:58:02 UTC and was forwarded straight into the main chat. It is six sentences. The root issue “has been identified, and work is underway to implement, test and deploy the fixes as quickly and safely as possible”. The Foundation “has contacted security partners, bridges, exchanges and relevant authorities to assist”. Foundation assets held in custody “remain safe”. There is “currently no confirmed timeline for restoration”. And for anything further, readers are pointed away from the Foundation's own channels: “For verified updates, follow @RadixAccountabilityCouncil”.

Who halted the network

The first sentence is the one worth reading twice. “Following the recent exploit, the Radix Foundation and RAC have halted the Radix network as a precautionary measure, temporarily making transactions and Radix Wallet activity unavailable.” That is an account of the halt as a thing two named bodies did, and it is not the account the network's own operators gave. As the previous evening's section records, the stop is not an action taken on the network but a quorum the network lost when enough independent node runners each shut down their own machine, and some declined and left theirs running. Neither the Foundation nor the council has a switch of this kind; what they had was a plan that enough operators, one at a time, agreed to.

The contradiction was already on the record in the same channel three hours earlier. At 06:04 UTC, answering people asking him privately whether Radix was finished, Timan of Astrolescent and DefiPlaza wrote that the exploit was serious and the halt severe, “but the node runners made that decision to protect the network. That was not a centralized decision. (Also didnt come from me btw).” Three hours later the Foundation's own announcement claimed it. Both cannot be describing the same event, and only one of them is checkable against the ledger, which shows a network that stopped producing rounds when its validating stake fell below the threshold the consensus protocol requires.

The distinction is not a quibble about credit. It decides who a holder should be watching for the restart. A network halted by two bodies resumes when those bodies decide it should; a network that lost quorum resumes when enough validator operators individually judge the patched software safe to run. The second is what the ledger describes, and it is why no announcement can carry a restart date.

No timeline, and the gap that fills it

“No confirmed timeline for restoration” is the Foundation's first public word on when the network comes back, and the vacuum around it is being filled by people with no more information. Just over an hour before the announcement, at 07:46 UTC, avaunt of Atomix answered a holder asking what to do with “it will take a few more days at least to restart the network”; Timan's message two hours earlier had said the same, “hopefully a few days”, with the qualifier that it is “better to get it right the first time than rush this”. Neither is an estimate anyone is in a position to make, and the announcement declined to make one.

The channel the Foundation designated as the source of verified updates has not used it. The council's four-step account of the fix at 12:16 UTC on 1 September, which closed by promising the next update “around the same time tomorrow”, is still its most recent word twenty-two hours and fifty minutes later. Nor has anything appeared where a fix would land: babylon-node's newest release is still v1.3.0.5 of 1 June 2026, the default branch of radixdlt-scrypto still ends at 858c70f1 of 27 March 2026, the DAO's notice feed still ends on 29 August, and the Foundation's blog carries no post about the incident. Thirty-eight hours in, the whole public record of the repair is four Telegram messages.

Day three, afternoon: the council returns, and the DAO's own clock stops with the network

Read at 15:10:08 UTC on 2 September 2026, the Gateway status endpoint returns the same ledger for a ninth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is forty-one hours and fifty-one minutes without a committed round. /state/validators/list still answers HTTP 500 and still counts the gap itself, now current_sync_delay_seconds 150,662 against a max_allowed_sync_delay_seconds of 720. Nothing has been published where a fix would appear: babylon-node's newest release is still v1.3.0.5 of 1 June 2026.

The council spoke again at 13:49:11 UTC. Its status update, posted by projectShift, is the first since the four-step account of the fix at 12:16 UTC the previous day, which had promised the next one around the same time the next day. It arrived twenty-five hours and thirty-three minutes later, an hour and a half past that.

On the repair it adds confidence and no dates. Progress is called excellent, the team handling it solid, and testing extensive and continuing, on the reasoning that there is only one chance to get the restart right; there are still no hard dates to commit to. The people doing the work stay unnamed, deliberately, with disclosure deferred to the aftermath. That leaves the public record of the repair where the morning's section found it: statements about work, and no artefact anyone outside can check.

The legal and exchange track

Two operational lines are new. The Foundation has taken legal steps over the hack, and the council says an update on them will come direct from Andy, whom it does not further identify; the Radix Foundation's chief executive is Andy Jarrett. Separately, coordination with exchanges, market makers and other partners is running through the Foundation rather than the council, and covers both the current state of the network and when and how it returns to liveness. The council adds one limit that matters to holders: whether trading continues inside any given exchange is that exchange's decision alone, which is consistent with the pattern recorded on day two, where XRD markets stayed open while deposits and withdrawals did not.

The halt stops the DAO's constitutional clock

The update's third section is the one with a consequence beyond the incident. The Radix DAO opened the Discussion phase on its Governance Framework at 17:30 UTC on 30 August, for a stated seven days, which would have closed it on 6 September. Because a halted ledger offers no way to run a Temperature Check or a ballot, the Transition RAC has removed the limit and will keep the phase open for as long as it is needed. The council's argument for doing so is that reading and challenging the twenty-one documents is the one useful thing still available while nothing can be transacted.

The effect is that the network's stoppage has propagated into the DAO's own timetable. Ratification is Activation Condition 6 of the Operating Agreement, and the Permanent RAC election cannot open until the framework is ratified, so an outage on the ledger now sits upstream of the transition it was meant to be independent of. Measured at 15:10 UTC, three days into the phase, the anchor discussion topic holds 13 posts from four accounts and 151 views, eight of the thirteen written by the council member who opened it.

Day three, evening: the first technical account, and a legal track

Read at 19:04:11 UTC on 2 September 2026, the Gateway status endpoint returns the same ledger for a tenth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is forty-five hours and forty-five minutes without a committed round. /state/validators/list answers HTTP 500 and states the gap in words as well as seconds, it is currently 1 day, 21 hours, 45 minutes, 10 seconds behind, with current_sync_delay_seconds 164,710 against a max_allowed_sync_delay_seconds of 720.

The first public account of the flaw

Until this afternoon no one connected to the network had described the defect in public. The official statements named the layer and stopped there: an outstanding issue in the execution layer, an issue in the Radix Engine, and, in the Foundation's statement that morning, a root cause identified but not characterised. That changed in the space of ten minutes in the main Radix group, after a holder asked at 14:44 UTC for an explanation in plain terms, and specifically why so simple a check had not been implemented and why an audit had not found it.

Timan of Astrolescent answered first and declined the question: that is the million dollar question, he cannot produce a plain-language account of how it was possible, and he expects the upcoming incident report to. That is the first indication from anyone close to the work that a written incident report is planned at all.

Council member projectShift then gave one, at 14:50:47 UTC. The attack, in his account, moves assets by bypassing security/ownership checks when calling a specific method and identifying the vault holding the assets by its internal id, and what fails is the checking of the requester had any authorization or ownership of the vault identified. His analogy is that everyone saw the door and the lock and accepted that it was locked and that only the owner held the key; nobody tried the handle, and it was not locked.

Ten minutes later flightofthefox, who leads the hyperscale-rs rewrite, placed it in the Engine's history, hedging it twice: take it with a pinch of salt because he has not looked exhaustively, and someone will have a more accurate write-up when the fires are out. His reading is that direct access to a vault was built to support the recallable resource behaviour, which is a capability asset issuers genuinely want, but it seems like the checks that the caller actually had the right recall authority (and indeed that the resource was even ever marked recallable) weren't in place or not functioning correctly.

Both accounts land where the code reading in the article landed two days earlier, and the second adds a detail worth keeping. verify_boot_ref_value tests the blueprint of the referenced node, FungibleVault or NonFungibleVault from the resource package, and nothing else; whether the resource behind that vault was ever configured as recallable is not one of its inputs, any more than ownership is. A capability introduced for recall was therefore reachable on resources for which recall had never been enabled. None of this is an incident report, and all three accounts are hedged or partial. What can be said as of this reading is that the first public technical explanations of the drain came from a protocol developer and a council member speaking in a chat group, four days after the transactions, and not from the organisation that says it has identified the root cause.

Reports to authorities in Jersey and the UK

The legal update the council had promised arrived at 16:13:34 UTC, in the main group rather than an announcement channel, from Andy Jarrett: the Foundation have submitted incident and forensic reports to various legal and cybercrime authorities in Jersey and the UK and had a number of follow up calls today. The two jurisdictions match where the group is registered. The Radix Foundation that now holds control of the group is a Jersey entity, and the operating companies are registered in England and Wales. No authority, reference or case is named, and nothing further has been published in writing.

Day four: two prices for a coin that cannot move

Read at 07:03:51 UTC on 3 September 2026, the Gateway status endpoint returns the same ledger for a thirteenth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is fifty-seven hours and forty-five minutes without a committed round. Three minutes later /state/validators/list and /state/entity/details both answer HTTP 500 and count the gap themselves, it is currently 2 days, 9 hours, 47 minutes, 45 seconds behind, with current_sync_delay_seconds 208,065 against a max_allowed_sync_delay_seconds of 720.

Nothing has appeared where a fix would appear. The newest babylon-node release is still v1.3.0.5 of 1 June 2026, the head of radixdlt-scrypto is still commit 858c70f1 of 27 March 2026, and the DAO's notice feed still ends on 29 August.

The two books come apart

The exchange freeze recorded on day two is unchanged at a third reading. Gate.io's native XRD chain carries deposit_disabled: true and withdraw_disabled: true; KuCoin reports isDepositEnabled and isWithdrawEnabled both false; CoinEx holds both external legs off and leaves inter_transfer_enabled true. What has moved is the price, and it has moved differently at each venue.

MEXC's last print sits 21.8% below Gate's. Two days earlier the same two books were within one per cent of each other, both quoting around 0.000658 after a twenty per cent fall. The gap that has opened since is not a disagreement about Radix. It is the absence of the mechanism that normally closes such a gap: arbitrage between two exchanges is a coin bought at the cheap venue and moved to the dear one, and the move is a Radix transaction, which is the one thing the ledger is refusing. Each book now prices its own trapped float against its own sellers, and the two answers no longer have to agree.

Gate's book has almost stopped. Its twenty-four-hour turnover fell from 114,272,110 XRD on 1 September to 7,536,673, a 93% drop, and its whole day's range is five per cent wide with the last print sitting on the low. MEXC took the selling instead, 116,901,175 XRD against 248,959,959 two days earlier, and printed a low of 0.0003738 that is 43% under Gate's last. The deeper book is the one still discovering a price; the shallower one is quoting a number at which almost nothing changed hands.

Day five: the fix is on GitHub, under a name the network has not heard

Read at 07:03:39 UTC on 4 September 2026, the Gateway status endpoint returns the same ledger for a seventeenth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is eighty-one hours and forty-four minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 3 days, 9 hours, 48 minutes, 38 seconds behind, with current_sync_delay_seconds 294,518 against a max_allowed_sync_delay_seconds of 720.

The repair has become readable, and it was readable before this reading. At 12:26:45 UTC on 2 September – thirty-nine hours into the halt, and seven hours before the first public account of the flaw was given in a chat group – pull request #2093 was opened against radixdlt-scrypto’s develop branch, titled 0xOmarA/vault access. Its author is 0xOmarA, the same contributor whose forensic notes this page records from the first night. It is still open, unreviewed and unmerged.

The six commits on it date the work. The earliest is 31 August at 22:41:32 UTC, one hour and twenty-two minutes after the last round the network committed; Add Eagle Ray protocol update lands at 23:27:33, and Add a receiver check to kernel_invoke at 00:12:54 on 1 September – under three hours after the halt, and roughly six hours before the first official update said anything in public. Two further commits on 2 September move the check from the kernel into the system layer.

Eagle Ray is a new named protocol update, the next after Dugong in the alphabetical sequence, and it is the second of the four steps the council named as well as the first: the code fix and the protocol upgrade that carries it are the same pull request. Its whole content is a flash update that advances the system logic from SystemVersion::V4 to V5, and V5 turns on a single check. Before an invocation runs, the system asks whether the calling frame can actually see the node whose method it is calling – direct methods, the type used for recall and other direct vault access, requiring direct visibility of the receiver – and rejects the call otherwise with a new error, SystemError::InvalidInvokeAccess. That is the handle nobody tried, given a lock: the test the change rewrites is test_recall_on_internal_vault, which used to fail obscurely inside the kernel’s frame construction and now fails cleanly at the system layer.

Two things follow, and they pull in opposite directions. The fix matches the flaw as both public accounts of it described it – a method reached on a vault the caller had no authority over – and it was written within hours, not days. But four days later it has no review, no merge, and no node: babylon-node’s newest release is still v1.3.0.5 of 1 June 2026, the node repository carries no Eagle Ray branch, and a protocol update reaches mainnet only when validators signal readiness for a node version that contains it. Steps three and four of the council’s list have not started. The Foundation’s blog still carries nothing about the incident and the DAO’s notice feed still ends on 29 August, so the most concrete public statement about how the network gets restarted remains an unannounced pull request that anyone could have read for two days.

Day six: the ledger has not moved, the fix has not moved, the paperwork has

Read at 15:03:41 UTC on 5 September 2026, the Gateway status endpoint returns the same ledger for a twenty-fifth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and thirteen hours and forty-four minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 4 days, 17 hours, 47 minutes, 47 seconds behind, with current_sync_delay_seconds 409,667 against a max_allowed_sync_delay_seconds of 720.

The fix has not been touched since day three

Pull request #2093, which carries Eagle Ray and the receiver check day five read line by line, was last updated at 13:06:16 UTC on 2 September. That is seventy-four hours before this reading, and the state at both ends is identical: open, six commits, no review comments, unmerged against develop. The node half is where day five left it too – babylon-node’s newest release is still v1.3.0.5 of 1 June 2026, and none of the repository’s 183 branches is named for Eagle Ray. A protocol update reaches mainnet only when validators signal readiness for a node version that contains it, and no such version exists in public.

The post-mortem waits on the restart, and the audits are under investigation

The main Radix group spent the middle of the day arguing about who should have caught the flaw. Daffy, the community contributor who maintains the DAO’s governance repository, answered three questions in it and each answer is new to the public record. At 11:34:59 UTC he asked the group to stop discussing the matter in public until the network is patched and running. At 12:04:27 UTC, asked whether anyone could yet explain where the bug was and how it passed the security reviews, he said the bug and its history are known and that why the Audits did not capture it is still under investigation. At 12:07:57 UTC, asked how the report could be read, he put it after the restart: After the network is patched and running smoothly again.

This is the first public statement that a written post-mortem exists as a commitment rather than an expectation, and the first that the audit history is itself being examined. Neither carries a date, and both are attributed to a contributor rather than to the Foundation, whose blog still carries nothing about the incident six days on.

The DAO's clock restarts, off the chain

The one thing that did move today moved where the ledger cannot reach it. At 13:17:43 UTC the Transition RAC member Tadkis told the council’s channel that the agreement with MIDAO has been signed and the registration fee has been paid, and that the formal registration process is scheduled to begin on Monday – 7 September 2026. An hour later projectShift relayed it to the main group as Step one of the DAO is actually done now.

Two things are worth holding together. The first is that this is the step the council said on 29 August would roll out from Monday onwards, meaning 31 August; it completed six days later, and the four-to-six week registry clock the council quoted starts from 7 September rather than from the end of August. The second is the contrast with what the halt did to the DAO’s other clock: ratification of the Governance Framework needs a vote the stopped ledger cannot hold, and remains open-ended. Incorporation runs through a registry in Majuro and does not care that Radix has stopped. The transition is now advancing on its off-chain leg alone.

Day seven: the fix repository moves, and none of the movement is the fix

Read at 11:06:56 UTC on 6 September 2026, the Gateway status endpoint returns the same ledger for a twenty-ninth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and thirty-three hours and forty-eight minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 5 days, 13 hours, 47 minutes, 50 seconds behind, with current_sync_delay_seconds 481,670 against a max_allowed_sync_delay_seconds of 720.

The pull request's timestamp moved; its commits did not

Pull request #2093, which carries Eagle Ray and the receiver check day five read line by line, was last updated at 08:04:48 UTC on 6 September – the first time that stamp has moved since the 13:06:16 reading day six recorded, ninety-one hours earlier. It is not the fix that moved. The six commits on the branch still end at 722c3f32, Move error to system layer, authored at 11:09:51 UTC on 2 September, and all three comments on the pull request are from github-actions[bot]: the benchmark table of 2 September, and two Docker-tag notices posted this morning at 08:01:22 and 08:04:48 for the images radixdlt/private-scrypto-builder and radixdlt/private-scrypto-dev-container. A GitHub pull request counts a bot comment as an update, so the stamp is not evidence that a review has started. There is still no review comment, and it is still unmerged.

Two more pull requests opened in the repository today, and both are housekeeping. #2094, Remove unused Phylum CI job; document workflows in .github/README.md, was opened at 09:38:46 UTC against the fix branch 0xOmarA/vault-access itself and closed unmerged at 10:54:29; three minutes before that close, #2095 reopened the same five files against develop, where it remains open. Five files of continuous-integration configuration, retargeted from the patch to the mainline. That is the whole of the day's activity in the repository holding the fix, and it is worth noting what it lands on: develop, the branch #2093 is opened against, last took a commit on 27 March 2026. The node half has not moved either – babylon-node’s newest release is still v1.3.0.5 of 1 June 2026, and no branch there is named for Eagle Ray.

The upgrade gets a rehearsal ground

The day’s one substantive statement came from the developer channel rather than the repository. At 07:27:12 UTC Daffy posted to the Radix Developers group: Stokenet Update. We expect that there we will be some instability and downtime in Stokenet in the coming days in preparation for the protocol upgrade. It is the first public statement that the upgrade is being staged anywhere, and the first thing said about the restart since the halt began that describes an action rather than a state.

Stokenet is Radix’s public test network, and it is running. Read at 11:07:28 UTC on 6 September, its Gateway returned state version 6,046,607, epoch 2,583, round 1,151 and a proposer round timestamp of that same second, and /state/validators/list answered HTTP 200 – the endpoint that has returned 500 on mainnet for six days. The instability being warned about is therefore ahead of the test network rather than behind it: what is coming is the upgrade being rehearsed on a live chain that can afford to break.

This is the first of the four steps the council named to acquire a schedule of any kind, and the schedule it acquires is a rehearsal rather than a mainnet date. The notice says the coming days; no node release carrying Eagle Ray exists in public on either network; and mainnet restarts only when validators signal readiness for a version they cannot yet download.

Day eight: the restart gets its first forecast, and it does not come from the Foundation

Read at 07:04:0x UTC on 7 September 2026, the Gateway status endpoint returns the same ledger for a thirty-fourth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and fifty-three hours and forty-five minutes without a committed round. /state/validators/list still answers HTTP 500 and still counts the gap itself, it is currently 6 days, 9 hours, 50 minutes, 7 seconds behind, with current_sync_delay_seconds 553,807 against a max_allowed_sync_delay_seconds of 720.

A forecast, from a dApp founder

At 06:32:47 UTC the first estimate of any kind about the restart was posted to the main Radix Telegram group, and it came from Timan Rebel, founder of Astrolescent: a great deal of patching work was done over the weekend, the network is getting closer to a restart, and more testing is needed before it happens. He was explicit that he was not among those doing the work and was posting because nobody else had.

That is the eighth day of this incident and the first forward-looking statement about it, and the notable thing is where it did not come from. The Radix Foundation’s announcement channel has published nothing since the IMPORTANT NETWORK UPDATE of 08:58 UTC on 2 September, five days earlier, which is the post day three recorded. Message 2778 is still the newest on the channel. An ecosystem project’s founder, relaying second hand in a community chat, is currently the most recent public account of when Radix expects to produce a block again.

The weekend left no public trace

The work described has no visible counterpart in either repository. Pull request #2093, which carries Eagle Ray and the receiver check, is still open and unmerged, and its branch still holds the same six commits ending at 722c3f32 of 11:09:51 UTC on 2 September. Nothing was pushed to it on 5, 6 or 7 September. babylon-node, the implementation every validator actually runs, is unchanged too: its release branch main still ends at 959b081e of 1 June 2026 and its newest release is still v1.3.0.5 of the same day.

The two readings are not in conflict. A patch to a live network can be written, reviewed and tested privately and land in public as a single push, and the Foundation has said nothing that promises otherwise. What it does mean is that the public record cannot yet corroborate the forecast: the only artefacts a reader can check are five days old, and the estimate rests entirely on the account of someone who says he did not do the work.

The rehearsal has not started

Stokenet, the public test network day seven identified as the rehearsal ground, is still running normally. Read at 07:04:08 UTC on 7 September, its Gateway returned state version 6,376,136, epoch 2,823 and round 227 with a proposer round timestamp of that same second, and /state/validators/list answered HTTP 200. The instability Daffy told the developer group to expect in the coming days in preparation for the protocol upgrade has now been awaited for twenty-four hours without appearing. Stokenet breaking would be the first thing a reader outside the Foundation could check that the restart forecast is real.

Day eight, evening: the fix merges, and Scrypto releases it ninety seconds later

Read at 19:03 UTC on 7 September 2026, the Gateway status endpoint returns the same ledger for a thirty-seventh consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and sixty-five hours and forty-four minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 6 days, 21 hours, 46 minutes, 25 seconds behind, with current_sync_delay_seconds 596,785 against a max_allowed_sync_delay_seconds of 720.

The ledger is the only thing here that did not move. Pull request #2093, which carries Eagle Ray and the receiver check day five read line by line, took its first push since 2 September at 16:50 UTC: a seventh commit, fba18466, titled Fix scrypto-coverage ci. Forty-three minutes later, at 17:33:31 UTC, it was merged. develop, the branch that had stood at commit 858c70f1 of 27 March 2026 through every reading this page has taken, now ends at the merge commit a62393f7.

At 17:34:30 UTC a tag was cut from that commit and at 17:35:11 UTC Scrypto v1.4.0 (Eagle Ray) was published by 0xOmarA, the first Scrypto release since v1.3.1 in January 2026. Its release notes are the repository’s licence text and nothing else: no description of the flaw, the fix or the update. The documentation page for Eagle Ray still answers HTTP 404. The code is the announcement.

What the merge contains is smaller than its size suggests. It touches 587 files and adds 58,244 lines, and 538 of those files are regenerated transaction-scenario receipts and manifests under generated-examples/eagle-ray/: the expected output of every existing scenario, re-recorded under the new protocol version, which is what a system-version change forces. The engine change is radix-engine/src/updates/eagle_ray.rs at 80 lines, plus 43 in the system callback that runs the check.

Two of the four steps the council named are now done and the remaining two are the ones that need other people. There is still no node release: babylon-node, the implementation every validator actually runs, has released nothing since v1.3.0.5 of 1 June 2026, and a protocol update reaches mainnet only when validator operators install a node version containing it and signal they are ready. Until that version exists there is nothing for them to install. The Radix Foundation’s announcement channel has published nothing since 2 September; the merge is on GitHub, where anyone who thinks to look can read it.

Day eight, night: the council reads the release and says it is not enough

Read at 23:06:43 UTC on 7 September 2026, the Gateway status endpoint returns the same ledger for a thirty-eighth consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is one hundred and sixty-nine hours and forty-seven minutes without a committed round. /state/validators/list still answers HTTP 500, now with current_sync_delay_seconds 611,257.

Three hours and ten minutes after Scrypto v1.4.0 was published, the Radix Accountability Council posted a status update to its own channel at 20:45:41 UTC, and it is the first statement from any body about how far the released code is from something a validator can run. The council writes that its developers have spotted that the Eagle has landed, meaning Eagle Ray, but don’t go jumping into conclusions yet, that’s not enough. It gives three reasons and no date: there are a lot of moving parts before we have a build completely ready for general deployment, and not all of them are ready at this point; the testing is still ongoing and has advanced significantly but is not finished; and the reviews under way have not all been completed. Asked for a date, the council says it has none it can commit to, and that hasting it is the poorest of choices.

That is the same gap this page read from the repositories at 19:03, stated by the people doing the work rather than inferred from what has not been published. The babylon-node release list is unchanged at v1.3.0.5 of 1 June 2026.

The update also moves the two tracks that are not the fix. On the legal one, the sign-up for MIDAO’s service is concluded and the transition council is working through the administrative steps that end with MIDAO submitting the formation request to the Marshall Islands registry, which is the filing the council said on 5 September would begin on Monday 7 September. On governance, the amendments raised in the Charter and Policies ratification discussion on RadixTalk have been incorporated where possible: Daffy reported at 21:19 UTC on 6 September that seven of thirteen points raised against the framework were in. The discussion stays open until the council has a firm date for restarting the ratification process, which it does not have while the network is down.

The Radix Foundation’s announcement channel has published nothing since 2 September.

Day nine: the node half opens, and it names an epoch

Read at 07:08 UTC on 8 September 2026, the Gateway status endpoint returns the same ledger for a thirty-ninth consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is 177 hours and 49 minutes without a committed round.

An hour before that reading, the second half of the fix became public. Pull request #1076 against babylon-node, the software every validator runs, opened at 06:00:59 UTC from a branch named 0xOmarA/vault-access, by the same author who wrote the Engine fix and tagged Scrypto v1.4.0 the evening before. It carries 12 commits written between 3 and 8 September, 82 files and 4,209 added lines, and it has no description. It is open and unmerged, GitHub reports its merge state as blocked, and babylon-node has still released nothing since v1.3.0.5 of 1 June 2026, so no operator can install any of this yet. What it does contain is the first public answer to when the network restarts and what happens when it does.

The epoch is written into mainnet_protocol_config.rs. A new constant, EAGLE_RAY_ENACTMENT_EPOCH, is set to 339,898, two past the 339,896 the ledger stopped on, and the trigger is EnactAtStartOfEpochUnconditionally: the Eagle Ray protocol update takes effect at the start of that epoch, with no readiness signal and no stake threshold. Every other entry in the mainnet list works the other way. Anemone, Bottlenose and Cuttlefish each wait for validators holding 75% of stake to signal readiness over a window measured in days or weeks, and Cuttlefish's second part follows its first automatically. Eagle Ray is the only one that enacts on an epoch number alone.

Between the restart and that epoch, the network runs without users. The pull request adds a subsystem the node did not have, a user transaction moratorium: a range of epochs during which nodes refuse user transactions while consensus itself continues. Mainnet gets exactly one range, commented "Mainnet incident of 1 September 2026", running from epoch 339,897 inclusive to 339,898 exclusive. That is a single epoch, nominally five minutes, in which validators come back up, produce rounds and commit an epoch change, and nobody can transact.

Three places enforce it. The mempool rejects a submission before it validates or caches it, with a comment that the payload can then be retried once the moratorium ends, and it offers no transactions to a proposal. The consensus pacemaker withholds its vote from any vertex carrying user transactions, dispatching an explicit NoVote and logging the epoch the moratorium runs to, including for vertices that arrive from other nodes through sync. A new verifier in the consensus processor chain applies the same check to incoming proposals. A node that skipped the update could still propose a user transaction; the rest would decline to vote for it.

The most recent commit, at 05:27 UTC on 8 September, corrects which epoch that check reads. Until it, the consensus-side check asked the node's own committed ledger for the current epoch; it now takes the epoch from the consensus event being voted on. The distinction matters only at an epoch boundary, which is exactly where this moratorium lives: a node still committed at 339,896 would otherwise have voted for a vertex proposed in 339,897.

A second correction in the same pull request has the same shape. Nodes ban peers that fall out of step around a protocol update and clear those bans when the update is close. That check read the epoch from the header of the node's latest proof, and an epoch-change proof's header names the epoch that ended rather than the one now running, so the reading was one too low. For an unconditional trigger the clearing window is a single epoch, the one before enactment, so the off-by-one would have missed it entirely.

Stokenet, the public test network, gets the ordinary treatment instead: a readiness signal, 80% of stake, ten consecutive epochs. Both configurations lose the placeholder line that had held a slot for Dugong, the update that was next in the alphabet before this one, and Eagle Ray takes it.

None of this is an announcement. It is an open branch, and every figure in it can change before it merges; the reviews the Radix Accountability Council said on 7 September were incomplete are the reviews this pull request is waiting on. What has to happen after it merges is unchanged: a node release, then operators installing it, then enough of them online to pass two thirds of stake.

Day nine, afternoon: the repository that has to publish the fix could not build

Read at 15:08 UTC on 8 September 2026, the Gateway status endpoint returns the same ledger for a forty-first consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is 185 hours and 49 minutes without a committed round.

Two and a half hours before that reading, babylon-node published a release. It is the repository's first since v1.3.0.5 of 1 June 2026, and it is not the fix.

The tag is v1.3.0.5-test.1, published at 12:28:06 UTC by github-actions[bot] with no release notes and seven build artifacts uploaded between 12:28 and 12:42 UTC. Every previous pre-release in this repository is an -rcN; v1.3.0.5 alone had six of them. This is the first tag in babylon-node's history to use -test, and because it is not flagged as a pre-release it is what the repository now reports as its latest release.

What it contains is readable from the tag. The commit it points at, f2543c1, is the merge of pull request #1075, and that merge's first parent is 959b081, the commit tagged v1.3.0.5: the version mainnet was running when it stopped. The merge changes five files. It adds a .github/README.md, deletes two workflow files, cuts jobs from ci.yml, and repins Debian package versions in the Dockerfile. Fifty-nine lines added, 274 removed, none of them node source. The build published on day nine of the halt is the halted software plus a change to how it is built.

The reason that change was needed is stated in the pull request itself, and it is the finding. Opened on 6 September and merged at 11:21:10 UTC on 8 September, #1075 records that while its author was validating the branch's CI they found main broken: apt-get failing with exit 100 across three build stages, because several exact-pinned Debian bookworm package versions had been superseded and withdrawn from the mirror. The repairs are one line each. curl moves from deb12u14 to deb12u15 in two stages, libssl-dev from deb12u1 to deb12u2 in two more, and three openjdk-17 packages get pinned alongside the JDK because the resolver was otherwise picking newer security builds the pinned JDK could not depend on. The same pull request removes a Snyk job that had, by its own account, failed on every pull request because the AWS secret it reads no longer exists.

Sixty-seven minutes after that merge, the repository produced a build. Nobody has said what the build is for, and the release carries no text to say it. What is on the record is the sequence: for some period ending on 8 September, the repository that has to publish the remedy for a halted network could not produce an artifact, and the first thing it produced once it could was the version that halted.

The pull request also closes with a breakage it does not fix. A note records that main additionally fails to compile under its pinned Rust 1.81.0 toolchain, on iter_repeat_n and is_multiple_of, and calls it separate and tracked elsewhere. Whether that still stands, and how a build was produced with it standing, is not established anywhere public.

The fix itself has not moved. Pull request #1076, the vault-access branch carrying the enactment epoch and the user transaction moratorium, is still open and unchanged since 06:01 UTC, though GitHub's merge state for it has gone from blocked to unstable since the morning reading. It targets develop, and develop is not the line this release came from: GitHub compares the tagged commit with the fix branch as diverged, with 235 commits on that branch the tag does not have and 32 the other way. Whatever the fix is merged into, it is not yet on the branch that produced today's build.

Day nine, evening: the fix merges, and there is a build

Read at 19:06 UTC on 8 September 2026, the Gateway status endpoint returns the same ledger for a forty-second consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is 189 hours and 47 minutes without a committed round. What changed in the four hours before it is that, for the first time since the network stopped, there is something an operator can install.

The move that made it possible was a change of destination. Pull request #1076 had been opened against develop, the branch GitHub serves as babylon-node's default and whose tip has not moved since March 2025 — which is why the tagged build published that lunchtime and the branch carrying the fix read as diverged. At 15:24:46 UTC its author force-pushed the branch, at 15:24:57 changed its base to main, the line the releases actually come from, and at 15:28:11 merged it there. The merged pull request is 15 commits, 79 files, 4,275 lines added and 247 removed. GitHub records no reviews and no comments on it: it was opened, retargeted and merged by the same person, the author of the Engine fix, in nine and a half hours.

Seven minutes after the merge, at 15:35:42 UTC, babylon-node published Eagle Ray v1.4.0.0-RC1 from the merge commit 7400951e, with seven build artifacts and a body containing the repository's licence text and nothing else. Container images followed: v1.4.0.0-RC1-amd64 at 16:06:37, -arm64 at 16:17:12 and the multi-architecture radixdlt/babylon-node:v1.4.0.0-RC1 at 16:23:04 UTC. This is a release candidate, flagged as a pre-release, and the flag has a side effect worth knowing: the repository's "latest release" still resolves to v1.3.0.5-test.1, the rebuild of the version that halted.

The schedule the branch named survives the merge unchanged. In mainnet_protocol_config.rs at the released commit, EAGLE_RAY_ENACTMENT_EPOCH is 339,898 with the trigger EnactAtStartOfEpochUnconditionally, and the user transaction moratorium runs from epoch 339,897 inclusive to 339,898 exclusive — one epoch of consensus without users, then Eagle Ray enacts. Stokenet keeps its ordinary readiness signal of 80% of stake over ten epochs.

The merge also carries the repository's Rust toolchain forward, which is the loose end #1075 had recorded that morning as unfixed. main had pinned CI to Rust 1.81.0 and had no core-rust/rust-toolchain.toml at all; the merge sets that pin to 1.92.0, adds the toolchain file at the same channel, and moves the release-artifact workflow off stable onto the same version, alongside the source changes those compilers demanded.

Nobody has announced any of it. The Radix Accountability Council's most recent statement remains the one at 20:45 UTC on 7 September, which said the testing was unfinished and named no date, and in the three and a half hours after the release candidate appeared the main Radix chat discussed the price on the exchanges that are still quoting XRD and nothing else. A release candidate is also not a restart: what remains is a final build, operators installing it, and validators holding two thirds of stake back online to commit epoch 339,897.

Day ten: the fix runs, and not here

Read at 19:04:37 UTC on 9 September 2026, the Gateway status endpoint returns the ledger it has returned since the halt: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is 213 hours and 45 minutes without a committed round. Five minutes later /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 8 days, 21 hours, 50 minutes, 3 seconds behind, with current_sync_delay_seconds 769,803 against a max_allowed_sync_delay_seconds of 720.

Twenty-one minutes before that reading, at 18:43 UTC, the Radix Accountability Council posted the first forward movement since the network stopped. The update, by projectShift as the council's updates have been throughout, is headed First milestone reached - STOKENET and says that a successful deployment of the new versions of software and protocol were achieved in Stokenet and the whole scenario was validated from end to end. The next steps it names are, in that order, a final commit for the official release, a date, and a plan for mainnet. It also asks node operators to leave the release candidate alone: do not use RC versions to test out on your nodes or similar ideas.

What the test network shows from outside

Stokenet's own ledger corroborates the deployment in the way that matters to someone waiting on mainnet: it never stopped. Sampled hourly through /state/entity/details pinned by timestamp – the same pinned read that gets an answer out of mainnet's frozen Gateway – Stokenet reports exactly twelve epochs in every one of the 28 hours from 15:00 UTC on 8 September to 19:00 UTC on 9 September, committing between 13,507 and 18,372 state versions an hour. At 19:05:34 UTC it was still committing about five state versions a second, at state version 7,346,809 in epoch 3,543.

That is what a protocol update is meant to look like from outside. It enacts at an epoch boundary on nodes that already carry the code, so a network that adopts one correctly shows no interruption – which is also why an unbroken ledger is not by itself proof the update enacted. The council's statement is the source for the deployment; the ledger is the source for the fact that nothing broke around it.

The release that is still not there

Nothing has been published on the mainnet side since. babylon-node's newest release is still v1.4.0.0-RC1 of 15:35:42 UTC on 8 September, still flagged a pre-release, so /releases/latest still resolves to v1.3.0.5-test.1 – the rebuild of the halted version, and the one the babylonnode CLI installs. The newest commit on main is still 7400951e of 15:28:10 UTC on 8 September, the merge of the fix itself. The final commit the council names as its next step had not been made twenty-seven hours later.

So the schedule now has everything in it except a date. Eagle Ray enacts on mainnet at the start of epoch 339,898 unconditionally, with user transactions refused through epoch 339,897, the only update in Radix's mainnet history that does not go to a readiness vote; Stokenet takes the same update on the ordinary 80%-of-stake signal, which is the vote that has now been exercised. Mainnet is two epochs from the fix and cannot reach either of them until enough validators restart on a build that has not been released.

Day ten, night: an operator names the room the halt was agreed in

Read at 23:06:50 UTC on 9 September 2026, the Gateway status endpoint returns the ledger it has returned since the halt: state version 557,840,622, epoch 339,896, round 102. That is 217 hours and 47 minutes without a committed round, and /state/validators/list answers HTTP 500 counting the same gap, it is currently 9 days, 1 hour, 47 minutes, 44 seconds behind.

The room the halt was agreed in

Who stopped the network came back in the main Radix chat tonight, and this time an operator answered with the mechanism rather than the principle. At 20:10 UTC a holder asked how decentralised Radix is if a handful of node runners and the Foundation can freeze the network in a few hours, and what stops anyone else doing the same. Seventy-two seconds later Timan of Astrolescent replied: It was done by a few dozen node runners.. we have a group where we can chat and share learnings. A few decided it was better to halt until the source of the exploit was found, and explained it to the rest of the group.

That names three things the earlier accounts left out. The operators have a standing channel of their own, separate from the Foundation and from the Radix Accountability Council. A few of them moved first and the rest were persuaded rather than instructed. And the count is a few dozen, which is the order of the set that has to agree again before validators come back. It is the same account the Foundation's announcement of 2 September contradicted when it said the Foundation and the council had halted the network, and it is the one the ledger supports.

The report comes after the network

Seventeen minutes earlier, at 19:53 UTC, a holder asked whether there is an official write-up of the exploit. projectShift, who has written the council's updates throughout, answered that enough detail is already public, that there will be an official report when the time is proper, and that the things that are safe to do will happen after we have this resolved and network liveness back. The sequencing is deliberate and it is the first time the council has stated it: the account of what happened is being held until the network is running.

Nothing has been published on the release side since. babylon-node's main branch still ends at 7400951e of 15:28 UTC on 8 September, so the final commit the council named four hours earlier as the first of its three next steps has not been made, and the branch has taken nothing for 31 hours and 39 minutes.

Day eleven: the release stops being a candidate, and the council clears operators to upgrade

Read at 11:12:37 UTC on 10 September 2026, the Gateway status endpoint returns the ledger it has returned since the halt: state version 557,840,622, epoch 339,896, round 102. That is 229 hours and 53 minutes without a committed round. /state/validators/list answers HTTP 500 and counts the same gap, it is currently 9 days, 13 hours, 53 minutes, 31 seconds behind, with current_sync_delay_seconds 827,611 against a max_allowed_sync_delay_seconds of 720.

The release is final, and that changes what the installer fetches

At 03:59:09 UTC babylon-node published v1.4.0.0, named Eagle Ray, the final commit the council named on 9 September as the first of its three next steps. Its tag resolves to 7400951e0eb76a725f39d04d57da293fb335bd0e, which is also what v1.4.0.0-RC1 of 8 September resolves to and the tip of main. The code is byte for byte the release candidate; what the final release changes is the pre-release flag.

That flag is not cosmetic. GitHub reports as latest the newest release that is neither a draft nor a pre-release, so from 8 to 10 September the answer was v1.3.0.5-test.1 – a rebuild of the very version mainnet halted on – and that is what the ghproxy mirror served to the babylonnode installer. Read at 11:12 UTC both now return v1.4.0.0. An operator who runs the standard install today gets the fix rather than the flaw, which was not true yesterday.

The instruction is still wait

At 05:54:09 UTC, in the main Radix chat, Timan of Astrolescent gave the first statement of near-term intent from anyone: The stokenet upgrade yesterday went super smooth, so we’re very close in bringing mainnet back up. That needs a bit of coordination with the node runners, so it won’t be today, but I really hope we can pull that off in the coming days. He is an operator, not the Foundation and not the council, neither of which has published a date.

Three hours later the council itself posted. At 09:13:53 UTC, projectShift wrote under the heading STATUS UPDATE FROM RAC: Although final versions has been made available, pls do not update your nodes yet. Further instructions and support will be shared later today or tmrw latest. Validator Node-runners should check dedicated chat often for specific updated information.

On 7 September the council read the Scrypto release and told operators not to run it, because a library release is not a node build. On 8 September it said the same of the release candidate, because a candidate is not a release. Today there is a release, it is flagged latest, the installer serves it – and through the middle of the day the instruction had not changed. What is being waited on is no longer a build. It is the few dozen operators who agreed the halt among themselves agreeing a restart the same way, on a schedule that has to be circulated before it can be run.

The instruction changed at 16:15 UTC. Seven hours after telling operators to wait, projectShift posted the update that message had promised, again under the heading STATUS UPDATE FROM RAC: You can upgrade and update your nodes now, using the latest software version available from official sources. Validator node-runners are pointed to the dedicated validator chat for the detail, and a node that is fully upgraded and running properly is to be left online and working. The council called it one important step closer to network liveness being restored. It is the third of the four steps it named on 1 September, the coordinated deployment across nodes, and it is the first of them that ordinary operators outside the repair are asked to carry out.

Deploying is not restarting. Read at 19:08 UTC, gateway-status returns the ledger it has returned since the stop, state version 557,840,622 at epoch 339,896, round 102, which is 237 hours and 49 minutes without a committed round; /state/validators/list still answers HTTP 500, now at a sync delay of 856,147 seconds against the 720 the Gateway tolerates. The ledger moves when enough upgraded validators agree to produce a round together, and the fourth step, a coordinated return to liveness, has no published date.

Day twelve: the restart gets its sequence, and the largest validators are still dark

Read at 07:07 UTC on 11 September 2026, the Gateway status endpoint returns the ledger it has returned since the stop: state version 557,840,622 at epoch 339,896, round 102, two hundred and forty-nine hours and forty-seven minutes without a committed round.

What the network does when it comes back is fixed in the node software rather than left to a decision on the day. babylon-node v1.4.0.0 sets Eagle Ray to enact at the start of epoch 339,898 unconditionally in its mainnet protocol config – the only mainnet protocol update in Radix's history that does not wait for the validator set to signal readiness – and declares a user transaction moratorium covering epoch 339,897, an epoch range during which user transactions are refused. The order that follows: once validators holding more than two thirds of active stake are online and running v1.4.0.0, consensus can certify rounds again and resumes inside epoch 339,897; that epoch produces rounds and accepts no user transactions; at the start of epoch 339,898 the fork enacts and the moratorium lifts together, and transactions are accepted again on the patched engine. Two node operators set that sequence out in the Radix Developers group this morning, one reading it from the code and Daffy confirming that the quorum for the fork is the same two thirds and that no announcement will precede it, because the moment cannot be predicted.

The threshold is closer than it was and it is not close. Read from StakeSafe's adoption dashboard at 07:12 UTC, 1,455,804,324 XRD is running v1.4.0.0, 31.22% of active validator-set stake, against 27.03% the previous evening; stake with a node online rose from 32.58% to 37.45% over the same hours, so operators are coming back online faster than they are coming back upgraded. The twelve largest validators account for 2,073,397,316 XRD between them, all twelve read a v1.3 version and all twelve read offline, and their stake exceeds the 1,668,419,975 XRD that still separates adoption from the threshold. One caveat on that column: the explorer reports the version a node last advertised, so an offline validator shows the release it was running when it stopped. The table says the explorer has not seen those twelve on Eagle Ray, not that their operators have not installed it.

Day twelve, midday: the network restarts

Radix mainnet committed a round at 11:35:28.96 UTC on 11 September 2026, its first in ten days. The restart is legible in the transaction stream as two consecutive ledger entries with nothing between them: state version 557,840,627 carries epoch 339,897 round 4 at 21:19:48.939 UTC on 31 August, and state version 557,840,628 carries epoch 339,897 round 5 at 11:35:28.96 UTC on 11 September. Measured between those two rounds the network was down for 254 hours, 15 minutes and 40 seconds, ten days and fourteen hours.

Those state versions correct a number this page has repeated for twelve days. Every reading recorded above came from the Gateway status endpoint, which reported the frozen ledger as state version 557,840,622 at epoch 339,896 round 102, timestamped 21:19:06.179 UTC. The transaction stream shows the ledger ran five state versions past that point before it stopped, through epoch 339,897 rounds 1 to 4 and three further user transactions, and the last of them is timestamped 21:19:48.939 UTC, forty-three seconds later than the halt time this page has been citing. The Gateway's status reading was its aggregator's tip rather than the ledger's, and the gap it left was invisible for as long as neither number moved.

The restart itself ran exactly as the node software specified it. Epoch 339,897 resumed under the user transaction moratorium and produced rounds 5 to 106 between 11:35:28.96 and 11:39:07.213 UTC, and every ledger entry in that window is a system transaction: the network was certifying rounds and refusing user payloads, which is what the moratorium is for. The fork then enacted at the start of epoch 339,898, and at 11:39:25.129 UTC round 2 of that epoch committed 17 user transactions at once, five of them failing, as the queue that had been waiting ten days cleared. Just under four minutes of empty blocks separate the network coming back from the network being usable.

Adoption crossed the threshold during the morning and kept going. This page recorded 31.22% of active validator-set stake on babylon-node v1.4.0.0 at 07:12 UTC; read from StakeSafe's adoption dashboard at 13:10 UTC, 3,737,284,159 XRD is on v1.4.0.0, 80.85% of a 4,873,528,908 XRD active set, and 81.67% of that set has a node online. The dashboard now leads with a banner of its own, reporting network liveness restored following a fix deployed at epoch 339,898.

The caveat this page attached to the morning reading turned out to be the whole of it. At 07:12 the twelve largest validators all read a v1.3 version and all read offline, and this page noted that the explorer reports the version a node last advertised, so an offline validator shows whatever it was running when it stopped. Faraz put it directly in the main Radix group at 10:11:24 UTC, answering a member asking why the ten largest validators could not spare ten minutes: the state was intentional, the largest nodes were upgraded and waiting to boot together, and the aim was to come back well clear of two thirds rather than marginally above it. Daffy had said the same sixteen minutes earlier in one line. The table was not showing a stalled upgrade. It was showing a coordinated one, held back on purpose.

Nothing official has announced any of it. The Radix Accountability Council's most recent message is still the 16:15 UTC instruction of 10 September telling operators to upgrade, and neither the Foundation's blog nor the announcements channel has posted since the network came back. That is the stated plan rather than an oversight: asked on the morning of 11 September whether an announcement would precede the fork, Daffy answered that there would be none, because the moment could not be predicted, and gave the order plainly as secure liveness first, announce after. The documentation page for Eagle Ray still answers HTTP 404, an hour after the update it is supposed to document enacted on mainnet.

The first published test of the fix is on the ledger, and it is the exploit. At 12:35:05.915 UTC, fifty-six minutes after user transactions resumed, a transaction in epoch 339,909 published a package to mainnet whose blueprint is named VaultDrainer and whose methods are drain and drain_victim_pays. It committed successfully for a fee of 14.14 XRD, which is a package publish succeeding rather than a drain succeeding. The operator who submitted it said why in the developer group a minute earlier: it is the drainer that had been hammering the unpatched network, the moratorium and the enacted network through testing, and it is on mainnet to verify the fix is operative against live vaults.

One reading does not agree with the rest, and is recorded here rather than resolved. The same StakeSafe dashboard's network summary still names the enacted protocol Cuttlefish, which is the version Eagle Ray replaces. The ledger behaviour is not ambiguous about which software produced these epochs, since the user transaction moratorium is a v1.4.0.0 feature and the network observed it for a hundred rounds, so the likeliest reading is a summary field that lags rather than a contradiction. Neither the Gateway's network-configuration nor its network-status response carries a protocol version, so it has not been confirmed from a second source.

Reading your own account at the halt

The question most often asked in the Radix chat since the halt is not about the exploit. It is whether an individual account lost anything, and during the halt the ordinary way to find out did not work: dashboard.radixdlt.com loaded and then failed, because it reads the Gateway API, and the Gateway would not answer a question about the present while it was days behind the network.

It would answer a question about the past, and still does. The guard is skipped for any request that names a ledger state, so a read pinned to state version 557,840,622 — the last one the Gateway reported, at 21:19:06.179 UTC on 31 August — returned 200 from the same endpoint that returned 500 unpinned. Verified at 07:07:56 UTC on 6 September 2026:

curl -X POST https://mainnet.radixdlt.com/state/entity/details \
  -H 'Content-Type: application/json' \
  -d '{"addresses":["account_rdx1..."],
       "at_ledger_state":{"state_version":557840622}}'

The same pin works on /stream/transactions, which with an affected_global_entities_filter set to the account returns that account's own transaction history up to the halt — the record of whether anything left it, and when. Both calls need no key.

Two limits applied while the network was down. A pinned read answers what did I hold when the network stopped, not what do I hold now, and the two were the same only because nothing could move until the restart. And it reads; it does not write. /transaction/construction refused pinned and unpinned alike, so no transaction could be built or submitted, which was the halt working as intended rather than a gap in it.

Since the restart at 11:35 UTC on 11 September, the ordinary route works again. Read at 03:06 UTC on 13 September 2026, an unpinned /state/entity/details answers 200 and /transaction/construction returns a current ledger state, epoch 340,371. The pinned read still answers, and it is now the way to compare an account at the halt with the same account today. Pin to 557840627, the last state the ledger committed before the halt (epoch 339,897 round 4, 21:19:48.939 UTC), rather than 557840622, the last one the Gateway reported. Both return 200.