Roadmap
Shipped with receipts. The rest in order.
Every shipped item carries the day it landed and a place to check it. Work underway is labeled underway, the program milestones we signed carry their due dates, and nothing further out gets a date it might not keep.
- ShippedOn chain or in the repository, with the day it landed and a place to check it.
- In progressWork underway now. No completion date, on purpose.
- CommittedA program milestone we signed, with the due date in the agreement. Progress is published live, not promised.
- NextWhat follows the current work, in order and undated.
- LaterDirection, undated. Known and wanted, not scheduled.
- Shipped39items
- In progress2items
- Committed2items
- Next4items
- Later5items
- Arc Mainnet
- Arc
- Stellar
- Algorand
- Base
- Robinhood Chain
- Arbitrum
- X Layer
- Celo
- Stellar test
- Algorand test
- Robinhood Chain Testnet
- Celo Sepolia
- Avalanche
Read from the chain registry at render time. A chain is live only after our own agent is minted and our own rail has settled on it.
Landed, dated, and checkable.
Newest first. Every item names the day it landed and a place to check it: a proof page, a live API answer, a docs page or a file in the repository.
October 2026
13 shipped- Platform and console
The manifesto, rebuilt as a reference
Four pillars, ten principles each tied to the mechanism that keeps it, the 2026 landscape read against dated sources, and four refusals the code enforces.
More
Written for investors, grant programs, partners and researchers as much as for developers. Every landscape row states only what we could verify, with the date we read it, and the section is a map of approaches rather than a scoreboard.
CheckRead the manifesto - Platform and console
A feedback button on every page
A note from any page, the console included, reaches the team inbox. The widget says it was delivered only after the email provider accepted it, and falls back to a mailto link when the server holds no key.
- Trust and security
/stats and /proof read one list of settlement logs
The two pages used to carry their own lists of which logs exist and drifted apart. One module now feeds both, and a log that fails to answer is an error on the page, never a zero.
- Ecosystem
Arc Acceleration Season progress, computed from the logs
GET /api/arc/season reports progress against each success metric from the settlement logs on every request, external usage counted apart from our own. /proof/arc shows the block, and the partner guide tells a team how to be counted.
More
The three lists a human curates (owner-held vaults, inspectable refusals, partner wallets) are exported as data and were empty on 2026-10-19: a vault counts only when its owner key is one we never held, a refusal only when a reviewer can inspect it, and a team only after its wallet has paid a check.
- Arc Mainnet
- Ecosystem
Member of the Circle Alliance Program
The landing's Member of band and the footer line read one memberships list, and only programs that have admitted us are on it.
- Trust and security
Every proof surface re-read against its chain
Each provenance entry was read live again on 2026-10-11 and the caveats moved with the facts: the ERC-8004 family's ValidationRegistry is deployed on six mainnets but not wired, so KYA stays off-chain everywhere we sell, and X Layer sells nothing since the OKX.AI delisting.
- Arc Mainnet
- Base
- Arbitrum
- Robinhood Chain
- X Layer
- Celo
- Stellar
CheckThe proof index - Spending limits
Stellar SoW 2, D3: an owner action signed by a device passkey
A passkey created in the browser is the one signer of a smart account, under our verifier instance of OpenZeppelin's audited v0.7.2 code, and that account owns the vault. The owner froze it with the passkey and paid no fee.
More
The smart account and the vault were published in the accounts table before any owner action. The 2026-09-19 passkey runs were rehearsals driven by software keys in our own script and are labeled as such; D3 is the first owner action on this ledger signed by a device we do not control. The owner's attempt to add a second device did not reach the ledger, so the account still has one signer, which the recovery page says plainly.
- Spending limits
Stellar SoW 2, D2: owner actions from a browser wallet
The D2 vault's owner, a key generated inside Freighter, froze the vault and withdrew from it in the live panel, each transaction signed whole in the wallet. The owner key was published before any owner action.
More
The vault runs the v0.1.1 code, instantiated against the code entry already on the ledger rather than re-uploaded. Testnet resets periodically, so a D2 vault is evidence that the flow works on the ledger at the time shown; the hashes and dates are what survive a reset.
- Stellar test
- Platform and console
Stellar SoW 2, D1: a live, read-only vault panel
/app/vault/stellar reads any AgentSpendPolicy vault by contract address with no wallet and no account, every value stamped with the ledger it was read at.
More
Checked the same day against the raw ledger storage of the flagship testnet vault and the D2 vault: every policy field and both balances matched. The panel sits in the console shell but outside the sign-in gate, because a vault's state is a public read.
- Stellar test
- Stellar
- Trust and security
The EVM vault gets a Foundry suite, and CI proves the suite notices
Unit, fuzz and invariant tests for AgentSpendPolicy.sol, plus a control job that deletes each guard in a temporary copy and requires the suite to turn red.
- Spending limits
Soroban vault v0.1.1: one refusal ladder for pay, owner_pay and withdraw
settle checks the amount first, so the three entrypoints refuse in the same order (audit finding A3-02). The code entry is on testnet and new testnet vaults instantiate against it instead of re-uploading the wasm.
- Stellar test
- Trust and security
/check/robinhood and /check/arbitrum: is it the real USDG, and who gets paid
Before an agent pays an x402 challenge on Robinhood Chain or Arbitrum One, one box answers whether the offered token is the real USDG or USDC and names the payee. A chain read that does not come back decides nothing.
- Robinhood Chain
- Arbitrum
- Spending limits
Agent keys split from owner keys on the Robinhood Chain and Arbitrum One vaults
Both vaults have a working agent key again, and it is no longer the owner key: the operator may only pay inside the policy, and the session keys are valid to 2026-11-15.
- Robinhood Chain
- Arbitrum
September 2026
10 shipped- Ecosystem
@a-identity/trust-mcp: pay for a check with XLM from Claude Code
One prompt gives anyone's Claude Code a wallet of its own. A single XLM deposit on Stellar is turned into what the Algorand checks cost, and the buy command spends it on checks on its own; the agent picks what to check and nothing is paid for twice.
- Stellar
- Algorand
- Trust and security
/check: paste an Algorand address, get one answer
Before you pay an Algorand address, ask whether it looks safe: one box and one plain answer, written for someone who has never heard of an AI agent. The detailed report costs five dollars, bought from your own Algorand wallet, and the page says who pays.
- Algorand
- Spending limits
Arc Mainnet vault: agent key split from owner key, source verified
The vault's operator is a separate agent key, its source is verified on Sourcify as an exact match of creation and runtime bytecode, and settlements went through Arc's predeployed Memo and Multicall3From contracts with mainnet receipts.
- Arc Mainnet
CheckArc proof - Payment rails
A SEP-1 stellar.toml, a Soroswap quote labeled as a quote, and the stock x402 payload
The Stellar rail accepts the payload shape a stock @x402/stellar client sends, the site publishes a stellar.toml that also states what it does not claim, and the passkey page quotes a swap off the Soroswap router live, saying plainly it is only a quote.
- Stellar
- Stellar test
- Spending limits
A WebAuthn passkey can own an on-chain spend vault
/stellar runs the passkey vault demo end to end in the browser on testnet: a passkey-owned smart account deploys and owns an AgentSpendPolicy vault, and every owner call dispatches to the account's __check_auth.
More
The runs that day were rehearsals signed by a software P-256 key in our own script, and the proof page records them as such. The first owner action from a device passkey outside our systems is D3, on 2026-10-04.
- Stellar test
- Chains
Arc Mainnet live on the day it opened
Agent #0 on the canonical ERC-8004 registry, the registry's first mint, is ours. An AgentSpendPolicy vault holds real USDC under dust caps, and paid trust calls settled on both rails that day: our own EIP-3009 facilitator and Circle Gateway nanopayments.
More
Gas on Arc is USDC itself, so every cost on the proof page is an exact dollar figure with no price feed. The operating wallet was funded by burning native USDC on Base through CCTP V2 with Circle's Forwarding Service, which minted it on Arc without any Arc gas of ours. The chain entered the registry as its own descriptor and was live on the bar every other chain met.
- Arc Mainnet
- Trust and security
The weekly Stellar ops job goes red on an empty vault
The pubnet vault was found empty, refilled, and its live policy documented. The weekly workflow now fails when a vault balance reads zero, alongside its warnings on archival, key-role overlap and allowlist drift.
- Stellar
- Spending limits
Stellar owner controls, a third-party registry read, and the ops calendar
The console shows live Soroban vault state and prepares the owner calls for the owner to sign with their own Stellar wallet, so the server never holds that key. A per-agent testnet vault is provisioned against the existing code entry, with pubnet gated behind an environment flag.
More
TrionLabs' Stellar 8004 registry is read, read-only and labeled third-party: a pointer rather than an anchor. RPC reads fail over across the registry's fallback list while sendTransaction deliberately never does, the x402 fee is reported as bid and charged separately instead of as one number, and a weekly ops workflow warns on vault archival, key-role overlap and allowlist drift.
- Stellar
- Stellar test
- Payment rails
CCTP between Stellar and EVM, proven both ways
Native USDC burned on Arc testnet and minted on Stellar testnet through Circle's CctpForwarder, and the reverse leg burned on Stellar and minted back on Arc, driven by our own code because Bridge Kit has no Stellar adapter.
More
A Stellar recipient rides in the hook data, because a direct mint to an account is unrecoverable. Mainnet stays opt-in only, capped, and returns a labeled prepared no-op wherever the keys are absent.
- Arc
- Stellar test
- Identity
Wallet sign-in and linking on every chain family
An owner signs in, or links a wallet to an existing account, with an EVM personal_sign, a Stellar SEP-43 signMessage through Stellar Wallets Kit, or an Algorand signed zero-value self-payment. One account can carry wallets from several families at once.
More
This is what lets an EVM-anchored passport and a Stellar signing key belong to one owner.
- Base
- Stellar
- Algorand
CheckSign in
August 2026
12 shipped- Chains
Algorand went live on its first mainnet sale
The second non-EVM ecosystem, promoted the same day on a real payment: x402 v2 exact in native Circle USDC, the buyer signing a fee-zero transfer inside a pooled-fee atomic group through the GoPlausible facilitator, and no sale counted until our own indexer read returned the transfer.
More
The AgentSpendPolicy vault landed with it as the policy's third implementation (Solidity, then Rust on Soroban, now Algorand Python): no update or delete handler, real USDC under a 1 USDC daily cap, walked through the same settle-refuse-freeze-override ladder as the Stellar releases.
- Algorand
- Algorand test
- Chains
Base went live
Agent #73232 on the canonical ERC-8004 registries, deployed by their authors, and x402 settling in native Circle USDC through the same first-party EIP-3009 facilitator that serves Robinhood Chain and Arbitrum One.
More
The operating wallets were funded from Stellar pubnet USDC through a NEAR Intents swap, and that funding trail is published rather than left as a gap. The canonical registry pair was verified by matching each proxy's implementation code against Arbitrum One, because Arc's three registry addresses also have code on Base and delegate to a non-canonical implementation.
- Base
CheckBase proof - Payment rails
The Stellar x402 rail sells on pubnet
First mainnet sale at ledger 64155370, 0.001 USDC through our own facilitator, the buyer signing a Soroban authorization entry and paying no fee.
More
Recorded with the part that did not work: two earlier attempts bid the 100-stroop minimum that testnet always accepts, lost pubnet's inclusion auction and sat invisible until they expired. The rail now bids the fee market's own rate with headroom. This is what turned stellar from a vault-only story into a selling rail.
- Stellar
CheckStellar proof - Spending limits
The payee-validity gate backported to the Solidity vault
Audit finding G-1: the Soroban and Algorand ports refused a payee equal to the vault itself while the Solidity original accepted it and burned the cap against a payment that went nowhere. The Solidity now declares InvalidPayee and reverts with it in pay, ownerPay and withdraw.
More
Three implementations of one policy model are a strength only while they agree, and on this gate they now do.
CheckThe contract - Spending limits
Stellar pubnet vault deployed, holding real USDC
The same wasm as testnet, byte for byte, holding real Circle USDC under a 1 USDC daily cap and a 0.25 USDC auto-approve ceiling, an order of magnitude under the testnet vault because this one holds real money.
More
Four settlements, a freeze and unfreeze pair, and an owner override are on the ledger, with spent_today coming to rest exactly at the cap. The owner account was raised to a 2-of-3 multisig on 2026-08-25, after an audit finding pointed out that a permanent owner behind a single key is a single point of total loss.
- Stellar
CheckStellar proof - Payment rails
The Stellar testnet rail went end to end
AgentSpendPolicy in Rust on Soroban (daily cap, auto-approve ceiling, allowlist, freeze, session key, typed errors, no upgrade entrypoint), plus our own Soroban x402 facilitator settling in SEP-41 USDC with the buyer paying no network fee.
More
Both halves are on the ledger: an under-limit payment settled and an over-limit one was refused on chain with DailyCapExceeded. The first non-EVM rail here, and the only one where the spend limit is enforced by a contract before the payment exists.
- Stellar test
- Chains
Arbitrum One went live
Agent #1259 on the canonical ERC-8004 registry, and x402 settling in native Circle USDC through our own EIP-3009 facilitator, with a per-chain fee derived from measured gas rather than guessed.
- Arbitrum
CheckArbitrum One proof - Chains
Robinhood Chain live, with agent #0
The canonical identity and reputation registries verified live on mainnet, and agent #0, the registry's first mint, is ours since 2026-08-12. Mainnet went live on 2026-08-13 once the x402 rail settled there in USDG, because the chain publishes no canonical Circle USDC.
More
The testnet came first, on 2026-08-11: the full canonical registry set is live there, with the missing ValidationRegistry implementation deployed by replaying the canonical Safe Singleton Factory calldata, and agent #0 minted there too. It stays beta as the rehearsal rail.
- Robinhood Chain
- Robinhood Chain Testnet
- Chains
Celo mainnet live
ERC-8004 identity and reputation reads wired, agent #9759, and the trust tools selling over the first-party Celo x402 facilitator in native USDC, with gas payable in stablecoins.
- Celo
- Celo Sepolia
- Spending limits
Spend preflight and a velocity circuit breaker
A dry run of the whole policy ladder with zero mutation, so a payment can be asked whether it would pass before anything is signed, and a brake on burst spending that trips on velocity rather than on the cap alone.
CheckThe policy module - Trust and security
merchant_check: counterparty verification for agentic checkouts
Commerce-grade verification of a merchant-side agent before a checkout, as an MCP tool and over REST, returning ALLOW, WARN or DENY with reasons.
CheckThe MCP server - Platform and console
The backend split into layered platform/ and http/ modules
Two monoliths became a layered platform with route-group handlers, the layer graph enforced by a test, and a unit suite whose size is asserted by a test rather than quoted here.
July 2026
4 shipped- Ecosystem
A trusted agent marketplace on Arc: verify, hire, work, release
Hire a verified agent with the payment held in an ERC-8183 escrow on Arc testnet until the work is delivered and released, with a composite leaderboard and public agent certificates.
- Spending limits
Session keys, the Arc Memo audit trail, and Multicall3From batch settlement
Time-bounded session keys, both vault-native and as a real ERC-4337 UserOp through a Kernel smart account; an on-chain Memo entry for every agent settlement; and batched settlement in one atomic transaction through Arc's Multicall3From.
- Arc
- Ecosystem
The paid Trust Oracle listed on OKX.AI, on X Layer
Six paid x402 tools plus a free preview, sold through OKX's x402 layer in USDT0 on X Layer mainnet: 120 real settlements between 2026-07-17 and 2026-07-24, every one paid by our own buyer wallet, published with transaction hashes.
More
OKX.AI delisted the listing on 2026-09-26. The gateway answers in free mode and nothing sells on X Layer now; the identity reads there stay live.
- X Layer
- Spending limits
The first AgentSpendPolicy vault: on-chain spend limits on Arc
A per-agent vault whose caps, auto-approve ceiling, allowlist and freeze are enforced by the contract, so an agent's authority is bounded where the money sits rather than in a prompt.
- Arc
CheckThe contract
Underway today.
Work in flight, with what is already done inside it stated as done. No completion dates, on purpose.
- Trust and security
Separate the testnet fee payer from the testnet vault operator
The pubnet half is done: since 2026-09-15 the pubnet fee payer is a dedicated XLM-only account, proven by the production sale it broadcast, so the key that may call vault.pay no longer pays for every settlement. On testnet the two Stellar roles still share one key, which is test money.
- Stellar test
CheckThe key inventory - Trust and security
Ops hardening: secret rotation, off the free tier, rate limits off process-local state
Post-event secret rotation, the backend off the free tier for demo reliability, and the rate-limit buckets out of process memory: the one piece of runtime state Postgres did not absorb, so a horizontally scaled deploy would still multiply every limit by the instance count.
The dates we owe.
Program milestones with the due dates in the agreement. These are the only future dates on this page, and the progress against them is read from the settlement logs and published on the Arc proof page rather than promised here.
- Spending limitsDue
Arc Acceleration Season M1: owner-held vaults from the browser, and verifyThenPay
Five AgentSpendPolicy vaults on Arc Mainnet deployed from the browser with an owner key A-Identity never holds, 100 verify-then-pay checks settled through Circle Gateway nanopayments, and two refusals anyone can inspect: a vault-policy revert with a hash, and a DENY that stopped a payment before signing.
More
A vault counts only when its owner key is one we never held, so the launch-day vault, owned by our operating wallet, does not. The browser deployer is planned at /app/vault/arc. Targets are the Deliverable 1 commitments as Circle revised them on 2026-10-19; the counts are read from the settlement logs on every request, and the curated lists are empty until the evidence exists.
- Arc Mainnet
- EcosystemDue
Arc Acceleration Season M2: the first external agents verifying and paying on Arc Mainnet
Two external teams live, 30 paid checks from wallets we do not control, one team active on more than one day, and one integration we may reference in public.
More
A wallet is external by default and attributed to a team by name only on request, and only after it has paid a check on Arc Mainnet. Deliverable 2, the progress report Circle judges, is due 2026-10-30 and is the same computed report.
- Arc Mainnet
What follows, in order.
Ordered and undated. The sequence is the commitment; a date would be a guess dressed as one.
- Payment rails
MPP session mode on the main backend
Open a funded session, make many vouchered trust checks, settle on close. Research and recommendation are done; the prototype follows the Arc x402 rail's durable-store discipline.
- Payment rails
X Layer: a rail that sells again
Identity reads on X Layer are live; the paid listing was delisted on 2026-09-26 and nothing sells there now. The payment rail returns as one deliberate listing update, with the OKX payment-surface expansion (subscription-style monitoring, an escrow-gated tool, batched settlement) bundled into it.
- X Layer
- Platform and console
Spend preflight in the console
The API is live. The Permissions screen gets a would-this-pass panel that runs the whole ladder with zero mutation before anything is signed.
- Identity
A readable identity story for the non-EVM rails
ERC-8004 is EVM-only, so a passport on Stellar or Algorand is bridged from an EVM chain rather than anchored. The pointer half shipped on 2026-09-15: TrionLabs' Stellar 8004 registry is read, read-only and labeled third-party, and A-Identity is agent 25 on its testnet instance.
More
Three things remain, and none of them is a registry of our own called a standard. Mainnet registration is blocked on the registry's owner, because their mainnet instance simulated as archived and restoring somebody else's contract is their call, not ours. Algorand still has no registry we can verify. And KYA remains unanchorable on both chains, which the point of sale has to keep saying out loud.
- Stellar
- Algorand
Direction, not schedule.
Known and wanted, not dated. An item moves up this page when the work ahead of it lands, not when a calendar says so.
- Payment rails
Cross-protocol settlement router
One quote layer answering 402s with the union of rails we accept (x402 exact, Nanopayments, MPP session) and routing settlement.
- Chains
Avalanche, the only planned entry in the registry
The descriptor is there and the canonical ERC-8004 identity and reputation registries are already live on the chain, deployed by their authors. What is missing is ours: an agent on them and a rail pointed at them. It stays planned until both exist, because a descriptor is not an integration.
- Avalanche
- Trust and security
Cross-operator Sybil detection
Funder-graph provenance, beyond the same-operator wash detection the score already applies.
- Ecosystem
Per-party escrow signing in the marketplace
Today the platform signer is the escrow party. Each party signing from its own wallet is the goal.
- Platform and console
Frontend debt
RegisterForm state to a single reducer, and the sitemap generator decoupled from the blog source text so content can be split freely.
Name the chain, the rail and the evidence you expect.
An issue that says what it would take to call something shipped is the fastest way to move it up this page. A chain lands as a registry entry plus at most one adapter, never as scattered special cases; CONTRIBUTING.md carries the rule.
Dates only on things that happened.