TLDR: Authorizing actions on platforms like Solana sometimes requires calls to other programs, where addresses can be spoofed and exploited. With “badges” as a native first-class feature of Radix Engine v2 (REv2), this hack could never happen on Radix.  

Wormhole is a bridge that allows users to deposit tokens on one network, such as ETH on Ethereum. A “wrapped” version of that token is then minted on Solana, whETH, which can be redeemed for the original ETH.

This allows representations of ETH to be utilized in Solana DeFi. 

A set of nodes that are present on both networks, “Guardians”, monitor when ETH has been deposited into the Wormhole account.

Once deposited, the nodes sign a transaction to Wormhole on Solana.

The transaction includes a “sysvar address”, which tells Wormhole which account in the Solana System Program to use to verify the signatures in the transaction. 

If the signatures are valid and meet the minimum threshold (e.g. 3/4) Wormhole mints the whETH.

On Feb 2 2022, after a few preparatory moves, a hacker submitted a transaction direct to Wormhole, ignoring the Guardians.

Instead of passing in the sysvar address for the legitimate System Program, the hacker passed in the address of their own program.  

Part of the execution of this logic failed to check whether the submitted address was valid, and so execution was routed to the Hacker’s Program.

The hacker used this to mint 120k whETH, which they redeemed or traded for other tokens.

So why couldn’t this hack happen on Radix’s upcoming Babylon mainnet?

Instead of authorizations being handled by system programs with specified addresses; on Radix, authorizations are handled by badges: a native first-class feature of the Radix Engine v2 execution environment. 

In fact, there are 2 types of badge:

1. A badge is a resource, like an NFT or token, that can be presented (shown) to smart contract components in a tx. REv2 will only execute the tx if all required badges are presented for each requested action, as defined by the component.

2. A virtual badge exists temporarily for on-the-fly authorizations. Before tx execution, REv2 creates a virtual badge for each signer’s public key. When the tx then calls a component, REv2 will check whether the component requires any specific combination of badges.

Either of these options would work for an implementation of “Wormhole” on Radix. But the simpler of the two is the use of virtual badges.

Here, after 3 Guardians sign their tx, REv2 creates 3 virtual badges for each Guardian’s public key. REv2 then checks whether the virtual badges defined in the “Wormhole” component corresponded to those presented. As 3/4 were present, 1 whETH is minted for the user.

Notice how there is no passing in of addresses to system programs.

Authorizations on Radix are handled natively by the platform through badges. As a result, the kind of complexity (and error) that led to this $326m hack just isn’t possible on Radix.

This is one more example where REv2 natively understanding what resources are means developers can create simple, elegant, powerful, and safe ways of managing what is devilishly complex on other platforms. That’s why we call it a DeFi Engine - the hard stuff is done for you.

https://www.radixdlt.com/post/the-defi-engine-and-what-it-means-for-the-future-of-finance

If you’d like to learn more about badges and virtual badges, our Scrypto v0.3 release blog provides a great overview:

​​https://www.radixdlt.com/post/scrypto-v0-3-released

Thank you to Andrew Fraser @SerFrae, CEO of Synchrony Labs, for insight on Solana architecture.

For the last in the Rekt Retweet series:

Rekt Retweet #9: The Transaction Manifest - Why the $14m Furucombo hack could NEVER happen on #Radix

https://twitter.com/radixdlt/status/1539570728357462018

‍

‍