What Is Blind Signing? How to Verify Before You Sign

TL;DR

The precise bytes of the payload placed before your key, executed exactly as composed, regardless of what any screen said about it. The chain verifies that you signed the data; it has no concept of what you were shown or what you meant.
On 21 February 2025 roughly $1.5bn in ether left a Bybit cold wallet after its signers approved a transaction. The FBI attributed the theft to North Korea, and Sygnia and the Safe Ecosystem Foundation reported a compromised Safe{Wallet} developer machine and altered front-end code; the account that the signers' display differed from the payload they approved is an inference from Sygnia's and Safe's findings, since no published primary record shows what the signers saw. The case rewards study because the observed facts, the attribution and the explanation of what signers saw rest on different kinds of evidence, and it helps to keep them apart.
Three layers, in rising order of assurance: wallets that decode payloads into meaning, a hardware display whose rendering does not depend on your computer, and independent decoding or simulation of the payload for signatures that matter. Each layer narrows one place a lie can live, and none closes them all: each reduces the risk of a malicious authorisation without eliminating it.
Four fields every time: destination, asset, amount, function. One rule always: unreadable means no. One escalation: for signatures that could cost more than a bad day, verify the payload independently before your key touches it. Short enough to use, which is the point.

В одном блоке

Blind signing is a way of approving a crypto transaction or message that commits the signer's key to data the signer cannot read or check. It happens when a wallet cannot decode the request and shows raw data, or when compromised software describes the request as something it is not. The approval then depends on trusting whoever built the request.

What does a signature actually authorise?

Быстрый ответ

The precise bytes of the payload placed before your key, executed exactly as composed, regardless of what any screen said about it. The chain verifies that you signed the data; it has no concept of what you were shown or what you meant.

The mechanics matter because they locate the risk. When a wallet asks you to sign, somewhere underneath is a structured payload: a destination address, an amount, and, for contract interactions, a function call with parameters, the machinery the smart contract guide describes. Your key signs those bytes. Validators check the signature against the bytes and execute the bytes. Everything between the payload and your eyes, the dApp's interface, the wallet's summary, the icons and labels, is presentation, produced by software of varying honesty, and none of it travels with the transaction.

That gap defines the two failure modes. In the first, the presentation is honest and unreadable: the wallet shows a hexadecimal blob because it cannot decode an unusual contract call, and a signer who approves is trusting the requesting site completely. In the second, the presentation is dishonest: malware or a compromised front end renders a comforting description of a hostile payload. Both are blind signing in effect, because in both cases the signer approves something they have not actually read.

The term is not used consistently across wallets and ecosystems, so it helps to know which sense a given document intends. Some hardware vendors use it narrowly, for what a device does when it cannot interpret a request: Ledger, for example, describes its devices falling back to a raw hash with a blind-signing warning when an application cannot interpret a contract (Ledger, clear signing explainer, updated 16 April 2026). Others use it more widely for any approval of data the signer cannot read or check, whether a transaction, an off-chain message or a payload whose display has been falsified. This guide uses the wider sense. When a wallet's settings or documentation refer to blind signing, its own definition decides what a setting enables or what a warning means. The second fits what investigators reconstructed in the February 2025 Bybit theft, which Chainalysis on 24 February 2025 called the largest digital heist in the history of cryptocurrency; the next section separates what was observed there from what is inferred.

What happened at Bybit, and what does it show about blind signing?

Быстрый ответ

On 21 February 2025 roughly $1.5bn in ether left a Bybit cold wallet after its signers approved a transaction. The FBI attributed the theft to North Korea, and Sygnia and the Safe Ecosystem Foundation reported a compromised Safe{Wallet} developer machine and altered front-end code; the account that the signers' display differed from the payload they approved is an inference from Sygnia's and Safe's findings, since no published primary record shows what the signers saw. The case rewards study because the observed facts, the attribution and the explanation of what signers saw rest on different kinds of evidence, and it helps to keep them apart.

What was observed

On 21 February 2025 a transaction from one of Bybit's Ethereum cold wallets, a Safe multi-signature wallet, moved approximately 401,000 ETH, worth nearly $1.5bn at the time, to addresses the attacker controlled (Chainalysis, 24 February 2025). Bybit's statement of 26 February 2025 said that the signers had been deceived into approving a malicious transaction and that its forensic experts found no indications of compromise within Bybit's infrastructure (Bybit, press release, 26 February 2025). The transfer is on-chain and independently checkable; the rest of this paragraph is Bybit's own account.

Who the FBI says was responsible

On 26 February 2025 the FBI published a public service announcement attributing the theft to the Democratic People's Republic of Korea, under the activity name TraderTraitor, and noting that, in its description, the actors had already begun converting stolen assets and dispersing them across thousands of addresses (FBI, PSA, 26 February 2025). The attribution is the FBI's, made in a public service announcement; it is not a court finding. The PSA is an attribution and a laundering warning; it does not describe how the transaction was engineered.

How investigators say it was done

Bybit said it had engaged Sygnia and Verichains for an independent review and that both "found no indications of any compromise within Bybit's infrastructure"; the same statement of preliminary findings said that "the credentials of a Safe developer were compromised", giving the attacker access to Safe{Wallet} infrastructure (Bybit, press release, 26 February 2025). The Safe Ecosystem Foundation stated on 28 February 2025 that the attack "was achieved through a compromised Safe{Wallet} developer machine resulting in the proposal of a disguised malicious transaction", and that the forensic review found no vulnerabilities in the Safe smart contracts (Safe Ecosystem Foundation, 28 February 2025). Sygnia's published investigation adds detail: it reports that a Safe{Wallet} developer's macOS workstation was compromised on 4 February 2025 and that the developer's AWS credentials were then used to reach Safe{Wallet} infrastructure, and that JavaScript files served from the AWS S3 bucket behind the Safe{Wallet} web interface were modified on 19 February 2025 with code that activated only for a specific Bybit cold wallet, and clean versions were uploaded about two minutes after the malicious transaction executed on 21 February (Sygnia, 16 March 2025). According to Sygnia, the altered code replaced the transaction's payload with a delegate call to a pre-deployed malicious contract (Sygnia, 16 March 2025).

The inferred part: what the signers saw

The account in which Bybit's signers approved a payload that differed from what their interface presented is an inference from Sygnia's and Safe's findings. Sygnia reports that the injected code's "primary objective was to modify transaction content with hardcoded parameters" and concludes that the Safe{Wallet} interface "displayed legitimate transaction data while malicious transactions were signed and executed in the background" (Sygnia, 16 March 2025); the Safe Ecosystem Foundation describes "a disguised malicious transaction" (Safe Ecosystem Foundation, 28 February 2025). Both are reconstructions from code and transaction data. No published primary record shows what appeared on each signer's screen or hardware device, so this guide does not describe it. If the reconstruction is right, the lesson is specific to this threat: several signatures gathered through one shared, compromised presentation layer could all be obtained with a single deception. Per-signer verification on infrastructure that layer did not control would address that particular single point of failure. It also adds costs of its own, including a second toolchain that must itself be trusted and slower coordination among signers, and the institutional custody guide covers those trade-offs.

The superlative, with its date and comparator

Chainalysis described the Bybit theft on 24 February 2025 as "the largest digital heist in the history of cryptocurrency", noting that it exceeded the roughly $1.34bn stolen across 47 DPRK-attributed incidents in 2024 (Chainalysis, 24 February 2025). Its mid-year update put the theft at about 69 percent of all funds stolen from services in the first half of 2025 (Chainalysis, 17 July 2025), and its December report attributed $1.5bn of the more than $3.4bn stolen from January to early December 2025 to the Bybit compromise alone (Chainalysis, 18 December 2025). "Largest" in this guide is Chainalysis's ranking as of 24 February 2025, by dollar value at the time of theft; a later incident could displace it.

The same shape at retail scale

Drainer kits present payloads whose approval or permit signatures read as routine mints and logins, and the poisoned request is one click among honest dozens. ScamSniffer, a data provider whose figures are its own on-chain estimates, reported about $494m in wallet-drainer losses in 2024 and about $84m in 2025 (ScamSniffer, 3 January 2025 and 3 January 2026). In drainer cases, and in the reconstruction of the Bybit case, the common thread is a hostile payload approved through a presentation that did not show what it did. The guide to how wallet-draining and approval attacks work covers the approval mechanics.

Diagram contrasting what the signer sees against what is signed, showing an interface layer displaying an illustrative routine transfer while the underlying payload carries a hostile approval or delegatecall, with the signature applying to the payload bytes alone and the chain executing them regardless of the display, annotated with the Bybit February 2025 case at institutional scale, where the display-versus-payload account is an inference from investigators' findings, and drainer campaigns at retail scale — Figure 1. The gap that blind signing exploits: presentation is produced by software of varying honesty, while the chain executes only the payload. Drainer campaigns fit this shape, and so does the account of the February 2025 Bybit theft that investigators inferred from altered front-end code.

What narrows the gap: clear signing, hardware displays, independent verification

Быстрый ответ

Three layers, in rising order of assurance: wallets that decode payloads into meaning, a hardware display whose rendering does not depend on your computer, and independent decoding or simulation of the payload for signatures that matter. Each layer narrows one place a lie can live, and none closes them all: each reduces the risk of a malicious authorisation without eliminating it.

Clear signing

Clear signing is the industry's name for wallets decoding structured payloads into statements a person can check: this call approves contract X to spend up to Y of token Z. On Ethereum, EIP-712 defines a way to hash and sign typed structured data rather than opaque byte strings, so that wallets can display message contents in readable fields (Ethereum Improvement Proposals, EIP-712, Final). Hardware vendors build on this and on contract metadata; Ledger's own description of clear signing, for example, states that when an application cannot fully interpret a new or complex contract, the device falls back to showing a raw hash with a blind-signing warning (Ledger, clear signing explainer, updated 16 April 2026). That fallback is the limit: coverage is partial, unusual contracts still produce blobs, and a readable request can still be a hostile one if the decoded meaning is read carelessly. Clear signing raises the share of requests you can check, and the decoding is only as reliable as the wallet's software and the contract metadata it relies on; it does not vouch for any request.

The hardware display

The hardware display matters because of where lies live. A compromised computer can falsify anything drawn on its own screen, including your wallet's summary; a separate signing device's screen is designed to be outside that computer's control. Verifying destination, amount and function on the device's own display, against a source of truth that did not come from the possibly compromised machine, takes the computer's presentation layer largely out of the trust equation. This is most of the practical argument for signing hardware. It addresses a compromised host and nothing else: it does not help against a flaw in the device, against a request the device cannot decode, or against a signer who confirms without reading, which is what drainer operators count on. Safe's own guidance for multi-signature signers reflects the same logic: compare the transaction fields shown on the signing device with the fields in the web interface, check that the operation is a plain call and not a delegatecall, and stop if anything differs (Safe, knowledge base, transaction checks).

Independent verification and simulation

Independent verification is the high-stakes layer. For signatures that move serious value or change control, such as moving a vault, granting a large approval or updating anything institutional, decode the payload somewhere the requesting context does not control: a second device, a transaction-decoding tool, or a simulation that shows resulting balance changes before commitment. Safe's guidance lists independent decoders and simulators as cross-checks for exactly this purpose (Safe, knowledge base, transaction checks). Simulation has its own limits: it shows what a transaction would do against the chain state at the moment of simulation, it depends on the tool's own correctness and on the payload it was given being the payload actually signed, and it cannot reveal a contract's later behaviour if the contract can be upgraded. After the Bybit theft, the Safe Ecosystem Foundation said it would lead an initiative to increase the verifiability of transactions (Safe Ecosystem Foundation, 28 February 2025); the institutional custody guide covers per-signer independent verification in more depth. A careful individual can borrow its core with one extra device and two extra minutes, and should still treat the result as a lower risk rather than a cleared one.

Two-tier verification drill diagram: for every signature, read destination, asset, amount and function on the most trustworthy display, with unreadable meaning declined; for high-stakes signatures, additionally decode the payload on an independent device or simulation tool and confirm expected balance changes before signing, with a note that signatures gathered through one compromised display can fall to a single deception — Figure 2. The verification drill, sized to the stakes: read the four fields on the best display available for routine signatures, add independent decoding or simulation for signatures that move serious value or change control. Each step reduces risk; none removes it.

What is the drill, in practice?

Быстрый ответ

Four fields every time: destination, asset, amount, function. One rule always: unreadable means no. One escalation: for signatures that could cost more than a bad day, verify the payload independently before your key touches it. Short enough to use, which is the point.

The four fields cover the payload's load-bearing content. Destination: is the address the one you independently believe it should be, checked against a saved and verified copy rather than by first-and-last characters alone, using the method in the address poisoning guide. Asset and amount: is it the token and quantity you intend, with approvals capped rather than unlimited, as the dApps guide explains. Function: does the action named match the action intended, a transfer where you meant a transfer, and anything resembling approve, permit, setOwner, upgrade or a delegatecall treated as the serious commitment it is. On hardware, read them on the device; the computer's screen is a convenience copy.

The refusal rule needs no judgement, which is its virtue. A request the wallet cannot render, from a site that insists, under time pressure that a countdown supplies, is the drainer pattern assembled in one place; declining costs a retry, and retries are cheap. The escalation rule is a calendar entry as much as a habit: know before the day comes which tool or second device you would use to decode a serious payload, so that the high-stakes moment is a procedure rather than an improvisation. Signers who decide their method during the request are deciding under the attacker's clock.

Frequently asked questions

Is blind signing ever acceptable?

As a considered exception at spending-wallet stakes: a niche protocol whose contracts your wallet cannot decode, an amount you can afford to lose, a source you chose deliberately. As a habit, or at holding-wallet stakes, no; the wallet tiering in the crypto wallet security guide exists to limit how far such an exception can reach.

Does a hardware wallet eliminate blind signing?

No. It gives you a screen designed to be outside your computer's control, which helps and is insufficient: coverage gaps still produce unreadable requests, a device can have flaws of its own, and a device confirms whatever its holder approves. The display reduces the risk from a lying computer, and the drill reduces the risk from haste.

What is the difference between blind signing and a bad approval?

An approval can be perfectly legible and still unwise, which is a judgement failure the dApps guide addresses. Blind signing is approving without legibility at all. The drainer economy uses both, and the defences stack: read what is readable, decline what is not, cap what you grant.

Did hardware wallets fail at Bybit?

The published investigations do not say. They describe a compromised developer machine and altered front-end code that targeted Bybit's wallet (Safe Ecosystem Foundation, 28 February 2025; Sygnia, 16 March 2025), and they do not report how each signer's device rendered the request. What the reconstruction suggests is that several signers relying on one presentation layer can share one point of deception, whatever devices they hold.

How can multisig signers protect against a Bybit-style attack?

Safe's published guidance for multi-signature signers describes the checks: compare the transaction fields shown on the signing device with those in the web interface, confirm that the operation is a plain call and not a delegatecall, cross-check with an independent decoder or simulator, and stop if anything differs (Safe, knowledge base, transaction checks). A worked example shows why each signer doing this separately matters. In a three-of-five wallet where all five signers open the same web interface, a single altered interface could show every one of them the same reassuring summary; if the reconstruction of the Bybit case is right, that is the single point of failure it exposed. If each signer instead decodes the payload on a tool the others do not share, one altered interface no longer reaches all of them, at the cost of more tooling to trust and slower coordination. After the theft the Safe Ecosystem Foundation said it would lead an initiative to increase the verifiability of transactions (Safe Ecosystem Foundation, 28 February 2025); the institutional custody guide sets out the design trade-offs.

What should I do if I signed a malicious transaction?

A confirmed on-chain transfer is not reversed by the network, and reporting it does not guarantee that anything is recovered. It still creates a record that investigators can use. In the US, the FBI asks victims to file a report at ic3.gov with the addresses, amounts, dates and transaction IDs involved (FBI, Cryptocurrency Investment Fraud). In England, Wales and Northern Ireland, Report Fraud has replaced Action Fraud (reportfraud.police.uk, 0300 123 2040; City of London Police, 4 December 2025); in Scotland, reports go to Police Scotland on 101. Approvals granted during a drainer signature can stay active after the first loss, and the guide to wallet-draining and approval attacks explains how to check and revoke them. Expect follow-up contact: the FBI warns that scammers impersonate law enforcement, companies and law firms to sell fake recovery services for a fee (FBI, Cryptocurrency Investment Fraud).

Can I practise reading payloads safely?

Yes: decode past transactions from your own history in a block explorer, simulate transactions with reputable tools before signing, and rehearse on trivial amounts. Ten minutes of practice makes the four fields familiar, and familiarity is what makes the drill fast enough to survive real use.

Key takeaways

A signature authorises payload bytes, and everything you see about them is presentation that does not travel with the transaction. Blind signing, approving what you cannot read, is the shape drainer campaigns use at retail scale, and it is the shape investigators' findings point to in the February 2025 Bybit theft of roughly $1.5bn, which Chainalysis on 24 February 2025 called the largest digital heist in the history of cryptocurrency; what the Bybit signers actually saw is not on the public record. The defences reduce risk in layers: clear-signing wallets that decode meaning, hardware displays designed so that a compromised computer cannot redraw them, and independent verification or simulation for signatures that move serious value. None is a guarantee. The drill is four fields, destination, asset, amount, function, one standing rule, unreadable means no, and one escalation, independent decoding when the stakes justify it, decided before the moment rather than during it.

Sources and further reading

Primary and reference sources for this guide, last checked on 23 September 2026; the FBI, Bybit, Safe Ecosystem Foundation, Sygnia and Chainalysis sources were rechecked on 24 September 2026. Dollar figures for the Bybit theft are values at the time of the theft as reported by the cited source.

North Korea Responsible for $1.5 Billion Bybit Hack (PSA I-022625-PSA; law enforcement attribution, not a court finding). FBI Internet Crime Complaint Center, 26 February 2025. https://www.ic3.gov/PSA/2025/PSA250226 (accessed 24 September 2026)
Bybit Confirms Security Integrity Amid Safe{Wallet} Incident: No Compromise in Infrastructure (exchange statement of preliminary forensic findings by Sygnia and Verichains). Bybit, 26 February 2025. https://www.bybit.com/en/press/post/bybit-confirms-security-integrity-amid-safe-wallet-incident-no-compromise-in-infrastructure-blt9986889e919da8d2 (accessed 24 September 2026)
Statement by the Safe Ecosystem Foundation on the Bybit incident (wallet provider statement). Safe Ecosystem Foundation, 28 February 2025. https://safefoundation.org/blog/safe-ecosystem-foundation-statement (accessed 24 September 2026)
Sygnia's Investigation into the Bybit Hack: What We Know So Far (forensic firm engaged by Bybit). Sygnia, 16 March 2025, updated 17 November 2025. https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ (accessed 24 September 2026)
Collaboration in the Wake of Record-Breaking Bybit Theft (data provider's own analysis; source of the ETH amount and the 2024 DPRK comparator). Chainalysis, 24 February 2025, updated 27 February 2025. https://www.chainalysis.com/blog/bybit-exchange-hack-february-2025-crypto-security-dprk/ (accessed 24 September 2026)
2025 Crypto Crime Mid-Year Update (data provider's own estimates). Chainalysis, 17 July 2025. https://www.chainalysis.com/blog/2025-crypto-crime-mid-year-update/ (accessed 23 September 2026)
Crypto Hacking and Stolen Funds in 2025 (data provider's own estimates; $3.4bn January to early December 2025). Chainalysis, 18 December 2025. https://www.chainalysis.com/blog/crypto-hacking-stolen-funds-2026/ (accessed 24 September 2026)
EIP-712: Typed structured data hashing and signing (Final). Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-712 (accessed 23 September 2026)
What is Clear Signing? (one vendor's description of payload decoding and its blind-signing fallback). Ledger, 17 July 2024, updated 16 April 2026. https://www.ledger.com/academy/topics/security/what-is-clear-signing (accessed 23 September 2026)
How to perform basic transaction checks on Safe{Wallet} (wallet provider guidance for multi-signature signers). Safe, knowledge base, undated. https://help.safe.global/articles/2485383995-how-to-perform-basic-transactions-checks-on-safewallet (accessed 23 September 2026)
Cryptocurrency Investment Fraud (victim services resource: reporting to IC3, recovery-scam warning). FBI, undated page. https://www.fbi.gov/how-we-can-help-you/victim-services/national-crimes-and-victim-resources/cryptocurrency-investment-fraud (accessed 24 September 2026)
Report Fraud service goes live with full public launch in January 2026 (replacement for Action Fraud in England, Wales and Northern Ireland). City of London Police, 4 December 2025. https://www.cityoflondon.police.uk/news/city-of-london/news/2025/december/report-fraud-service-goes-live-with-full-public-launch-in-january-2026/ (accessed 24 September 2026)
Scam Sniffer 2025: Crypto Phishing Losses Fall 83% to $84 Million, and Scam Sniffer 2024: Wallet Drainers Drain $494 Million (data provider's own on-chain estimates). ScamSniffer, 3 January 2026 and 3 January 2025. https://drops.scamsniffer.io/ (accessed 23 September 2026)