OOneLink PayHome
Claim discipline

What’s real, what’s a pattern, what’s future.

We keep an honest-claim ledger: every public claim maps to something verifiable on-chain or in our own code. Here is exactly what is live today, what is a pattern we implement, and what we deliberately do not claim.

6 real · live1 pattern1 future
No overclaiming
  • Cross-chain USDC settlement via Particle Universal Account + EIP-7702 — no manual bridge

    Real · live

    Live and proven on-chain (ledger C21): paid on Arbitrum, USDC sourced from Base in one operation.

  • On-chain spend mandate — per-charge / daily / total caps + expiry + single-merchant + revoke

    Real · live

    Enforced by our SpendPolicy contract on Base + Arbitrum. Over-cap reverts at zero gas. 22 contract tests pass.

  • Walletless login (Magic email / Google)

    Real · live

    No seed phrase, no extension: a Magic embedded wallet is live. Magic exposes the headless EIP-7702 authorization methods used by our Particle UA flow, so onboarding stays embedded and the one-time delegation can be relayer-sponsored.

  • Agent buys an x402-gated API; over-cap call is blocked

    Pattern

    The x402 pattern (402 → pay → retry-with-proof → 200), settled by the mandate via our onelink-mandate scheme — NOT the Coinbase EIP-3009 facilitator.

  • The “agent”

    Real · live

    Runs unattended: one click and it works through the x402 APIs within its budget, halted by the firewall on the over-cap call. Deterministic — not LLM-driven, so we don't claim AI reasoning.

  • Gas abstraction — network fee paid in USDC, no destination-chain gas to hold

    Real · live

    Particle deducts the routing/network fee in USDC from your Universal Account, so you never top up native gas on the destination chain. And the one-time EIP-7702 delegation per chain is relayer-sponsored (C23), so a first-time payer needs zero native gas too.

  • Zero-gas onboarding — the one-time EIP-7702 delegation is relayer-sponsored

    Real · live

    The payer signs the authorization (gasless, via Magic); our relayer submits the type-4 delegation tx and pays the gas. Proven live on Arbitrum (C23). Scoped to the one-time delegation only — a general settlement paymaster is still NOT claimed (the settlement fee is paid in USDC by the Universal Account).

  • Circle Gateway · ZeroDev · Openfort

    Not built

    Not integrated — narrative / prior-art only; cross-chain is proven natively via Particle. For arming unattended automation, ZeroDev session keys are the production primitive we'd adopt; enforcement today is our own SpendPolicy contract.

Where OneLink fits the 2026 stack

We don’t replace the rails — we’re the consent, on-chain enforcement, and proof layer on top of any of them.

  1. AuthorizationGoogle AP2 (→ FIDO) · Mastercard Verifiable Intent
  2. CheckoutOpenAI ACP · Google UCP
  3. Settlementx402 · cards (Visa, Mastercard) · USDC (Circle)
  4. Enforcement & proofYou are hereOneLink Pay — on-chain SpendPolicy + verifiable proof receipt

The trust gap we close

The agent economy isn’t short of rails — it’s short of trust. Independent research, not our numbers:

~3 in 4 are uncomfortable letting an AI pay autonomously — even with limits set in advance.

Forrester · external research · 2026-06

Only 13.9% would trust an AI agent to complete a purchase on their behalf.

Ecommpay / The Paypers · external research · 2026-06

~2 in 3 will try agentic shopping — but demand human approval before the buy.

Commerce + PayPal · external research · 2026-06

Distrust is rising, not falling: a majority (55%) are now uncomfortable letting AI agents make purchases — a reversal from the comfortable majority a year earlier.

Riskified · external research · 2026-04

Everyone is building rails. The blocker is trust. That is the layer we are.

How OneLink is different

Other tools move money between people. OneLink makes the payments your apps and agents send safe — non-custodial, on-chain enforcement on your own account, with a publicly verifiable proof.

PlayerWhere OneLink differs
Visa Intelligent Commerce + OpenAISame pre-authorization idea, but on-chain and non-custodial, on your own account.
Coinbase Agentic WalletsWallet-agnostic — the limit lives on your own EIP-7702 account, chain-abstracted.
AWS Bedrock AgentCore PaymentsNon-custodial and on your own on-chain account — the limit is a public contract anyone can re-check, with a proof receipt per payment.
MetaMask Smart Accounts · ERC-7715 session keysWe don't reinvent the primitive — we package it as a legible, revocable payments mandate with a public proof receipt, on your own EIP-7702 account.
Circle / CatenaNon-custodial — you hold the keys; we enforce, we don't custody.
Google AP2Same intent, enforced on-chain at your account — a promise becomes a guarantee.
x402 (Coinbase)We bound x402 spend with the mandate (live).
Consumer crypto wallets (send-money apps)Not another wallet: we make app & agent payments safe — an on-chain limit they can't exceed + a proof anyone can verify.
Other rails (cards · bank · PSP)directionalThe same mandate is designed to front them too — one on-chain guardrail across rails.

“Built” rows are live today and map to our honest-claim ledger. The “directional” row is a design direction, not a shipped integration.

Built for the emerging standards

The Ethereum community is now drafting the exact shape OneLink already ships — bounded, revocable, code-enforced agent spend. We’re a working implementation of that idea today (our own SpendPolicy, live on Base + Arbitrum), aligned with the vocabulary — not an implementation of any single draft ERC.

  • Asset-Enforced Spend MandateDraft ERC · discussionaligned

    Per-charge cap, expiry, allowed token and instant revoke enforced by the asset itself — not by the agent behaving well.

    The same shape, live today: our SpendPolicy enforces per-charge / daily / total caps + expiry + revoke on-chain (C1–C6). The draft explores the token layer; we enforce at the account layer.

  • ERC-8226 · Regulated Agent MandateDraft EIPaligned

    A compliance-layer mandate for regulated tokenized assets: a verified principal delegates scoped, time-bounded, financially capped authority to an on-chain agent, checked before each transfer.

    Same mandate shape (scoped / capped / expiring / revocable), a different domain — 8226 targets regulated tokenized assets, while OneLink applies the pattern to general USDC agent spend on-chain today (SpendPolicy — C1–C6, C16).

  • ERC-8312 · Bounded Agent ActionsDraft ERC · discussionaligned

    Track how much of a bounded mandate an agent has already spent, so a contract can see the room that is left.

    Our SpendPolicy already accounts spend against the caps and reverts over-budget charges at zero gas (C3).

  • ERC-8004 · Trustless AgentsDraft EIPcomplements

    On-chain registries for agent identity, reputation and validation.

    Complementary, not competing: reputation is attested, and its reliability is under active study; our proof receipt is a verifiable record of the actual settlement — proof of the interaction, re-checkable with no account (C20).

“Aligned” means the same shape as our live on-chain mandate; “complements” means it solves a different problem — agent identity/reputation — that our proof receipt sits beside. OneLink implements its own SpendPolicy contract, not these drafts.

Don’t take our word for it

The cross-chain claim is backed by public transactions. Open the proof receipt — it cross-checks the on-chain settlement against the invoice, with explorer links per chain and the InvoicePaid attestation, no account required.

Open a verifiable cross-chain receipt

The agent runs unattended once started (deterministic, not an LLM), the x402 scheme is our own (not facilitator-compatible), and the one-time delegation is relayer-sponsored (zero-gas onboarding) while no general settlement paymaster is claimed. Saying so plainly is the point.