Across

• Name: Across
• URL: https://across.to/
• Tags: ethereum-ecosystem
• Category: cross-chain execution and settlement middleware / intent bridge
• Summary: Across is a fast-fill interoperability rail with a thick integrator layer around it. The useful read is relayer behavior, refund policy, embedded-action packaging, and which settlement path the API decides to use. Keep this note on the protocol and product surface itself; the named company boundary around the hosted interface, production API-auth flow, project-registration workflow, and legal/support shell now lives separately in risk-labs.
• What it does:
  • Provides a consumer bridge/swap interface plus developer-facing APIs for cross-chain swaps, bridging, and embedded actions
  • Uses an intents-style model with competitive relayers and a modular three-layer system covering RFQ, relayer execution, and settlement
  • Routes transfers through multiple settlement pathways, including intent-based fills as well as USDC/CCTP and USDT OFT flows documented in official materials
  • Exposes operational docs for API keys, fee mechanics, deposit tracking, refunds, relayer participation, bug bounties, and security verification
  • Maintains public smart-contract, relayer, SDK, and related infrastructure repositories
• Key claims:
  • Official site says Across is “Powered By Intents” and presents itself as a production interoperability system with $22B+ volume, 15M+ transactions, and sub-minute average fill times
  • Official docs say Across provides cross-chain interoperability with ~2 second fills across 23+ chains and powers swaps, bridges, and embedded actions through a unified API, which is why this note belongs at the routing layer rather than at the trust-anchor layer
  • The docs llms.txt index shows a notably broad operating surface: actors, fees, refunds, stablecoin pathways, relayer docs, deposit tracking, embedded actions, bug bounty, and security/verification pages
  • Security docs say Across uses optimistic verification secured by on-chain contracts, ABT bonds, challenge periods, and UMA’s oracle/DVM process rather than a traditional validator-set bridge model
  • Public GitHub materials show Across shipping contracts, a relayer stack, SDKs, and adjacent infra repos including an MCP server, reinforcing that the project operates as a developer-facing interop control plane rather than only a frontend bridge
• Whitepaper: No classic whitepaper or litepaper was found in this pass. The strongest primary materials were the official site, docs portal, docs llms.txt index, security docs, and public GitHub organization; see ../whitepapers/across-primary-sources-2026-04-25.md.
• Sources:
  • https://across.to/
  • https://docs.across.to/introduction
  • https://docs.across.to/llms.txt
  • https://docs.across.to/introduction/security
  • https://github.com/across-protocol

Internal linkages

• Company / hosted-interface boundary: risk-labs.
• Strongest same-tier routing-and-relay peer: skip.
• Settlement-rail contrast worth keeping nearby: cctp.
• Read this note for relayer behavior, refund logic, and settlement-path choice, not for an inventory of every rail Across can package.

Protocol / company boundary

• Keep this note on the mechanism and product layer: route construction, relayer fills, optimistic verification, refund flow, embedded-action packaging, and which settlement path Across chooses to expose.
• Use risk-labs when the sharper question is who runs the hosted frontend, issues production API credentials, controls the project-registration lane, publishes the legal/privacy shell, and can suspend or modify the easiest production access path.
• That split matters because Across is analytically useful both as a protocol design and as a still-company-shaped developer and user entry shell.

Control surface

• The leverage is in relayer participation, deposit and fill handling, refund timing, embedded-action packaging, and which settlement path Across exposes for a given route.

• The protocol is not just intents. It is a live operating surface that decides how much execution complexity users and integrators see versus how much gets normalized behind the API.

• Optimistic verification and the UMA dispute path matter because they define what kind of failure or fraud story users actually inherit when the fast path breaks.

• For the hosted API-auth, route-linking, and product-terms shell above those mechanics, read risk-labs.

• Last reviewed: 2026-08-12 UTC