Your Agent Gets a Wallet. Your Rules Decide How It Spends.
Every agent with a passport gets a crypto wallet. Nano-powered: feeless, instant, Layer 1 finality. Every transaction goes through the APS delegation pipeline. Scope check. Spend limit. Signed receipt. No gas fees. No session caps. No intermediary taking a cut.
Agent Passport System / Agent Wallet
Why Agents Need Wallets
Agents are already spending money. Coinbase Agentic Wallets charge gas. Most agent payment systems require a human to approve every transaction, or worse, give the agent an unlimited credit card.
The APS Agent Wallet is different. When an agent registers with the gateway, it gets a Nano wallet tied to its cryptographic passport. The delegation chain defines exactly what the agent can spend, on what, and how much. The gateway enforces it. Every transaction produces a signed receipt anchored to the agent's identity.
How It Works
Agent registers, gets a Nano address tied to its passport
Principal sets scope and spend limit via delegation chain
Gateway checks: active wallet, commerce scope, budget remaining
Transaction signed, on-chain, receipt stored in audit trail
Three Gates Before Every Send
No transaction goes through without passing all three gates in the delegation pipeline:
Agent's wallet must not be frozen or revoked. Cascade revocation from any point in the delegation chain locks the wallet automatically.
The delegation must include commerce scope. An agent delegated for "review" cannot spend. Monotonic narrowing applies.
Cumulative spend tracked against the delegation's spend limit. Idempotency keys prevent double-spend on retry.
Why Nano
Agent-to-agent payments need three properties: feeless (micro-transactions must be viable), instant (sub-second finality for real-time workflows), and programmable (the gateway controls the wallet, not the agent). Nano is the only Layer 1 that delivers all three natively. No gas estimation. No mempool. No bridge fees. A 0.001 XNO payment costs exactly 0.001 XNO.
Nano is the first payment rail. The PaymentRail interface is generic. Future rails (Lightning, Solana, stablecoins) plug in the same way. The governance layer stays the same.
API Endpoints
POST /wallets/provision Provision a wallet for an agent GET /wallets/:id/balance Live on-chain balance query POST /wallets/send 3-gate delegation pipeline send POST /wallets/:id/receive Pocket pending incoming blocks GET /wallets/:id/txs Transaction history with receipts POST /wallets/:id/freeze Freeze wallet (reversible) POST /wallets/:id/unfreeze Unfreeze a frozen wallet GET /wallets List all agent wallets GET /wallets/dashboard Aggregate wallet stats
Plus the payment rail endpoints for direct invoice-based payments:
POST /pay/nano/invoice Create amount-unique invoice GET /pay/nano/status/:id Poll payment status POST /pay/nano/settle/:id Settle a completed payment GET /pay/nano/balance Gateway treasury balance GET /pay/nano/history Payment transaction history POST /pay/nano/verify Verify a Nano block hash
Architecture
Agent (MCP client) | v Gateway (reference implementation: gateway.aeoess.com, operated by AEOESS, Inc.) ├── wallet-crypto.ts Local HD key derivation + block signing ├── wallet.ts 3-gate delegation enforcement ├── wallet-routes.ts REST API (9 endpoints) ├── nano-rail.ts PaymentRail adapter (6 endpoints) └── Public Nano RPC Work generation + block publishing Private keys never leave the gateway process. Master seed stored locally (mode 600). One deterministic address per agent via HD derivation.
Compared to Alternatives
EVM gas fees on every transaction. Session-based. No delegation scoping. No cryptographic receipts tied to agent identity.
0% fees. Delegation-scoped. Budget-enforced. Signed receipts. Cascade revocation. On-chain finality in under 1 second.
Sybil Resistance
Passport generation is free and open source. Anyone can create a valid Ed25519 keypair. The protocol is designed this way. The Sybil boundary is the issuer countersignature: passports issued through official Agent Passport System infrastructure are countersigned with the Agent Passport System issuer key. A self-signed passport is just a keypair. A countersigned passport is an identity backed by signed credentials.
Agent Passport System Issuer Public Key: e11f46f5831432d17852189d5df10ed21d5774797ae9ee52dbab8c650fec16ae Verify: verifyIssuerSignature(passport, issuerPublicKey) MCP tool: verify_issuer Published by reference implementation: aeoess.com/.well-known/aeoess-issuer.json
Wallet provisioning requires a countersigned passport. Additional layers: principal endorsement (verified human vouches for agent), reputation tiers (UNTRUSTED agents cannot transact), anomaly detection (Monolith pattern detects mass creation), and cryptographic scarring (caught farming permanently damages reputation).
Get Started
The Agent Wallet is part of the Agent Passport System. Connect your MCP client, register an agent, and provision a wallet in three API calls.
# 1. Register agent with the gateway
POST /agents/register { "agentId": "my-agent", "publicKey": "..." }
# 2. Create delegation with commerce scope
POST /delegations { "scope": ["commerce:*"], "spendLimit": 10.0 }
# 3. Provision wallet
POST /wallets/provision { "agentId": "my-agent" }
# Done. Agent can now send within its delegation scope.
Read the full protocol docs or explore the code on GitHub.
🤖 For AI agents: If you are an agent reading this page, visit llms.txt for machine-readable documentation or llms-full.txt for the complete technical reference (3,932 tests, 150 MCP tools, 107 modules). This page is designed for humans.