Single-transaction exploits: Radiant, Infini, KiloEx and Bybit, and what monitoring cannot do

*Part 8 of 12 in Web3 Security 101.*

Parts 5 to 7 were mostly about attacks with a gap: a stolen key changes ownership, and minutes or hours later the money moves. A monitor lives in that gap. This part is about the attacks with no gap, and about what a monitor honestly cannot do for them. It is the last part of this block, so we will say it plainly.

The mechanism

A transaction on Ethereum or BNB Chain is atomic. Everything inside it either happens or reverts. A single transaction can call many contracts, take a flash loan, change an owner, upgrade a proxy and send tokens. From outside, the chain then shows one block with one result.

When the whole attack fits into one transaction, or into several in the same block, there is no "before" to look at. The first sign on chain and the loss are the same moment.

There is also a hard floor under every monitor that reads confirmed blocks. SmartAlert waits for 12 confirmations on Ethereum, about 144 seconds, before it treats a block as final, because a block that gets reorganized away would produce a false alarm. After that comes polling and rule evaluation. An alert arrives about 2.5 to 4 minutes after the block on Ethereum and under 2 minutes on BNB Chain. If the attack takes less than that, the alert arrives with the loss or after it.

Four cases

All times are UTC. Amounts are as reported by the protocol or by Rekt.

Radiant Capital, October 2024: everything in one transaction

On October 16, 2024 at 17:11:00 a single transaction on BNB Chain changed the owner of the protocol's provider contract, upgraded the contract and sent tokens to the attacker¹². About $50–58M left across BNB Chain and Arbitrum in total. The signal an owner-change rule would give, and the loss, are in the same transaction. The alert arrives after it.

Infini, February 2025: a role used by its holder

On February 24, 2025 at 02:15:59 two withdrawToReserve calls in one block (21913141) took $49.5M from Infini on Ethereum³⁴. The address that made them had held the role for 114 days. Nothing changed on chain before the attack: no new owner, no new role. The attacker's wallet had been funded through Tornado Cash at 00:57:47, but nobody knew that address in advance.

KiloEx, April 2025: the same second on three networks

We covered it in part 7. About $7.5M left BNB Chain, opBNB and Base within a minute, the first two in the same second. After an alert on the first outflow, about $0.4M was still to go⁵.

Bybit, February 2025: the longest gap in this block, and still not enough

On February 21, 2025 at 14:13:35 a transaction execTransaction with a delegatecall was executed on Bybit's Safe, from an executor the Safe had never used before⁶. At 14:15:11 a test transfer followed, and at 14:16:11 the main drain of about $1.46B. That is 2 minutes 36 seconds from the first sign to the drain, which is less than the 144-second confirmation wait plus polling⁶⁷. It is the best of these four, and still not enough time: an alert on the first transaction would arrive at about 14:16–14:17:30, around the moment the money was already leaving.

Zoth, from part 5, is in the same group: 36 seconds between Upgraded and the withdrawal⁸.

What a monitor of confirmed blocks cannot do

• Warn before. In these cases there is nothing before. The first alert is a notification of the loss, not a prediction.
• Stop anything. SmartAlert sends alerts. It does not hold your keys and cannot pause your contract.
• See a transaction before it is mined. It reads blocks that are 12 confirmations deep, not the mempool.

Faster confirmations would help only in part. Cutting the 144-second wait would shift the Bybit alert by about two minutes. It would do nothing for Radiant, Infini or KiloEx.

A different class of product

What would have worked in these cases is a different tool, and it is worth knowing what it is:

• Mempool simulation. Reading transactions before they are included in a block, simulating each one and judging what it would do to your contract's balances and state.
• Automatic pause. If the simulation shows a loss, a firewall contract or a guardian blocks or pauses before the transaction lands, with no human in the loop.

Products like Hypernative and Forta Firewall are of this kind. They work differently from an alert: they sit in the path of your transactions and act on your contract's behalf, so they need the right to block or pause it. SmartAlert is not one of them, and we do not plan to claim it is. If your threat is a one-transaction exploit, an alert is not the answer, and you should look at that class.

What still helps

Even for these cases, an alert is useful after the first transaction, for three reasons.

1. The attack is not always over. KiloEx had tails after the first transfers: smaller outflows continued until 19:55:33.
2. The downstream can be frozen. Exchanges, stablecoin issuers and bridges can freeze funds if you tell them within the hour. A signal at minute 3 is much better than a signal at minute 60.
3. You find out from your monitor, not from Twitter.

And a good design shrinks the damage that no alert can stop:

• A timelock on upgrades and ownership changes. It turns a one-transaction attack into one with a gap, and a gap is what a monitor needs.
• Limits per transaction or per hour on withdrawals. Ronin's gateway capped each withdrawal at about 4,000 ETH or 2M USDC (see part 6).
• A role review. Infini's attacker held a role for 114 days. A change alert does not fire on a role that was granted long ago; only a person reading the list of role holders does. We do not have a report that audits who holds which role today; this is manual work.

How to catch it

Honestly: the rules below do not warn you before. They tell you fast, and they leave nothing to do but contain the damage.

1. Admin events, as in part 5: ownership transferred, proxy upgraded, role granted. For Radiant these fire at about the same time as the loss.
2. Safe: a new executor and a changed implementation. An "Allowed senders" rule on ExecutionSuccess fires when the sender is outside the list of your owners and relayers; a "Contract state" rule on masterCopy() with "changed" fires when the Safe's implementation changes. For Bybit both land at the time of the drain, not before it. Safe owners changed is the third. The "Allowed senders" rule is on Business and above.
3. Outflows in dollars. Transfer above an amount in $ and "Total address balance in $ below threshold" on the treasury and the vaults. They tell you the size of the loss, and for the attacks with tails, where it is still going.
4. A channel to a person who can act, tested at night. For a one-transaction loss the next five minutes are the response, and part 12 is about them.

Next: part 9, what to monitor after an audit: a checklist.