RADIX WikiRADIX Wiki

On 31 August 2026, between 16:02 and 16:58 UTC, twenty-six transactions on Radix mainnet emptied every Hyperlane-bridged asset held on the network and sent the proceeds out over Hyperlane's own warp routes. The assets came out of user accounts and out of the liquidity pools of Radix dApps alike, in one pass, without a single owner signing anything. Six hours later the remaining supply of hUSDC on Radix was 1,092.79 tokens, and the other five wrapped assets stood at fractions of one unit.

The incident followed by less than a day the exploit of Weft Finance, whose attacker also left through a Hyperlane warp route. No party had stated a root cause for the drain at the time of writing, and this page reports what the ledger holds rather than a diagnosis.

What the ledger shows

The largest of the twenty-six is txid_rdx19lzunu3…qd60u5v, committed at 16:33:28.554 UTC for a network fee of 8.39 XRD. It is a single manifest and it does three things in order.

First it publishes a package. The blueprint is named LiquidityTool and it exposes sixty-one functions called run_0 through run_60, which is the shape of code written for one transaction rather than for reuse.

Then it calls all sixty-one, and each call takes one argument: an internal_vault_ address. Sixty distinct vaults appear across the calls. An internal vault is the container an account or component holds a resource in, and its address is public. After the calls the worktop holds 442,985.632108 hUSDC drawn from fifty-nine separate accounts and components.

Last it takes that balance and 380.037752172 XRD into buckets and calls transfer_remote on the hUSDC warp route, passing destination domain 1 and a twenty-byte recipient address in EVM format. The change goes to account_rdx168lx…3973f29, which is the only account the manifest names anywhere.

Two absences in that manifest carry as much as the instructions do. There is no proof, no badge and no owner authorisation of any kind in front of the vault calls. And there is no LOCK_FEE instruction at all: the fee was locked from inside the published blueprint, against a vault the transaction passed to it by address. The XRD for fees came out of account_rdx1283x6…0ucx9j, which lost 500 XRD on each of the twenty-six and received nothing back. Whether that account belongs to the attacker or to a third party whose XRD vault was used the same way as the sixty others is not settled by the ledger.

What was taken

Summed across all twenty-six transactions, and set against what the same resources report on the ledger at epoch 339,871 (19:09:50 UTC, 31 August 2026):

AssetTakenSupply remaining on Radix
hUSDC458,914.8857411,092.793964
hUSDT72,420.3844760.036292
hETH61.0780060.010278
hWBTC6.3482430.005600
hSOL536.1598060.136338
hBNB32.9101050.002105
XRD13,000 (fees, 500 per transaction)–

The two stablecoins alone carry a face value of 531,335.27 US dollars. The rest depends on market prices, and the wiki states no total for it. The supply column is the plainer measure of what happened: bridging an asset out of Radix burns it here, so the drain is visible in the supply of each resource, and what is left of five of the six is dust.

The hour

The sequence reads as a test followed by a sweep.

  • 16:02:20 to 16:22:37. Six transactions, one per asset, each moving a token amount: 0.005 hETH, 0.00035324 hSOL, 0.015 hBNB, 0.00084948 hWBTC, 482.99 hUSDT, 384.81 hUSDC. Each still paid the full 500 XRD bridge fee.
  • 16:30:08 to 16:57:41. Twenty transactions carrying the rest. The hUSDC sweep at 16:33 is the largest single one; hUSDT, hWBTC, hETH and hSOL follow in blocks.
  • 17:17 UTC. The first public report reaches the main Radix Telegram group, twenty minutes after the last transaction committed.
  • 18:18 UTC. A message in that group states that Hyperlane, the security firm Zellic and others have been contacted, and that parties on the receiving chain are being approached to contain the assets.

The collecting account has committed no further transaction since 16:57:41, read at ledger state version 557,804,842.

Why the usual controls did not apply

A Radix resource can carry authorities that let a named badge holder claw tokens back or halt movement in them. Neither existed here. Read live at 19:08 UTC on 31 August, hUSDC reports recaller and freezer both set to deny_all, with rules_locked true, so those settings cannot be changed by anyone. The token can be minted and burned only by the badge the bridge holds, which is what a warp route needs in order to work at all.

The consequence runs both ways. Nobody could have recalled these assets out of user accounts, which is the property holders were told they had. And nobody can recall them back, which is why containment moved to the receiving chain within the hour. The drain was not a recall and not a freeze; on the ledger it is an ordinary withdrawal that no owner authorised.

XRD itself was not swept. The 13,000 XRD that moved was fee payment, and it came from one vault rather than from the network at large. The scope of the drain is what the attacker could bridge, which is not the same statement as the scope of what the method could reach.

What is unresolved

Three questions were open at the time of writing, and each has an answer the ledger cannot supply.

The first is the cause. A published blueprint took resources out of vaults it had no authority over. That is either a flaw in the warp-route package the six assets share, or a flaw underneath it in the authorisation the Radix Engine applies to a vault reference. The two readings imply very different scopes, and only the code answers it.

The second is recovery. The assets left the network, so what is left to recover sits on the receiving chain and depends on the parties there.

The third is who responds. The incident landed in the week the Radix DAO was taking over from the Foundation, with the Governance Framework in its ratification discussion period and no permanent council elected. Radix governance describes the bodies that exist and what each of them can decide.

HydrateLast updated 1h agov1.0.01 revision