---
title: "Hyperlane Asset Drain (August 2026)"
url: "https://radix.wiki/contents/history/hyperlane-asset-drain-2026"
updated: 2026-08-31
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
version: "1.0.0"
---

# Hyperlane Asset Drain (August 2026)

|  |  |
| --- | --- |
| **Date** | 31 August 2026 |
| **Window** | 16:02:20 – 16:57:41 UTC |
| **Network** | Radix mainnet |
| **Transactions** | 26, all committed successfully |
| **Assets taken** | hUSDC, hUSDT, hETH, hWBTC, hSOL, hBNB – the whole Hyperlane-bridged set |
| **Face value of the stablecoins** | 458,914.89 hUSDC + 72,420.38 hUSDT |
| **Exit** | Hyperlane warp routes, destination domain 1 |
| **Recall or freeze used** | No. Every asset had `recaller` and `freezer` set to `deny_all` and locked |
| **Root cause** | Not stated by any party as of 19:30 UTC, 31 August 2026 |
| **Ledger record** | [Collecting account](https://dashboard.radixdlt.com/account/account_rdx168lx67kgw2fsd9awudqhmwlhc9gwjw79d84mrx5cayul7gg3973f29) · [Largest transaction](https://dashboard.radixscan.io/transaction/txid_rdx19lzunu3relu436dm9r4mnmvyjx3yzr2723gk7d7kv0tce8g9h4kqd60u5v/summary) |

On 31 August 2026, between 16:02 and 16:58 UTC, twenty-six transactions on Radix mainnet emptied every [Hyperlane](https://hyperlane.xyz)-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](https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) 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](/ecosystem/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](https://dashboard.radixscan.io/transaction/txid_rdx19lzunu3relu436dm9r4mnmvyjx3yzr2723gk7d7kv0tce8g9h4kqd60u5v/summary), 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](https://dashboard.radixdlt.com/component/component_rdx1crvhu42czzpvkh556228sc5xk7uz69yvwcsqn23u5yy65pea0w02l0), passing destination domain `1` and a twenty-byte recipient address in EVM format. The change goes to [account_rdx168lx…3973f29](https://dashboard.radixdlt.com/account/account_rdx168lx67kgw2fsd9awudqhmwlhc9gwjw79d84mrx5cayul7gg3973f29), 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](https://dashboard.radixdlt.com/account/account_rdx1283x6gv9sxx75q4aypdpra5u0v3e7hh4hk7paskd4egx2nev0ucx9j), 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):

|  |  |  |
| --- | --- | --- |
| **Asset** | **Taken** | **Supply remaining on Radix** |
| [hUSDC](https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) | 458,914.885741 | 1,092.793964 |
| [hUSDT](https://dashboard.radixdlt.com/resource/resource_rdx1th4v03gezwgzkuma6p38lnum8ww8t4ds9nvcrkr2p9ft6kxx3kxvhe) | 72,420.384476 | 0.036292 |
| [hETH](https://dashboard.radixdlt.com/resource/resource_rdx1th09yvv7tgsrv708ffsgqjjf2mhy84mscmj5jwu4g670fh3e5zgef0) | 61.078006 | 0.010278 |
| [hWBTC](https://dashboard.radixdlt.com/resource/resource_rdx1t58kkcqdz0mavfz98m98qh9m4jexyl9tacsvlhns6yxs4r6hrm5re5) | 6.348243 | 0.005600 |
| [hSOL](https://dashboard.radixdlt.com/resource/resource_rdx1t5ljlq97xfcewcdjxsqld89443fchqg96xv8a8k8gdftdycy9haxpx) | 536.159806 | 0.136338 |
| [hBNB](https://dashboard.radixdlt.com/resource/resource_rdx1t4et4jddp2fdupr00k83ct9jpnkgewply42l5098ztjkfvjfedvjva) | 32.910105 | 0.002105 |
| XRD | 13,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](https://t.me/radix_dlt/1000557) 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](https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) 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](https://radixdao.org/) was taking over from the Foundation, with the Governance Framework in its ratification discussion period and no permanent council elected. [Radix governance](/contents/tech/core-concepts/radix-governance) describes the bodies that exist and what each of them can decide.

## External links

- [Collecting account on the Radix Dashboard](https://dashboard.radixdlt.com/account/account_rdx168lx67kgw2fsd9awudqhmwlhc9gwjw79d84mrx5cayul7gg3973f29) – the twenty-six transactions, newest first
- [The 16:33 hUSDC transaction on RadixScan](https://dashboard.radixscan.io/transaction/txid_rdx19lzunu3relu436dm9r4mnmvyjx3yzr2723gk7d7kv0tce8g9h4kqd60u5v/summary) – manifest, balance changes and affected entities
- [hUSDC resource](https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) – authorities and current supply
- [Hyperlane](https://hyperlane.xyz) – the interchain messaging protocol whose warp routes issue the six assets