omniflow

Demo

About

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.

How it's made

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).