Proxy Support at Ledger

Side Channel – Where Ledger engineers talk about how they design, build, and scale our systems.

---

Before you dive in:

• Proxy contracts can change their underlying logic without changing their address, making attacks nearly invisible to end users.
• The Bybit hack exploited this exact weakness, redirecting funds through a malicious implementation contract.
• Ledger now detects proxy patterns during clear signing, and uses execution simulation traces to reveal the actual contract being called.
• The protection is already deployed in production, silently securing every user’s clear signed transaction.

The Lesson from the Bybit Hack

In February 2025, Bybit suffered one of the largest losses in crypto history. Over $1.4 billion disappeared after an attacker used malware to change the input of a transaction calling a Safe contract. 

Behind the scenes, the malicious calldata changed the contract proxy implementation address. The rogue logic contract was then able to drain approximately 400 000 ETH (as well as other assets like stETH) and transfer those instantly to the attacker’s wallet.

Rewriting History: Could the Bybit Hack Have Been Prevented?

If the transaction had been clear signed, would the Bybit operator have been able to spot the hack in progress?

Yes, with Ledger’s proxy support, he would. Our goal is to ensure that the real behavior of a smart contract being signed by our user is known and audited, prior to clear signing step.

At Ledger, we acknowledge that proxies are often used by smart contract editors for practical reasons, such as deployment fees control. Usually, a lightweight proxy contract is deployed, pointing to a heavier logic contract that contains the real implementation. This implementation can evolve at any time, while the proxy address remains the same. For end users, this nearly invisible change can quietly introduce severe risks, and have onerous consequences.

To achieve this level of transparency, we had to look closely at how smart contracts operate at their core.

In Code We Trust

We chose to assume that a smart contract cannot be expected to follow any particular industry standards: many exist, none of them are mandatory. At the moment a smart contract interaction is clear signed on a Ledger signer, there is no reliable way to assess whether or not it meets any standard. We therefore rely on the code only to discover underlying contract calls. 

All contract codes run on top of the Ethereum Virtual Machine (EVM), a stack-based, Big Endian virtual machine. Variables, function arguments and return data reside in a stack. The EVM also includes a transient memory and a persistent associative map, called storage. The latter is an expensive artefact: developers use it sparingly.

Any Solidity code ends up into opcode instructions executed by the EVM. Among the approximately 140 opcodes, only one – delegatecall – allows a contract to run code from another contract. 

Info: delegatecall is the instruction that allows a proxy to execute another contract’s logic while keeping its own storage. This is the core mechanism behind upgradeable contracts and also behind many proxy attacks.

Understanding this mechanism, it becomes clear that the most reliable way to clear sign an EVM smart contract proxy interaction is to detect the presence of delegatecall instructions within its disassembled code.

Since contract bytecodes are public on the blockchain, and since edge cases as library usage within contracts are not significant, this statement became the foundation of our proxy support solution.

Never Again: How Ledger Detects Proxy Risks

Our proxy support solution originally involved building a stack simulator, with contract opcodes list and calldata as inputs. 

However, making this simulator ready for production would require supporting numerous EVM flavors. In addition, maintenance costs related to the EVM evolving constantly would be significantly high. 

Fortunately, many EVM nodes now propose the feature of listing all traces from a transaction simulation. At Ledger, we chose to rely on a full node to spot delegatecall traces and identify the actual logic contract targeted by the proxy. 

Given the method signature and the encoded parameters, it is possible for an Erigon node to output an array of the simulated execution traces. The trace action calltype field contains the EVM method called, in other words, the opcode behind the solidity code. This is where hidden delegatecall can be spotted.

Now, every Ledger user benefits from this anonymised transaction simulation at the clear signing step. If an implementation contract is found, the implementation details are displayed on the device.

This solution is already deployed in production and actively protects our user’s transactions from proxy-based attacks.

Conclusion

Proxy attacks represent a sophisticated evolution in crypto-theft, turning a useful developer tool into a dangerous weapon. While proxy attacks are invisible to most users, they are no longer invisible to Ledger.

With simulation trace-based proxy detection, every clear signed transaction is now protected against hidden delegatecall redirections, ensuring that what you see is truly what you sign.

---

Claire GUERRE GIORDANO – Staff Architect