Skip to main content
The second step in the auth flow. Submit your wallet, the base58 Ed25519 signature of the challenge, and the challenge itself. The gateway verifies the signature and, if you’ve deposited SOL to the gateway wallet, returns your API key exactly once. Store it immediately, it cannot be retrieved again. Public endpoint, no existing key required.

Why agents use this

  • Wallet address IS the identity. No user table, no email verification. Your pubkey is your account.
  • One-shot key delivery. The pending record is deleted the moment the key is issued. Signature can’t be reused.
  • Requires prior SOL deposit. Payment happens before the key exists. There’s no free-trial abuse surface.
  • Deterministic identity. Same wallet always maps to the same account. Re-claiming after a loss requires wallet control.

Use cases

  • Web onboarding flow. After the Phantom popup, POST here, store the returned apiKey in the user’s browser and never show it again.
  • Autonomous agent bootstrap. Agent funds its own wallet, calls challenge + claim, writes the key to its own secrets store.
  • Team-key provisioning script. Ops runs a script that funds a service wallet, claims a key, injects into k8s secrets.
  • Key rotation for compromised agents. Detect leak, deposit new SOL, re-run challenge + claim from a fresh wallet, decommission the old one.
  • CLI setup. mint-solana-key command runs the flow interactively and writes the key to ~/.solana-gateway/config.

Recipe: Node.js claim script

claim-key.ts
The key is returned once. If you lose it, you’ll need to fund a new wallet and repeat the challenge + claim flow with fresh SOL. Store it securely on first receipt.
You must deposit at least the credit threshold to the gateway wallet Brpc8HoPo1d3Uiyo7kbERnjMqwLJJmbWxtwxHxzar6DU before calling claim, otherwise you’ll get a 404.