Skip to main content
The caw CLI lets you manage wallets, addresses, transactions, delegations, policies, and agents from the terminal.

Global options

These options are available on every command.
OptionEnv variableDefaultDescription
--api-keyAPI key for authentication
--api-urlAGENT_WALLET_API_URLAPI base URL
--timeout30HTTP timeout in seconds
--verbose / -vfalseEnable debug logging

Config file

The CLI stores configuration in ~/.cobo-agentic-wallet/ (JSON format). The config file tracks the active profile; per-agent credentials (API key, API URL, wallet UUID) are stored under profiles/profile_<agent_id>/credentials. Most commands that accept a wallet UUID as a positional argument will fall back to the wallet_uuid from the active profile’s credentials if the argument is omitted.

Output format

All commands output JSON to stdout:
{
  "items": [
    {"uuid": "abc-123", "name": "My Wallet", "status": "active"}
  ]
}

Error output

Policy denials are written to stderr with structured context and a non-zero exit code:
{"code": "TRANSFER_LIMIT_EXCEEDED", "reason": "max_per_tx", "details": {"limit_value": "100", "requested": "1000"}, "suggestion": "Retry with amount <= 100."}

caw update

Download and install a caw CLI binary from the official download server. Fetches the binary, verifies its checksum, and replaces the current binary in-place. Omit —version to install the latest release. Use —check to check for a newer version without installing.
caw update
OptionDefaultDescription
--checkCheck for updates without installing
--versionTarget version to install (default: latest)

caw version

Print the current version of the caw CLI binary.
caw version

caw wallet

Manage Cobo Agentic Wallet wallets and perform on-chain operations. Local wallet commands (list, current) operate on credentials stored on this machine. Platform commands (get, balance, rename, archive, pair) call the Cobo Agentic Wallet service and require an active wallet with valid credentials. Run “caw wallet —help” for a full list of subcommands.
caw wallet

list

List all wallets stored on this machine. Each wallet corresponds to one Cobo Agentic Wallet and holds the credentials and metadata needed to call the Cobo Agentic Wallet service. The active wallet is marked with “active”: true.
caw wallet list

current

Without —wallet-id: shows the currently active wallet. With —wallet-id: switches the active wallet to the given one. —wallet-id is the UUID of the wallet to switch to; obtain it from “caw wallet list”.
caw wallet current
OptionDefaultDescription
--wallet-idUUID of the wallet to switch to; if omitted, shows the currently active wallet
--show-api-keyInclude the API key in the output (sensitive; omitted by default)

get

Get details for the active wallet on the Cobo platform.
caw wallet get

balance

List token balances for the active wallet on the Cobo platform.
caw wallet balance
OptionDefaultDescription
--addressFilter by on-chain address
--token-idFilter by token ID (e.g. SETH, SETH_USDC)
--chain-idFilter by chain ID (e.g. SETH, BASE_ETH, SOL)
--limit50Maximum number of results to return (1–200)

rename

Rename the active wallet on the Cobo platform.
caw wallet rename
OptionDefaultDescription
--name / -nNew display name for the wallet

pair

Initiate pairing and obtain a one-time pairing token (8-digit code) for the user to enter in the Cobo Agentic Wallet app. Share the code with the user through a secure channel. Use caw wallet pair-status to monitor whether the user has completed pairing.
caw wallet pair
OptionDefaultDescription
--code-onlyPrint only the pairing token (plain text)

pair-status

Check whether the user has completed the wallet ownership pairing initiated by caw wallet pair.
caw wallet pair-status

caw tx

Manage on-chain transactions for a wallet. Subcommands let you transfer tokens, submit contract calls, sign messages, estimate fees, and manage in-flight transactions via cancel (drop) or replace-by-fee (speedup). All mutating operations are evaluated against active policies before submission.
caw tx

transfer

Transfer tokens from a wallet to a destination address. The transfer is evaluated against all active policies before submission. If a policy denies the transfer, the command exits non-zero and writes structured denial details to stderr. If a policy requires manual approval, the transfer is queued as a pending operation.
caw tx transfer
OptionRequiredDefaultDescription
--dst-addressYesDestination on-chain address (required)
--amountYesTransfer amount as a decimal string, e.g. 1.5 (required)
--token-idYesToken ID, e.g. SETH, SETH_USDC (required). Use the List supported assets operation to retrieve all supported token IDs
--chain-idNoETHChain ID, e.g. SETH, BASE_ETH. Resolved automatically from token ID if omitted
--src-addressNoSource address to transfer from. If omitted, the server auto-selects the wallet address on this chain with the highest available token balance (explicit src-address takes precedence)
--request-idNoClient-supplied idempotency key. If a transfer with the same request-id already exists, the existing record is returned
--descriptionNoOptional description for this transaction
--feeNoCustom fee parameters as a JSON object (EIP-1559 or SOL). If omitted, the network default is used
--pact-idYesPact UUID [required]

call

Submit a smart contract call from a wallet. For EVM chains (e.g. SETH, BASE_ETH), provide —contract and —calldata. For Solana (SOL), provide —instructions as a JSON array of SolInstruction objects and optionally —address-lookup-tables. The call is evaluated against active policies before submission.
caw tx call
OptionRequiredDefaultDescription
--chain-idNoETHChain ID, e.g. SETH, BASE_ETH, SOL. Defaults to ETH. Use the List supported chains operation to retrieve all supported chain IDs
--contractNoEVM contract address to call
--calldataNoEVM calldata as a hex-encoded string (0x-prefixed)
--valueNo0Native token amount to send with the call as a decimal string, e.g. 0.01
--src-addressNoSource address to call from. If omitted, the server auto-selects the wallet address on this chain with the highest available native token balance (explicit src-address takes precedence)
--request-idNoClient-supplied idempotency key. If a call with the same request-id already exists, the existing record is returned
--descriptionNoOptional description for this transaction
--feeNoCustom fee parameters as a JSON object (EIP-1559 or SOL). If omitted, the network default is used
--pact-idYesPact UUID [required]
--instructionsNoSolana instructions as a JSON array of SolInstruction objects
--address-lookup-tablesNoSolana address lookup table accounts as a JSON array

list

List transaction records for the active wallet, newest first.
caw tx list
OptionDefaultDescription
--limit50Maximum number of results to return (1–200)
--statusFilter by transaction status, e.g. pending, success, failed
--typeFilter by record type, e.g. transfer, deposit, contract_call
--token-idFilter by token ID, e.g. SETH, SETH_USDC
--chain-idFilter by chain ID, e.g. SETH, BASE_ETH, SOL
--addressFilter by on-chain address

get

Retrieve the full details of a single transaction record. Provide either —tx-id (the record UUID from caw tx list or submit response) or —request-id (the same request_id you passed on the submit call). The wallet is taken from your active wallet (use “caw wallet current” to check). The response includes status, amounts, fees, and any policy evaluation results.
caw tx get
OptionDefaultDescription
--tx-idTransaction record UUID (from caw tx list or submit response)
--request-idSame request_id as on submit; looks up the record for the configured wallet

estimate-transfer-fee

Estimate the network fee for a token transfer without submitting it. Provide the same flags you intend to use for caw tx transfer. The response includes the estimated fee amount and the token used to pay it.
caw tx estimate-transfer-fee
OptionRequiredDefaultDescription
--dst-addressYesDestination on-chain address (required)
--amountYesTransfer amount as a decimal string, e.g. 1.5 (required)
--token-idNoToken ID, e.g. SETH, SETH_USDC. Use the List supported assets operation to retrieve all supported token IDs
--chain-idNoETHChain ID, e.g. SETH, BASE_ETH. Resolved automatically from token ID if omitted
--src-addressNoSource address to transfer from. If omitted, the server auto-selects the wallet address on this chain with the highest available token balance (explicit src-address takes precedence)

estimate-call-fee

Estimate the network fee for a contract call without submitting it. Provide the same flags you intend to use for caw tx call. —context, —request-id, —description, and —gasless are not applicable for estimation. The response includes the estimated fee and the native token used to pay it.
caw tx estimate-call-fee
OptionDefaultDescription
--chain-idETHChain ID, e.g. SETH, BASE_ETH, SOL. Defaults to ETH. Use the List supported chains operation to retrieve all supported chain IDs
--contractEVM contract address to call
--calldataEVM calldata as a hex-encoded string (0x-prefixed)
--value0Native token amount to send with the call as a decimal string, e.g. 0.01
--src-addressSource address to call from. If omitted, the server auto-selects the wallet address on this chain with the highest available native token balance (explicit src-address takes precedence)
--instructionsSolana instructions as a JSON array of SolInstruction objects
--address-lookup-tablesSolana address lookup table accounts as a JSON array

drop

Cancel a transaction that has not yet been confirmed on-chain. Pre-broadcast transactions (pending screening, authorization, or signature) are cancelled directly without a fee. Broadcasting transactions use Replace-By-Fee (RBF): a zero-value replacement is submitted to the same nonce with a higher fee. The fee is derived automatically from the original transaction’s recorded fee bumped by —fee-multiplier (default +15%). —tx-id is the UUID of the transaction to cancel; obtain it from ‘caw tx list’ or the submit response.
caw tx drop
OptionRequiredDefaultDescription
--tx-idYesTransaction record UUID [required]
--request-idNoClient-supplied idempotency key for the replacement transaction
--fee-multiplierNo0.15Fractional fee increase for RBF replacement (e.g. 0.15 = +15%). Only applied when the transaction is broadcasting.

speedup

Resubmit a broadcasting transaction to the same nonce with a higher fee (RBF). The replacement fee is derived automatically from the original transaction’s recorded fee bumped by —fee-multiplier (default +15%). Only transactions in the ‘broadcasting’ sub-status can be sped up. —tx-id is the UUID of the transaction to speed up; obtain it from ‘caw tx list’ or the submit response.
caw tx speedup
OptionRequiredDefaultDescription
--tx-idYesTransaction record UUID [required]
--fee-multiplierNo0.15Fractional fee increase for the RBF replacement (e.g. 0.15 = +15%)
--request-idNoClient-supplied idempotency key for the replacement transaction

sign-message

Sign a message using a wallet address. —pact-id is the pact that scopes the signing key and wallet; obtain it from “caw pact list” or a pact submit response.
caw tx sign-message
OptionRequiredDefaultDescription
--chain-idYesChain ID, e.g. SETH, BASE_ETH (required). Use the List supported chains operation to retrieve all supported chain IDs
--destination-typeNoSigning scheme, e.g. eip712 for EIP-712 typed data
--eip712-typed-dataNoEIP-712 typed data as a JSON object (required for eip712 destination type)
--src-addressNoAddress to sign with. If omitted, the server auto-selects the wallet address on this chain (explicit src-address takes precedence)
--descriptionNoHuman-readable description of what is being signed
--request-idNoClient-supplied idempotency key
--pact-idYesPact UUID [required]

caw address

Manage on-chain addresses associated with your Cobo Agentic Wallet. Use the subcommands to list existing addresses or generate new ones for a specific wallet and chain.
caw address

list

List all on-chain addresses associated with the active wallet. Use “caw wallet current” to check which wallet is active.
caw address list

create

Generate a new on-chain address for the active wallet and chain.
caw address create
OptionDefaultDescription
--chain-idChain ID, e.g. SETH, BASE_ETH, SOL. Use ‘caw meta chains’ to retrieve all supported chain IDs

caw meta

Query metadata about supported blockchains, tokens, and current market prices. Subcommands:
chains        List all chains supported for a given wallet type
chain-info    Get detailed information for a specific chain by ID
tokens        List supported token IDs and their metadata
search-tokens Search token candidates by symbol
prices        Get current market prices for one or more asset coins
caw meta

chains

List all blockchains supported by Cobo for a given wallet type. Results are paginated.
caw meta chains
OptionDefaultDescription
--wallet-typeMPCWallet type to filter by. Valid values: MPC, Custodial
--chain-idsFilter by chain ID. Accepts a comma-separated list, e.g. SETH,BASE_ETH
--limit50Maximum number of results to return
--beforeCursor for the previous page (use meta.before from a prior response)
--afterCursor for the next page (use meta.after from a prior response)

chain-info

Retrieve detailed information about a specific blockchain by its chain ID. —chain-id is the Cobo chain identifier, e.g. SETH or BASE_ETH. Use “caw meta chains” to list all supported chain IDs.
caw meta chain-info
OptionRequiredDescription
--chain-idYesCobo chain ID, e.g. SETH, BASE_ETH [required]

tokens

List all token IDs and their metadata supported by Cobo for a given wallet type. Results are paginated.
caw meta tokens
OptionDefaultDescription
--wallet-typeMPCWallet type to filter by. Valid values: MPC, Custodial
--chain-idsFilter by chain ID. Accepts a comma-separated list, e.g. SETH,BASE_ETH
--token-idsFilter by token ID. Accepts a comma-separated list, e.g. SETH,SETH_USDC
--limit50Maximum number of results to return
--beforeCursor for the previous page (use meta.before from a prior response)
--afterCursor for the next page (use meta.after from a prior response)

search-tokens

Search for token candidates matching a symbol and return matching token IDs and their metadata across supported chains.
caw meta search-tokens
OptionRequiredDescription
--symbolYesToken symbol to search for, e.g. USDC, ETH

prices

Get current market prices for one or more Cobo asset coins. —asset-coins is a comma-separated list of Cobo asset coin IDs, e.g. BTC,ETH. Use “caw meta tokens” to discover supported IDs.
caw meta prices
OptionRequiredDefaultDescription
--asset-coinsYesComma-separated Cobo asset coin IDs, e.g. BTC,ETH [required]
--currencyNoUSDISO 4217 currency code for price output, e.g. USD, EUR

caw faucet

Interact with the Cobo testnet faucet to obtain tokens for development and testing. Use the tokens subcommand to browse available testnet tokens, then use the deposit subcommand to request a specific token be sent to an on-chain address.
caw faucet

tokens

List all testnet tokens currently available from the Cobo faucet. The returned token IDs can be passed to —token-id when running caw faucet deposit to request a specific token be sent to an address.
caw faucet tokens

deposit

Request a testnet token deposit from the Cobo faucet to an on-chain address. Example:
caw faucet deposit --address `<on-chain-address>` --token-id SOLDEV_SOL_USDC
caw faucet deposit
OptionRequiredDescription
--address / -aYesOn-chain address to receive the testnet tokens (required)
--token-id / -tYesTestnet token ID to request, e.g. SOLDEV_SOL_USDC. Use caw faucet tokens to list available tokens (required)

caw pending

Manage pending operations that are awaiting approval under your wallet policies. Pending operations are created automatically when a transaction or other action requires human or policy approval before it can execute. Use the subcommands to list, inspect, approve, or reject pending operations.
caw pending

list

List pending operations that are waiting for approval or are currently executing. Results are paginated.
caw pending list
OptionDefaultDescription
--limit50Maximum number of results to return (1–200)
--statusFilter by status, e.g. pending_approval, executing, completed, rejected

get

Retrieve full details of a single pending operation. The response includes the operation type, current status, policy context, and any available result payload. —operation-id is the ID of the pending operation to retrieve; obtain IDs from “caw pending list”.
caw pending get
OptionRequiredDescription
--operation-idYesPending operation ID [required]

approve

Approve a pending operation, allowing it to proceed to execution. This action is irreversible — once approved, the operation will begin executing immediately if all other policy conditions are satisfied. —operation-id is the ID of the pending operation to approve; obtain IDs from “caw pending list”.
caw pending approve
OptionRequiredDefaultDescription
--operation-idYesPending operation ID [required]
--confirmNoAsk for interactive confirmation before executing

reject

Reject a pending operation, preventing it from executing. This action is irreversible. —operation-id is the ID of the pending operation to reject; obtain IDs from “caw pending list”.
caw pending reject
OptionRequiredDefaultDescription
--operation-idYesPending operation ID [required]
--reasonNoHuman-readable reason for the rejection
--confirmNoAsk for interactive confirmation before executing

caw node

Manage the local TSS Node process used for threshold signature scheme operations. Subcommands let you start, stop, restart, and inspect the node, view its logs, run health checks, and query its status both locally and via the Cobo API.
caw node

status

Show TSS Node status. Without —scope, returns both local process info and remote API status. —scope local: show only the local process state (PID, running, binary path) —scope remote: query only the remote API for the node’s online status
caw node status
OptionDefaultDescription
--scopeShow only local or remote status; omit for both (local, remote)

info

Show installation metadata for the local TSS Node. Reports the TSS directory, binary path, whether the binary and secrets database exist, and the configured environment (dev or prod). If both the binary and database are present, the node ID is also retrieved by running the node’s own info subcommand.
caw node info

health

Run a suite of health checks on the local TSS Node installation. Verifies that the binary, secrets database, config file, and key file all exist, that the key file has permissions 600, and that the node process is currently running. The node ID is included in the output when the binary and database are present. Exits with a non-zero status code if any check fails, making this command suitable for use in scripts and monitors.
caw node health

start

Start the TSS Node process as a background daemon. If the node is already running, this command reports its PID and exits without starting a second instance. The process is launched with a new session (detached from the terminal), its PID is written to a file for later management, and output is appended to the log file shown in the result. The command polls briefly to confirm the process stays alive during startup and returns an error with recent log output if it exits immediately.
caw node start

stop

Stop the running TSS Node process. Before stopping, the command checks whether there are any pending transactions in the configured wallet and refuses to stop if any are found, to avoid interrupting in-flight signing. The process receives SIGTERM and is given up to five seconds to exit gracefully before SIGKILL is sent. The PID file is removed on success.
caw node stop
OptionDefaultDescription
--force / -fStop even if pending transactions exist

restart

Restart the TSS Node process. If the node is currently running, it is stopped gracefully (SIGTERM, then SIGKILL after a timeout) before the new instance is launched. If the node is not running, it is started directly. The result includes the new PID and the path to the log file.
caw node restart

logs

View the TSS Node log file. By default, the last 50 lines are printed. The command exits with an error if no log file exists yet.
caw node logs
OptionDefaultDescription
--lines / -n50Number of lines to show from the end of the log
--follow / -fStream log output in real-time (Ctrl-C to stop)

caw onboard

Interactive onboarding (default): collects input via prompts while wallet KeyGen runs in the background. Re-run until wallet_status is active; JSON output includes prompts for agents to fill in.
caw onboard
OptionDefaultDescription
--envCobo environment: sandbox, dev, or prod (default: prod, env: CAW_ENV)
--invitation-codeInvitation code
--agent-nameOptional display name for the agent (provision) and, when set, names the wallet “<name>’s Wallet”
--session-idInteractive onboarding session id. If omitted or not found, a new session is created
--answersJSON object merged into collected answers, e.g. {“invitation_code”:“X”,“risk_ack”:true}
--waitBlock until the wallet reaches active status (default: return immediately with current phase)

bootstrap

Run the MPC wallet bootstrap sequence as a detached background worker. This command is spawned automatically by caw onboard after provisioning and is not intended to be called directly. It prepares the TSS cache, waits for the prime-generation step to complete, creates the MPC wallet record via the Cobo Agentic Wallet API, and writes the resulting wallet UUID back to the wallet state file so that subsequent caw onboard poll calls can detect activation.
caw onboard bootstrap
OptionRequiredDescription
--agent-idYesAgent / wallet id

health

Check whether the Cobo Agentic Wallet backend API is reachable. Does not require authentication. Useful for verifying network access or environment configuration before running other commands.
caw onboard health

self-test

Run two test transfers against the configured wallet to verify that policies are working correctly: one transfer that should be blocked by policy, and one that should be allowed. Exits non-zero if either test produces an unexpected result.
caw onboard self-test
OptionDefaultDescription
--wallet / -wWallet UUID
--tokenUSDCToken ID for test transfers
--chainBASEChain ID for test transfers
--blocked-amount500Amount expected to be blocked
--allowed-amount2Amount expected to be allowed
--toDestination address for tests

caw fetch

Perform an HTTP request and automatically handle 402 Payment Required responses using the x402 or MPP machine-payment protocols. —url is the endpoint to fetch. When a 402 is received, caw detects the payment protocol from the response headers (unless overridden), pays using the configured wallet, and retries the request with the payment headers. Example:
caw fetch --url https://api.example.com/data --wallet-id `<uuid>` --network eip155:8453
caw fetch
OptionRequiredDefaultDescription
--method / -XNoGETHTTP method to use for the request (e.g. GET, POST, PUT)
--header / -HNonilHTTP request header in Key: Value format; may be repeated
--data / -dNoRaw HTTP request body to send with the request
--output / -oNobodyOutput mode: body prints the response body only, full includes status code and headers
--wallet-id / -wNoWallet UUID to charge for payment; falls back to wallet_uuid in the active wallet (see caw wallet list)
--protocol / -pNoautoPayment protocol to use: auto detects from response headers, x402 forces x402, mpp forces MPP
--networkNoCAIP-2 network filter that excludes payment options on other networks (e.g. eip155:8453); x402 only
--urlYesURL to fetch [required]
--jsonNoSend JSON data (sets Content-Type/Accept to application/json, defaults method to POST)
--assetNoToken contract address filter that excludes payment options for other tokens (case-insensitive); x402 only
--max-amountNoMaximum acceptable raw token amount; payment options requiring more than this amount are excluded; x402 only
--depositNoSession deposit amount in raw token units; defaults to per_request_amount multiplied by 10; MPP session intent only
--dry-runNoPrint the payment challenge received in the 402 response and exit without calling the payment API

caw payment

Manage Cobo payment features including MPP (Merchant Payment Protocol) sessions and payment gateway configuration. Use the session subcommand to inspect and manage active or historical payment sessions, and the gateway subcommand to configure payment gateway settings for the active wallet.
caw payment

session

Manage Micropayment Protocol (MPP) payment sessions. Subcommands let you list active sessions, close individual or all sessions, and withdraw deposited funds after a channel is closed on-chain.
caw payment session

list

List currently active MPP payment sessions stored locally. By default only sessions in active state are shown.
caw payment session list
OptionDefaultDescription
--allInclude closed sessions from history

close

Close a single active MPP payment session. By default the session is closed via protocol negotiation with the relay server. Use —force to bypass the relay server and submit an on-chain requestClose transaction directly; after a force-close there is a 15-minute grace period before you can reclaim funds with “caw payment session withdraw”.
caw payment session close
OptionDefaultDescription
--realmRealm of the session to close
--channel-idChannel ID of the session to close
--forceBypass RS and close on-chain directly via requestClose

close-all

Close every active MPP payment session found in the local sessions directory. Each session is closed via protocol negotiation with the relay server by default. Use —force to bypass the relay server and submit an on-chain requestClose for all sessions instead. A summary of closed, close-requested, and failed sessions is printed on completion.
caw payment session close-all
OptionDefaultDescription
--forceClose all sessions on-chain directly via requestClose

withdraw

Reclaim deposited funds from an MPP channel that has been closed on-chain and whose grace period has expired. The session must be in ‘close_requested’ status; use “caw payment session close —force” to initiate an on-chain close if it is not.
caw payment session withdraw
OptionDefaultDescription
--realmRealm of the session to withdraw
--channel-idChannel ID of the session to withdraw

gateway

Start a local HTTP proxy that intercepts outgoing requests and automatically handles payment challenges using the x402 or MPP protocol. Two proxy modes are available. In forward mode the proxy accepts plain HTTP requests whose URL contains the full target address. In MITM mode the proxy intercepts HTTPS traffic by acting as a transparent TLS terminator; a CA certificate is generated on first run and must be trusted by the HTTP client. Example:
caw gateway --wallet-id `<uuid>` --mode mitm --protocol x402
caw payment gateway
OptionDefaultDescription
--listen / -l127.0.0.1:8402Listen address for the proxy
--wallet-id / -wWallet UUID to use for payments
--protocol / -pautoPayment protocol: auto, x402, or mpp
--depositInitial deposit amount (in the payment token’s base unit) pre-funded into each MPP session
--modeallProxy mode: all, forward, or mitm
--mitm-port8403Listen port for MITM proxy (used when mode=all)
--ca-certPath to CA certificate for MITM (default: ~/.cobo-agentic-wallet/proxy/ca.crt)
--ca-keyPath to CA private key for MITM (default: ~/.cobo-agentic-wallet/proxy/ca.key)

caw export-key

Exports the wallet’s MPC private key through a secure MPC reshare and local reconstruction, writing derived private keys to a CSV file. The first invocation creates an export request and prints an authorization URL that the wallet owner must approve in the Cobo Agentic Wallet app. Re-run the command after approval; it will detect the approved state, spin up two temporary TSS recovery nodes, perform the reshare, reconstruct the root private key, derive keys for all wallet addresses, and write the result to —output-dir.
  • —wallet: specify the wallet UUID (from caw wallet list); omit to use the active profile default
  • —output-dir: control where the CSV is written; defaults to the profile directory
The export session is resumable: re-running at any intermediate stage continues from where it left off. Example:
caw export-key --wallet 4b2e...f1a0 --output-dir ~/exports
caw export-key
OptionDefaultDescription
--walletWallet UUID to export (from caw wallet list); falls back to the active profile default
--output-dirDirectory for exported CSV (defaults to profile directory)

caw status

Check backend connectivity and wallet status in a single call. Returns three fields: healthy (whether the backend API is reachable), wallet_status (the current wallet lifecycle state such as active or pending), and wallet_paired (whether the wallet ownership pairing has been completed).
caw status

caw util

Utility commands for encoding, decoding, and inspecting data used in transactions. Intended for development and debugging. Subcommands:
  • abi: ABI encode and decode EVM calldata, and compute function selectors.
  • base64: Base64 encode and decode strings.
caw util

abi

ABI encoding and decoding utilities for EVM smart-contract calldata. Subcommands:
  • encode: Encode a function call into hex calldata.
  • decode: Decode hex calldata back into function name and arguments.
caw util abi

encode

Encode a function call into hex calldata for use with caw tx call —calldata. Examples:
# ERC-20 approve(address, uint256)
caw abi encode --method "approve(address,uint256)" --args '["0x1234...", "115792089237316195423570985008687907853269984665640564039457584007913129639935"]'

# Uniswap V3 exactInputSingle (tuple)
caw abi encode --method "exactInputSingle((address,address,uint24,address,uint256,uint256,uint160))" \
  --args '[["0xTokenIn","0xTokenOut",3000,"0xRecipient","1000000","0","0"]]'

# Zero-argument function
caw abi encode --method "totalSupply()"
caw util abi encode
OptionRequiredDefaultDescription
--methodYesFunction signature, e.g. transfer(address,uint256) (required)
--argsNoFunction arguments as a JSON array, e.g. [“0x1234…”, “1000000”]

decode

Decode hex calldata back into function name and arguments, or decode an eth_call return value using —output-types. Examples:
# Decode input calldata (validates selector)
caw util abi decode --method "transfer(address,uint256)" --calldata 0xa9059cbb000000...

# Decode eth_call return value (no selector check)
caw util abi decode --output-types '["string"]' --calldata 0x000000...
caw util abi decode --output-types '["uint256","address"]' --calldata 0x000000...
caw util abi decode
OptionRequiredDefaultDescription
--calldataYesHex calldata or return value to decode (required)
--methodNoFunction signature, e.g. transfer(address,uint256)
--output-typesNoJSON array of Solidity types for decoding return values, e.g. ’[“string”]‘
--abiNoABI JSON array; combined with —method to auto-extract output types and decode return values

selector

Compute the 4-byte function selector from a function signature. Examples:
caw abi selector --signature "transfer(address,uint256)"
caw abi selector --signature "approve(address,uint256)"
caw abi selector --signature "exactInputSingle((address,address,uint24,address,uint256,uint256,uint160))"
caw util abi selector
OptionRequiredDescription
--signatureYesFunction signature, e.g. transfer(address,uint256) [required]

call

Send a raw eth_call to an EVM contract and return the hex result. Use this when you already have ABI-encoded calldata. For a higher-level command that handles encoding and decoding automatically, use “caw util eth-call”. Example:
CALLDATA=$(caw util abi encode --method "balanceOf(address)" --args '["0xYourAddress"]' | jq -r .calldata)
caw util abi call --chain-id SETH --to 0xContractAddress --data "$CALLDATA"
caw util abi call
OptionRequiredDefaultDescription
--chain-idYesCobo chain ID (e.g. SETH, BASE_ETH) [required]
--toYesContract address to call [required]
--dataYesABI-encoded calldata as hex (use ‘caw util abi encode’ to build) [required]
--fromNomsg.sender override (optional)
--blockNolatestBlock tag or hex number (default: latest)

base64

Encode and decode data in base64 format. Use the encode subcommand to convert hex bytes, raw strings, or stdin to a base64 string. Use the decode subcommand to recover the original bytes from a base64 string, with output as hex or raw text. Both subcommands support standard and URL-safe base64 variants via —url.
caw util base64

encode

Encode hex, raw string, or stdin to base64. Examples:
# Encode hex bytes (auto-detected by 0x prefix)
caw util base64 encode --data 0x02000000008078120000000000

# Encode raw string
caw util base64 encode --data "DCA_ROUND_1_USDC_SOL" --raw

# Encode from stdin
echo -n "hello" | caw util base64 encode --stdin
caw util base64 encode
OptionDefaultDescription
--dataData to encode: hex (0x-prefixed) or raw string
--rawTreat the input as a raw string instead of hex (0x-prefixed input is treated as hex by default)
--stdinRead input from stdin instead of —data
--urlUse URL-safe base64 encoding (replaces + with - and / with _)

decode

Decode a base64 string and output as hex or raw. Examples:
# Decode to hex (default)
caw util base64 decode --data "AgAAAACAehIAAAAAAA=="

# Decode to raw string
caw util base64 decode --data "RENBX1JPVU5EXzFfVVNEQ19TT0w=" --raw

# Decode from stdin
echo "AgAAAACAehIAAAAAAA==" | caw util base64 decode --stdin
caw util base64 decode
OptionDefaultDescription
--dataBase64 string to decode
--rawInclude the decoded bytes as a raw UTF-8 string in the output
--stdinRead the base64 string from stdin instead of —data
--urlUse URL-safe base64 decoding

eth-call

Encode calldata from an ABI, call the contract via eth_call, and decode the return value — all in one command. For raw eth_call without encoding/decoding, use “caw util abi call”. Examples:
caw util eth-call --chain-id SETH --to 0x1c7D... \
  --abi '[{"name":"name","type":"function","inputs":[],"outputs":[{"name":"","type":"string"}]}]' \
  --method name

caw util eth-call --chain-id SETH --to 0x1c7D... \
  --abi erc20 --method balanceOf --args '["0xYourAddress"]'
caw util eth-call
OptionRequiredDefaultDescription
--chain-idYesCobo chain ID (e.g. SETH, BASE_ETH) [required]
--toYesContract address to call [required]
--abiYesABI JSON array [required]
--methodYesFunction name or signature (e.g. balanceOf or balanceOf(address)) [required]
--argsNoFunction arguments as a JSON array, e.g. ’[“0x1234…”]’
--fromNomsg.sender override (optional)
--blockNolatestBlock tag or hex number (default: latest)

caw pact

Manage pacts — delegated access agreements that grant an operator agent permission to act on a wallet owner’s behalf within defined policy limits. Use submit to request a new pact, status or show to inspect one, and revoke to terminate an active pact.
caw pact

list

List pacts accessible to the authenticated principal. Results are paginated.
caw pact list
OptionDefaultDescription
--statusFilter by pact status: pending_approval, active, rejected, completed, expired, or revoked
--wallet-idFilter by wallet UUID
--limit50Maximum number of results to return (1–200)

status

Fetch the current status of a pact by its ID, triggering lazy activation if the pact is ready to become active. —pact-id is returned when you run “caw pact submit”, or found via “caw pact list”.
caw pact status
OptionRequiredDescription
--pact-idYesPact UUID [required]

show

Show the full detail of a pact, including its spec, status, policies, and completion conditions. —pact-id is returned when you run “caw pact submit”, or found via “caw pact list”.
caw pact show
OptionRequiredDescription
--pact-idYesPact UUID [required]

events

List all lifecycle events recorded for a pact in chronological order. Events capture state transitions such as submission, approval, activation, and revocation. —pact-id is returned when you run “caw pact submit”, or found via “caw pact list”.
caw pact events
OptionRequiredDefaultDescription
--pact-idYesPact UUID [required]
--limitNo50Maximum number of results to return (1–200)

submit

Submit a new pact request. A pact grants an agent delegated access to the wallet, scoped by policies (spending caps, chain/token filters, address constraints, approval thresholds) and completion conditions (transaction count, amount spent, or elapsed time) that automatically terminate the delegation when reached. caw pact submit Flag Reference Translate the user’s request into caw pact submit flags. Each row maps one aspect of the user’s intent to the corresponding flag and describes how to derive the value. Least privilege: Default to the narrowest scope — shortest duration, tightest token/chain/contract allowlist, and lowest spend cap that fulfills the user’s intent. Only widen when the user explicitly asks.
FlagRequiredNotesHow to Derive from User Input
—intent <text>yesNatural language description of the pact’s purposeDistill into action + asset + chain: “buy 500ETHweekly""WeeklyDCA:500 ETH weekly" → "Weekly DCA: 500 ETH on Ethereum”.
—original-intent <text>noUser’s original message(s) that triggered this requestCapture raw message(s) as typed. If refined across multiple messages, concatenate chronologically.
—policies <json>yesJSON array of detailed risk control policy definitions: chain/token/contract allowlists, per-tx caps, rolling limits, review thresholds.See Policy Reference below.
—completion-conditions <json>yesJSON array of completion conditions.See Completion Conditions below.
—execution-plan <text>yesConcrete on-chain steps the agent will perform post-approval.See Execution Plan below.
Complete Example
User request: “Help me transfer 1000 USDC to 0xABC…123 on Base”
caw pact submit \
  --intent "Transfer 1000 USDC to 0xABC...123 on Base" \
  --original-intent "Help me transfer 1000 USDC to 0xABC...123 on Base" \
  --policies '[
    {
      "name": "usdc-transfer",
      "type": "transfer",
      "rules": {
        "effect": "allow",
        "when": {
          "chain_in": ["BASE_ETH"],
          "token_in": [{"chain_id":"BASE_ETH","token_id":"BASE_USDC"}],
          "destination_address_in": [{"chain_id":"BASE_ETH","address":"0xABC...123"}]
        },
        "deny_if": {
          "amount_usd_gt": "1001"
        }
      }
    }
  ]' \
  --completion-conditions '[{"type": "tx_count", "threshold": "1"}]' \
  --execution-plan "# Summary\nTransfer 1000 USDC to 0xABC...123 on Base.\n\n# Operations\n- Transfer 1000 USDC to 0xABC...123 on Base\n\n# Risk Controls\n- Per-tx cap: $1001\n- One-time transfer only"
Execution Plan (—execution-plan) Describe the operations the agent will run after the pact is active. Use these sections:
  • # Summary — one-line goal
  • # Operations — concrete calls/transfers (token, amount, target contract)
  • # Risk Controls — per-tx cap, daily cap, etc
Example — “buy $500 ETH weekly on Base”:
# Summary
Weekly DCA: swap $500 USDC to ETH on Base via Uniswap V3.

# Operations
- Approve USDC spend on Uniswap V3 Router (0x2626...1e481) if needed
- Swap $500 USDC → ETH via Uniswap V3 on Base
- Repeat weekly

# Risk Controls
- Per-swap cap: $550 (includes slippage buffer)
- Rolling 24h limit: $600
Completion Conditions (—completion-conditions) JSON array defining when a pact is considered complete. Each object has type and threshold (required). At least one condition is required. Types cannot be duplicated within a pact.
TypeThresholdDescription
tx_countstring (integer)Complete after N successful transactions (across all operation types). E.g., “5”
amount_spentstring (decimal)Complete after cumulative token amount reaches threshold. E.g., “3.5”. Uses the token’s transfer unit (e.g., “1.5” means 1.5 USDC or 1.5 ETH, not wei).
amount_spent_usdstring (decimal)Complete after cumulative USD spend reaches threshold. E.g., “3000”. Note: transactions without price data won’t increment progress.
time_elapsedstring (seconds)Complete after N seconds from pact activation. E.g., “3600” (1 hour).
Multiple conditions can be set; the pact completes when any one is satisfied (any-of semantics). Once complete, the pact is revoked immediately and no further operations can be executed under it. Policy Reference (—policies) Policies constrain operations within a pact via the —policies flag. Each policy targets a specific operation type (transfer, contract_call, or message_sign) and always uses allow effect. Default-deny semantics apply: any operation not matching the when conditions of at least one policy is automatically denied — no implicit pass-through. Always define policies that explicitly cover every operation the agent needs to perform. Policy Structure
{
  "name": "`<human-readable-name>`",
  "type": "transfer | contract_call | message_sign",
  "rules": {
    "effect": "allow",
    "when": { ... },
    "deny_if": { ... },
    "review_if": { ... },
    "always_review": true | false
  }
}
FieldRequiredDescription
nameYesHuman-readable policy name for identification
typeYesOperation type: transfer, contract_call, or message_sign
rules.effectYesAlways set to “allow”.
rules.whenYes (unless always_review=true)Allowlist conditions — which chains/tokens/contracts/domains to permit
rules.deny_ifOptionalHard-block conditions — usage limits that trigger an automatic deny.
rules.review_ifOptionalSoft-block conditions — thresholds that require owner approval before proceeding
rules.always_reviewOptionalWhen true, every operation matching when requires owner approval. Use for sensitive or high-risk tasks.
Evaluation flow:
Operation


Match any policy's when? ──No──► DENY

  Yes


Hit deny_if limit? ──Yes──► DENY

  No


Exceed review_if threshold? ──No──► ALLOW

  Yes


Pause for owner approval

  ├── approved ──► ALLOW
  └── rejected ──► DENY
Allowlist Conditions (when) For transfer policies:
FieldTypeDescription
chain_instring[]Restrict to specific chains (e.g. [“BASE_ETH”, “ETH”])
token_inChainTokenRef[]Restrict to specific tokens, e.g. [{“chain_id”:“BASE_ETH”,“token_id”:“BASE_USDC”}]
destination_address_inChainAddressRef[]Restrict to specific destination addresses
For contract_call policies (EVM):
FieldTypeDescription
chain_instring[]Restrict to specific chains
target_inContractTargetRef[]Restrict to specific contract addresses. E.g. [{“chain_id”:“BASE_ETH”, “contract_addr”:“0x…”}]
For contract_call policies (Solana):
FieldTypeDescription
chain_instring[]Restrict to specific chains
program_inProgramRef[]Restrict to specific program IDs
Usage Limits (deny_if)
FieldTypeApplies toDescription
amount_gtstring (decimal)transfer onlyDeny if single operation token amount exceeds this
amount_usd_gtstring (decimal)transfer onlyDeny if single operation USD value exceeds this
usage_limits.rolling_24h.amount_gtstringtransfer onlyDeny if cumulative token amount in the 24h window exceeds this
usage_limits.rolling_24h.amount_usd_gtstringtransfer onlyDeny if cumulative USD value in the 24h window exceeds this
usage_limits.rolling_24h.tx_count_gtintegertransfer, contract_callDeny if transaction count in the 24h window exceeds this
Review Threshold (review_if) Matching operations require owner approval before execution.
FieldTypeApplies toDescription
amount_gtstring (decimal)transferRequire approval if token amount exceeds this
amount_usd_gtstring (decimal)transferRequire approval if USD value exceeds this
Message Sign Policies message_sign policies control EIP-712 typed-data signing.
RuleFieldTypeDescription
when.domain_match[]param_namestringEIP-712 domain field to match (e.g. “name”, “verifyingContract”)
opstringeq, neq, in, not_in
valueanyValue to compare against
deny_ifusage_limits.rolling_24h.request_count_gtintegerMax signing requests per 24h window
review_if(same fields as when)Require owner approval for matching signatures
Example — restrict Permit2 signatures to a specific contract:
{
  "name": "permit2-sign",
  "type": "message_sign",
  "rules": {
    "effect": "allow",
    "when": {
      "domain_match": [
        { "param_name": "name", "op": "eq", "value": "Permit2" },
        { "param_name": "verifyingContract", "op": "eq", "value": "0x000000000022D473030F116dDEE9F6B43aC78BA3" }
      ]
    },
    "deny_if": {
      "usage_limits": { "rolling_24h": { "request_count_gt": 50 } }
    }
  }
}
Amount Units and USD Pricing Amount units: amount_gt values are in the token’s transfer unit — the same unit used when submitting a transfer. For example, “1.5” means 1.5 USDC for USDC, or 1.5 ETH for ETH/SETH (not wei). USD Conditions: USD-based conditions (amount_usd_gt, usage_limits.rolling_24h.amount_usd_gt) only apply to tokens with available price data — tokens without price data bypass them entirely. For tokens without price data, use token-denominated limits (amount_gt, usage_limits.rolling_24h.amount_gt) instead.
caw pact submit
OptionRequiredDefaultDescription
--intentYesNatural language description of the pact’s purpose, e.g. “Weekly DCA: $500 ETH on Ethereum”
--original-intentNoRaw user message(s) that triggered this request; concatenate chronologically for multi-turn sessions
--execution-planYesConcrete on-chain steps the agent will perform after approval (markdown). Suggested sections: # Summary, # Operations, # Risk Controls
--completion-conditionsYesJSON array of conditions that auto-terminate the pact. Each object has “type” (tx_count, amount_spent, amount_spent_usd, or time_elapsed) and “threshold”. The pact completes when any one is met
--policiesYesJSON array of policy objects. Each has “name”, “type” (transfer, contract_call, or message_sign), and “rules” (effect, when, deny_if, review_if)

revoke

Revoke an active pact. Only the wallet owner can revoke a pact. Revoking removes the associated delegation and invalidates the pact-scoped API key. This action cannot be undone.
caw pact revoke
OptionRequiredDefaultDescription
--pact-idYesPact UUID [required]
--confirmNoAsk for interactive confirmation before executing

caw schema

Output a machine-readable JSON description of any caw command, including its flags, positional arguments, and exit codes. Without arguments, returns a lightweight index of all commands (name + description). With arguments, returns the full schema for the specified command. Examples:
caw schema                 # list all commands
caw schema tx transfer     # full schema for tx transfer
caw schema wallet balance  # full schema for wallet balance
caw schema [command...]

caw track

Read tracked transactions and query their current status. Each tracked entry records a command type (tx, pact, or wallet pair) and a response ID; caw resolves the current status by querying the Cobo WaaS API. The notification channel, target, and prompt are read from the context JSON recorded at submission time.
caw track
OptionDefaultDescription
--watch / -wPoll until all entries reach terminal status
--interval5*time.SecondPoll interval in watch mode

caw recipe

Search and retrieve recipes from the Cobo Agentic Wallet knowledge base. Use the search subcommand to find relevant recipes using natural language queries via LightRAG.
caw recipe
Search the recipe knowledge base using a natural language query via LightRAG. Returns relevant recipe documents, knowledge graph entities, and relationships that match the query. Results can be filtered by chain or token symbol and tuned via search mode and token budgets.
caw recipe search
OptionRequiredDefaultDescription
--queryYesNatural language search query [required]
--sourceNoDocument source: graph or knowledge
--modeNoSearch mode: local, global, or mix (default: mix)
--top-kNo0Number of entities/relationships to retrieve
--chunk-top-kNo0Number of text chunks to retrieve
--max-entity-tokensNo0Token budget for entity context
--max-relation-tokensNo0Token budget for relation context
--max-total-tokensNo0Overall token ceiling
--limitNo0Max results for knowledge search
--chainNoFilter by chain symbol (e.g. ethereum, solana, bitcoin)
--tokenNoFilter by token symbol (e.g. ETH, USDT, BTC)
--keywordsNonilKeywords for filtering documents (knowledge search)
--search-typeNoSearch type: vector, keyword, or hybrid (knowledge search)