Private Key Security - SEND Docs

Where Your Keys Are Generated

When you create a wallet, the keypair is generated on SEND servers, not in your browser. The private key is encrypted before it is stored, and it is never sent to the client -- no key material exists in the browser at any point.

This is a custodial arrangement, stated plainly: SEND holds your trading keys and signs transactions on your behalf.

How Keys Are Encrypted at Rest

Each private key is encrypted with AES-256-GCM under a key derived specifically for your account. Because that derivation is per account, one account's wallet ciphertext cannot be decrypted under another account's key.

Cipher: AES-256-GCM, an authenticated cipher -- tampered ciphertext fails to decrypt rather than yielding garbage
Key derivation: HKDF-SHA256 over a server-held master key, using your user ID as the derivation input, producing a distinct 32-byte key per account
Nonce: 12 random bytes drawn fresh for every single encryption, never reused across wallets
Stored per wallet: the ciphertext and its nonce. The plaintext key is never written anywhere

Who Can Use a Key

Every operation that needs to sign resolves the key through a single path, and that path checks ownership before it decrypts. A request naming a wallet you do not own is rejected with 403 and never reaches the decryption step.

Administrative API responses are structurally barred from carrying key material: the response types that describe wallets cannot expose the encrypted key or its nonce, and that constraint is asserted by test.

SEND's servers can decrypt your wallet keys -- that is how your transactions get signed. Anyone holding both the server master key and database access could do the same. Your account credentials, not a seed phrase, are what stand between an attacker and your funds.

Private Keys Cannot Be Exported

There is no way to take a private key out of SEND. Key export is deliberately unimplemented and responds with 501 Not Implemented -- secure key export has not been built.

Plan around this. A SEND wallet is reachable only through your SEND account -- there is no offline copy to fall back on, and there is no self-service account recovery, so losing account access means losing the ability to move those funds.

You cannot download, display, or copy a wallet private key
Fund a SEND wallet by sending SOL to its address
Move value out by withdrawing to an address you control

Creating Wallets

Wallets are created from the Wallets area, either one at a time or as a batch when you create a wallet set. Batch generation reports progress over the live feed as each wallet completes, rather than blocking until the whole batch is done.

Batch wallet generation is a heavy-write endpoint, capped at 5 requests per minute. That is 5 batch calls, not 5 wallets -- but a script firing batches back to back will start receiving 429 responses.

What This Means in Practice

Custody means the controls that protect your account are the controls that protect your funds. In order of impact:

Enable two-factor authentication -- it is the strongest control you have over key access
Use a password unique to SEND; credential reuse is the realistic attack path
Revoke API keys you are not actively using, since a key is full account access
Withdraw balances you are not actively trading to an address whose keys you hold yourself