ByBit, one year on: clear signing, Guardrail and EIP-7702 — what changed in the multi-sig ecosystem

21 February 2026 marks one year since the ByBit hack — 401,347 ETH ($1.5B) drained by TraderTraitor through the Safe{Wallet} frontend. We covered it in detail at the time: developer machine compromise chain, JavaScript injected into the app.safe.global S3 bucket, divergence between what the signer saw and what they signed, operation=0 → operation=1, slot 0 rewritten to the attacker’s implementation.

Twelve months later the question is not what happened — that is closed — but what changed. Short answer: three concrete pieces in the defensive chain. An on-chain piece (Safe Guardrail, August 2025), a protocol piece (EIP-7702 and the family of smart EOAs, Pectra May 2025), and a UX piece (ERC-7730 and the Ethereum Foundation’s stewardship of clear signing, announced in May 2026). And one piece that did not change: the recovery numbers. Only 3.54 % of the stolen funds have been frozen at the one-year mark.

Sources: work based on public material from the Safe Foundation, Ledger, the Ethereum Foundation, Bybit (LazarusBounty reports) and the original technical post-mortems. Own PoC on Sepolia testnet reproducing the ByBit pattern in miniature and showing which of the three defences would have blocked the attack — no traffic against third parties, no victim.

One-sentence recap

If you did not read last year’s post: attackers with access to a Safe developer machine injected JavaScript into _app-52c9031bfa03da47.js that only acted if the signer was the ByBit cold wallet address. The JavaScript replaced the transaction the operator wanted to sign with another one carrying operation=1 (DELEGATECALL) to an attacker contract. On signing and execution, the contract’s SSTORE(0, ...) rewrote the proxy’s slot 0 — its implementation address. The multi-sig stopped being a multi-sig. Three legitimate signatures, a disguised transfer(address,uint256) call, and control of the proxy changes hands.

The control that closes that vector is two-fold: that the signer sees decoded what they are signing (clear signing) and that the Safe contract itself rejects unauthorised DELEGATECALL (Guardrail). Either defence on its own would have blocked the attack. The two together are the mature pattern.

Recovery — one year on

As of 21 February 2026 the balance is the following, according to ByBit’s own LazarusBounty program:

Ben Zhou (CEO ByBit) keeps the bounty public — total payouts close to $4M of the $140M provisioned. The LazarusBounty has shown two things: the EU/US/JP/KR exchange network cooperates faster than Lazarus’s pace through mixers, but the final mile (turning traced funds into frozen funds outside cooperative jurisdictions) stays blocked. THORChain and cross-chain bridges with Asian jurisdiction absorb a good share of the flow. Without extra jurisdictional pressure, recovery stalls at the 3-4 % line.

Comparison with other Lazarus hacks for perspective: the WazirX hack of July 2024 (~$235M) had recovered around 85 % of value by the end of 2025 — but only because WazirX restructured legally and the debt was absorbed against equity, not because funds were recovered on-chain. Phemex ($100M, April 2024) closed without public user reimbursement. ByBit absorbed the loss through 1:1 solvency with reserves, no restructuring.

The reading: funds stolen by Lazarus in ByBit-scale operations do not get recovered. The loss is absorbed by the operator or transferred to the user. The practical defence is in not signing the malicious transaction, not in chasing it afterwards.

What changed on-chain — Safe Guardrail (7 August 2025)

Safe Research publishes Guardrail on 7 August 2025. It is a Safe Guard — the Transaction Guards mechanism that already existed in Safe v1.3 and that the documentation recommended but few operators used — implemented as a contract on Safe v1.5.0+.

What it does, in one line: it rejects any execTransaction with operation=1 (DELEGATECALL) whose to is not in the Safe’s pre-approved allowlist.

Operational details:

• Pre-approved allowlist. On installing Guardrail, the operator defines the initial list of contracts the Safe can delegate-call to. No delay for this initialisation (one-shot at setup).
• Time delay for new entries. Adding a contract to the allowlist after initial install requires a commit with a timer (configurable, e.g. 24h). During the delay any owner can veto the addition. The inspiration is the Compound/Aave governance timelock pattern applied to a DELEGATECALL allowlist.
• Coverage of modules. Guardrail does not only intercept direct execTransaction; it also verifies DELEGATECALLs executed through Safe modules (modules like SafeModuleGuard sit in the same perimeter).
• Formal verification. Safe Research includes Certora specs for the contract. The intent: the property “no DELEGATECALL outside the allowlist without going through the delay” is proven, not tested.

Had Guardrail been active on the ByBit Safe on 21 February 2025, the attacker contract 0x96221423... was not in the allowlist. The transaction would have reverted through the guard before reaching execTransaction. None of the three signatures would have mattered. The injected JavaScript would not have been able to escalate.

Why few large operators had it in February 2025: Safe Guards existed but were an opt-in feature, with no UI pressure to activate. After August 2025, with Guardrail as a reference implementation backed by formal verification, Safe{Wallet} pushes Guard installation in the enterprise onboarding flow. For multi-sigs with >$10M under custody, Safe{Wallet} shows a degraded security score if no Guard is active. The pressure is UX, not protocol.

What changed in the protocol — EIP-7702 and Pectra (May 2025)

Pectra, the Ethereum mainnet upgrade, ships on 7 May 2025. It brings EIP-7702, among other things — proposed by Vitalik Buterin in May 2024 and refined through Q3 2024 to Q1 2025.

What EIP-7702 does, in one sentence: it lets any EOA (externally owned account) register a delegation designator — the address of a smart contract whose code executes as if it were the EOA’s code for the duration of the transaction.

For a ByBit-type attack, the interesting piece is the constrained session keys this primitive enables. Typical setup:

1. The cold wallet signer uses EOA-A with a master key on an offline hardware wallet.
2. EOA-A delegates to a smart contract C implementing session keys: it lets a secondary key K (on a connected device, e.g. another Ledger in the hot path) sign transactions only if they meet rules: spending cap, recipient allowlist, selector allowlist, time window.
3. For routine operations (small transfers to a hot wallet), the signer uses key K on the connected device. For exceptional operations (Safe upgrade, owner change), they have to take out the master key.

Where this fits the ByBit threat model: the attack hit signers using their principal key. If ByBit’s routine operation had been handled via a constrained session key, the injected JavaScript would have had to make the session key sign a setImplementation() or delegatecall transaction — out of session-key scope. The signer holding the master key would never have been in that flow.

EIP-7702 is not defence per se against the ByBit pattern; it is infrastructure to separate paths. Routine operations with a low-privilege key, exceptional operations with the master key. The actual defence is what the operator builds on top.

The Safe Foundation proposes a path for existing Safe deployments to register as valid EIP-7702 delegation targets. Operational implementation through 2026. Known risk: an EOA with delegation can change the delegation at any time (the master key always holds power); the pattern does not turn EOAs into trustless multi-sigs — there is still a single point of compromise in the master key.

What changed in the UX — clear signing becomes the standard

The control most discussed after ByBit was clear signing: the hardware wallet decodes the calldata and shows the signer what each parameter does in human language, instead of truncated hex. Ledger supported it with contract-specific plugins; Trezor supported it partially; MetaMask delegated to Tenderly and Blockaid. With no open standard between wallets, the experience was inconsistent.

Twelve months on:

• May 2025 — Ledger publishes ERC-7730 as an open Generic Parser spec. It lets dApps publish JSON descriptors with how to decode their transactions; wallets that understand the format show human-readable output. ERC-7730 v1.0 enters the EIP process in Q2 2025.
• May 2026 — the Ethereum Foundation takes stewardship of ERC-7730 and combines it with ERC-8176 (cryptographic attestation framework for the descriptors). Announcement on 12 May 2026 from the Foundation’s Trillion Dollar Security Initiative.
• Initial backers: Ledger, Trezor, MetaMask, WalletConnect. Trezor announces implementation in the Safe 5 / Safe 7 firmware with plans for full transaction decoding by Q2 2026 (CTO Tomáš Sušánka in CoinDesk, April 2026).
• Ledger ships ERC-7730 as the Clear Signing engine in the Ledger Nano Gen5 (October 2025) and backports it to Ledger Stax / Flex / Nano X with firmware ≥ 2.4.

State as of February 2026 (just before the EF announcement):

The sector pattern is clear: clear signing moves from opt-in to default. What in February 2025 was a best-practice discussion has become baseline for enterprise hardware wallets.

Sepolia PoC — comparing signing with and without defences

We reuse the lab from the original post and add the two defensive controls. Operational question: what happens if in February 2026 we reproduce the ByBit attack, but the Safe has Guardrail and the signer uses clear signing?

Setup

- Sepolia RPC: https://sepolia.infura.io/v3/<key>
- Foundry to compile and deploy
- Ledger Nano X firmware 2.4.x with Safe Eth app installed
- node 20 + express for the malicious "frontend"
- Safe v1.5.0 with Guardrail v1.0 deployed

Step 1 — 1-of-1 Safe + Guardrail installed

Same factory as in the original post (createProxyWithNonce), but with an extended setup(...) to register the Guard:

GUARDRAIL=$(forge create Guardrail --constructor-args $SAFE_ADDRESS [$ALLOW_LIST] --rpc-url $SEPOLIA_RPC --private-key $OWNER_KEY)
# After the Safe setup, call setGuard(GUARDRAIL):
cast send $SAFE_ADDRESS "setGuard(address)" $GUARDRAIL \
  --rpc-url $SEPOLIA_RPC \
  --private-key $OWNER_KEY

The initial [$ALLOW_LIST] contains only legitimate Safe upgrade contracts (e.g., MultiSendCallOnly). The attacker’s Mimic contract is not in it.

Step 2 — Mimic + Drainer (same as the original post)

// Mimic — rewrites slot 0 via delegatecall, as in February 2025
contract Mimic {
    function transfer(address _to, uint256 /* _value */) external returns (bool) {
        assembly { sstore(0, _to) }
        return true;
    }
}

forge create leaves 0xMIMIC and 0xDRAINER deployed on Sepolia. The attacker chain is intact.

Step 3 — Local frontend that lies (same)

The Express server from the original lab serves the UI-vs-calldata divergence. The operator’s HTML page renders “routine transfer 0.01 ETH”; the block that calls the Ledger uses tx.to = 0xMIMIC, tx.operation = 1.

Step 4 — Result A: Ledger without clear signing, Safe without Guardrail

Same as last year’s lab. The Ledger screen shows truncated hex:

Review transaction
To:    0xMIMI...iC
Data:  0xa9059cbb...
Value: 0 ETH

The signer trusts the browser UI, signs. The transaction executes. cast storage 0xLAB_SAFE 0 returns 0xDRAINER. Lab compromised. This is the February 2025 scenario.

Step 5 — Result B: Ledger with clear signing, Safe without Guardrail

Safe Eth plugin installed, firmware ≥ 2.4.x, Safe app active. The Ledger screen now shows:

WARNING: delegate call
This transaction will execute code from
  0xMIMI...iC
in the context of YOUR SAFE.
Storage may be modified.

Continue?

If the signer reads the warning and rejects, no hack. If they trust the browser UI and approve by pressing Continue, the transaction executes anyway. The defence is human: it depends on the signer looking at the device and understanding what it says. Under operational pressure, with an operator used to approving routine transactions several times a day, the “skim through and approve” ratio is not zero. Clear signing turns blind sign into informed sign; informed sign still depends on the human.

Step 6 — Result C: Safe with Guardrail active (with or without clear signing)

The transaction reaches the Safe’s execTransaction. Before executing, the Safe calls the registered Guard. Guardrail checks to = 0xMIMIC and operation = 1 against the allowlist. 0xMIMIC is not in it. The call reverts with error: DelegateCallNotInAllowlist(0xMIMIC).

> cast send $SAFE_ADDRESS "execTransaction(...)" 0xMIMIC 0 0xa9059cbb... 1 ... \
    --rpc-url $SEPOLIA_RPC --private-key $OWNER_KEY
Error: execution reverted: DelegateCallNotInAllowlist

cast storage 0xLAB_SAFE 0 returns the legitimate implementation. Slot 0 does not change. The Ledger signature does not matter — the Safe contract rejects the transaction before executing the delegatecall. The defence is on-chain and non-negotiable: for the attack to land, the attacker would first have to make 0xMIMIC enter the allowlist, which requires an addToAllowlist(0xMIMIC) with their own 3-of-N signatures plus waiting out the time delay. During the delay any owner sees the pending proposal and can veto it.

Step 7 — Lab conclusion

The mature 2026 pattern is C + D combined. Guardrail as an on-chain safety net (not dependent on the signer); clear signing as an extra check for the human. Either alone is better than February 2025; both together close the vector.

Total Sepolia lab cost: < 0.1 ETH of testnet, trivial gas. Implementation time: ~2 hours with Foundry installed.

What changed on the audit and vendor side

The audit firms that produced ByBit post-mortems in 2025 have expanded scope through the year:

• Sygnia keeps ByBit as a reference customer and publishes several sector analyses on developer machine compromise in crypto through 2025. The TraderTraitor playbook of “malicious Docker project via social engineering” is still active; Sygnia documents more cases through 2025 without escalation to a major hack.
• NCC Group and Trail of Bits incorporate frontend security review as a standard part of audits for protocols with hosted UI. What used to be “we audit the smart contract” becomes “we audit the smart contract + the JavaScript bundle + the deploy chain”. Sector practice changes.
• Hypernative becomes a Safe Foundation partner. Safe Shield integrates Hypernative’s real-time detection engine inside app.safe.global — every transaction is scanned against pre-execution heuristics, with policies the operator defines. Available to enterprise customers in 2025-2026.

Where there has been no meaningful change: the segment of individual non-custodial wallets that depend on browser extensions or mobile apps with auto-updates. The Trust Wallet incidents in September and December 2025 (Chrome extension v2.68 compromised via supply chain) show that the ByBit pattern applied to individual users still works: if the extension is compromised, the signer sees one thing and signs another. Clear signing on a hardware wallet is the valid local defence; Guardrail-style protection in a personal wallet is not yet a generalised product.

What TraderTraitor is doing in 2026

The North Korean cluster within Lazarus that ran ByBit is still active. Documented pattern through 2025-2026:

• Stable initial TTP. Malicious Docker projects downloaded by crypto developers via social engineering on LinkedIn / Discord / GitHub. The opening sophistication has not increased — the vector works because targets keep falling for it.
• Target diversification. In April 2026, Lazarus drains $285M from Drift Protocol and $292M from KelpDAO — months of prior social engineering, per the reports. Same modus operandi: compromise a developer / operator with access to critical infrastructure, wait for the high-value transaction, intervene.
• Faster attribution. The FBI publishes Lazarus attribution advisories within days of major incidents, not weeks. Sector intelligence is consolidated; what stays slow is the operational response of receiving exchanges in non-cooperative jurisdictions.

Updated operational detection and mitigation

For Safe multi-sig operators with significant custody, the 2026 baseline is no longer optional:

1. Guardrail or equivalent Safe Guard active. Block unauthorised DELEGATECALL on-chain. For Safe v1.5.0+. Documented at docs.safe.global.
2. Clear signing by default on every signer. Ledger Nano Gen5 / Stax / Flex with firmware ≥ 2.4 + Safe Eth app active, or Trezor Safe 5/7 with ERC-7730 as it rolls out through 2026. Without clear signing, the signer is blindly depending on the frontend.
3. Independent double-check of the payload before signing. Before pressing Continue, the operator decodes the safeTxHash in a second client (Etherscan Transaction Decoder, Tenderly Simulator, local cast 4byte-decode). If the decoding does not match the frontend UI, stop and escalate.
4. EIP-7702 session keys for routine operations, master keys only for exceptions (Safe upgrades, owner changes). 2026 work — implementation still in progress for Safe.
5. On-chain monitoring of the proxy’s slot 0. On-chain monitoring services (Forta, Blockaid, Hypernative) have specific detectors for Safe implementation changes. Immediate alert on change.
6. Air-gap the proposal process. The machine that proposes the transaction must be different from the one that signs. The signing machine builds from the raw transaction hash received through an alternative channel, not from the hosted frontend JavaScript.
7. Hosted frontend as documented single point of failure. If the multi-sig manages >$10M, the official hosted frontend (app.safe.global) is a known and accepted but recorded risk. Alternatives: self-deploy of the Safe frontend (it is open-source), or a pure CLI client (Safe CLI, Ape Safe). After the Safe Shield + Hypernative integration in 2025, the official hosted is safer than in February 2025 — but it is not the only path.

What this leaves for the rest of 2026

• Guardrail-style protections become general. The 2026 discussion is no longer whether to install a Safe Guard, it is which one. Variants (Fiducia with on-chain co-signers, integrations with AWS AgentCore-style Cedar policies) enter the catalogue.
• EIP-7702 operational implementations on Safe. Through 2026 Safe completes the path for existing deployments to accept delegation; first operational constrained session keys deployed in enterprise production.
• ERC-7730 as the de facto standard. The EF’s Trillion Dollar Security Initiative maintains the registry; wallets that do not support clear signing will lose enterprise market share.
• Lazarus stays active, the same initial vector keeps working. April 2026 with Drift + KelpDAO confirms that developer machine compromise via social engineering is not a closed problem. Defence on the developer endpoint is continuing work, not resolved.

References

• IRONHACKERS — original post: ByBit / Safe{Wallet}: how Lazarus stole $1.5B (Feb 2025)
• Safe Research, Guardrail: Locking Down Delegate Calls in Safe (7 Aug 2025): https://safefoundation.org/blog/safe-research-guardrail-locking-down-delegate-calls
• Safe Foundation, EIP-7702: A Win for Smart Accounts in Ethereum’s Pectra Upgrade: https://safefoundation.org/blog/eip-7702-smart-accounts-ethereum-pectra-upgrade
• Ledger, Stewardship of Clear Signing Passed to Ethereum Foundation: https://www.ledger.com/blog-ledger-clear-signing-ethereum-foundation
• Ledger Developer Portal, ERC-7730 Specifications: https://developers.ledger.com/docs/clear-signing/reference/specifications
• Safe Foundation, Safe partners with Hypernative: https://safe.global/blog/safe-partners-with-hypernative-to-launch-enterprise-security-integration
• Coira, Bybit Hack Anniversary: One Year Later: https://coira.io/news/bybit-hack-anniversary-1-5b-lazarus-recovery
• FBI / IC3, North Korea Responsible for $1.5 Billion Bybit Hack (PSA 250226): https://www.ic3.gov/PSA/2025/PSA250226
• Sygnia, Investigation into the Bybit Hack: https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/
• NCC Group, In-Depth Technical Analysis of the Bybit Hack: https://www.nccgroup.com/research/in-depth-technical-analysis-of-the-bybit-hack/
• Safe Guards documentation: https://docs.safe.global/advanced/smart-account-guards
• EIP-7702 spec: https://eips.ethereum.org/EIPS/eip-7702
• ERC-7730 registry (Ethereum Foundation): https://github.com/ethereum/clear-signing-erc7730-registry