| title | Biconomy's Proposal: Orchestration, Composable Batching, and Frame Transaction Predicate Validators for Ethereum UX and Interop | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| date | 2026-02-11 | ||||||||||
| author | Mislav Javor | ||||||||||
| description | A proposal for Biconomy's contributions to Ethereum's UX and interop roadmap—from vendor-neutral orchestration and composable batching standards to predicate validators for EIP-8141 Frame Transactions. | ||||||||||
| tags |
|
Biconomy is proposing to contribute directly to Ethereum's UX and interop roadmap—building on standardized foundations (ERC-4337, EIP-7702, EIP-8141).
The core idea is orchestration: a vendor-agnostic, credibly neutral execution model where a user signs a single Merkle root authorizing a multi-chain transaction sequence, and predicate-based conditions gate each step's execution. Orchestration works with every Ethereum bridging and messaging provider—native bridges, intent-based bridges, ERC-7683, message passing protocols—without privileging any one of them.
Biconomy already has orchestration in production. The proposal is to standardize it, convert the components into ERCs, gather community feedback, and build reference open-source implementations of all required node infrastructure and smart contracts. This happens in two stages:
Stage 1 — Composable Batching & Predicate Validator Contracts: An open standard for composable, dynamic batching plus standalone predicate validator contracts that evaluate orchestration conditions (balance thresholds, nonce gates, etc.) on-chain. Works across the entire smart account ecosystem—ERC-4337, ERC-7579 modules, and ERC-6900 modules. Compatible with Biconomy, ZeroDev, Alchemy, and all other providers. Composable batching proposed as an extension to ERC-5792 or a standalone ERC; predicate validators ship as standalone contracts usable by any relayer or wallet.
Stage 2 — Frame Transaction Predicate Validators: Staked validation entities that access non-self state during mempool verification to evaluate whether transaction predicates have been met—e.g. "has the bridged token balance arrived?", "has the target account's nonce incremented?". Their staking and reputation economics are inspired by the ERC-4337 paymaster mechanism, but they are not paymasters: their function is predicate evaluation for orchestrated transaction sequences, not gas sponsorship.
Biconomy has previously described the concept of verifiable EVM scripting—dynamic, conditional, composable execution scripts that span multiple chains and are authored in TypeScript, compiled to Merkle-hashed bytecode, and executed by relayers. That model focused on the scripting engine: Turing-complete on-chain logic with runtime variable resolution, conditional branching, and storage-aware execution within a user's smart account.
This article reframes the concept around its core primitive: orchestration.
Orchestration is a single-signature, multi-chain execution model built on two mechanisms:
1. Merkle Tree Authorization
Every instruction in a multi-step, multi-chain flow is hashed. These hashes are composed into a Merkle tree. The user signs the Merkle root once—this single signature authorizes the entire sequence of operations across any number of chains and rollups.
Each instruction can be independently verified against the root. Relayers or nodes can prove that a specific call was authorized without revealing the full transaction set. The user never signs again after the initial authorization.
2. Predicate-Gated Execution
Each instruction in the sequence specifies a predicate—an on-chain verifiable condition that must be true before execution proceeds. Predicates are state queries:
balanceOf(token, account) > 100— wait until a token balance exceeds a thresholdnonce(account) > 50— wait until a smart account's nonce confirms prior transactions landedblock.timestamp > T— wait until a specific timestorageAt(contract, slot) == value— wait for arbitrary contract state
Relayers continuously evaluate predicates. When a predicate resolves to true, the corresponding instruction is submitted for execution. This creates an asynchronous, event-driven execution flow that naturally handles cross-chain latency—bridging delays, finality windows, sequencer confirmation times—without any off-chain coordination logic.
The Ethereum ecosystem has multiple interoperability solutions: native rollup bridges, intent-based bridges (Across, DeBridge), standardized intent protocols (ERC-7683), message passing systems (LayerZero, Hyperlane, Wormhole), and more. Each has different trust assumptions, latency profiles, and cost structures.
Orchestration is agnostic to all of them.
Because predicates only observe state—not how that state was produced—orchestration doesn't care which bridge moved the tokens, which message protocol relayed data, or which intent solver filled the order. It simply waits for the expected state to materialize, then proceeds.
This makes orchestration credibly neutral:
- It doesn't privilege any bridge or messaging protocol
- It doesn't require integration with specific relayer networks
- It doesn't impose trust assumptions beyond the chains themselves
- Any new interop provider works automatically—if it produces the expected state change, orchestration proceeds
For Ethereum specifically, this matters because:
- Rollup diversity: Ethereum's scaling roadmap produces many rollups with different bridging mechanisms. Orchestration works across all of them without per-rollup integration.
- No vendor lock-in: Users and apps aren't locked into a single bridge or intent network. They can switch providers per-transaction based on cost, speed, or trust preferences.
- Composability preservation: The multi-rollup Ethereum ecosystem risks fragmenting composability. Orchestration restores single-signature, single-click UX across fragmented state—without centralizing control in any bridging layer.
- Forward compatibility: Future interop solutions (native L1↔L2 messaging improvements, based rollup shared sequencing, etc.) are automatically supported. The predicate model doesn't need to know about them.
Current smart account batching (via ERC-4337 executeBatch) is static. Every call, every parameter, and every amount must be known at signature time. But real-world DeFi flows produce dynamic outputs:
- A swap yields a variable amount depending on slippage and MEV
- A withdrawal from a vault returns a variable share-to-asset conversion
- A bridge delivers tokens after an unpredictable delay
Static batching forces developers into one of two bad choices: hardcode optimistic amounts (risking reverts) or underestimate (leaving value stranded). Both degrade UX and capital efficiency.
Composable batching introduces runtime parameter resolution within a batch. Instead of static {to, value, data} tuples, each call in the batch can reference outputs of prior calls or read on-chain state at execution time:
- Return value injection: Step 2 can use the return value of Step 1 as an input parameter. "Supply all the USDC I just received from the swap" becomes expressible.
- Balance-delta resolution: "Use my entire balance of token X" resolves at execution time, not signature time.
- Conditional execution: Steps can be gated by predicates evaluated during batch execution. If a condition isn't met, the step is skipped or the batch reverts—without external coordination.
The composable batching contracts are designed to work across the entire smart account ecosystem:
- ERC-4337 Smart Accounts: Compatible with any 4337 account as an execution module
- ERC-7579 Modules: Installable as a 7579-compliant execution module—works with Biconomy, ZeroDev, Rhinestone, and any 7579-compatible account
- ERC-6900 Modules: Compatible with Alchemy's modular account standard, ensuring coverage of the Alchemy/Modular Account ecosystem
This means a single composable batching standard works across Biconomy, ZeroDev, Alchemy, Safe, and every other major smart account provider. No fragmentation.
Composable batching can be standardized in two ways:
-
Extension to EIP-5792 (
wallet_sendCalls): EIP-5792 already defines the wallet RPC interface for batched calls. Composable batching could extend this with a parameter resolution specification—adding fields for return value references, balance queries, and conditional gates alongside the existing call array. -
Standalone ERC: A new ERC defining the composable batch encoding format, the execution semantics, and the module interface. This approach is cleaner but requires more ecosystem coordination.
Either path produces an open standard that any wallet, SDK, or dApp can implement.
For users:
- One signature, one click for complex multi-step DeFi flows
- No value left stranded due to conservative amount estimation
- Fewer reverts from optimistic parameter guesses
- Works with their existing smart account—no migration
For developers:
- No custom Solidity contracts for multi-step flows
- No off-chain orchestration servers to maintain
- Composable building blocks: swap → supply → stake as a declarative sequence
- Test and simulate before execution
For the ecosystem:
- Unified standard across all major account providers
- Reduces fragmentation in how smart accounts handle batching
- Enables a shared library of composable "recipes" that work everywhere
- An ERC standard for Composable Batching—compatible with all wallets and interop providers
- An open-source orchestration SDK/Node, implementable by wallets, relayers, interop providers, and anyone else
- Predicate Validator contracts—on-chain contracts that evaluate orchestration predicates (balance checks, nonce gates, etc.) at the smart contract level. In Stage 1 these operate outside the protocol as standalone contracts used by relayers; in Stage 2 they graduate into Frame Transaction validation frames
- Fully audited orchestration, composable batching, and predicate validator contracts
- Negotiated consensus with all major stakeholders (wallet providers, smart account vendors, L2 teams, interop protocols)
The Ethereum Foundation's EIP-8141 (Frame Transactions) represents the "full generality" path for native UX improvements at the protocol level—emerging from the account abstraction lineage (ERC-4337 → EIP-7701 → EIP-8141). Frame Transactions enable arbitrary validation logic—any signature scheme, any gas payment method, any transaction pattern—through a sequence of validation and execution frames.
The power comes with a cost: the mempool problem. If validation can run arbitrary code, attackers can craft transactions that pass validation but fail on-chain, wasting node resources. The EIP-8141 specification acknowledges this and proposes mitigations (validation restrictions, bounded validation, one pending transaction per account), but the mempool acceptance model for advanced use cases remains an open design question.
ERC-4337 already solved this problem for its own context through the paymaster mechanism.
A paymaster in ERC-4337 has full state access during validation. It can read token balances, verify allowances, check contract storage—arbitrary state queries that would normally be dangerous in a mempool context. The system works because:
-
Paymasters stake ETH. This creates economic skin-in-the-game. A paymaster that validates transactions which then fail on-chain is wasting bundler resources.
-
The protocol acts as a meta-mempool-acceptance-rule. Anyone can stake ETH to register their mempool acceptance logic. The paymaster's
validatePaymasterUserOpfunction is a custom mempool acceptance rule—it defines the conditions under which a transaction should be considered valid for inclusion. -
Throttling and delisting. If too many transactions that pass a paymaster's validation fail to land on-chain, mempool nodes throttle and eventually delist that paymaster. This is a subjective decision by each node, creating a reputation market: good paymasters stay listed, bad ones get removed.
This three-part design—staking, custom acceptance rules, reputation-based delisting—turns the unbounded mempool problem into a bounded economic game.
Since EIP-8141 is a modification on EIP-7701, and EIP-7701 is itself an on-chain formalization of ERC-4337, the paymaster mempool pattern can be applied directly to Frame Transactions.
The proposal:
Predicate validation frames. A Frame Transaction can include a validation frame operated by a staked entity. This frame has expanded state access during validation—it can read token balances, account nonces, contract storage slots—capabilities that are normally restricted in mempool validation to prevent DoS. The purpose is to evaluate predicates: has the expected state change occurred so the next step in an orchestrated sequence can proceed?
Staking for state access. Entities that want to run predicate evaluation with expanded state access must stake ETH. The stake serves as a bond: if the entity's validation frames consistently pass in the mempool but fail on-chain, they lose reputation and eventually get delisted.
Custom mempool acceptance rules. Each staked predicate validator effectively adds a custom acceptance rule to the mempool. Mempool nodes can subscribe to whichever validators they trust. A validator monitoring cross-chain token arrivals reads destination balances during validation. A validator tracking multi-step sequence progress reads account nonces. Each operates independently.
Reputation and throttling. Mempool nodes track the on-chain success rate of transactions that passed each validator's acceptance rules. High failure rates trigger throttling (fewer transactions accepted from that validator) and eventual delisting (the validator's transactions are no longer propagated).
-
Predicate evaluation in the mempool. A staked validator can read non-self state—token balances, nonces, storage slots—during validation to determine whether an orchestrated transaction's preconditions are satisfied. This is what enables multi-step, multi-chain flows to be represented as pending mempool transactions rather than requiring external relayer infrastructure.
-
State-dependent validation without DoS risk. Any state query during validation is backed by the validator's economic stake. The cost of griefing is bounded by the stake, and the consequence is losing mempool access.
-
Permissionless validator market. Anyone can stake ETH and run a predicate validation service. Competition drives quality: validators that offer better state coverage, faster predicate evaluation, or support for more predicate types attract more mempool nodes.
-
Gradual rollout. The mempool starts restrictive (basic signature checks only). As validators stake and build reputation, nodes can opt into expanded predicate evaluation capabilities. This matches Vitalik's recommendation of shipping protocol changes early and rolling out mempool features gradually.
The two stages compose into a complete UX and interop stack for Ethereum:
Today (Stage 1): Composable batching contracts give every smart account—regardless of provider—dynamic, runtime-resolved batch execution. Predicate validator contracts evaluate orchestration conditions on-chain as standalone contracts, usable by any relayer or wallet without protocol changes. Users get single-signature, multi-step DeFi flows. Developers get composable building blocks. The ecosystem gets a unified standard. Orchestration connects this across chains using predicate-gated, Merkle-authorized execution sequences that work with any interop provider.
Tomorrow (Stage 2): The Stage 1 predicate validator contracts graduate into Frame Transaction validation frames, bringing paymaster-inspired staking economics into the native protocol. Staked validators provide custom mempool acceptance rules with non-self state access, enabling predicate evaluation for orchestrated transaction sequences directly in the mempool—all without sacrificing mempool safety.
Together, orchestration + composable batching + frame transaction predicate validators give Ethereum:
- Credibly neutral multi-chain UX: One signature, any chain, any bridge, any rollup
- Vendor-agnostic standards: Works across Biconomy, ZeroDev, Alchemy, Safe, and all other providers
- Economic mempool safety: Staking-based reputation system bounds DoS risk while enabling full state access
- Forward compatibility: Orchestration predicates and frame validation are extensible to post-quantum signatures, privacy protocols, and use cases that don't exist yet
Biconomy already has orchestration, composable batching, and predicate validation infrastructure in production. The path to Ethereum-wide adoption:
-
Standardize: Convert the production-tested components into formal ERC proposals. Composable batching as an EIP-5792 extension or standalone ERC. Frame Transaction predicate validator staking as a companion specification to EIP-8141.
-
Community Feedback: Publish drafts, present to the broader Ethereum community (including the account abstraction working groups), gather input from wallet providers (MetaMask, Ambire, Trust), smart account vendors (ZeroDev, Alchemy, Safe, Rhinestone), and L2 teams (Optimism, Arbitrum, Base).
-
Reference Implementation: Build and open-source reference implementations of all required infrastructure:
- Composable batching module contracts (ERC-7579 and ERC-6900 compatible)
- Standalone predicate validator contracts (Stage 1), upgradeable to Frame Transaction validation frames (Stage 2)
- Orchestration relayer with predicate evaluation engine
- Mempool node plugin for staked validator reputation tracking (Stage 2)
-
Testnet Deployment: Deploy on Ethereum testnets and willing L2s for integration testing across smart account providers and interop services.
-
Audits and Hardening: Security audits of all reference contracts and node infrastructure. Particularily of critical paths (Merkle authorization, predicate evaluation, stake slashing).
-
Mainnet Rollout: Phased deployment starting with composable batching and standalone predicate validators (no protocol changes required), followed by predicate validators graduating into Frame Transaction validation frames as EIP-8141 ships.
The goal is not to impose Biconomy's implementation on Ethereum—it's to take what works in production, open it up, and let the ecosystem build on a shared foundation.
This is an example video of how the UX onchain looks with composable batching and orchestration!