Skip to content
1Claw Academy
Curriculum/Transactions & Treasury3 minAdvanced · Lesson 13 of 16

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. 1

    Get the whole portfolio, with token balances and USD estimates.

    bash
    curl -s "https://api.1claw.co/v1/portfolio?chains=ethereum,solana&include_tokens=true" \
      -H "Authorization: Bearer $ONECLAW_TOKEN"
    # or: 1claw portfolio
  2. 2

    Generate native treasury wallets. Six chains are supported: Ethereum, Bitcoin, Solana, XRP, Cardano, Tron.

    bash
    curl -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. 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.

    bash
    curl -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. 4

    Send gaslessly by wrapping it as an ERC-4337 UserOperation with paymaster sponsorship.

    bash
    curl -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. 5

    Bring your own key. Import is human-only and requires password re-auth.

    bash
    curl -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"}'
Concept

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.

Watch out

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.

Tip

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.
Tip

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 questions
1

What does GET /v1/portfolio aggregate?

2

Why does reading __treasury-keys directly return 403?

3

Which MPC custody mode applies to a Business-tier org's treasury keys?