Memory & wallet

Inspect what it remembers, read the chain, set the policy, ask it to act.

Memory

GET/v1/memory

Keywords with tier, weight, and days remaining — the data behind Inspect & edit.

json

{
  "pinned": [{ "key": "chain:base", "note": "trades on Base only" }],
  "fading": [{ "key": "frost-tone", "days_left": 3 }]
}

Call	Body	Notes
POST /v1/memory/pin	{ "key" }	Pins. Idempotent — pinning a pinned key is a no-op 200.
DELETE /v1/memory/{key}	—	Forgets immediately. 404 if the key was already gone.

Reading the chain

GET/v1/chain/{view}

The digesting chain skill — meaning, priced and block-stamped, not raw RPC. view is one of tokens, pools, positions, safety.

http

GET /v1/chain/pools?pair=ETH-USDC

{
  "pair": "ETH/USDC",
  "depth_usd": 48000000,
  "as_of_block": 19402118
}

Always available with wallet:read; no policy applies to reads.

Wallet & policy

Call	Does
GET /v1/wallet	Address, digested balances (USD-priced), policy state.
PUT /v1/wallet/policy	Replaces the policy document — schema in Spend policy. Needs `admin`.
POST /v1/wallet/withdraw	To an allowlisted address only. The presence cannot call this — you can.

Acting

POST/v1/wallet/intent

Intent, not calldata. The presence resolves it through the chain skill and obeys the policy — same path as conversational acting, reached by code.

http

POST /v1/wallet/intent
{ "do": "swap 0.1 ETH to USDC, max 0.4% slippage" }

# 200 — done within policy
{ "status": "done", "tx": "0x7a…f3", "block": 19402150 }

# 202 — over confirm_over, held
{ "status": "needs_confirm", "confirm_id": "cf_9b2…" }

A 202 needs_confirm is resolved by you on the events stream — never by re-POSTing. Re-POST with the same Idempotency-Key returns the same held intent, not a second one.