ez-wallet: programmatic Solana wallet creation

ez-wallet is a wallet creation API. The product does one mechanical thing: it accepts an HTTP POST and returns a freshly generated Solana wallet, with optional bells (BIP39 mnemonic, HD derivation, HSM custody) attached. It is not a wallet frontend, it is not a custodian for end-user balances in the consumer sense, it is not a competitor to Phantom or Solflare or Backpack. It sits one layer below those.

The job it solves is unglamorous and surprisingly common. A CEX needs to mint a unique deposit address per user; that's a wallet creation event per signup. An airdrop campaign needs ten thousand fresh addresses to fund a snapshot drop; that's a batch generation. A custody product wants to give every institutional client an HD wallet hierarchy with a master rooted in an HSM; that's SLIP-0010 derivation under a managed key. These are all mechanically different requests but they share a pattern: nobody wants to write the keygen plumbing.

We wrote it. The keygen runs on AVX2-accelerated ed25519 implementations, the BIP39 entropy comes from a kernel getrandom() that we audit twice a year, the HD code follows SLIP-0010 to the byte, and the optional managed-custody mode stores secrets in AWS KMS HSMs at FIPS 140-2 Level 3. The resulting wallets are indistinguishable from anything Phantom generates, because they are the same bytes generated the same way.

What that buys you, on top of just rolling your own ed25519: 12,000 wallets per second sustained, batched JSONL streaming for million-record onboarding lists, signing as a managed service if you don't want to handle keys, and an audit trail for every operation that auditors and compliance teams like to see.

If your application creates more than a few wallets a week, ez-wallet is probably the right answer. The four patterns we see most:

Two patterns we explicitly don't recommend ez-wallet for: single-user personal wallets (use Phantom) and end-user-facing embedded wallet UX (use Privy or Magic, which include the login and recovery flows we don't).

The hardest question in any wallet API is “who holds the key.” ez-wallet supports two answers, you pick per-call.

custody=client (default). The API generates the keypair, returns the secret key in the response body, and immediately drops it from memory. We never persist it. We don't log it. The TLS response is the only place it ever existed on our side. If you want to verify, the Rust code sample on this page round-trips the secret to a public key and checks against the address we claimed; do that in CI on every release if your auditors care. This is the right mode when your application owns the wallet and stores keys in your own KMS.

custody=managed. The API generates the keypair, the secret key goes directly into AWS KMS using a FIPS 140-2 Level 3 HSM, and we return only an opaque wallet_id. To sign with that wallet, you call POST /v1/wallets/{id}/sign with the message bytes; we authenticate the request against your account, ask KMS to sign without ever pulling the key into our process, and return the signature. Plaintext private keys never exist outside the HSM, never appear in logs, and survive employee access reviews because nobody has the box that holds them. This is the right mode for CEX deposit wallets, custody products, and anywhere your security team would otherwise ask you to write a key-storage service from scratch.

For BIP39 mnemonic generation, the entropy source is the kernel's getrandom() pulling from a CSPRNG seeded by hardware RNG (RDSEED on AMD EPYC). We don't use any userspace PRNG for key material. The audit firm that reviewed this last is Trail of Bits; we share the report under NDA on request. If you find a weakness in the entropy chain, we have a $25,000 bug bounty for keygen-affecting issues.

The full API is six endpoints. Most teams use two of them.

Authentication is a bearer token in the Authorization header. Rate limits default to 1000 requests/minute on the create endpoints (the batch endpoint counts as one request regardless of size); we lift those on request for production accounts. The OpenAPI spec lives at api.nolimitnodes.com/v1/openapi.json and the SDK packages are @nolimitnodes/ez-wallet for Node and nolimitnodes-ez-wallet for Python.

Errors follow the standard HTTP convention plus a stable error-code field; an exhaustive list is in the docs. The two you'll hit in practice: 429 when you cross the rate limit (back off and retry, the Retry-After header is accurate), and 402 if your account hits its prepaid balance (top up via the dashboard or move to invoiced billing).

Three numbers make up the bill. Wallet creation, HD derivation, and managed signing.

A worked example. A mid-size CEX onboarding 50,000 users a month, using HD derivation under a custody master, with each user receiving roughly 10 deposit signatures a month. That's 50k * $0.0005 + 500k * $0.0001 = $75/month. The custody side is essentially free at that scale; what matters more is the downstream wallet-transfers stream for deposit detection.

For airdrop campaigns the math is simpler: count the wallets, multiply by the per-wallet rate. A million-wallet airdrop is $1,000 at standard rate, $400 at the volume tier. We invoice monthly above $1,000/month; smaller accounts run on prepaid balance via Stripe. Get an API key from the pricing page.