Summary: In 2025, “bridgeless deposits” are finally practical: you can accept funds on almost any chain and automatically credit and settle them wherever your treasury lives—without forcing users to touch a bridge. This playbook explains the engineering patterns, rails, and controls 7Block Labs uses to deliver Any‑Chain In, Any‑Chain Out accounts, with concrete architectures, build steps, and risk controls you can ship this quarter.

Bridgeless Deposits: Engineering ‘Any‑Chain In, Any‑Chain Out’ Accounts

Fragmented liquidity, new L2s every week, and the rise of intent-based execution have made “move value anywhere” a board-level requirement. The goal: let customers deposit value on any supported chain and see spendable balance where your product operates—no browser extensions, no bridge UIs, no “refuel gas first.” This post is a deep, hands-on guide to building that: precise components, when to use which rails, how to prevent routing mistakes, and how to prove settlement.

Below we summarize what changed in 2025, a reference architecture you can adapt, and concrete examples you can take to sprint planning.

What changed in 2025 (why bridgeless UX is now feasible)

• USDC got canonical and fast cross‑chain rails. Circle’s CCTP v2 cut settlement from minutes to seconds via “Fast Transfer” and smart-contract “Hooks,” with v1 entering deprecation (v1 deprecates starting July 31, 2026). That means you can route USDC deposits cross‑chain with near‑instant settlement and programmatic post‑settlement actions. (circle.com)
• Intent rails matured. ERC‑7683 (cross‑chain intents) moved from proposal to adoption via the Open Intents Framework (OIF), giving apps a shared filler network and order schema to do “any‑to‑any” fills without bespoke market-making integrations. Across V4 pushed intents further with a ZK‑verified universal verifier for faster chain expansion. (blog.uniswap.org)
• Clearing/settlement layers went live. Everclear (ex‑Connext) launched mainnet to net liquidity flows and cut rebalancing drag for intent bridges—useful when you abstract deposits at scale. (theblock.co)
• Canonical multi‑chain token standards stabilized. Chainlink CCIP released Cross‑Chain Tokens (CCT) with programmable token transfers; Axelar’s Interchain Token Service (ITS) and Wormhole’s Native Token Transfers (NTT) formalized burn‑and‑mint native distribution. LayerZero’s OFT matured as a widely used omnichain token standard. These reduce wrapped-asset fragmentation for your own token and large partner assets. (docs.chain.link)
• Permissionless interop made adding chains routine. Hyperlane’s permissionless deployments and modular security (ISMs) let you light up new appchains and rollups—Celestia’s 2025 expansion is a good example. (v2.hyperlane.xyz)
• Gas abstraction moved from concept to implementation. Wallet Call API (EIP‑5792) and ERC‑4337 paymasters are now supported in major SDKs; refuel utilities (e.g., Bungee’s Refuel) top up gas on the target chain—critical for “bridgeless” onboarding. (blog.thirdweb.com)

The upshot: you can design accounts that accept deposits on many chains and show settled balance on your operating chain(s) in seconds, with strong security controls and no user-visible bridging.

---

A reference architecture for “Any‑Chain In, Any‑Chain Out” accounts

Below is a production‑tested blueprint we use at 7Block Labs. Adapt component choices to your assets, target chains, and risk budget.

1) Deposit surface (Any‑Chain In)

• Addresses
  • EVM: per‑user deterministic deposit addresses (smart accounts or EOAs) on supported networks.
  • Non‑EVM: mapped deposit identifiers (e.g., Solana PDAs) and memo-based routing where applicable.
• Watchers
  • Event listeners per chain detect deposits, verify token contract, chainId, and amount.
  • Classification: stablecoin (USDC), blue‑chip assets (ETH, WBTC), or your own token.
• Decision engine (rail selection)
  • USDC: Prefer Circle CCTP v2 Fast Transfer + Hook into a receiver on your “ledger chain” to instantly credit internal balance. (circle.com)
  • Your token: Prefer a canonical multi‑chain standard you control:
    • CCIP Cross‑Chain Token (CCT) if you want defense‑in‑depth security, rate limits, and programmable transfers. (docs.chain.link)
    • LayerZero OFT for broad ecosystem reach (burn/mint or adapter for existing tokens). (docs.layerzero.network)
    • Wormhole NTT if you need multi‑VM (EVM + SVM) with CLI tooling; choose hub‑and‑spoke vs burn‑and‑mint per token. (wormhole.com)
    • Axelar ITS to keep custom token functionality and a single token address across EVM chains. (axelar.network)
  • Other assets: Use an intent router/aggregator (ERC‑7683/OIF-compatible) with SLAs and fallback bridges.
• Gas abstraction
  • Sponsor the first deposit with an ERC‑4337 paymaster; for non‑AA wallets, integrate EIP‑5792 Wallet Call API to batch gasless calls where supported; as a safety valve, auto‑“refuel” native gas on the destination via Bungee Refuel. (docs.erc4337.io)

Output: a normalized “DepositIntent” containing source chain, asset, route, expected settlement chain, and credit policy.

2) Settlement and credit (Unified account ledger)

• Settlement target
  • Choose a primary ledger chain (often your L2 of choice) and optionally a shadow ledger on a second chain for resilience.
• Programmable settlement
  • Use CCIP Programmable Token Transfers when possible to deliver tokens plus arbitrary data/instructions to your ledger contract in one cross‑chain tx (e.g., credit account, emit receipt, update risk counters). (blog.chain.link)
  • For CCTP v2, attach a Hook on the receiver to call your ledger after mint—achieves the same effect in seconds. (circle.com)
• Clearing
  • If you use multiple intent fillers/bridges, connect to Everclear to net flows and reduce rebalancing and capital lockup across chains. (theblock.co)

3) Payout/withdrawal (Any‑Chain Out)

• Orchestrator
  • Given a requested asset+chain, pick the outbound rail with: canonicality > latency > cost (in that order).
• Rail policy example (by asset)
  • USDC: CCTP v2 if supported on the dest chain; otherwise route via an OIF/7683 solver to a supported USDC domain and settle via CCTP on the last hop. (theblock.co)
  • ETH and gas tokens: intent layer (Across V4 or equivalent) for speed; repay origin on your schedule; cap by limits. (across.to)
  • Your token: native OFT/NTT/ITS or CCT to keep a single supply; avoid wrapped forks. (docs.layerzero.network)
• Gas UX
  • Offer “withdraw with gas included” by bundling a small native token top‑up on the destination chain. (docs.bungee.exchange)

4) Controls, risk, and observability

• Rate limits and circuit breakers
  • CCIP supports configurable per‑token and per‑lane limits; mirror similar quotas on your ledger contract. (docs.chain.link)
• Multi‑bridge policy firewall
  • Use Glacis to aggregate GMPs (Axelar, Wormhole, LayerZero, CCIP, Hyperlane) with access‑control on allowed routes, quoruming, and standardized adapters. This lets you enforce “only this source contract on chain X can trigger function Y across these bridges.” (docs.glacislabs.com)
• Proving and receipts
  • Persist cross‑chain message IDs and provider receipts; expose a public “Proof of Credit” endpoint for auditors.
• L2 due diligence
  • Track the L2BEAT security stage and DA assumptions for chains you accept deposits on; raise per‑chain limits until proof systems are live. (medium.com)
• Audits and upgrades
  • Treat bridge adapter changes as high‑risk deploys; follow diff‑audit discipline (e.g., Across’s OE diff audit style). (blog.openzeppelin.com)

---

Concrete patterns you can ship

Pattern A — Canonical USDC, seconds‑level credit

Goal: Customer sends USDC on Chain A; your product credits their balance on Chain B in seconds, with an on‑chain receipt.

• Use CCTP v2 Fast Transfer on the source chain.
• On the destination chain, your CCTP Hook calls your Ledger.credit(user, amount, srcChain, txId).
• Emit a cross‑system receipt ID that encodes source lane and message. Customers see balance fast; backend reconciliation remains deterministic.

Why now: v2 reduces USDC cross‑chain from ~13–19 min to seconds and adds Hook composability to automate crediting. Plan v1→v2 migrations before the v1 deprecation phase that begins July 31, 2026. (theblock.co)

Pattern B — Your token as a true multi‑chain asset (no wrappers)

Goal: Offer your utility or RWA token natively on multiple chains without liquidity fragmentation.

• If you want oracle‑secured messaging and a managed explorer, deploy as a Chainlink CCIP Cross‑Chain Token (CCT) with rate‑limited pools and programmable transfers (stake on arrival, fee skim, etc.). (docs.chain.link)
• If you want OFT semantics and wide integration, deploy LayerZero OFT (burn/mint for new tokens; adapter for existing). (docs.layerzero.network)
• If you need multi‑VM reach (e.g., SVM/EVM), configure Wormhole NTT burn‑and‑mint for native fungibility; the NTT CLI scaffolds deployments. (wormhole.com)
• If you want single‑address EVM deployments with preserved custom logic, register with Axelar ITS. (axelar.network)

Trade‑off notes: CCIP offers defense‑in‑depth and programmability; OFT offers broad app adoption; NTT targets multi‑VM reach and explicit native‑supply control; ITS preserves token functionality and same address across EVMs.

Pattern C — “Invisible bridge” checkout with intents

Goal: User mints/pays on your target chain even if their funds sit elsewhere.

• Embed an ERC‑7683/OIF‑compatible flow: user signs a CrossChainOrder; fillers compete; winner pays gas and executes on your target chain; your settlement releases user escrow only if the target action succeeded. (erc7683.org)
• Case in point: Across’ “web2‑like” minting flow let users mint on Base while paying from any chain. Users never saw a bridge UI. (across.to)
• Scale it: Connect your solvers to Everclear so fills net across chains, reducing rebalancing and quote spread. (theblock.co)

Pattern D — “Withdraw with gas included”

Goal: Avoid the classic “I withdrew but can’t transact” bug.

• On withdrawal, attach a small native gas top‑up to the destination wallet via a Refuel utility or run your own native‑token dripper keyed to destination chain. (docs.bungee.exchange)
• If the user’s wallet supports EIP‑5792, batch the first action and gas sponsorship in one call; otherwise sponsor via ERC‑4337 paymaster on your side. (blog.thirdweb.com)

---

Build it: step‑by‑step delivery plan (8–12 weeks)

Phase 0 — Scoping and policy

• Pick your ledger chain(s) and assets in scope: USDC, ETH, your token v2.
• Define per‑chain trust policy and limits (e.g., “Stage 1+ L2s unlimited; Others capped at $X”). (medium.com)

Phase 1 — USDC fast path (Weeks 1–3)

• Integrate CCTP v2 on source/dest chains; implement Hook to credit ledger and emit receipts. Roll canary to 2–3 chains first. (circle.com)
• Backfill v1→v2 migration plan and deprecation timers in ops runbooks. (blockchain.news)

Phase 2 — Intent router (Weeks 2–6)

• Add an ERC‑7683/OIF adapter; whitelist fillers; set SLAs; connect to Everclear for clearing if you expect meaningful bidirectional flow. (erc7683.org)
• Implement ledger escrow and proof‑of‑fill checks.

Phase 3 — Your token canonicalization (Weeks 3–8)

• Choose CCT, OFT, ITS, or NTT; deploy to priority chains with rate limits and admin keys sharded via a secure process. (docs.chain.link)

Phase 4 — UX polish + gas (Weeks 5–10)

• Offer “gas included” withdrawals; add EIP‑5792 support in your front‑end; sponsor first actions via a paymaster. (blog.thirdweb.com)

Phase 5 — Controls and firewall (Weeks 6–12)

• Introduce Glacis (or similar) to standardize allowed cross‑chain routes and quorum policy; wire rate‑limit telemetry to alerts. (docs.glacislabs.com)

---

Security and compliance guardrails that matter

• Rate‑limit everything that mints/unlocks on arrival. CCIP exposes lane and token‑level limits; implement parallel application‑level limits and emergency “pause on amount>threshold” for high‑value transfers. (docs.chain.link)
• Multi‑rail redundancy with explicit allowlists. A router like Glacis lets you whitelist specific source contracts, chains, and GMPs; deny everything else by default. For high‑value flows, require multi‑bridge quorum. (docs.glacislabs.com)
• Prefer canonical rails for fiat‑proximate flows. For USD flows, make CCTP v2 your default and only fall back under explicit policy. Document the deprecation timeline of v1 so teams don’t accidentally integrate legacy endpoints. (circle.com)
• Favor native token standards over wrapped assets. For your token and strategic partners, use OFT/NTT/ITS/CCT to maintain a single supply and reduce fragmentation risk. (docs.layerzero.network)
• Audit aggressively and monitor diffs. Bridges and adapters change frequently; adopt a diff‑audit habit before going to prod (the Across diff audit is a good model). (blog.openzeppelin.com)
• Cosmos ecosystem? Use ICS‑27 Interchain Accounts to drive remote actions via IBC, with unordered channels now supported in newer IBC‑Go—helpful for parallelism. (docs.cosmos.network)

---

KPIs and SLOs we recommend

• P95 credit time (USDC CCTP v2): ≤10 s across supported lanes after source finality. (circle.com)
• P95 credit time (intent fills via 7683 rails): ≤60 s including solver competition (tighter if you operate your own solver). (erc7683.org)
• Failed‑route fallback success: ≥99% of attempts find an alternative within policy; alerts when policy denies.
• Reconciled vs real‑time credits: 100% matching within T+1 with durable cross‑chain receipt IDs.
• Security SLOs: zero credits without matching cross‑chain receipt; no unlock/mint beyond policy limits.

---

Deep dive: choosing the right token rail

• USDC: CCTP v2 is canonical and fast; Hooks let you automate treasury/credit operations on arrival. Track chain coverage (e.g., early 2025 support: Ethereum, Avalanche, Base; with additional chains rolling in 2025). (coindesk.com)
• Chainlink CCIP (CCT + Programmable Token Transfers): best when you need to send value plus instructions atomically across chains (e.g., “transfer + stake” or “transfer + swap”). Also offers rate‑limiting and DON‑secured messaging. (docs.chain.link)
• LayerZero OFT: strong adoption across DeFi; supports burn/mint or lock/unlock via adapters; good if your partners already speak OFT. (docs.layerzero.network)
• Wormhole NTT: ideal for multi‑VM ecosystems; clear operational modes (hub‑and‑spoke vs burn‑and‑mint) and tooling via NTT CLI. (wormhole.com)
• Axelar ITS: same EVM address across chains, preserving custom token logic; integrates with Squid for distribution. (axelar.network)

Tip: for very high‑value tokens and exchange listings, consider xERC20 (EIP‑7281) rate‑limited mint/burn across multiple bridges to cap blast radius of any one rail, then route via an aggregator/firewall. (cointelegraph.com)

---

Example end‑to‑end flows

1. USDC (Solana) → Account credit (Base) in seconds

• Detect SPL‑USDC deposit; initiate CCTP v2 transfer; on Base, Hook calls credit(); emit receipt with CCTP message ID. User sees balance in seconds. (circle.com)

1. Your token (new launch) → Multichain distribution

• Deploy CCT or OFT contracts across chains; set rate limits; when users deposit on Chain A, your router uses programmable transfers to settle and credit on Chain B with a one‑tx “transfer+credit.” (docs.chain.link)

1. “Pay from anywhere” checkout

• User signs an ERC‑7683 order; a solver fills on your target chain; ledger credits on success; Everclear nets flows across the day to reduce capital shuttling. (erc7683.org)

1. Withdraw to a new chain with gas included

• Orchestrator chooses the best rail; append a small native token refuel to the destination; if wallet supports EIP‑5792, batch calls; otherwise sponsor first action via an ERC‑4337 paymaster. (docs.bungee.exchange)

---

Emerging best practices we’re advising enterprise teams

• Prefer “programmable settlement” over message + later action. Use CCIP’s Programmable Token Transfers or CCTP v2 Hooks to make settlement “do something” on arrival (credit, stake, sweep fees). Fewer moving parts; fewer reconciliation edge cases. (blog.chain.link)
• Standardize cross‑chain intents on ERC‑7683. It broadens your filler pool and reduces vendor lock‑in; OIF adoption means you won’t rebuild the same infra twice. (erc7683.org)
• Use a multi‑rail firewall from day one. Aggregate Axelar/Wormhole/LayerZero/CCIP/Hyperlane behind a policy engine (e.g., Glacis) so you can change route policy without redeploying app logic. (docs.glacislabs.com)
• Net your flows. If you’re abstracting deposits at scale, the rebalancing tax will dominate. A clearing layer like Everclear materially reduces liquidity churn and lets you quote better UX. (theblock.co)
• Treat L2 security posture as a credit limit input. Use L2BEAT stages and DA assessments to set caps by chain until proofs and bridges meet your policy. (medium.com)

---

The bottom line

“Bridgeless deposits” aren’t magic; they’re careful routing across the right canonical rails plus programmable settlement and strong policy controls. With CCTP v2, ERC‑7683/OIF, CCIP Programmable Token Transfers, OFT/NTT/ITS token standards, permissionless interop (Hyperlane), and clearing layers (Everclear), you can ship Any‑Chain In, Any‑Chain Out accounts that feel like Web2—while keeping security and observability where your auditors want them. (circle.com)

If you want a reference implementation or an integration plan tailored to your chain mix and risk policy, 7Block Labs can drop in as a strike team—shipping the USDC fast path in weeks and the full multi‑rail orchestration in a quarter.