Omni Account
Architecture
Omni Account

Omni Account

Omni Account consists of two onchain components: 1) an ERC-7579 compliant Smart Account, and 2) the Omni Account Modules, including the Resource Lock Hook and the Settlement Executor Modules.

Omni Account

Supported Accounts

  • Safe, via the Safe7579 Adapter
  • Biconomy’s Nexus Account
  • Magic’s Newton Account

Resource Lock Hook

The Resource Lock Hook is a Smart Account Module that inspects all account execution and checks a simple invariant: will the execution, and any approvals made during execution, reduce the account balance below the resource locked amount? If false, the Resource Lock Hook allows the transaction to pass. If true, the transaction will only pass with a signature from the Orchestrator.

Core features of the Resource Lock Hook:

  • Simple invariant check that the post-execution balance of the account will not be less than the locked balance
  • Tracks and manages token approvals during transaction execution, ensuring that any increases or decreases in allowances are properly accounted for when verifying the locked balance invariant.
  • Pre-validation hooks allow the Resource Lock to run checks before UserOp and signature validation, ensuring that an account has enough unlocked balance to pay paymasters or use permit/permit2 signatures.
  • Data structures and interfaces natively support The Compact, an open-source escrow contract for cross-chain intents, enabling EIP-7702 support.

Settlement Executors

The Settlement Executors consist of two Modules:

  1. Destination Executor: This module interprets and executes arbitrary call data from the Across Spokepool when the Relayer fills an intent with an injected execution. This allows for any action to be appended to the bridge intent – e.g., swap, lend, borrow, liquidate, LP, buy NFT, etc.
  2. Origin Executor: Provides verifiable “onchain rails” for claim requests made by the Relayer after filling a user's intent on the destination chain. The Origin Executor receives, verifies and processes these claim requests on behalf of the user. A claim request includes the user’s signatures, a token transfer, and the claim co-signature from the Orchestrator.