Stellar

Mainnet, real money in dust amountsno XLM needed

A passkey that owns a spend vault.

Your face or fingerprint becomes a smart account on Stellar. It deploys a vault, sets the limit, watches the vault refuse a payee it does not trust, and keeps the owner's levers: freeze, withdraw, add a device.

This side is Stellar mainnet with real Circle USDC, in dust amounts the server enforces.

You need no wallet, no seed phrase and no XLM. This deployment did not say whether fees are sponsored on Stellar mainnet.

Signing uses smart-account-kit 0.8.0 against OpenZeppelin smart-account contracts.

The backend did not answer for Stellar mainnet, so the caps and contract ids this page needs are unknown. Give it a few seconds and reload.

1

Create your passkey

No wallet and no seed phrase. The passkey's private key stays in your device's authenticator (or in the password manager that syncs it) and controls an OpenZeppelin smart account, a C... contract deployed for you on Stellar mainnet.
2

Know how you recover it

Read this before any money goes in. The vault deploy below stays locked until you tick the box.

If you lose every device that holds this passkey, the funds in the vault become unreachable to you, and nobody, including A-Identity, can recover them.

  • There is no seed phrase to write down. The passkey is the key, and it stays in the authenticator that made it (or in the password manager that syncs it).
  • A synced passkey survives losing one phone; a passkey bound to one device or one security key does not. The page tells you which kind you made.
  • Add a second device in step 8 once your vault is deployed. Each device gets its own rule, so either one can sign alone. Not before: the vault deploy checks that this passkey is your account's one signer, and refuses an account that already has a second one.
  • Our server holds the vault's operator key. It can call pay() inside the daily cap and per-payment ceiling, and once you turn the allowlist on (signing the limit does) only to payees you allowed. It cannot withdraw, change your limit, unfreeze the vault or add a signer.
  • This is mainnet. The amounts are dust by design, and they are real.

The full recovery document its source in the repository

3

Deploy a vault and set its limit

A fresh AgentSpendPolicy vault whose owner is your smart account. The server first reads your account off the ledger and deploys only if this passkey is its one signer; it then seeds the vault with USDC, and you sign the limit yourself, which is what proves the passkey owns it.
4

Check who you are about to pay

Our risk engine answers ALLOW, WARN or DENY for this payee, and hands back the one chain write that verdict implies. You sign it with the passkey.
Try

The on-chain allowlist is binary: ALLOW writes an entry, WARN is a server-side flag and writes nothing, and DENY writes a revoke so pay() reverts with PayeeNotAllowed. Only two of the three verdicts ever touch the ledger.

5

The agent pays someone untrusted

The agent asks the vault to pay an address that is not on the allowlist. The vault refuses before anything moves.

Any Stellar address that is not on your allowlist. A refused payment moves nothing and costs nothing.

6

The agent pays someone trusted

Same vault, same agent, same amount. This payee is on the allowlist and inside the limit, so the payment settles. Our operator key signs this one, inside the policy your passkey set.

Create your passkey account first; on mainnet the trusted payee is your own smart account.

Allow it in step 4 first, or the vault will refuse this too.
7

Freeze it, or take the money back

The owner's own controls, signed by your passkey through the smart account: a freeze that stops every agent payment, and a withdrawal back to you. The operator key can do neither.

Deploy the vault in step 3 first.

8

Add another device

One passkey on one device is one point of failure. A second device gets its own rule on your smart account, so either can sign alone.

Create your passkey account in step 1 first.

Your receipts

Every transaction this page put on Stellar mainnet, in the order it happened. Nothing is listed here without a hash that made a ledger.

No transactions yet. Run step 1 and this fills itself in.

Stated plainly
  • This side is Stellar mainnet. The USDC is real and the amounts are dust, capped by the server for every visitor.
  • A refused payment fails in simulation, so it has no hash.
  • The passkey's private key never leaves your authenticator. Our server holds the vault's operator key: it can call pay() inside the cap and ceiling you signed, and with the allowlist on only to payees you allowed. It cannot withdraw, change your limit, unfreeze the vault or add a signer.
  • Lose every device with this passkey and the vault's funds are unreachable; nobody, including A-Identity, can recover them.