We tested Safe, Aave, and Morpho Clear Signing flows. This essay examines the finding and its implications for hardware-wallet trust. The security advisory documents affected versions, mitigations, and coordinated disclosure.

Remediation status: Ledger Ethereum app 1.22.3 rejects the demonstrated flows. Users should update the Ethereum app separately from their device firmware. See the advisory for the affected-version matrix and verification guidance.

1. The Threat Model

Ledger’s security premise is sound: the computer and transaction interface may be compromised. Its secure-display threat model therefore requires the device to preserve What You See Is What You Sign even when the host cannot be trusted.

For institutional Safe users, Ledger applies the same principle directly. Its Beyond the Quorum article identifies a compromised frontend as the threat and presents Clear Signing as an independent view of a transaction’s true intent.

Ledger Enterprise Multisig at app.multisig.ledger.com, captured on 2026-08-26. The product presents Clear Signing as the point where “blind signing stops” for Safe transactions.

Clear Signing therefore sits at the final security boundary. When browser JavaScript is compromised, the device must independently describe the authorization it is about to sign.

The February 2025 Bybit theft made the compromised-frontend threat concrete. Sygnia’s public findings describe malicious JavaScript injected into resources served from Safe’s AWS S3 bucket. The code manipulated the transaction initiated through Safe. Ledger’s response presented trusted hardware display and Clear Signing as the layer that should contain that failure mode.

LEDGER_CLEAR_SIGNING_BYPASS reaches the same threat model through a different failure mode: a compromised frontend supplies the payload, and device-side Clear Signing produces a human-readable description that omits part of the signed authorization.

2. The Parser Bug

The vulnerability was in the shared array machinery of Ledger’s Ethereum Generic Transaction Parser. The parser calculated an attacker-controlled array pass count as a 16-bit integer, then stored it in an 8-bit countdown:

uint16_t passes;
uint8_t passes_remaining[MAX_ARRAYS];

passes_remaining[index] = passes;

For a 257-element array, the narrowing conversion changes 257 to 1:

passes = 257
(uint8_t)257 = 1

The parser then combines the full-width count with the truncated countdown to select the first element it will review:

idx = start + (passes - passes_remaining)
idx = 0 + (257 - 1)
idx = 256

The same truncated value controls iteration. Instead of starting at element 0 and reviewing all 257 elements, the parser starts at element 256 and reviews one. Elements 0 through 255 remain in the signed calldata but never reach the trusted screen.

The behavior generalizes for any non-zero remainder:

array length = N = 256q + k, where 1 <= k <= 255
displayed    = final k elements = N mod 256
omitted      = first 256q elements = N - (N mod 256)

The hidden prefix can contain different actions, mostly no-op calls surrounding one consequential operation, or any other valid execution sequence that fits the device’s constraints. The demonstrated Safe payload uses q = 1 and k = 1: the screen reviews one call while the signature authorizes 257.

The original fix is commit 2c3d93cc — “Fix array iteration truncation”.

3. Signed Metadata

Clear Signing does not interpret every contract call generically. A transaction enters this parser path only when a host-side Context Module supplies matching, contract-specific metadata. That metadata tells the Ethereum app which intent, fields, labels, paths, and formatting to render.

These Ledger-authorized descriptors make supported protocols legible on the device. They also define the attack surface wherever they direct the vulnerable parser through an attacker-controlled array.

In our August 25 snapshot, Ledger’s production dapp descriptor service exposed array-backed CALLDATA fields for these transaction shapes:

We demonstrated three paths through this surface:

Safe is the main worked example because its array elements carry arbitrary nested calls and its multi-owner treasury workflow makes the organizational impact especially clear. Aave and Morpho extend the result beyond Safe and EIP-712 authorization.

4. Safe

Safe’s BatchExecutor provided a path from parser failure to treasury impact. Its batchExecute(Call[]) entry point accepts an array whose elements contain a target, value, and arbitrary nested calldata. Ledger’s production Clear Signing infrastructure supplied the archived batchExecute(Call[]) context for that transaction shape.

The operational threat is malicious JavaScript running inside an authorized Safe frontend. The frontend constructs one attacker-chosen SafeTx, obtains the accepted display context, and asks each required owner to sign the same hash.

The attack path is:

1. Malicious JavaScript runs inside the transaction frontend trusted by the organization.
2. The browser presents a routine payment while sending an attacker-crafted EIP-712 SafeTx to each required owner.
3. Each affected Ledger displays only the final batch action and returns a valid signature over the complete hash.
4. Once the configured threshold is met, any relayer can submit the signed SafeTx to Safe.
5. The hidden maximum allowance survives the displayed payment and lets the approved spender transfer the remaining token balance.

Safe still enforces its configured threshold and any independent guards or policy controls. The exploitable failure is correlated semantic review: if the owners rely on the same affected firmware and metadata path, every device can repeat the same incomplete interpretation while contributing a valid signature to the quorum.

The execution-critical fields in our proof were:

The affected application identified a Safe transaction and its nested batch, displayed only the 10 USDC transfer, showed operation type 1, and asked the user to sign. It never displayed the maximum allowance in SafeTx.data.

Actual Ragger frames from the affected Apex P review. Surrounding labels and background are editorial.

Safe’s own getTransactionHash matched the hash signed by the Ledger. An unrelated relayer submitted those fields and the recorded signature to a real Safe 1.4.1 proxy on a pinned, disposable mainnet fork. The fork installed the recovered Ledger address as the effective owner and set threshold 1.

Execution emitted 256 undisplayed USDC Approval events, the displayed 10 USDC Transfer, and ExecutionSuccess. The Safe nonce advanced and the attacker’s allowance became uint256.max. A second local transaction then acted as the approved spender and transferred the remaining USDC from the Safe.

That run proves a signature produced after an incomplete device review was blockchain-usable.

5. Aave

Aave V3’s archived multicall(bytes[]) context provides a direct-transaction path through the same shared array parser.

A user opens a compromised frontend to supply 10 USDC to Aave. The browser sends a 257-entry multicall to the Ledger. Entry 0 withdraws the user’s existing USDC supply position to the attacker, entries 1 through 255 reference aliased filler calls, and entry 256 performs the expected 10 USDC supply.

With Ethereum app 1.22.2, the parser starts at entry 256. The device displays the 10 USDC supply while its signature covers the complete multicall, including the withdrawal. We submitted that exact signed transaction to a pinned mainnet fork: the existing position moved to the attacker, and the displayed supply completed.

The affected app reviewed the final supply entry. The signed multicall also contained the preceding withdrawal.

6. Morpho

Morpho’s archived Bundler3 multicall context supplied a second direct-transaction path through the vulnerable parser.

A user opens a compromised frontend to supply 10 USDC to a Morpho market. The browser sends a 257-entry Bundler3 multicall to the Ledger. Entry 0 moves the expected 10 USDC into Morpho’s adapter, entry 1 withdraws the user’s complete existing USDC position to the attacker, entries 2 through 255 reference one aliased no-op call, and entry 256 performs the expected 10 USDC supply for the visible recipient.

With Ethereum app 1.22.2, the parser starts at entry 256. The device displays the 10 USDC supply while its signature covers the complete multicall, including the withdrawal. We submitted that exact signed transaction to the pinned mainnet fork: the existing 100 USDC position moved to the attacker, the displayed supply completed, and no residual USDC remained in the adapter.

The affected app reviewed the final supply entry. The signed multicall also contained the preceding funding call, withdrawal, and aliased no-op calls.

Aave and Morpho establish the same result through different transaction shapes: the screen reviewed a suffix while the signature authorized the whole array.

7. Making 257 Calls Fit

Practical exploitation also had to satisfy the device’s memory constraints.

A conventional batchExecute(Call[257]) encoding repeats every dynamic tuple. For the demonstrated ERC-20 calls, that produces 65,860 bytes, far beyond the tested flow’s practical limit.

The conventional encoding does not fit. Reusing tuple bodies brings the same 257 logical entries below the parser’s 16 KiB allocation.

ABI dynamic offsets allow multiple array entries to point to the same tuple. We built an offset table in which the first 256 entries all point to one shared approval tuple while the final entry points to one transfer tuple:

The offset table contains 257 entries, but the encoded payload stores only two tuple bodies.

Aliasing reduced the calldata from 65,860 bytes to 8,740 bytes, allowing it to fit the original 16 KiB parser allocator. The signature still commits to all 257 logical array entries.

At execution, Safe invokes tuple A 256 times. Those calls repeatedly set the same allowance, leaving one maximum approval. Tuple B performs the small payment shown by the device. The approved spender can then call transferFrom directly.

The device starts at entry 256 and reviews the transfer. Safe interprets the complete array, and the signature commits to both tuple bodies.

The signed descriptor remains authentic. The calldata remains valid ABI. The signature remains cryptographically correct. The trusted interpretation omits signed actions.

8. Proof of Concept

Before testing: Treat the PoC page and its outputs as untrusted. Use a separate test device with a new, disposable seed phrase and no real funds. Never use your everyday wallet or reuse its recovery phrase. Never enter a seed phrase into the PoC page or any website.

The hardware signing artifact wizard presents the Safe, Aave, and Morpho proofs as three paths through one page. For each protocol it reconstructs the canonical 257-element payload, requests a fresh signature from a connected Ledger through WebHID, and verifies the signer against the complete payload.

The page ships a frozen copy of the Ledger-signed production descriptors, token metadata, and device certificates used by the demonstrations. It does not query Ledger’s current metadata service and does not require a CAL origin token. This preserves the historical Clear Signing inputs if the hosted metadata changes or disappears.

The page keeps the evidence chain explicit: Select, Capture, Inspect, and Export. Safe exports an EIP-712 owner authorization with every SafeTx field and the corresponding Safe.execTransaction calldata. Aave and Morpho export complete raw signed EIP-1559 transactions.

The page generates commands that consume the exported artifact through independent Safe or DeFi runners on a pinned, disposable Anvil fork.

The final result compares the device display, signed authorization, and local execution:

• Device display
  • Send 10 USDC
• Signed authorization
  • Transfer 10 USDC
  • Approve attacker: MAX
• Anvil result
  • Transfer completed
  • Allowance created
  • Safe balance: 0

A physical-device capture requires Chrome or Edge, an affected test device, and a disposable seed. The fixed Ethereum app rejects the malformed array. The page does not offer an archived-signature fallback.

9. Fix and Release

Ledger merged the root-cause correction into public develop on May 5. The security-relevant change was a three-line bounds check:

@@ -261,6 +261,9 @@ static bool path_array(const s_array_args *array,
     *offset += 1;
     if (arrays_info->index == arrays_info->depth) {
         // new depth
+        if (passes > UINT8_MAX) {
+            return false;
+        }
         arrays_info->passes_remaining[arrays_info->index] = passes;
         arrays_info->depth += 1;
     }

The first installable stable release containing the correction became available on August 25.

On August 26, we gave only that patch hunk to a fresh, isolated Codex session running gpt-5.6-sol. We omitted the commit title, repository, report, surrounding declarations, and exploit details. Its first conclusion was:

An unchecked narrowing conversion when storing passes in passes_remaining[].

The model selected 256 as the first boundary test, identified 255 as the valid maximum, and warned that the old code could select the wrong element or stop traversal early. Reconstructing the complete exploit chain still required surrounding source and human analysis. This single triage run illustrates how the patch hunk alone enabled an agent to identify the bug class and critical input boundary.

Source correction and user protection are separate milestones. GitHub’s repository security advisory workflow supports private fix development, allowing a root-cause diff to remain private until an installable release is ready.

The correction missed stable versions 1.22.1 and 1.22.2. Version 1.22.2 fixed a separate issue reported by TestMachine, but left this bug unfixed. For most of the agreed disclosure period, the correction was visible in public Git history while users on the stable release remained affected.

We notified Ledger that the original PoC still reproduced on the exact 1.22.2 tag. The fixed Ethereum app 1.22.3 became installable two days later, on August 25. We retested it immediately and confirmed that the same PoC was rejected. The full disclosure and remediation record is in the appendix.

We are publishing with fixed Ethereum app 1.22.3 available through Ledger’s normal application catalog.

10. Conclusion: One Thing Well

Version 1.22.3 removes this truncation. The harder question remains: what other bugs could emerge from the same firmware complexity?

Ledger’s default flow gives trusted firmware two security-critical jobs:

1. protect and use the private key; and
2. interpret evolving smart-contract semantics for the user.

The second job is substantial. A stateful C parser combines attacker-controlled calldata with evolving metadata, walks nested structures, manages parser state, formats values, and decides which facts deserve space on a small screen. Here, one unchecked narrowing conversion changed 257 reviews into one. Each protocol and display feature adds another opportunity for interpretation to diverge from authorization.

Metadata signatures establish the provenance of rendering instructions. Completeness, correct firmware interpretation, and correspondence between the screen and every signed action remain separate security properties.

For multisig custody, identical devices create a shared semantic control. A quorum can be cryptographically valid while every signer receives the same wrong interpretation from the same firmware and metadata path.

Blind signing makes the absence of semantic verification visible. Incomplete Clear Signing can instead present a readable interpretation that omits actions covered by the signature.

A narrower hardware signer would protect keys, display one stable commitment, and sign exactly that commitment. Decoding, simulation, policy evaluation, and human-readable views could run across independent, replaceable systems that bind their conclusions to the same hash.

11. Appendix: Disclosure Record

Dates use YYYY-MM-DD. Times in the underlying correspondence are retained in America/Argentina/Cordoba (ART, UTC-3). The table records confirmed email exchanges and public GitHub or release activity.

The Attack Unfolds

The Balancer exploit originated from a subtle rounding error in the protocol’s upscale function during EXACT_OUT swaps within Composable Stable Pools, allowing attackers to drain tokens like WETH, osETH, and wstETH from pools on Ethereum, Arbitrum, Base, and other networks.

For a detailed technical breakdown, see the explanations from Unvariant and Coinspect.

According to Balancer’s preliminary postmortem, the incident affected Composable Stable Pools across multiple networks, with immediate responses including pausing pools, freezing assets, and whitehat recoveries reducing the net impact. The root cause involved deferred settlement in batch swaps allowing extreme low-liquidity states, combined with the rounding flaw. Final losses were estimated around $98 million after mitigations, though initial exploits exceeded $128 million.

The vulnerability, undetected despite multiple audits, enabled attackers to artificially suppress pool token (BPT) values and arbitrage the discrepancies.

Timeline

A special shoutout to @pcaversaccio for always being helpful and to the Balancer team (Danko, Fabio, Juani, and Daniel) for their collaboration throughout the return process.

Conclusion

We’re grateful to have helped return funds to a core DeFi protocol. Our interception agent runs as a public good: it watches the chain in real time, models likely exploits, and when a pattern is confirmed it rebuilds the attacker’s path and tries to land a preemptive whitehat transaction first to move assets to safety. In this case it acted one block after the first exploit and secured about $1M.

Unblind applies the same concept to user signatures, protecting them from drainers, scams and mistakes. It explains transactions in plain language, flags unexpected behavior, and empowers users and platforms with the knowledge required to operate in hostile blockchain environments. If you run a wallet, custody platform, or DAO treasury and want this by default, Unblind easily integrates via API. Please get in touch below.

The Easiest Security Upgrade You’ll Ever Make

We know that cumbersome security tools are often ignored. That’s why we designed the Unblind Dashboard with extreme simplicity in mind.

• If your Safe URL looks like this: https://app.safe.global/transactions/queue?safe=arb1:0x...

• Just add a “u” to the domain to access our dashboard: https://app.usafe.global/transactions/queue?safe=arb1:0x...

That’s it. No installation, no setup. Just one letter separates you from confusion to clarity. Review the human-readable explanations, and once you’re confident, proceed to sign in the official Safe app.

Video: Unblind Safe Dashboard Demo

The Multisig Paradox: Secure Keys, Blind Signatures

Even the best security practices, like using hardware wallet and a Safe multisig, have a critical flaw: you can’t always trust what you see on the screen. The infamous Bybit hack proved that a compromised or malicious UI can show you a harmless transaction while tricking you into signing a malicious one. Your multisig security means nothing if all signers are looking at the same deceptive interface.

These are the gold standard for asset protection. But even with a multisig, a fundamental problem remains: how can you trust that what you see on your screen is what you’re actually signing?

Every time that wallet notification pops up asking for a signature, a moment of anxiety follows. Are we really approving a simple token swap, or are we accidentally giving away the keys to our digital kingdom?

This is the exact problem we built Unblind to solve. Our engine goes beyond just decoding data; it simulates transactions, analyzes on-chain history, and pulls from multiple sources to translate a transaction’s true intent into plain English. The difference is night and day: an action like “Send 5 USDT to bill.eth” should look alarmingly different from “You are about to send 100,000 USDT to an unknown address”, and with Unblind, it does. If the explanation feels wrong, you cancel. It’s that simple.

Introducing the Unblind Safe Dashboard: Your Independent Verification Layer

To showcase Unblind’s power and provide a ready to use security tool for the community, we created the Unblind Safe Dashboard. It’s a read-only, alternative interface that translates your pending Safe transactions into plain English, so you know exactly what you’re signing.

What makes it secure?

• Independent Data Source: The dashboard pulls transaction data directly from the official Safe API. This means even if the primary app.safe.global interface were compromised or manipulated, our dashboard would show you the transaction’s true intent. This security model relies on the integrity of the Safe API itself, providing a crucial check against frontend-specific attacks.

• Out-of-Band Verification: For maximum security, you should view this dashboard on a separate device like your phone or tablet. If your main computer is compromised, this “out-of-band” check acts as an independent lifeline, allowing you to see the real details before you or your team approve a malicious transaction.

Standard Safe UI	Unblind Safe Dashboard

This is Just the Beginning

The Unblind Safe Dashboard is more than just a tool for Safe users; it’s a demonstration of a future where no one has to sign a transaction blindly. This same Unblind engine can be integrated into any wallet, dApp, or platform to provide users with the clarity they need to navigate Web3 safely.

We want to hear from you!

• Try it out: If you use a Safe, give our dashboard a try and let us know what you think.
• Feedback & Suggestions: How can we improve the dashboard? What other information would be useful?
• Builders & Wallets: If you’re building a product and want to eliminate user anxiety and enhance security, contact us to learn more about integrating Unblind.

It’s time to replace signing anxiety with signing confidence.

We previously discussed this in our previous blog post.

Video: Unblind Second Factor Snap: How to install and use

You can install the Unblind Snap by visiting the official MetaMask Snaps Directory.

Why Translation is the Foundation of Transaction Security

The typical security approach relies on blocklists, issuing generic warnings like “High-Risk Contract.” While these alerts can provide a useful signal, they are a fundamentally incomplete solution that often leads to alert fatigue.

• False Positives: A brand-new, legitimate DeFi protocol might be flagged simply because it’s unknown, causing you to miss opportunities.
• False Negatives: A novel phishing scam might be marked as “safe” because it hasn’t been blocklisted yet, giving you a false sense of security.

Reputation-based alerts create uncertainty. Our approach adds a foundational layer: clarity through high-fidelity translation.

Unblind runs a powerful context extraction and simulation of the transactions and messages before you sign it. We don’t just show you data; we show you what that data is designed to do in a way that’s relevant to you. This simulation provides the core context that is missing from today’s signing experience, and it’s a layer upon which other signals, like reputation data, can be added for even greater security.

For example, when all the other alert systems failed at the time to warn about the Bybit hack, this is what our tool would have shown:

“You will update the master copy of your Safe Wallet to 0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516. This is an administrative action.”

This shifts the power back to you. With a clear understanding of the transaction’s consequences, your decision to approve or reject becomes confident and informed.

Why a Second Factor

Our primary goal is to protect you from approving malicious requests. A key security principle of Unblind is its function as an out-of-band verification channel.

If your browser, operating system, or even your software wallet is compromised, an attacker can display a fake transaction on your screen while submitting a malicious one in the background. Unblind defeats this vector. You will either receive no notification on your secondary device (Telegram), or you will receive a notification that accurately describes the actual malicious action.

This discrepancy is your most critical alert. The absence of a matching message is an unambiguous signal to reject the signature request immediately. This protects you even when your primary device cannot be trusted.

Privacy Posture

We respect user privacy and only store the minimal information needed to deliver these alerts to your Telegram.

However, for those who wish to avoid linking a Telegram account at all, Unblind offers a fully air-gapped verification method. This flow ensures your addresses and account information remain entirely separate.

The workflow is simple:

1. When prompted to sign, select the “QR Code” option within the Unblind snap.
2. On a separate device (like a phone), open a web browser and navigate to https://unblind.app.
3. Use this second device to scan the QR code displayed on your primary machine.
4. The human-readable translation will appear directly on your second device for verification, with no account or connection to your identity required.

Our Mission: A New Standard for Digital Ownership

The Unblind Snap for Metamask is just the beginning. Our mission is to protect every single user signing a transaction on any chain. We believe that human-readable, verifiable intent should not be an optional plugin, but a native, fundamental part of the digital ownership experience. True security should be invisible and universal.

For this to become a reality, we need to work together.

For Our Users

Your feedback on the current Snap is invaluable. Every suggestion helps us refine the core engine that will power this broader mission. Please continue to share your experiences with us. Join the telegram group or go to the anonymous form

A Call to Builders: Partner with Us

We are calling on wallet developers, dApps, and exchanges who share our vision. To make human-readable security a universal standard, we need to work together.

Unblind’s translation engine is not just a standalone tool; it’s a foundational security layer designed for integration. We offer a simple and powerful API that allows you to embed transaction simulations directly into your product.

By partnering with us, you can:

• Enhance User Trust: Give your users the clarity to transact confidently.
• Reduce Support Overhead: Prevent security incidents caused by user error and phishing.
• Strengthen Your Brand: Signal that you prioritize user safety above all else.

We are establishing an early partner program to make integration seamless. If you are building a product that involves signing requests, contact us.

Let’s make fearless signing the default experience across the web3 ecosystem.

The security of your blockchain interactions increasingly depends on validating these simulation outcomes. However, the core issue is their inability to enforce state consistency between the simulation and the actual execution. This gap can lead to vulnerabilities, especially when key contract states, like proxy implementations or DEX reserves, change unexpectedly.

This problem only gets worse now that Pectra has enabled multiple batch of calls in a single transaction making simulations far more complex.

Core Problem: State Divergence

The central challenge is state divergence: critical smart contract states can change organically or adversarially between the time you simulate your transaction and when it’s actually mined on the blockchain.

s0 = (calldata, contracts, state0)
s1 = (calldata, contracts, state1)
exec(s0) != exec(s1)

Several scenarios illustrate this risk:

1. Proxy Upgrade: Imagine you’re interacting with an NFT marketplace that uses a proxy contract (allowing logic upgrades). You simulate listing an NFT. Between simulation and execution, if the marketplace upgrades its implementation contract, new logic might interpret your data differently or change fees, leading to unexpected outcomes like lost funds or incorrect listings.
2. DEX Reserve Shift: You simulate swapping 1 ETH for USDT on Uniswap, expecting 3000 USDT based on current reserves. If a large trade occurs just before your transaction, shifting pool reserves, your 1 ETH might yield only 2950 USDT, or the transaction could revert due to slippage.
3. Oracle Value Update: Many DeFi protocols use oracles for price feeds (e.g., ETH/USD). You simulate borrowing against collateral, and the oracle price at simulation time is favorable. If the oracle updates with a lower price for your collateral right before execution, due to market volatility or manipulation, your transaction might fail or put you at immediate risk of liquidation.

Attacking Simulation Reliance

Wallets and security tools are increasingly relying on transaction simulations to protect users. By previewing the outcome of complex smart contract interactions, simulations aim to prevent users from signing malicious transactions. However, this reliance introduces its own set of challenges and potential vulnerabilities.

A white paper by Zengo funded by the Ethereum Foundation highlights critical limitations. While simulation is a valuable tool, it’s not foolproof. Attackers can exploit both theoretical constraints and practical implementation issues. One notable vulnerability is the “Red Pill Attack,” where a malicious contract detects it’s running in a simulated environment. It behaves benignly during the simulation, lulling the user into a false sense of security, but then executes its malicious payload once on the actual blockchain. This deception can lead users to approve harmful transactions they believe are safe.

This underscores that while simulations enhance security, they can also create a deceptive safety net if their limitations are not understood and addressed. The integrity of the simulation environment itself becomes a target for sophisticated attackers.

Enter State Constraints

To bridge this simulation-to-execution gap more robustly, we propose that transactions carry not just their execution data (the “what to do”) but also a compact set of state constraints (the “under these conditions”). These constraints act as on-chain guards: the transaction asserts them before proceeding, reverting early if the underlying assumptions from your simulation no longer hold.

These constraints can be written using a Domain Specific Language (DSL) designed to be expressive yet simple:

At runtime, these constraint checks are performed first. If all pass, the main transaction logic proceeds. If any fails, the entire transaction reverts, preventing unintended outcomes.

Step by Step: From Simulation to Trusted Execution

Let’s walk through how this works, using our DEX trade and proxy upgrade examples.

1. Transaction Simulation & Intent Representation

When you initiate a transaction, your wallet software performs a simulation. Crucially, the tooling also identifies key blockchain state your transaction depends on like storages, environment, balances, nonces, etc. These are translated into conditions using a DSL.

• DeFi Trade Example: Swap 1 ETH for at least 2950 USDT. Simulation shows 3000 USDT based on current reserves.
• Proxy Upgrade Example: List an NFT for 5 ETH. Simulation uses marketplace implementation $GOOD_CONTRACT_V1.

2. Extracting the State Constraints

The simulation engine analyzes relied-upon state and extracts these as explicit constraints.

• DeFi Trade Example DSL:

// Preconditions: Ensure DEX pool state is as expected
900 < WETH.balanceOf($PairAddress) < 1100
2,900,000 < USDT.balanceOf($PairAddress) < 3,100,000
// Postcondition: Ensure user receives minimum USDT
USDT.balanceOf($UserAddress) >= $oldBalanceOfUSDT + 3000

• Proxy Upgrade Example Constraint:

// Preconditions: Ensure proxy implementation matches the simulation
MarketProxyAddress.implementation() == $GOOD_CONTRACT_V1

3. Transaction Packaging

The final transaction, with constraints, is packaged using a multicall provided by the users’ wallet (ERC-4337 UserOperation) or delegating to a contract (EIP-7702). This effectively structures the transaction as:

[Constraint Pre-checks] -> [Original Transaction Logic] -> [Constraint Post-checks (optional)]

4. Signing the Enhanced Transaction

The user can now simulate the transaction in different settings. The outcome will either stay true to user expectations or revert if the on-chain conditions no longer match the simulation. The user sees a simulation outcome, similar to what wallets show, but this one can be trusted because the constraints are bundled with the transaction. This entire package, including the constraints, is presented for review before the user signs.

5. Constraint Enforcement On-Chain

When executed: pre-checks compare current on-chain state against your constraints. For example, if DEX reserves shifted too much or the proxy changed, a constraint fails. If any violation occurs, the transaction reverts before main logic runs. If all pass, main logic executes, followed by post-condition checks.

Why This Works (Better Now)

This approach of embedding state constraints becomes particularly powerful and user-friendly due to recent Ethereum improvements, offering several key advantages:

• Atomicity and Improved User Experience: The Pectra upgrade, through EIP-7702, makes Smart Account functionalities accessible to EOAs through delegation. This allows bundling multiple calls (constraint checks and main actions) into one atomic transaction, ensuring all-or-nothing execution with a single signature.

• Backward Compatibility: This system works with existing smart contracts. The constraint checking logic lives in a separate contract that only requires an extra call with the constraints to check.

• Cost Efficiency: Reading storage or calling view functions multiple times within the same transaction is relatively cheap. The gas for these checks is often a small price for significantly enhanced security.

• Granular Control: You can enforce exact matches for critical state (like a proxy’s implementation) and acceptable ranges for volatile state (like DEX reserves within slippage tolerance).

The Dream: Low-Level Storage Checks

Currently, state checks often rely on public getter functions. This is limited because the contract must expose the state via a truthful getter, and cross-contract calls can be gas-intensive. For example, if a proxy doesn’t expose the implementation() function, we can’t check it!

For truly robust, universal, and gas-efficient enforcement, direct, low-level access to read raw storage from other contracts is needed: The concept of an EXTSLOAD opcode as previously discussed in this EIP would tackle all these challenges.

Alternatively, standardized interfaces like IExtsload (e.g., in UniswapX/Uniswap v4 research) also offer gas-efficient batch state reads:

interface IExtsload {
    function extsload(bytes32 slot) external view returns (bytes32 value);
    function extsload(bytes32 startSlot, uint256 nSlots) external view returns (bytes32[] memory values);
    function extsload(bytes32[] calldata slots) external view returns (bytes32[] memory values);
}

While still a contract call, standardization would improve efficiency. Native EVM support would be the ultimate goal.

Takeaways & What’s Next

Enforcing transaction simulation integrity is crucial for user safety in the dynamic world of blockchain.

• State divergence between simulation and execution is critical.
• Attaching explicit state constraints to transactions acts as an on-chain safeguard, ensuring assumptions hold.
• EIP-7702, ERC-4337 and EIP-5792 provide the ideal framework for bundling constraint checks with main transaction logic atomically and with good UX.
• This method is backward-compatible and can be gas-efficient, making it practical for widespread adoption.
• Future EVM improvements for direct external state reads will make this approach even more powerful and affordable.

At Bitfinding, we are experts in low-level EVM execution for security and optimization. We are prototyping these state constraint principles with our simulation engine. We are actively working on moving the EVM ecosystem forward to prevent hacks through research and innovative services.

If you’re interested in integrating this solution to protect yourself or your users, or want to discuss how to make your dApp interactions safer, we’d love your feedback or to explore collaboration.

We faced these challenges constantly while intercepting attacks at Bitfinding. That’s why we created Multiplexer, our internal engine for crafting powerful, precise, atomic Ethereum operations. Today, we’re proud to open source it for everyone.

👉 github.com/Bitfinding/multiplexer

What does Multiplexer actually do?

Think of Multiplexer as multicall on steroids. It’s a smart contract that acts like a mini virtual machine executing a list of instructions you provide. You can pack an incredible amount into one transaction:

🔗 Batch calls (CALL, DELEGATECALL) to interact with any contract.

🚀 Deploy new contracts (CREATE) that can be used in the same transaction.

⚡ Handle Flash Loans from providers like Morpho and Aave, including managing the required callbacks seamlessly.

Let’s See It: Flash Loan Arbitrage Example

Imagine you want to perform a flash loan arbitrage using Morpho. With Multiplexer and our Rust FlowBuilder tool, the setup becomes much clearer:

// Simplified FlowBuilder example

// Define the steps inside the flash loan callback
let inner_arbitrage_flow = FlowBuilder::empty()
    // 1. Swap Token A for Token B on DEX 1
    // 2. Swap Token B for Token A on DEX 2
    .optimize().build_raw();

// Prepare the main flash loan call, embedding the arbitrage logic
let flashloan_calldata = IMorpho::flashLoanCall {
    token: WETH9, assets: LOAN_AMOUNT, data: inner_arbitrage_flow.into(),
}.abi_encode();

// Build the main transaction flow
let main_flow = FlowBuilder::empty()
    .set_fail() // Ensure atomicity
    .set_callback(MORPHO) // Specify expected callback sender
    // Optional: Approve necessary tokens first if needed
    .call(WETH9, &approve_calldata, ...)
    // Trigger the flash loan; Morpho executes inner_arbitrage_flow on callback
    .call(MORPHO, &flashloan_calldata, ...)
    .optimize().build();

// Send transaction with `main_flow` calldata to the Multiplexer contract.

Notice how Multiplexer handles the callback routing? You define the logic (inner_arbitrage_flow) and tell Multiplexer to expect Morpho’s call. No custom callback handler needed in your main execution flow.

For the full example, check the README of the crate here.

What Else Can You Build With It?

Multiplexer is incredibly versatile:

🤖 Efficient Automation: Batch ERC-4337 UserOperations or fulfill complex Intents.

🔬 MEV & Security Research: Model sophisticated interactions or potential exploits.

🧩 Complex DeFi Strategies: Execute multi-step yield farming, collateral swaps, or liquidity migrations atomically.

🛡️ Battle-tested: Used internally at Bitfinding for intercepting exploits and executing complex rescue operations.

Get Started Now

Ready to build more powerful transactions? Don’t forget to brace for EIP-7702!

🐙 Main Repo: github.com/Bitfinding/multiplexer

📦 Rust Crate: crates.io/crates/multiplexer-evm

Contains:

• Solidity contract

• Flow-builder for easy transaction construction

• Examples and tests using Morpho, Aave, Uniswap.

Multiplexer has been a game-changer for our internal operations, giving us speed and precision. We’re open-sourcing it because we believe these capabilities should be accessible to all builders pushing the boundaries of DeFi and MEV. We also think this is the right timing for teams tackling the challenges that enable the upcoming EIP-7702.

We can’t wait to see what you create. Share your projects, ask questions, or contribute! Find us on Twitter.

All these users were tricked into signing messages they did not want:

1. The user accesses a seemingly legitimate dApp on a compromised computer.
2. The user interface decodes the intended transaction or message (e.g., sending a specific amount to a particular address)
3. Malware intercepts and modifies the actual data sent to the hardware wallet.
4. Due to UI limitations, the hardware wallet shows bytes and hashes, making it challenging to verify the altered parameters accurately.
5. The malicious message is signed, and funds are stolen.

What’s wrong with the hardware wallet threat model

Hardware wallets excel at safeguarding users’ seed phrases, making mnemonic exfiltration nearly impossible while allowing users to sign transactions and messages. However, they were primarily designed for simpler protocols, like Bitcoin, which did not require users to verify the parameters of more complex transactions. Blackhats know this.

These wallets cannot verify whether the signing request aligns with the user’s true intent. While they attempt to decode the data and present the parameters for user attestation, this is inadequate. Humans are not good at processing long hexadecimal numbers and often fail at it. Moreover, an attacker controlling the user’s computer can intercept and forge the signing request, replacing legitimate interactions, addresses, and target contracts with malicious ones—even generating fake emulation results. Thus, the hardware wallet alone provides insufficient context for confirming a transaction’s legitimacy.

Emulating transactions on a computer isn’t a silver bullet either. Any attestation or verification mechanism running on a compromised device is fundamentally untrustworthy. Attackers can emulate hardware wallet interactions, mask UI elements, and even display fraudulent confirmations to trick users into signing dangerous transactions. It creates an “interactive movie” scenario where everything seen and interacted with is controlled by the attacker, leading users to sign fraudulent messages.

Clear signing alone isn’t enough

To address this issue, hardware wallets have started implementing more advanced decoding of messages and calldata during the signing process, often referred to as clear signing. These are baby steps in the right direction, allowing users to better understand what they are signing.

Here’s a sneak peek of some of the challenges and why clear signing alone is insufficient:

• Addresses as Identifiers: Addresses are poor identifiers for humans. Users can’t easily memorize all the contracts they interact with, and they must also guard against address poisoning and spoofing. The reputation of an address is important and varies from user to user. Etherscan provides great insights on this.

• Complex Calldata: Calldata can become very complex. For example, a simple swap on 1inch might involve multiple hops that could be meaningless to the user, especially with abstract instructions seen in smart accounts. The decoder should be adept at handling userOperations, executeTransaction commands, and other increasingly popular functions.

• Changing Signing Requests: In today’s era of intents and smart accounts, custom decoders are necessary and must be tailored to the target contract where these are executed.

• State Manipulation: Transaction results can vary depending on multiple factors, with calldata being just one of them. Blockchain state elements, such as balance values, contract code, nonces, and storage variables, can impact execution outcomes. Sandwich attacks are a prime example of how state manipulation affects transactions.

Not everything is bad: current industry recommendation

SEAL provides an extensive list of measures users can take to protect themselves against sophisticated attacks here.

In summary:

• Ensure the device used for wallet operations is updated, isolated, and regularly factory reset
• Use Antivirus and Endpoint Detection and Response software
• Conduct regular Red Teaming exercises
• Utilize Hardware Wallets with clear signing support

The community, also created tools like safe-tx-hashes-util for decoding transactions that gets us closer to understanding what we are signing.

However, this doesn’t account for the scenario where this is run in the same device that could be compromised. We need something else.

Enter Web3 Semantic Second Factor

To mitigate the risks of compromised devices and blind signing, we propose a second-factor semantic attestation system using an independent device. This helps ensure the integrity of both transactions and messages.

Here’s how it works:

1. Users interact with dApps to construct the signing request.
2. A wallet with Semantic Second Factor (SSF) enabled displays a QR code containing the complete unsigned message or transaction.
3. The SSF provider emulates and tests it, provides insights, and displays its hash.
4. Users must ensure that the hashes match on both the hardware wallet and the SSF device.

Intent Verification Through Emulation

This layer ensures that both transaction and message actions perform as expected:

• Transaction Emulation: The system emulates the transaction execution to predict outcomes and effects.
• Structured Data Analysis: In case the messages match standards like EIP-712, which are used for smart accounts like Safe and ERC-4337, they are emulated to extract their intent.
• Natural Language Summary: It provides a clear, user-friendly explanation of balance changes and any significant on-chain effects.
• Statistical Analysis: Conducts a statistical analysis of the involved addresses to estimate risk.
• Adversarial Scenario Testing: Providers could test the transaction outcomes over synthetic adversarial blockchain scenarios.

This significantly increases the attacker’s difficulty, as compromising a single device is no longer sufficient. The approach can be extended to additional devices or even decentralized networks, establishing a more robust security model, much like how 2FA became the industry standard for password security.

One of the key advantages of this security model is its seamless integration into existing security workflows. Since both wallets and hardware wallets already support the necessary features, this approach enhances protection without expanding the attack surface of the systems.

Seriously, Stop Blind Signing

We believe that combining hardware wallets, robust security operations, and second-factor semantic verification can enhance the security of the signing workflow. At BitFinding, we’ve been working on a comprehensive solution that not only strengthens the current security model but also enhances transaction emulation outcomes using smart account modules.

If you’re interested in boosting your security model and want to test our prototype, contact us now using the form below.

The Attack Unfolds

Our systems detected unusual activity on the Arbitrum network. An attacker was attempting to exploit a vulnerability in Paribus’s lending platform, leveraging price manipulation and a bug to siphon funds. The initial target was ~$60K in assets, including ETH, USDT, and ARB tokens.

We also identified additional funds at risk on Ethereum Mainnet, bringing the total potential loss to ~$86K USD.

Cross-Chain Risks Averted

This incident highlights the growing threat of cross-chain exploits, where attackers target multiple networks simultaneously. Our ability to monitor and respond across chains was critical in mitigating the damage.

By collaborating with the Paribus team and leveraging our real-time monitoring tools, we ensured that no further funds were lost.

💡 Pro Tip:

Prevent firefights by investing in security audits and real-time monitoring solutions. Hardening your defenses today can save you from costly exploits tomorrow.

Timeline

Our Exploit Interception Agent deployed a counter measure in just 3.2 seconds. UTC Timeline.

Conclusion

At Bitfinding, we’re proud to have turned another potential disaster into a success story. This incident underscores our commitment to protecting our partners and their users, no matter the scale or complexity of the threat

If you’re a DeFi project or crypto user, don’t wait for an attack to happen. Reach out to us today to learn how we can help you secure your assets.

This system recently proved its value in a real-world scenario. Our bot successfully recovered 54k that would otherwise have been stolen from [redacted]. While it may seem like a small victory, this is a huge validation of our approach and fills us with optimism to expand the solution to other networks.

Failed attack:

In this case, the bot was able to frontrun the attacker and secure the assets for safekeeping. After following the procedures defined in the Safe Harbor Agreement and the protocol was secured, the funds were returned to the rightful owners.

This successful recovery highlights how crucial it is to have this last line of active defense. We’re excited to expand our bot’s coverage to other networks and continue refining the detection and prevention algorithms. Our ultimate goal is to reduce the number of successful exploits on EVM blockchains and make decentralized ecosystems safer for everyone.