Authentication
Store tokens securely
Store tokens securely
Store JWT tokens in environment variables or a secrets manager. Never commit tokens to source control or include them in log output.
Refresh tokens before expiry
Refresh tokens before expiry
Proactively refresh your token before it expires to avoid mid-operation failures.
Handle 401 responses gracefully
Handle 401 responses gracefully
Watch for unauthorized responses and re-authenticate automatically rather than surfacing errors to users.
Transactions
Always use idempotency keys
Always use idempotency keys
Include
Idempotency-Key headers on all financial operations — transfers, trades, and liquidity operations.Check balances before operating
Check balances before operating
Verify sufficient funds are available before attempting transfers to avoid unnecessary
400 errors.Use appropriate slippage for trades
Use appropriate slippage for trades
Set slippage tolerance based on the liquidity profile of the token pair.
| Pair type | Recommended slippage (bps) |
|---|---|
| Stable pairs | 10–30 |
| Major tokens | 50–100 |
| Volatile tokens | 100–300 |
Verify recipient addresses
Verify recipient addresses
Validate recipient addresses before sending funds. For high-value agents, use a recipient whitelist in your policy.
Policy management
Start conservative
Begin with low limits (500 daily) and increase them only as you understand your agent’s actual needs.
Use recipient whitelists
For high-value agents, configure
allowedRecipients to restrict which addresses can receive funds.Disable unused features
Turn off trading, liquidity provision, or prediction markets if your agent doesn’t use them — this reduces your attack surface.
Monitor spending patterns
Track daily spending via audit logs before raising limits. Understand normal usage before expanding permissions.
Error handling
Implement exponential backoff for 429 and 503
Implement exponential backoff for 429 and 503
When you hit rate limits or temporary service errors, wait progressively longer between retries.
Do not retry 4xx errors without fixing the cause
Do not retry 4xx errors without fixing the cause
4xx errors indicate a problem with your request — a bad parameter, a policy violation, or an expired token. Fix the underlying issue before retrying.The exception is
401: you can re-authenticate and retry. For all other 4xx errors, inspect the message field to understand what needs to change.Generate a new idempotency key when retrying errors
Generate a new idempotency key when retrying errors
Never reuse an idempotency key after receiving an error response. The cached error will be returned again.
Log all errors with context
Log all errors with context
Maintain detailed error logs for debugging and monitoring.
Verify on-chain when uncertain
Verify on-chain when uncertain
If you’re unsure whether a transaction succeeded, check the Solana chain directly rather than assuming success or failure.
Skill discovery
Fetch skill.md at agent startup
Fetch skill.md at agent startup
Load the capability spec when your agent initializes so it has accurate API knowledge before making calls.
Cache and refresh periodically
Cache and refresh periodically
Cache
skill.md locally to reduce API calls, but re-fetch it daily or weekly to pick up new endpoints and features.