omniflow

OmniFlow is a payments orchestration protocol built on Circle's Arc that unifies fragmented crypto liquidity into a single balance across all chains.

The problem: tokens and USDC are scattered across chains with no unified way to manage them. An organization paying 50 contributors across 5 chains needs 50 separate transactions, native gas tokens on every chain, and manual tracking.

OmniFlow fixes this. Deposit any token from any chain — it auto-swaps to USDC via LI.FI and settles on Arc. Pay out to any chain in any token recipients actually want. Your balance is always unified.

Killer features:

1. Invisible liquidity hub on Arc: chain abstraction, instant withdrawals, secure issuer-native blockchain.

2. AA batching: any sequence of actions in a single atomic UserOperation.

3. Batch payouts: any recipients, any chains, any different tokens — one API call.

4. Passkey authentication: FaceID/TouchID (Passkey) to sign transactions.

5. Fully non-custodial: every user owns their Modular Smart Contract Account (MSCA). The protocol orchestrates but never holds funds.

6. Any token in, any token out: LI.FI handles conversion on both ends. ENS DeFi Payment Preferences — recipients store preferred chain and token in ENS text records. Send to alice.eth — OmniFlow auto-routes the payment. ENS becomes a payment routing protocol.

OmniFlow is built on the full Circle developer stack with Arc as the settlement hub.

Architecture: hub-and-spoke model. Every deposit flows inward (any chain → Arc), every payout flows outward (Arc → any chain). This reduces routing complexity from N×(N-1) cross-chain paths to just 2N. Arc is the invisible center — users never see it.

Circle integration stack:

— Circle Modular Wallets: each user gets an ERC-4337 MSCA (Modular Smart Contract Account) with Passkey/WebAuthn as the signer. One Passkey controls accounts on all chains. Lazy deployment via CREATE2 — the address is deterministic (computed from owner + salt), so users can receive funds before the contract even exists. It deploys automatically on first interaction.

— Circle Gateway: native USDC burn-attestation-mint across chains. No wrapped tokens, no liquidity pools — real native USDC on each chain.

— Circle Bundler: submits UserOperations for AA wallets. We batch multiple actions (approve + swap + transfer + fee collection) into a single atomic UserOp.

LI.FI integration: powers any-token support on both ends. On deposit — LI.FI swaps the source token to USDC before bridging. On payout — LI.FI swaps USDC to the recipient's preferred token on the destination chain. The swap calls are built into the AA UserOp batch: approve + swap execute atomically. We use LI.FI's quote API to find optimal routes across aggregated DEXes (1inch, Paraswap, Uniswap, etc.).

ENS integration: we defined a custom namespace com.omniflow.* in ENS text records. Recipients write their preferences (preferred chain, token, slippage tolerance) as setText calls. When a payment is sent to an ENS name, OmniFlow resolves the address, reads text records, and auto-configures the payout route. Setting preferences is batched into a single gasless UserOp via AA. This turns ENS from identity into a payment routing protocol — and it's an open standard anyone can read.

Notable hacks and engineering decisions:

— Problem: a single deposit or payout requires 3-5 on-chain actions (approve, swap, deposit, bridge, fee). Without batching, users sign each one manually — unacceptable for a payments protocol. Solution: we wrapped protocol entry and exit points in ERC-4337 smart accounts. The entire chain of actions collapses into one atomic UserOp with one biometric confirmation. AA isn't a buzzword here — it's what makes the protocol usable.

— Problem: every chain requires its own native token for gas. A multi-chain payment protocol would force users to manage ETH, AVAX, S, and other native tokens across every chain they touch. Solution: gas costs are deducted from the USDC transfer amount itself (from the body), not from a separate native balance. The user never holds any native token anywhere. The entire multi-chain flow runs on USDC alone.

— Problem: simple transfers are limited. What if the user wants to do something with the funds on the other side — swap, deposit into a protocol, provide liquidity — not just make a transfer? Solution: because entry and exit are AA smart accounts, any external protocol plugs into the UserOp call array. LI.FI today, any DEX, lending, or yield strategy tomorrow. Adding a new integration = adding calls to the batch, not touching the core. OmniFlow orchestrates any on-chain action, not just transfers.

— Problem: the payer doesn't know what chain or token the recipient prefers. If preferences change, there's no way to notify every payout service. Solution: recipients store their preferences (chain, token, slippage) in ENS text records under com.omniflow.*. Send to alice.eth — OmniFlow reads on-chain preferences and auto-routes. Alice changes her mind — updates ENS once, every future payment re-routes automatically. No backend, no database, no notifications needed. This is an open standard any protocol can read.

— Problem: users hold any tokens — ETH, AVAX, WBTC — but the protocol settles in USDC. Forcing users to swap manually before depositing kills UX. Solution: LI.FI aggregates DEXes (1inch, Paraswap, Uniswap) for automatic conversion. The hack: we embed LI.FI's raw transaction data directly into the AA UserOp call array alongside deposit, bridge, and fee calls. One biometric tap = approve + swap + deposit + fee — all atomic. Same on payout: USDC auto-swaps to the recipient's preferred token.

— Problem: how do you collect protocol fees without adding extra steps or trust assumptions? A separate fee transaction means race conditions and off-chain reconciliation. Solution: fees are collected inside the same UserOp batch as the payment. On-chain guarantee — impossible to execute the payment without the fee, impossible to charge the fee without the payment. One atomic operation, zero reconciliation.

— Problem: Circle Gateway (cross-chain USDC) requires EIP-712 signatures — EOA only, no smart account support (EIP-1271). But our wallets are MSCAs. Solution: we add an EOA as a delegate to the MSCA via addDelegate() with limited permissions. Roles are split: MSCA holds the balance, EOA delegate handles Gateway signing. This is direct product feedback for Circle — Gateway and Modular Wallets don't work together out of the box, and we bridged the gap.

Tech stack: TypeScript SDK, Viem, vanilla JS dashboard, NestJS backend with Prisma ORM + PostgresSQL, Hono-based lightweight REST API, Circle Modular Wallets SDK, Passkey/WebAuthn for auth, all external APIs consumed via fetch (LI.FI, Circle Gateway — no heavy SDKs).