stellar:pubnet is live,
stellar:testnet is beta. Both
networks are on protocol 29 (testnet since 2026-09-29, pubnet since 2026-10-01).
Three companion pages: the live vault panel
reads any of our vaults with no wallet and no sign-in, the proof page
lists every transaction we claim on this chain, and the passkey owner has its own
selection record and recovery page.
Why Stellar
Native Circle USDC
Real USDC, issued by Circle, reachable from Soroban as a SEP-41 Stellar Asset Contract. Seven decimals, not the six every EVM USDC uses.
The buyer signs, not the transaction
A Soroban authorization ENTRY is signed for one specific
transfer call. The seller assembles, pays the network fee and submits, so the buyer never touches a sequence number and never pays a stroop.A policy the ledger enforces
AgentSpendPolicy is ours, written in Rust for Soroban rather than translated. A daily cap, an auto-approve ceiling, an allowlist, a freeze and a session-key expiry, with typed errors a client can branch on.Stellar pubnet is live, and live has never meant “no caveats”. Four of them, stated
up front:
- Real money, but small money. The pubnet vault’s policy is 1 USDC per UTC day and 0.25 USDC per payment, an order of magnitude under the testnet vault, because this one holds value.
- Both sides of every payment have been ours so far. All three x402 sales on pubnet, one from an operator machine on 2026-08-27 and two through the hosted deployment, had our payer and our payee. That is evidence the rail works, not evidence of demand, and the proof page says so.
- The contract is not audited. Free tooling we can re-run, an adversarial review that found and fixed real defects, and a negative-control runner that deletes each guard in turn and requires the suite to go red. None of that is an audit and this project does not call it one.
- No identity anchor. ERC-8004 is EVM-only. A Stellar agent’s passport is bridged from an EVM chain, and KYA cannot be anchored here at all.
Network config
Two properties of that table are worth stating rather than leaving implicit.
The SAC id is derived, never pasted. A Stellar Asset Contract id is a deterministic
function of the classic asset plus the network passphrase, which is why the same asset
code maps to a different contract on each network. Both ids above came out of
stellar contract id asset and were then read back live for symbol(), decimals() and
name(). On pubnet the issuer was checked first, because anyone may issue an asset called
USDC: GA5ZSEJ... publishes circle.com as its home domain, which is the SEP-1 binding
between an issuer and a company.
Reads fail over across the RPC list; a sendTransaction never does. A resubmitted
envelope answers DUPLICATE on the second host, and the rail would read that as a decided
refusal of a payment that is in fact in flight.
What is deployed
The vaults are ours. The USDC SACs are Circle’s asset seen through Soroban. The CCTP
contracts are Circle’s, and the registry cites the Circle page each row was read from. The
Stellar 8004 rows belong to TrionLabs: we read them, labeled third-party, and they are
not our anchor. See Identity on Stellar below. The
two OpenZeppelin rows are theirs as well: the smart account instance is ours, the account
wasm and the WebAuthn verifier behind it are OpenZeppelin’s published deployments, read
out of the
smart-account-kit manifest rather than built by us. The device-passkey owner
for SOW 2 does not use them on testnet: we build the account and verifier ourselves from
OpenZeppelin’s audited release line, as the selection record
explains. See Passkey owner below.
The three vaults above carry the same wasm, v0.1.0, sha256
155eb31c1867254eacbf1b7a4755164d15cc6b6f939644705ab6b8df61579239, byte for byte, so
pubnet runs the code that has been under test since the first testnet deploy rather than a
rebuild of it. The pubnet vault was deployed 2026-08-24, the first testnet vault
2026-08-15, and the passkey rehearsal vault 2026-09-19. The same v0.1.0 code also runs
in the sponsored rehearsal vault CCV2MMK4... from the same day, recorded in
testnet-passkey-owner-2026-09-19.json, and in every vault the
/stellar page deploys on pubnet, because pubnet has no
other build. v0.1.1 is a rebuild with one change (see the gate order).
Its code entry, sha256
353e4264f51e6173b9a2a60603239914cbb1456956e912374caf4d9b358db7c0, was uploaded to
testnet on 2026-10-01 (tx 09d041ab...9e02, ledger 4974389, archived in
soroban/releases/tx-archive),
and new testnet vaults instantiate against it. The first is the SOW 2 D2 vault
CDEU2D4TFDA5XMFI7QMCOGR2O6HWLV2QMOHYVEQDC4Z6REG73HNF2MKT, deployed 2026-10-03, whose owner is a key generated inside
Freighter. The same day, from the vault panel, that owner froze it
(60a7dd67...4c6e, ledger 5006288)
and then withdrew 0.5 test USDC to its own account
(b59f6ed8...61c4, ledger 5006299),
each a transaction the owner account sources, pays for and signs whole in Freighter, with no
signature from any system of ours. The SOW 2 D3 vault runs the same code:
CCTYM23I6UCKKFWHBUWU2GFUSDY6WJEJ3FYSS7WI33DTI5P5HARB72EH, deployed 2026-10-04
(fa1080f6...2c38, ledger 5019022),
whose owner is the OpenZeppelin smart account CBII2K5RHXA7QTBXXUG6O3EMR25NOVOL73KMVGWKWGH7PHO7QXDTHMUD
(5af017bd...ff9b, ledger 5019008).
That account’s one signer is a passkey the owner created in a browser on
/stellar. The same day the owner froze the vault with that passkey
(2d4cb917...6fe6, ledger 5019748):
its one authorization is a WebAuthn (secp256r1) signature through the account, on rule 0, and OpenZeppelin Channels
paid the fee. The decoded authorization is at
/api/stellar/tx/2d4cb917....
Each vault’s release receipt is in
soroban/releases. The existing vaults keep v0.1.0: the contract has no upgrade
entrypoint, so a fix reaches a vault only through a new deployment.
The spend vault
AgentSpendPolicy holds an agent’s USDC and refuses anything the owner did not permit. It
has no upgrade entrypoint and no initialize: the constructor ran atomically at deploy
and its arguments are permanent. There has been no upgrade, no re-initialization and no
owner transfer on either network.
Check a number yourself: a worked example
Every number the vault panel shows is read off the ledger, and you can read the same storage without us. Take the testnet vault’s limits:- Open
CAIL6ECR...OEB4UIon stellar.expert and choose the Storage tab. - Open the contract instance entry. It is one ledger entry holding the vault’s configuration as a map.
- Find
DailyCap. It reads100000000, ani128in the token’s base units. Stellar USDC has 7 decimals, so that is 100000000 / 10^7 = 10 USDC per UTC day. - Find
AutoApproveMax. It reads20000000, which is 2 USDC: the largest single payment the agent may make on its own. - Compare both with the panel’s daily cap and auto-approve rows. They are the same two integers, divided by 10^7.
Owner, Operator, Token, Decimals (7),
Frozen, AllowlistEnabled and SessionKeyExpiry (0, meaning no time bound).
Why you will usually not find “spent today”. The day’s running total is not in the
instance. It is a separate temporary entry keyed SpentOnDay(day), where day is the
ledger’s Unix time divided by 86400 and rounded down (day 20727 is 2026-10-01 UTC). It is
written only when a payment happens. On a day with no payments it simply does not exist,
and the vault reads a missing entry as zero, which is the correct answer: nothing was
spent. On 2026-10-01 both SpentOnDay(20726) and SpentOnDay(20727) were absent for this
vault, so its spend for both days read as zero. On a day with payments the entry appears, its value is
an i128 in the same 7-decimal units, and it lives for about two days, so yesterday’s
entry can still sit beside today’s. owner_pay adds to it like any other payment, but it
is never refused by it.
The gate order, and why order is the product
The ladder runs in a fixed order, and the order is observable behaviour rather than an implementation detail: an agent toldFrozen when it expected DailyCapExceeded routes to
the wrong recovery path. For an operator payment the ladder runs amount, payee (refusing
the vault itself or the settlement token), freeze, session-key expiry, allowlist,
auto-approve ceiling, daily cap, and finally balance.
That first pair changed between versions, and the change is the only one in v0.1.1. In
v0.1.0 the payment path checked the payee before the amount while withdraw checked
the amount first, so the same doubly invalid input (a zero amount to the vault’s own
address) was refused as InvalidPayee by pay and as InvalidAmount by withdraw.
Our internal audit recorded it as finding A3-02. v0.1.1 moves the amount check to the
front of the shared payment path, so pay, owner_pay and withdraw all answer
InvalidAmount first, which is what the invariant and the test written for it always
said. Every v0.1.0 vault keeps the old order: the three above, the sponsored rehearsal
vault and the pubnet vaults /stellar deploys.
That last pair is worth reading closely. When the pubnet vault’s budget was spent to its
edge, the next payment was refused with DailyCapExceeded even though the vault was also
short of funds and InsufficientBalance was available, because the cap gate fires first.
The agent is told its budget is spent rather than that the account is short, and those call
for different human responses.
owner_pay is a human act, so it skips the ceiling, the allowlist and the freeze. It does
not skip the payee check, the amount guard, the arithmetic or the balance check, and
the amount it moves is still added to the day’s total, so on-ledger accounting stays honest
about total outflow.
These discriminants are frozen public ABI. A client decodes an integer, not a name, so the
list is append-only. Two changes that would break that ABI or the constructor, renumbering
the errors (internal finding A4-01) and taking the allowlist as a constructor argument,
are deliberately not in
v0.1.1; they are deferred to a later version so that every
client decoding these codes today keeps working.
Archival, which is a calendar item rather than a risk
Soroban charges rent, and a contract instance whose rent lapses is archived rather than lost. The pubnet vault’s instance archives around 2027-01-06 unless it is touched in time, and a touch only counts once the remaining life is under the contract’s re-extension threshold of 1,036,800 ledgers. The contract calls that 60 days, counted at 17,280 ledgers a day, but at the measured 5.625 s close it is about 67.5 days, so the action window opens around 2026-10-31 rather than in November. A weekly GitHub workflow turns red at 45 days remaining rather than waiting for the deadline.Owner controls, signed by the owner
The console reads live vault state and prepares owner calls:set_policy, set_frozen,
set_allowed, set_session_key_expiry, withdraw and owner_pay. The owner signs each
one with their own Stellar wallet and the server never holds the key. A per-agent Soroban
vault can also be provisioned on testnet: it instantiates against the existing code entry
rather than re-uploading the wasm, which is the difference between about 0.1 XLM and about
12 XLM. Pubnet provisioning is gated behind STELLAR_VAULT_ALLOW_PUBNET.
There are two ways to be that owner, and the second one has no seed phrase in it. An owner
can be a plain G... account signing with a Stellar wallet, which is what both vaults in
the table above use. Or the owner can be a contract, because owner.require_auth()
does not care which: Soroban dispatches to a contract owner’s __check_auth, so a smart
account whose only signer is a passkey can hold the same authority. The contract path ran
on testnet on 2026-09-19 with a software key standing in for the passkey; the next section
is that record, and what the device-passkey run for SOW 2 changes.
Passkey owner
A spend vault whose owner is a passkey. No seed phrase, no browser extension, and no owner key this server could sign with even if it wanted to. The owner is an OpenZeppelin smart account contract whose single signer is a WebAuthn P-256 credential, and the vault’sowner.require_auth() is satisfied because that contract is the direct invoker of the call,
which it can only be after the passkey has signed for that exact call. Why this account
and not another is the selection record; what happens if
the passkey is lost is the recovery page, and it is
worth reading first.
The page that runs this flow is a-identity.xyz/stellar.
It opens on pubnet by default, with dust amounts capped by the backend and
OpenZeppelin’s own published account and verifier, labelled as theirs. Add
?network=testnet to run it on testnet, where the SOW 2 device-passkey evidence is
produced, against an account and verifier we build from OpenZeppelin’s audited release
line. Fees are sponsored through OpenZeppelin Channels only when the deployment has a
Channels key configured for that network; when it does not, the page says so and submits
nothing.
What ran, and what it cost
The vault is
CBGTXWFB...NS6J6U,
carrying wasm 155eb31c...9239, the same code the other two vaults run. Its owner is
CC5RNXNH...VM3RWA,
an instance of OpenZeppelin’s account wasm 1b5f4534...785a with their WebAuthn verifier
CC7EKIHQ...ZIOM3F
behind it, deployed through the smart-account-kit npm package 0.8.0. The whole record,
with fees and the live reads taken afterwards, is testnet-passkey-owner-2026-09-19.json
in soroban/releases.
The rehearsal smart account’s instance has since been archived for unpaid rent (read
over RPC on 2026-10-01), so it cannot sign again without a restore; the vault itself is
still live.
Why this is a second vault rather than a migration
AgentSpendPolicy has set_operator and deliberately no set_owner. The owner is
permanent, which is the point of it, so an existing vault cannot be handed to a passkey.
The vault above was deployed with the smart account as its owner from its first ledger, and
CAIL6ECR...OEB4UI
keeps its G... owner. Neither upload was needed: both instantiate against the code entry
already on the ledger, about 0.1 XLM rather than about 12.
KYA maps onto a binary allowlist, and that is worth saying exactly
The trust verdict has three states andset_allowed has two, so the mapping is published
rather than implied:
- ALLOW writes
set_allowed(payee, true). The agent can pay that payee inside the cap. - WARN writes nothing on chain. It is a server-side flag on the decision record.
- DENY writes
set_allowed(payee, false), after whichpay()to that payee reverts withPayeeNotAllowed, error3.
Pay for a trust check
Four tools sell on this rail. The base price is identical on every chain we sell on:
Ask for one without paying and you get a 402 carrying both networks:
Two payment schemes
soroban-auth is the default and the one to use. You sign a Soroban authorization
entry for one specific transfer call on the USDC SAC, hand it over base64 in X-PAYMENT,
and pay no network fee. The nonce inside that entry is what ties a transaction on the
ledger to this purchase.
settled exists for contract payers only. An agent whose spending a vault already
bounds cannot sign an authorization entry, because a contract has no key. That agent calls
pay() on its vault and hands us the resulting transaction hash instead. The binding is
then weaker and the rail says so in the challenge itself: we can prove the payment happened
and that nobody has redeemed it here before, but not that it was made for this particular
purchase rather than another of the same price, and not that the presenter is the party who
made it. A landed transaction is public, so a hash should be presented promptly. That is
why this is the second shape and not the default.
What “settled” means here
A sale counts only once we read the SEP-41 transfer event back off the ledger and match it to the buyer’s authorization nonce. Not the facilitator’s word, not a 200 from anyone: our own read of the event, with{sac, to, from, amountRaw, authNonce} all required. An
earlier version keyed only on the contract, recipient and amount, and an adversarial review
broke it immediately with a real unrelated transaction that had moved the same number of
base units. The nonce is what closed that.
The fee, in the units the ledger uses
The buyer pays nothing. We do, and rather than adding a settlement line item to a sub-cent sale we absorb it, which is a decision rather than a free lunch.
The bid is the maximum offered into the inclusion auction; the ledger charges what it
charges, and Horizon’s
fee_charged is the figure that left the account. Recorded with the
part that did not work: the first two pubnet attempts bid the 100-stroop minimum that
testnet always accepts, lost pubnet’s auction and sat invisible until they expired.
The break-even on the cheapest tool is XLM at 0.4353 USD: above that, one settlement
costs more than a verify_agent sale. XLM has traded above that before, so this is a price
move and not a hypothetical, and the decision gets revisited rather than discovered.
Sign in with a Stellar wallet
An owner signs in, or links a wallet to an existing account, with SEP-43signMessage
through Stellar Wallets Kit
(@creit.tech/stellar-wallets-kit 2.6.0). Freighter signs
SEP-53. The same account can carry wallets from several chain families at once, so an
EVM-anchored passport and a Stellar signing key belong to one owner rather than two.
USDC across chains (CCTP)
Circle’s CCTP moves native USDC between Stellar and the EVM chains here by burn and mint, never a wrapped twin. Stellar is CCTP domain 27, and a Stellar recipient must ride in the hook data and be minted through Circle’sCctpForwarder: the message format has no room
for a StrKey type marker, so a direct mint to a G... account is unrecoverable. Proven
both ways on testnet on 2026-09-10; mainnet is opt-in only and capped. Details on
Circle CCTP.
Identity on Stellar, stated plainly
There is no ERC-8004 on Stellar, because that standard is EVM-only. A Stellar agent’s passport is bridged from an EVM chain rather than anchored here, and KYA cannot be anchored on Stellar at all. We say so at the point of sale rather than reporting a zero that reads like a real count. TrionLabs’ Stellar 8004 is a real Soroban agent registry on both networks, and since 2026-09-15 we read it, read-only and labeled third-party. It is not our anchor, and three differences are the reason:- It mints its own ids in its own space. An id there and an ERC-8004 token id are different
identities that happen to both be integers, so the labels stay explicit:
stellar:{testnet|mainnet}:{registry}#{id}. - Its exported interface binds no foreign-chain identity. There is no CAIP-10 and no chain
id; the only places a cross-chain reference could live are the free-form
agent_uriandset_metadata, which are assertions by whoever holds the key. - It is upgradeable behind a timelock and owned by Trion. Ours deliberately is not upgradeable.
60701278...54b07,
2026-09-08). Mainnet registration is not done: a write simulation on 2026-09-09
reported their mainnet registry instance archived, with a 36.6 XLM restore in the
footprint. Whether that is still true is a live read rather than a claim in this page.