The infinite inflation of VLX could have destroyed Velas’ $100M market cap, but the threat has been mitigated thanks to the responsible disclosure of the vulnerability, and the resulting security fix (commit).

After spending some time writing infrastructure for finding smart contracts vulnerabilities, I stumbled upon pwning.eth’s great writeups for “delegatecall -> precompiled smart contract”-type bugs found in the implementations of blockchain nodes.

It struck me as the type of pitfall that would require deep EVM internals knowledge in order to avoid, so I decided to change my research focus from smart contracts, to the blockchain nodes themselves.

To follow what comes next, I recommend you read this great analysis to understand how this class of bugs work.

In any case, the important takeaway to keep in mind is that an attacker can trick a precompiled contract they’re sending assets to it, if the precompiled contract’s implementation doesn’t make sure it’s not called using delegatecall.

Let the games begin

I opened DefiLlama’s list of top EVM chains, and started auditing them one by one.

Most blockchains didn’t add any new precompiled contracts, and only had the ones forked from Ethereum.

Some blockchains introduced new precompiled contracts, but they didn’t touch anything sensitive.

Some blockchains introduced new precompiled contracts that touched sensitive areas, but also implemented the relevant guardrail of not allowing them to be called with delegatecall.

And then came Velas.

What’s Velas?

Velas is a hybrid chain, leveraging Solana’s high transaction throughput (up to 65k TPS), together with Ethereum’s Virtual Machine (EVM), the de-facto standard for smart contract execution in the blockchain space.

How does Velas work?

Velas’ chain supports EVM transaction execution via wrapping it into a regular native (Solana-like) transaction with an instruction to invoke an EVM Program which executes the wrapped EVM transaction inside the chain’s embedded EVM.

You can hold the chain’s native currency, VLX, in "Solana space" aka "Native space", or in "EVM space".

When it’s in Native space, it’s owned by your Native, Solana-type account.

And when it’s in EVM space it belongs to an EVM address, while in the Native space it’s represented as being held “in custody" by the EvmState account.

How do you bridge VLX from EVM space to Native space?

The way to bridge VLX from the EVM space to Native space is to send a transaction to a precompiled contract called ETH_TO_VLX at 0x56454c41532D434841494e000000000053574150:

Which has following interface:

interface ETH_TO_VLX {
  function transferToNative(bytes32 native_recipient) external payable;
}

Vulnerability Breakdown

This bug is very similar to the Aurora and Moonbeam bugs.

It’s caused by the ETH_TO_VLX precompiled contract not taking into account it can be called with delegatecall, and thus not properly verifying that the funds it’s being asked to bridge are actually being sent to it.

The vulnerability’s PoC creates a smart contract which calls this precompiled contract using delegatecall which doesn't actually send the VLX tokens to it, but it does trick it into transferring the corresponding amount of VLX to our Native space account.

This process can be repeated to steal all the VLX tokens owned by the EVMSTATE Native account, while also minting an infinite amount of VLX tokens in the EVM space.

The infinite inflation of VLX could have seriously damaged the whole ecosystem of Velas (the market-cap of VLX was 100 million dollars at the time of disclosure).

🙏🏻🤝🏻

I’d like to thank Mitchell of Immunefi for his gracious pro-bono assistance with the vulnerability’s disclosure, out of his deep commitment for securing the crypto space (it wasn’t as straightforward because Velas does not have a bug bounty program).

I wouldn’t have gone this particular research path if it wasn’t for pwning.eth’s inspiring writeups. First of all for the merit of their top-notch technical breakdowns, and second of all for their unique and engaging literary style that makes them a joy to read.

Last but not least, I would like to thank Roman and the rest of the Velas team for their decision to reward me a $100k bounty for the disclosure (denominated in VLX staked for 6 months), and for releasing the security fix so quickly (released within 23 hours).