The wallet for AI agents.
Stripe Link gave 200 million humans a one-click wallet. Hyperspace Wallet gives every AI agent — Hermes, OpenClaw, ChatGPT, custom enterprise — a portable identity (did:hyperspace:), a multi-rail wallet, on-chain reputation, and one line of code to pay any counterparty across five payment rails.
block + agent count read live from rpc.a1.hyper.space when JS is enabled
Stripe Link gives 200 million humans a wallet. Hyperspace Wallet gives every agent its own identity, its own keys, and one API across every payment rail.
One wallet.pay(). Five rails. The SDK quotes each, picks cheapest, falls through on failure. Every receipt has the same shape.
The full pipeline runs end-to-end on the live a1 testnet today. Verified at block 14210, chain id 808080.
Use both. Stripe Link wins humans paying merchants. Hyperspace Wallet gives the agent its own identity, its own keys, its own reputation, and one API across every payment rail — including Stripe ACP itself.
contents
why this exists
An AI agent that wants to pay another agent — for inference, data, an API call, a tool invocation, a checkout — has nowhere to go. Today it has to:
- Sign up to each merchant or counterparty with a human's email and credit card
- Or hard-code a custodial private key and hope nothing leaks
- Pick one payment rail (ACP or x402 or AP2 or Tempo MPP) and live with it
- Reinvent identity, reputation, idempotency, receipt verification, and dispute handling itself
Stripe knows this. Per their March 2026 announcement, agentic commerce is the next $350B+ TAM. They shipped four primitives (Link, ACP, SPT, MPP) and explicitly said they assume "the agent already exists and has authority." Google's AP2 is a trust framework for agent mandates. Coinbase's x402 is a peer-to-peer USDC settlement protocol. Each rail solves part of the problem. None of them issue an agent identity.
our claim
Hyperspace Wallet is the missing layer. The SDK gives every agent one identity (did:hyperspace:), one wallet that speaks every rail, one receipt format portable across rails, one policy engine for spend caps and counterparty whitelists, and one rating call to build reputation on a public chain. The SDK is MIT-licensed and free. We earn 5–15% on transactions routed through it.
what you get
Portable identity
did:hyperspace: resolves on-chain. Ed25519 for receipts, secp256k1 for chain transactions, both derived from one 32-byte seed.
Multi-rail pay()
One method, five rails — native HSPACE channels, Coinbase x402, Stripe ACP, Google AP2, Stripe MPP. Smart routing picks cheapest.
Spend policy
Declarative caps, reputation thresholds, allow/deny lists, capability requirements, custom guards. Wallet-level + per-call.
Idempotency
Persistent (key → request hash → receipt) cache. Replays return cached receipts. Conflicts throw IdempotencyConflictError.
Unified receipts
Schema-versioned envelope wraps rail-specific cryptographic proofs. Verifiable forever, portable across systems.
On-chain reputation
wallet.rate(receipt, did, rating) writes 1-5 stars + sub-ratings to ReputationRegistry. Discovery filters by score.
quickstart — sixty seconds
TypeScript / Node
Python
CLI
did:hyperspace: — agent identity
Every agent gets a W3C-compliant Decentralized Identifier the moment Wallet.init() runs. Format:
The agent-id is sha256(ed25519PublicKey || ":" || agentName) — deterministic, so restoring from a 24-word BIP-39 mnemonic produces the same DID. Two keys are derived from one master seed via independent HKDF chains:
The DID Document carries both verification methods (Ed25519VerificationKey2020 + EcdsaSecp256k1RecoveryMethod2020), resolves to the on-chain AgentRegistry, and ships with a Hyperspace-specific extension carrying chainId, agentId, and the EVM address.
One 32-byte seed → independent HKDF chains → Ed25519 (for receipts) and secp256k1 (for chain). Lose either, the other is still safe.
spec
Full did:hyperspace: method specification: DID_SPEC.md — operations (Create / Resolve / Update / Deactivate), W3C conformance matrix, example DID Document.
five payment rails — one pay() call
The SDK ships an adapter for every major agent payment rail. wallet.pay() picks the cheapest available rail by quote; you can force one with rail: 'native' or restrict the set with policy.allowedRails.
| rail | backed by | typical use | latency | SDK take rate |
|---|---|---|---|---|
| native | Hyperspace PaymentChannel, off-chain | HSPACE micropayments, sub-cent | ~50ms | 3% |
| x402 | Coinbase HTTP-402, USDC on Base/ETH/Polygon/Arbitrum/Optimism | peer-to-peer, no intermediary | ~80ms | 5% |
| acp | Stripe Agentic Commerce Protocol | checkout against Stripe-connected merchants | ~1.2s | 2% over Stripe |
| ap2 | Google Agents-to-Payments mandates | card / USDC / PayPal via VC mandate | ~1.5s | 3% over rail |
| mpp | Stripe Machine Payments Protocol on Tempo | session-based streaming micropayments | ~200ms | 3% over rail |
Smart routing
By default selectRail() tries adapters in this order: native → x402 → acp → mpp → ap2. Each adapter quotes { totalCostMicroUsdc, estimatedLatencyMs }, the cheapest wins; on failure the SDK falls through to the next rail in the order. Counterparties advertise which rails they accept via the PayChallenge.acceptedRails field.
stripe + coinbase, in the SDK today
The Stripe ACP adapter calls api.stripe.com/v1/payment_intents with Stripe-Agentic-Commerce: true and either an sk_live_... or a Shared Payment Token issued via the consent flow. The Coinbase x402 adapter signs an EIP-712 PaymentReceipt and adds it as the X-Payment header on outbound HTTPS calls; the included X402Server verifies replay-protected receipts on the receive side. Both adapters are real REST/HTTP clients — no stubs.
Smart routing quotes every available adapter, picks the cheapest by total cost + latency, falls through on failure. The agent never has to pick a rail by hand.
unified receipt envelope
Every pay() returns a Receipt of the same shape, regardless of rail. The rail-specific cryptographic proof lives in receipt.proof as a discriminated union — verifiable forever by anyone who has the SDK.
For the x402 rail, proof is an EIP-712 signature recoverable to fromAddress. For native channels, it's a per-update Ed25519 signature over (channelId, totalAmount, nonce). For ACP, it's a Stripe PaymentIntent id queryable against the Stripe API. For AP2, it's the embedded mandate VC + the network reference. For MPP, it's a Tempo tx hash + sequence number.
Verification is one method call:
Same outer shape every time. The proof is rail-specific (EIP-712 / Ed25519 channel sig / Stripe id / VC mandate / Tempo tx) but the receipt itself is portable forever.
spend policy — declarative authority
The policy engine evaluates every pay() before it touches the network. Wallet-level policies set the trust envelope; per-call withPolicy overrides can only narrow that envelope further (never widen).
If a policy denies, PolicyDeniedError is thrown with the specific rule that triggered (err.rule === 'perTxCap' | 'dailyCap' | 'minCounterpartyReputation'...) so the agent can choose to retry, ask the user, or fail.
Spend history persists at ~/.hyperspace/wallet-sdk/spend-history/<did>.jsonl so caps work across restarts.
Declarative authority. Wallet-level + per-call. Per-call only narrows — never widens — so a misbehaving subroutine can't escalate spend.
discovery + reputation
An agent that needs a service finds counterparties via wallet.discover(), then pays the best-ranked one. Ratings flow back to the on-chain ReputationRegistry via wallet.rate().
Reputation is the moat. Once an agent has 10K transactions and a 4.8 rating on did:hyperspace:, the cost of moving to a competing rail (lose reputation, start over from zero) is high. ENS captured Ethereum names this way.
Tied to receipts, not free-form. Slashable on dispute. Lock-in compounds with every transaction — the ENS pattern, applied to agents.
architecture
The SDK is one Wallet class composing six modules. The agent app imports it; everything else is internal.
arch — 6 internal modules · 5 rail adapters · multi-RPC failover · pluggable storage
One Wallet class. Six internal modules. Five adapters. Same shape from CLI, from a framework recipe, or from raw code.
live a1 testnet
The SDK ships with the canonical Hyperspace a1 chain id 808080 as default and resolves rpc.a1.hyper.space:8545 for JSON-RPC. Production validators run Narwhal-Tusk DAG BFT consensus across 7 DigitalOcean droplets.
Deployed contracts
| contract | address | purpose |
|---|---|---|
| AgentRegistry | 0xEa3d307678bb3dEcbB239176f42ff12AcE92d93E | identity, staking, revenue |
| PaymentChannel | 0xdAc91f0e11Be05E33dAE82AD30a2E53d58Df1971 | off-chain HSPACE channels |
| ReputationRegistry | 0x42C0F15bF0dBF101d623142e7fBbBf6f9cfF7b90 | scores, ratings, slashing |
| PaymentFacilitator | 0x237732AE105b7891fd2B6a30333585ECCDb5a055 | HTTP-402 settlement |
| MarketplaceEscrow | 0x57C6488B1b99329c50BFaa3fE0A945e151EdE8bd | service-completion escrow |
| WrappedUSDC | 0xEaE0b38B7F800a1B81942A38015F7Dd769AC1c41 | bridged USDC |
| Woppal (WOPPAL) | 0x6b3380AE2D061bC4eAe2B7c3Be9176917DE8F141 | experiment-adoption micropayments |
All addresses verified live at block 14210 on 2026-04-29 (deploy manifest: a1-blockchain-hyperspace/contracts/deployments/hyperspace-do-prod.json). Override any of them via HYPERSPACE_AGENT_REGISTRY_ADDRESS, HYPERSPACE_PAYMENT_CHANNEL_ADDRESS, etc., or in WalletConfig.addresses.
end-to-end live
The full agent → wallet → chain → settlement flow works on the live testnet today. Verified in scripts/e2e-register.mjs: SDK creates a DID, signs a tx via the public RPC hostname, validators mine it within 3 blocks, the SDK reads it back via eth_call. totalRegistered increments. No IPs in the user-facing path.
stripe ACP — agentic commerce
Stripe's Agentic Commerce Protocol is implemented as a real REST client in src/adapters/acp/index.ts. The adapter authenticates via a Stripe API key (sk_live_... / sk_test_...) for development, or a Shared Payment Token issued via the user's ACP consent flow for production.
The SDK posts to /v1/payment_intents with the Stripe-Agentic-Commerce: true header, on_behalf_of set to the merchant's connected account, and an idempotency key to prevent double-spends. verifyReceipt() queries /v1/payment_intents/{id} to confirm async settlement.
SDK take rate over Stripe: 2% via application_fee_amount. Net merchant cost ~4.9% + $0.30 (2.9% + $0.30 Stripe + 2% Hyperspace).
Stripe ACP and Coinbase x402 are real REST clients in the SDK — no stubs. Same Receipt envelope wraps either rail's proof.
coinbase x402 — peer-to-peer USDC
x402 is a peer-to-peer protocol — no platform credentials needed. The SDK ships both sides: X402Adapter for the consumer, X402Server for the receiver.
Consumer — pay any 402 server
Receiver — paywall any HTTP endpoint
The server verifies receipt freshness, payee match, EIP-712 signature recovery, signer/payer cross-check, and replay (per-receipt-id dedupe with TTL pruning). All in-memory; zero deps beyond ethers v6.
cli — hyperspace-wallet
| command | does |
|---|---|
| init <name> | create identity, persist seed, print 24-word recovery |
| show | print did, EVM address, ed25519 pubkey, balance |
| pay <to> <amount> | make a payment with smart routing or forced rail |
| discover <capability> | search counterparties on the catalog API |
| policy [--per-tx --daily ...] | view or set spend caps |
| session create <cap> <ttl> | scoped delegation key |
| session list | list active sessions with remaining caps |
| recover <name> | restore from 24-word mnemonic (stdin) |
| register --tier 0|1|2|3 | register on-chain via AgentRegistry |
framework recipes
The SDK is framework-agnostic. Drop-in wrappers ship for the five most common agent stacks:
LangChain
DynamicStructuredTool wrapping discover + pay. The agent uses pay() as a tool when its plan requires purchasing data or calling a paid API.
CrewAI (Python)
@tool-decorated wallet methods. Each crew member can have its own session key with independent spend caps.
Hermes
Wallet provisioned at agent boot. Direct pay() on tool invocation. Receipts cached to the agent's memory.
OpenClaw
Wallet plugin in the OpenClaw skill-pack format. Skills can declare a priceMicroUsdc and the SDK auto-handles 402.
Eliza
Crypto-native framework integration. Wallet derives from the agent's existing key material — no new keys to manage.
Anthropic / OpenAI
Use the Wallet for outbound payments from a managed agent. The SDK doesn't replace the agent host — it complements it.
Recipes: examples/ in the SDK source tree.
pricing & take rate
The SDK is MIT-licensed and free. No API key, no install gate, no rate limit. We earn on transactions routed through it.
| transaction class | take | rationale |
|---|---|---|
| native HSPACE channels | 3% | our rail; sub-cent fees; zero counterparty cost |
| x402 USDC (Coinbase) | 5% | commodity micropayments; high volume |
| ACP (Stripe checkout) | 2% over Stripe | identity + policy + reputation premium |
| AP2 mandates (Google / Mastercard) | 3% over rail | trust framework adapter |
| MPP (Stripe / Tempo sessions) | 3% over rail | streaming micropayment adapter |
| Skill marketplace listings | 15% | App Store comp; bundles discovery + reputation + dispute |
| cross-rail smart routing | +1% | premium feature on Expert tier |
Headline blended rate: ~10%. Volume discounts kick in at $10M annual GMV (-20%); custom revshare at $100M+.
Free thresholds
- First $1,000 of GMV per agent identity: 0% take (encourages onboarding).
- Hobbyist tier: agents under $50/month total GMV: 0%.
- Open-source projects: apply for waiver via the GitHub repo.
live demo — generate an agent identity
Click the button. Your browser will generate a fresh Ed25519 + secp256k1 keypair, derive the did:hyperspace:, and show the recovery mnemonic. This is purely client-side — keys never leave your browser, never hit our servers.
demo only
This demo creates the keypair using browser crypto.subtle. Real agents use storage: 'tee' or 'keychain' for hardware-backed storage. Don't put real money behind keys generated in a browser tab.
vs. the alternatives
| Stripe Link | Apple Pay | custodial wallets | Hyperspace Wallet | |
|---|---|---|---|---|
| customer | humans | humans | humans / agents | agents |
| identity | email + card | device | vendor account | cryptographic DID |
| payment rails | Stripe only | card networks | vendor-bound | 5 rails, smart routing |
| cross-merchant reputation | — | — | — | on-chain, portable |
| spend policy engine | limited | device PIN | vendor UI | declarative, in code |
| self-custody | — | device-bound | — | yes (TEE / passkey) |
| open-source SDK | partially | — | — | MIT-licensed |
We don't compete with Stripe Link — we use it. The ACP adapter is one of five rails. We sit above the payment processors, not against them.
sdks & types
TypeScript / Node
Package: @hyperspace/wallet-sdk · 44 source files · 18 test files · 161 tests passing · 144 KB tarball · MIT.
| module | exports |
|---|---|
| @hyperspace/wallet-sdk | Wallet, errors, types, version |
| /identity | IdentityManager, KeyStore variants, DID functions, Sessions |
| /payments | SpendHistory, IdempotencyStore, evaluatePolicy, selectRail, build/verifyReceipt |
| /reputation | ReputationModule (read scores, submit ratings, discover, dispute) |
| /chain | ChainClient, MultiRpcProvider, contract clients, A1_* constants |
| /adapters/native | x402 | acp | ap2 | mpp | per-rail adapter classes + config types |
Python
Package: hyperspace-wallet · 34 source files · 4 test files · 36 tests passing · MIT · Python ≥ 3.10.
Same API surface as TS, idiomatic Python (snake_case, dataclasses, async). Receipt JSON wire format is identical: same DID, same fields, same proofs.
faq
Is the SDK free?
Yes. MIT-licensed, no install gate, no API key required. We earn on transactions (5–15% take rate by class — see pricing).
Do I need to run a Hyperspace node?
No. The SDK reads/writes the chain via rpc.a1.hyper.space. Operators who want their own RPC pass rpcUrl in WalletConfig.
Can I use Stripe Connect with this?
Yes. The ACP adapter is a real Stripe REST client. Either pass apiKey (your platform's sk_...) or a Shared Payment Token issued via the user's consent flow.
Is this custodial?
No. Master seed never leaves the keystore. All signatures are local. The SDK doesn't have a server-side; everything runs in your process.
What happens if the chain is down?
The SDK's MultiRpcProvider retries across all configured endpoints with per-endpoint health tracking. Off-chain receipts (x402, ACP) work even with the chain unreachable — they only depend on the rail provider's API.
Does it work in browsers?
Core types and the demo above run in browsers. Full Wallet ships node:fs in the keystore — a browser-friendly entry with IndexedDB-backed storage ships in 0.2.0. The current alpha is Node-only.
How is reputation prevented from being gamed?
On-chain ReputationRegistry requires staking to register; slashing for misbehavior is built in. Ratings are tied to receipts (you can't rate without a payment record). Anti-Sybil via stake.
When mainnet?
The current chain is testnet (chain id 808080). Mainnet plan ships when contracts pass external audit and the dispute infrastructure is in place. Roadmap below.
roadmap
- 5 rail adapters, on-chain reads, MIT-licensed
- Live a1 testnet, 198 tests passing across TS + Python
- npm + PyPI publish workflows in CI
- Browser-native entry — IndexedDB key store, WebCrypto AES-GCM
- Passkey + WebAuthn-backed signing
- Vite + ES modules CDN bundle
- Ledger / Trezor hardware-wallet signing
- True TEE/Secure Enclave on macOS + Linux + Windows
- L2 support: Base, Arbitrum, Optimism, Polygon
- Cross-chain DID resolution
- Full dispute resolution flow with on-chain attestations
- 5-of-9 multisig oracle
- External audit complete
- Mainnet launch
- Production SLA
changelog
- Live a1 testnet contracts deployed (AgentRegistry, PaymentChannel, ReputationRegistry, PaymentFacilitator, MarketplaceEscrow, WrappedUSDC). Full agent → wallet → chain → settlement loop verified live.
- Hostname-first defaults — rpc.a1.hyper.space, no validator IPs in the public tarball. Operator opt-in via HYPERSPACE_RPC_USE_FALLBACK_IPS=1.
- Multi-RPC failover with per-endpoint health tracking, batchMaxCount: 1 for chain compatibility.
- Default 1-gwei gas-price plumbed through every write (chain validators reject below 1 gwei).
- First public alpha. Full Wallet class, did:hyperspace: identity, 5 rail adapters, spend policy engine, idempotency cache, unified receipt envelope, on-chain reputation reads, CLI, examples for LangChain/OpenClaw/CrewAI/Eliza/Hermes.
- 198 tests passing across TypeScript + Python.