Portfolio and treasury operations
Read balances across every wallet type from one endpoint, then send, swap, and import keys safely.
An org accumulates wallets in three different shapes: treasury wallets, agent signing keys, and imported smart accounts. The Portfolio API aggregates all of them behind a single call.
- 1
Get the whole portfolio, with token balances and USD estimates.
bashcurl -s "https://api.1claw.co/v1/portfolio?chains=ethereum,solana&include_tokens=true" \ -H "Authorization: Bearer $ONECLAW_TOKEN" # or: 1claw portfolio - 2
Generate native treasury wallets. Six chains are supported: Ethereum, Bitcoin, Solana, XRP, Cardano, Tron.
bashcurl -s -X POST https://api.1claw.co/v1/treasury/wallets/generate \ -H "Authorization: Bearer $ONECLAW_TOKEN" \ -H "Content-Type: application/json" \ -d '{"chains":["ethereum","solana"]}' - 3
Send from a treasury wallet. Non-EVM chains take chain-specific fields: a destination_tag for XRP, a fee rate for Bitcoin, a memo for Solana.
bashcurl -s -X POST https://api.1claw.co/v1/treasury/wallets/ethereum/send \ -H "Authorization: Bearer $ONECLAW_TOKEN" \ -H "X-Auth-Confirm: $REAUTH_TOKEN" \ -d '{"to":"0xabc...","amount":"0.01"}' - 4
Send gaslessly by wrapping it as an ERC-4337 UserOperation with paymaster sponsorship.
bashcurl -s -X POST https://api.1claw.co/v1/treasury/wallets/ethereum/send \ -H "Authorization: Bearer $ONECLAW_TOKEN" \ -H "X-Auth-Confirm: $REAUTH_TOKEN" \ -d '{"to":"0xabc...","amount":"0.01","gasless":true}' - 5
Bring your own key. Import is human-only and requires password re-auth.
bashcurl -s -X POST https://api.1claw.co/v1/treasury/wallets/ethereum/import \ -H "Authorization: Bearer $ONECLAW_TOKEN" \ -H "X-Auth-Confirm: $REAUTH_TOKEN" \ -d '{"private_key":"0x...","format":"hex"}'
Treasury private keys live in a per-org __treasury-keys vault with MPC custody set automatically by tier: XOR 2-of-2 on Pro and Team, Shamir 2-of-3 across multiple HSMs on Business and Enterprise.
Direct API reads of __treasury-keys and __agent-keys are blocked with a 403. Private keys only ever come out through the designated export endpoints, which require password re-authentication and are audit-logged.
Treasury wallets are human-only: agents get a 403. Swap remains EVM-only, while send now covers all six chains.
Where this goes wrong in practice. Aggregation looks like a reporting concern until someone makes a decision on a number that was quietly wrong.
- USD estimates are treated as authoritative. They are estimates from a price feed at a moment in time, fine for a dashboard and not for settlement.
- Token balances are omitted by default. Without include_tokens the total reflects native balances only, which under-reports a stablecoin treasury dramatically.
- Chain filters silently narrow the answer. A query scoped to two chains returns a confident total that is simply missing the others.
- Imported smart accounts drift. An account imported once is included in the portfolio, and if its ownership changes externally the aggregate keeps reporting it.
Any number shown to finance should carry its scope: which chains, whether tokens are included, and when the prices were read. An unqualified total invites a decision it cannot support.
Decide
Finance asks for a single number: total holdings across the org. You have treasury wallets on four chains, agent signing keys on three, and two imported smart accounts.
What is the right approach?
Check your understanding
3 questionsWhat does GET /v1/portfolio aggregate?
Why does reading __treasury-keys directly return 403?
Which MPC custody mode applies to a Business-tier org's treasury keys?