4. Send from a wallet

curl -s $BASE/dashboard/partner/wallet_keys \
  -H "Content-Type: application/json" \
  -d '{"recovery_key": "ed25519:...", "primary_signing_key": "ed25519:..."}' | jq .

We never ask for, accept, or store a private key, and the two must differ. Registration happens once: re-pointing an identity would leave every existing wallet derived from the old one, so a second attempt returns 409 keys_already_registered.

The response includes an activation object carrying the envelope for the next step.

Registering turns wallet creation on. Sending needs one on-chain step that only your Recovery Key can authorize.

Rebuild the activation delegate from your own inputs and confirm that installing_primary_signing_key is your key and that the digest matches your rebuild. Then sign the digest raw with the Recovery Key and return it:

curl -s $BASE/dashboard/partner/wallet_keys/activation/authorize \
  -H "Content-Type: application/json" \
  -d '{"delegate": "<the base64 you verified>", "signature": "<base64>"}' | jq .

The full procedure is in the Signing Guide. On success, sending is enabled for every wallet you will ever create, and the ceremony never repeats.

Until it completes, wallet creation and deposits work normally, and creating a send returns 400 activation_required.

curl -s $BASE/api/customers/cus_.../wallets \
  -H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"chain": "solana", "name": "Operating wallet",
       "partner_reference_id": "wallet-4471"}' | jq .

{
  "id": "wal_0K3y2GhUPnpX0X3kBvTwRy",
  "object": "wallet",
  "customer_id": "cus_033y1FhTOmoW9W2jAuSvQx",
  "chain": "solana",
  "address_wallet_id": null,
  "address": "3Nq8vT7YbCk1RjvFhcHc3mYwBSy8PmZ6LcQ5tXhr9Aur",
  "status": "active",
  "custody": "non_custodial",
  "signing_reference": "wallet/wal_0K3y2GhUPnpX0X3kBvTwRy/solana",
  "name": "Operating wallet",
  "partner_reference_id": "wallet-4471",
  "created_at": "2026-08-26T09:40:00+00:00"
}

Store signing_reference now. It is immutable, and your verifier compares against it on every send. Storing it at creation is what makes the comparison meaningful: a value you read back later came from the same platform you are verifying.

Creation is instant and involves no third party. The address is derived arithmetic, so there is nothing that could fail or lag.

curl -s $BASE/api/sandbox/simulate/wallet_deposit \
  -H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"wallet_id": "wal_...", "asset": "usdc", "amount": "500.00"}' | jq .

In production nobody calls an endpoint to fund a wallet: someone sends to its address, and wallet.deposit_received tells you it landed. Read the balance back, which is a chain read, not a ledger:

curl -s $BASE/api/wallets/wal_... -H "Api-Key: $KEY" | jq '.balances'

curl -s $BASE/api/wallets/wal_.../operations \
  -H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"asset": "usdc", "amount": "250.00",
       "to_address": "5HSqKCN2eoHWe7p36GeUftEL9XnT6MbsvrxHgwgpYWQf"}' | jq .

Nothing moves. The response is an operation in status authorization_required carrying two siblings: an authorization object (what to verify) and a signing envelope (what to sign, once verification passes). The chain is the wallet's, never a parameter.

The clock starts now. You have 30 seconds.

Rebuild the transaction from inputs you already trust, and require byte equality before your key touches anything:

1. Decode authorization.solana.message_base64 and require it to be exactly one TransferChecked for your amount, to your recipient, on your mint, optionally preceded by one create-account instruction. Not "check the important fields": require the whole message to be one of the two legitimate shapes.
2. Rebuild the delegate from your identity, your registered signing key, the signing_reference you stored at creation, and the constants published in the Signing Guide.
3. Require the canonical hash of your rebuild to equal signing.digest.
4. Only then sign that digest, raw, with the Primary Signing Key.

curl -s $BASE/api/wallets/wal_.../operations/wop_.../authorize \
  -H "Api-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"signature": "<base64 raw 64-byte ed25519>"}' | jq .

The full procedure, with the constants to pin and the libraries to use, is the Signing Guide. It is the page to read properly before you write this code.

wallet.operation_confirmed fires with the tx_hash, or wallet.operation_failed if it did not land. Or poll:

curl -s $BASE/api/wallets/wal_.../operations/wop_... -H "Api-Key: $KEY" | jq '.status'