Despite years of progress in Ethereum tooling, building user-friendly, production-ready dApps still feels unnecessarily difficult. Self-custody wallet UX is notoriously complex, and development workflows are slowed by smart contract constraints, security audits, and limited upgradeability. The current stack is functional, but outdated — and developers are feeling the friction.
Let’s begin with the UX problem. A common DeFi flow, like supplying tokens to a lending market, often requires multiple steps:
- First, the user approves the token.
- Then they sign the supply transaction.
- If the operation involves another chain, they may need to bridge, confirm again, and cover gas fees on the destination network.
Each signature and wallet interaction is a point of friction. Completion rates drop sharply after the second interaction. And if the user lacks ETH on the right chain? The flow breaks completely.
Now consider the developer experience. Suppose you want to streamline that multi-step flow into a single click. You’re likely writing and deploying new smart contracts. That means:
- Testing and QA across multiple chains
- Audit cycles before shipping
- Smart contract redeployment for any update or bug fix
In practice, this turns a simple feature into weeks of development — just to improve UX.
Why the Current Model Falls Short
At the root of these challenges is the Ethereum transaction model. Every transaction is a {to, value, data} tuple:
- It executes a single function call on a single contract
- The sender must pay gas
- It’s valid for a single chain
As a result, bundling multiple dependent operations (e.g. swap + supply) requires either a Solidity utility contract or application-layer orchestration. Neither option is flexible or easy to maintain.
ERC-4337: A Meaningful Step
ERC-4337 (Account Abstraction) aimed to decouple the transaction sender from the gas payer and enable higher-level features:
- Batch execution: multiple actions under one signature
- Gas abstraction: sponsor transactions or pay with ERC-20 tokens
These features made it possible to improve UX and reduce user friction by bundling approvals and actions. However, ERC-4337 remains constrained in a few critical ways.
Why the Batching Model Falls Short
The ERC-4337 batching model is static and sequential. Every action in the batch must be known and encoded upfront, with no capability to respond to the result of prior calls. This presents a significant limitation when building flows where outputs of earlier steps influence the next.
For example, consider the common DeFi workflow:
1. Swap WETH to USDC on Uniswap
2. Supply the received USDC to Aave
In an ERC-4337 batch, you'd need to hardcode the amount of USDC to supply. But that amount isn’t deterministically known ahead of time — it depends on runtime conditions like slippage or MEV effects. The actual received amount can vary significantly from expectations.
If you encode a supply amount greater than what is received, the transaction reverts. If you guess conservatively, you might leave value idle in the smart account.
Workarounds like chaining transactions outside of the batch or deploying custom contracts to calculate the output at runtime bring back the complexity and friction 4337 was meant to eliminate. There is no native support for dynamically injected parameters, flow control, or early termination within a batch.
Additionally, 4337 is limited to single-chain contexts. Cross-chain batching, ordering enforcement, and state dependencies between chains are out of scope. As a result, while 4337 improves on basic UX for single-chain interactions, it does not address the core complexity of multistep, dynamic, or multichain DeFi operations.
A Better Model: Verifiable Multichain Scripting
Verifiable scripting takes the smart account model to the next level. Rather than encoding transactions as static tuples, developers can author dynamic, conditional, and composable execution scripts. These scripts can:
- Read runtime values (e.g. balances, oracle prices)
- Inject computed parameters
- Use control flow (
if,else, early exit) - Span multiple chains in a single logical operation
Scripts are authored in TypeScript, using abstractions over on-chain functions. The result is compiled to verifiable, Merkle-hashed bytecode that can be signed and executed by relayers.
Example: Limit Order + Supply
1. Swap WETH to USDC on Uniswap (on Optimism)
2. If output < 2500 USDC, revert
3. Else, supply all USDC to Aave
This flow used to require a custom contract. Now it’s a script that can be authored, tested, and pushed without any on-chain deployment. Developers can simulate the flow with testnets or mainnet forking before execution.
Extending to Multichain Workflows
The real power of verifiable scripting emerges in multichain environments. Modern dApps interact across L1s, L2s, and AppChains. With scripting, developers can encode multi-chain flows as a single logical unit, with sequencing enforced through:
- Merkle Encoding: Each function call instruction is hashed; The hashes are then hashed into a Merkle Tree. The user approves the entire sequence by signing the Merkle Tree root hash with their private key.
- Preconditions: Execution of each instruction is gated by on-chain verifiable conditions (e.g.
balanceOf(token) > X). - Asynchronous Relayers: Relayers simulate until preconditions are met, then execute the instruction.
Example: Cross-Chain Yield Flow
1. Swap WETH to USDC on Optimism
2. Bridge USDC to Base via Across
3. Supply on Morpho (Base)
4. Stake the yield-bearing tokens
Each step in this flow may occur on a different chain, at different times — yet the entire process is signed and authorized up front.
Turing-Complete and Storage-Aware
All execution in verifiable scripting happens fully onchain. Every conditional branch, loop, and runtime variable resolution is encoded into the callData submitted to the blockchain. There is no offchain execution logic, simulation fallback, or implicit client-side orchestration. The entirety of the script is encoded and verifiable.
Relayers do not execute logic themselves — they post the callData directly to the user's smart account by invoking a special execute function. This means the execution happens within the sandboxed environment of the user’s own account, fully isolated from external side effects and secured by the same guarantees as any smart contract call.
This architecture ensures that:
- The logic is tamper-proof and publicly verifiable
- All runtime conditions are enforced onchain
- State transitions and outputs are deterministic
The scripting engine can perform conditional branching, loops, and variable storage — using storage slots on the smart account itself. This makes it possible to:
- Reuse intermediate values (e.g. token amounts from step 1 used in step 3)
- Execute adaptive logic depending on runtime state
The scripting engine can perform conditional branching, loops, and variable storage — using storage slots on the smart account itself. This makes it possible to:
- Reuse intermediate values (e.g. token amounts from step 1 used in step 3)
- Execute adaptive logic depending on runtime state
With simple building blocks, this enables full Turing completeness — programmable entirely from the client.
Gas Abstraction and UX Simplicity
From the user’s perspective, everything happens in one step:
- One signature authorizes the full operation (across multiple chains)
- No ETH required on any chain
- No additional approvals or interactions
Relayers sponsor gas, and users can optionally pay in any supported token — even LP or yield-bearing tokens. This eliminates one of the biggest UX pitfalls in Ethereum today.
Verifiable scripting isn’t a minor improvement — it represents a shift in how smart accounts, transaction flows, and user interactions are designed. Ethereum has evolved beyond single-chain, single-step interactions. Now the tools are catching up.
EIP-7702 Orchestration
Verifiable scripting was originally designed for execution via smart accounts. However, with the introduction of EIP-7702, it’s now possible to execute these same scripts directly on the user's Externally Owned Account (EOA).
EIP-7702 enables installing smart account logic onto the EOA itself — meaning the script no longer needs to be routed through a separate contract. Execution occurs within the same address the user controls, while still preserving the security and isolation guarantees.
This makes orchestration even simpler: no additional deployment, no funding of smart accounts, and minimal setup.
ERC-7715 → Security Through Sandboxing
Executing the scripts on the EOA, while possible – might not be the smartest idea. Since the script has access to all the user funds, it might be considered dangerous to run arbitrary scripts on it.
This is, however, solved with the ERC-7715 standard which enables a Companion Account to request a specific amount of funds which the script can access.
You can imagine this account requesting e.g. 500 USDC and 1000 USDT for a certain scripting operation – the script would not run on the users main EOA then, but it would run on a separate, sandboxed smart account which would only have access to the funds which were requested through ERC-7715!
Explore the documentation and build your first verifiable script: https://docs.biconomy.io