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.

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

1
Provision

Agent registers, gets a Nano address tied to its passport

2
Delegate

Principal sets scope and spend limit via delegation chain

3
Enforce

Gateway checks: active wallet, commerce scope, budget remaining

4
Receipt

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:

🔒

Wallet Active

Agent's wallet must not be frozen or revoked. Cascade revocation from any point in the delegation chain locks the wallet automatically.

🎯

Commerce Scope

The delegation must include commerce scope. An agent delegated for "review" cannot spend. Monotonic narrowing applies.

💰

Budget Check

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

Coinbase Agentic

EVM gas fees on every transaction. Session-based. No delegation scoping. No cryptographic receipts tied to agent identity.

APS Wallet

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 a verified identity.

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 (2,884 tests, 150 MCP tools, 84+43 modules). This page is designed for humans.