Blind Signing and Transaction Manifests

Introduction

Blind signing is the act of approving a blockchain transaction without being able to verify what it actually does. On networks where wallets cannot natively understand token operations — including Ethereum and most EVM-compatible chains — transactions are presented to users as opaque hexadecimal strings. Users and AI agents sign what amounts to a blank check, trusting that the dApp frontend is honestly representing the transaction's intent.

The Radix Knowledge Base identifies blind signing as the root cause of many hacks across Web3 and DeFi. Radix eliminates the problem entirely through transaction manifests — declarative, human-readable instructions that make every operation visible and verifiable before signing.

The Cost of Blind Signing

Blind signing has enabled some of the largest exploits in DeFi history:

Badger DAO (December 2021): An attacker compromised a Cloudflare API key and injected malicious JavaScript into BadgerDAO's frontend. The script silently added unlimited approve() calls to users' transactions. Because wallets displayed these as opaque hex data, 500 wallets unknowingly signed unlimited token approvals. The attacker then called transferFrom() to drain $120 million. One victim reportedly lost $50 million in a single transaction. The smart contracts worked correctly — the exploit was entirely at the signing layer.

Wallet Drainer Campaigns: In 2024, wallet drainer phishing stole $494 million from approximately 332,000 victims, with 85.3% of losses on Ethereum. Thirty incidents exceeded $1 million each. Permit and Permit2 approval signatures — designed to improve the approval UX — have become a primary phishing vector, accounting for 38% of high-value losses.

The fundamental issue is architectural: on chains without native token understanding, wallets cannot display meaningful transaction previews. Users and agents must trust the frontend, the RPC provider, and every intermediary in the signing pipeline.

How Transaction Manifests Work

A Radix transaction manifest is a sequence of instructions that describe exactly what a transaction will do. Each instruction is explicit:

• CALL_METHOD — invoke a specific method on a named component
• withdraw — remove a specified amount of a named resource from an account
• deposit_batch — deposit all resources on the worktop into an account
• lock_fee — reserve XRD for transaction fees

Resources flow through a temporary holding area called the "worktop" during execution. Every resource withdrawn must be deposited somewhere — the Radix Engine enforces that all buckets are empty at transaction end. No resources can be lost, orphaned, or left unaccounted for.

Manifests can include assertions — for example, guaranteeing that the signer will receive at least a minimum amount of a specific resource. If any assertion is violated, the entire transaction reverts atomically. An AI agent can encode its expected outcomes directly into the manifest, making manipulation detectable and rejectable at the protocol level.

Manifest Types

The Radix Wallet recognizes conforming manifest types and displays tailored transaction previews for each:

• Transfer — simple resource transfers between accounts
• Stake / Unstake — validator staking operations
• Claim — claiming staking rewards or other entitled resources
• Account Deposit Settings — configuring account deposit rules

Because Radix has native assets, the wallet knows what every resource is — its name, symbol, and icon — and can display it meaningfully. EVM wallets can only show raw contract addresses and hex-encoded function calls.

With the Cuttlefish upgrade, subintents extend this model to multi-party transactions. Each participant signs their own sub-manifest, which is then assembled into a complete atomic transaction. Every party verifies only what they are authorizing.

Why AI Agents Need Readable Transactions

An AI agent operating autonomously on-chain is in a worse position than a human when it comes to blind signing. A human might recognize a suspicious dApp or get a gut feeling about a phishing site. An agent has no such intuition — it can only verify what its inputs formally describe.

On EVM chains, an agent receiving a transaction to sign gets ABI-encoded calldata. Even with ABI decoding, the agent cannot guarantee that the contract's runtime behavior matches the function signature — proxy contracts, delegatecall patterns, and upgradeable contracts all obscure actual execution logic.

On Radix, the same agent receives a manifest listing every operation in plain text: which resources leave its account, which components are called, what assertions must hold, and what resources it expects to receive. The agent can verify intent at the transaction level, not the contract level. This is the difference between signing a blank check and signing an itemized invoice.

External Links

• What is Blind Signing? — Radix Knowledge Base
• Transaction Manifest Documentation — Radix Docs
• Conforming Manifest Types — Radix Docs
• Explained: The BadgerDAO Hack — Halborn
• Wallet Drainers Stole $494M in 2024 — BleepingComputer
• Pre-Authorizations and Subintents — Radix Docs