CLI - Cobo Agentic Wallet

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.

Option	Env variable	Default	Description
`--api-key`	—	—	API key for authentication
`--api-url`	`AGENT_WALLET_API_URL`	—	API base URL
`--timeout`	—	`30`	HTTP timeout in seconds
`--verbose` / `-v`	—	`false`	Enable 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. —version is required. Use —check to verify a version is available without installing.

caw update

Option	Default	Description
`--check`	—	Check for updates without installing
`--version`	—	Target version to install (required), e.g. v1.2.3

`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-uuid: shows the currently active wallet. With —wallet-uuid: switches the active wallet to the given one. —wallet-uuid is the UUID of the wallet to switch to; obtain it from ‘caw wallet list’.

caw wallet current

Option	Default	Description
`--wallet-uuid`	—	UUID of the wallet to switch to; if omitted, shows the currently active wallet
`--show-api-key`	—	Include 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 all token balances for the active wallet. Optionally filter by —token-id, —chain-id, or —address to narrow the results.

caw wallet balance

Option	Default	Description
`--address`	—	Filter by on-chain address
`--token-id`	—	Filter by token ID (e.g. SETH, SETH_USDC)
`--chain-id`	—	Filter by chain ID (e.g. SETH, BASE_ETH, SOL)
`--limit`	`50`	Maximum number of results to return (1–200)

`rename`

Rename the active wallet on the Cobo platform.

caw wallet rename

Option	Default	Description
`--name` / `-n`	—	New 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. To verify pairing completion at any time, run caw status and check the wallet_paired boolean.

caw wallet pair

Option	Default	Description
`--code-only`	—	Print 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

`archive`

Archive a wallet locally. Archived wallets are hidden from ‘caw wallet list’ but no server-side changes are made. Use —list to view all archived wallets, or —rollback with a wallet UUID to restore one.

caw wallet archive

Option	Default	Description
`--wallet-uuid`	—	UUID of the wallet to archive
`--list`	—	List all archived wallet UUIDs
`--rollback`	—	Restore an archived wallet by UUID

`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. Pass —request-id as an idempotency key — retrying with the same value returns the existing record without re-submitting.

caw tx transfer

Option	Required	Default	Description
`--dst-address`	Yes	—	Destination on-chain address (required)
`--amount`	Yes	—	Transfer amount as a decimal string, e.g. 1.5 (required)
`--token-id`	Yes	—	Token ID, e.g. SETH, SETH_USDC (required). Use the List supported assets operation to retrieve all supported token IDs
`--chain-id`	No	`ETH`	Chain ID, e.g. SETH, BASE_ETH. Resolved automatically from token ID if omitted
`--src-address`	No	—	Source 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-id`	No	—	Client-supplied idempotency key. If a transfer with the same request-id already exists, the existing record is returned
`--description`	No	—	Optional description for this transaction
`--fee`	No	—	Custom fee parameters as a JSON object (EIP-1559 or SOL). If omitted, the network default is used
`--pact-id`	Yes	—	Pact UUID [required]

`call`

Submit a smart contract call from a wallet. For EVM chains (e.g. SETH, BASE_ETH), provide —contract and —calldata. EVM addresses must be exactly 42 characters (0x + 40 hex digits). For Solana (SOL), provide —instructions as a JSON array of SolInstruction objects and optionally —address-lookup-tables. Solana addresses must be 43–44 characters (Base58). The call is evaluated against active policies before submission.

caw tx call

Option	Required	Default	Description
`--chain-id`	No	`ETH`	Chain ID, e.g. SETH, BASE_ETH, SOL. Defaults to ETH. Use the List supported chains operation to retrieve all supported chain IDs
`--contract`	No	—	EVM contract address to call
`--calldata`	No	—	EVM calldata as a hex-encoded string (0x-prefixed)
`--value`	No	`0`	Native token amount to send with the call as a decimal string, e.g. 0.01
`--src-address`	No	—	Source 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-id`	No	—	Client-supplied idempotency key. If a call with the same request-id already exists, the existing record is returned
`--description`	No	—	Optional description for this transaction
`--fee`	No	—	Custom fee parameters as a JSON object (EIP-1559 or SOL). If omitted, the network default is used
`--pact-id`	Yes	—	Pact UUID [required]
`--instructions`	No	—	Solana instructions as a JSON array of SolInstruction objects
`--address-lookup-tables`	No	—	Solana address lookup table accounts as a JSON array

`list`

List transaction records for the active wallet, newest first. Filterable by —status, —token-id, —chain-id, —address, and —type.

caw tx list

Option	Default	Description
`--limit`	`50`	Maximum number of results to return (1–200)
`--status`	—	Filter by transaction status, e.g. pending, success, failed
`--type`	—	Filter by record type, e.g. transfer, deposit, contract_call
`--token-id`	—	Filter by token ID, e.g. SETH, SETH_USDC
`--chain-id`	—	Filter by chain ID, e.g. SETH, BASE_ETH, SOL
`--address`	—	Filter 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

Option	Default	Description
`--tx-id`	—	Transaction record UUID (from caw tx list or submit response)
`--request-id`	—	Same 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 and without running policy checks. 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

Option	Required	Default	Description
`--dst-address`	Yes	—	Destination on-chain address (required)
`--amount`	Yes	—	Transfer amount as a decimal string, e.g. 1.5 (required)
`--token-id`	No	—	Token ID, e.g. SETH, SETH_USDC. Use the List supported assets operation to retrieve all supported token IDs
`--chain-id`	No	`ETH`	Chain ID, e.g. SETH, BASE_ETH. Resolved automatically from token ID if omitted
`--src-address`	No	—	Source 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

Option	Default	Description
`--chain-id`	`ETH`	Chain ID, e.g. SETH, BASE_ETH, SOL. Defaults to ETH. Use the List supported chains operation to retrieve all supported chain IDs
`--contract`	—	EVM contract address to call
`--calldata`	—	EVM calldata as a hex-encoded string (0x-prefixed)
`--value`	`0`	Native token amount to send with the call as a decimal string, e.g. 0.01
`--src-address`	—	Source 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)
`--instructions`	—	Solana instructions as a JSON array of SolInstruction objects
`--address-lookup-tables`	—	Solana 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

Option	Required	Default	Description
`--tx-id`	Yes	—	Transaction record UUID [required]
`--request-id`	No	—	Client-supplied idempotency key for the replacement transaction
`--fee-multiplier`	No	`0.15`	Fractional 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

Option	Required	Default	Description
`--tx-id`	Yes	—	Transaction record UUID [required]
`--fee-multiplier`	No	`0.15`	Fractional fee increase for the RBF replacement (e.g. 0.15 = +15%)
`--request-id`	No	—	Client-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

Option	Required	Default	Description
`--chain-id`	Yes	—	Chain ID, e.g. SETH, BASE_ETH (required). Use the List supported chains operation to retrieve all supported chain IDs
`--destination-type`	No	—	Signing scheme, e.g. eip712 for EIP-712 typed data
`--eip712-typed-data`	No	—	EIP-712 typed data as a JSON object (required for eip712 destination type)
`--src-address`	No	—	Address to sign with. If omitted, the server auto-selects the wallet address on this chain (explicit src-address takes precedence)
`--description`	No	—	Human-readable description of what is being signed
`--request-id`	No	—	Client-supplied idempotency key
`--pact-id`	Yes	—	Pact 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. Run this before creating a new address to check whether one already exists for a given chain. Use ‘caw wallet current’ to check which wallet is active.

caw address list

`create`

Generate a new on-chain address for the active wallet on the specified chain. The response includes a compatible_chains field listing all chain IDs that share this address (e.g. all EVM chains share one address).

caw address create

Option	Default	Description
`--chain-id`	—	Chain 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

Option	Default	Description
`--wallet-type`	`MPC`	Wallet type to filter by. Valid values: MPC, Custodial
`--chain-ids`	—	Filter by chain ID. Accepts a comma-separated list, e.g. SETH,BASE_ETH
`--limit`	`50`	Maximum number of results to return
`--before`	—	Cursor for the previous page (use meta.before from a prior response)
`--after`	—	Cursor 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

Option	Required	Description
`--chain-id`	Yes	Cobo 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

Option	Default	Description
`--wallet-type`	`MPC`	Wallet type to filter by. Valid values: MPC, Custodial
`--chain-ids`	—	Filter by chain ID. Accepts a comma-separated list, e.g. SETH,BASE_ETH
`--token-ids`	—	Filter by token ID. Accepts a comma-separated list, e.g. SETH,SETH_USDC
`--limit`	`50`	Maximum number of results to return
`--before`	—	Cursor for the previous page (use meta.before from a prior response)
`--after`	—	Cursor 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

Option	Required	Description
`--symbol`	Yes	Token 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

Option	Required	Default	Description
`--asset-coins`	Yes	—	Comma-separated Cobo asset coin IDs, e.g. BTC,ETH [required]
`--currency`	No	`USD`	ISO 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

Option	Required	Description
`--address` / `-a`	Yes	On-chain address to receive the testnet tokens (required)
`--token-id` / `-t`	Yes	Testnet 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

Option	Default	Description
`--limit`	`50`	Maximum number of results to return (1–200)
`--status`	—	Filter by status: pending, executing, rejected, executed

`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

Option	Required	Description
`--operation-id`	Yes	Pending 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

Option	Required	Default	Description
`--operation-id`	Yes	—	Pending operation ID [required]
`--confirm`	No	—	Ask 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

Option	Required	Default	Description
`--operation-id`	Yes	—	Pending operation ID [required]
`--reason`	No	—	Human-readable reason for the rejection
`--confirm`	No	—	Ask 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

Option	Default	Description
`--scope`	—	Show 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

Option	Default	Description
`--force` / `-f`	—	Stop 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

Option	Default	Description
`--lines` / `-n`	`50`	Number of lines to show from the end of the log
`--follow` / `-f`	—	Stream 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

Option	Default	Description
`--agent-name`	—	Optional display name for the agent (provision) and, when set, names the wallet “`<name>`’s Wallet”
`--session-id`	—	Interactive onboarding session id. If omitted or not found, a new session is created
`--answers`	—	JSON object merged into collected answers, e.g. {“agent_name”:“MyAgent”}
`--wait`	—	Block 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

Option	Required	Description
`--agent-id`	Yes	Agent / 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

Option	Default	Description
`--wallet` / `-w`	—	Wallet UUID
`--token`	`USDC`	Token ID for test transfers
`--chain`	`BASE`	Chain ID for test transfers
`--blocked-amount`	`500`	Amount expected to be blocked
`--allowed-amount`	`2`	Amount expected to be allowed
`--to`	—	Destination address for tests

`caw fetch`

Perform an HTTP request and automatically handle 402 Payment Required responses using the x402 or MPP machine-payment protocols. <pact-id> is the pact UUID used to resolve the paying wallet and the pact-scoped API key (same behavior as ‘caw tx transfer <pact-id>’). <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 wallet bound to the pact, and retries the request with the payment headers. Example:

caw fetch `<pact-uuid>` https://api.example.com/data --network eip155:8453

caw fetch <pact-id> <url>

Option	Default	Description
`--method` / `-X`	`GET`	HTTP method to use for the request (e.g. GET, POST, PUT)
`--header` / `-H`	`nil`	HTTP request header in Key: Value format; may be repeated
`--data` / `-d`	—	Raw HTTP request body to send with the request
`--output` / `-o`	`body`	Output mode: body prints the response body only, full includes status code and headers
`--protocol` / `-p`	`auto`	Payment protocol to use: auto detects from response headers, x402 forces x402, mpp forces MPP
`--network`	—	CAIP-2 network filter that excludes payment options on other networks (e.g. eip155:8453); x402 only
`--json`	—	Send JSON data (sets Content-Type/Accept to application/json, defaults method to POST)
`--asset`	—	Token contract address filter that excludes payment options for other tokens (case-insensitive); x402 only
`--max-amount`	—	Maximum acceptable raw token amount; payment options requiring more than this amount are excluded; x402 only
`--deposit`	—	Session deposit amount in raw token units; defaults to per_request_amount multiplied by 10; MPP session intent only
`--dry-run`	—	Print 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

Option	Default	Description
`--all`	—	Include 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’. The session is closed under the pact that originally opened it (persisted in active.json). Pass —pact-id to override when that pact has been rotated or revoked, or to recover a session opened by an older CLI that did not persist the pact id.

caw payment session close

Option	Default	Description
`--realm`	—	Realm of the session to close
`--channel-id`	—	Channel ID of the session to close
`--force`	—	Bypass RS and close on-chain directly via requestClose
`--pact-id`	—	Pact UUID to authorize the close; defaults to the pact that opened the session

`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. Each session is closed under the pact that originally opened it. Sessions that have no persisted pact_id (opened by older CLIs) are skipped unless —pact-id is provided to apply the same pact to every session. A summary of closed, close-requested, failed, and skipped sessions is printed on completion.

caw payment session close-all

Option	Default	Description
`--force`	—	Close all sessions on-chain directly via requestClose
`--pact-id`	—	Pact UUID to authorize all closes; defaults to each session’s own pact

`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. The withdraw is signed under the pact that opened the session. Pass —pact-id to override when that pact has been rotated, or to recover a session opened by an older CLI.

caw payment session withdraw

Option	Default	Description
`--realm`	—	Realm of the session to withdraw
`--channel-id`	—	Channel ID of the session to withdraw
`--pact-id`	—	Pact UUID to authorize the withdraw; defaults to the pact that opened the session

`gateway`

Start a local HTTP proxy that intercepts outgoing requests and automatically handles payment challenges using the x402 or MPP protocol. <pact-id> is the pact UUID used to resolve the paying wallet and the pact-scoped API key (same behavior as ‘caw tx transfer <pact-id>’). All payments signed by the gateway are authorized under that pact. 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 payment gateway `<pact-uuid>` --mode mitm --protocol x402

caw payment gateway <pact-id>

Option	Default	Description
`--listen` / `-l`	`127.0.0.1:8402`	Listen address for the proxy
`--protocol` / `-p`	`auto`	Payment protocol: auto, x402, or mpp
`--deposit`	—	Initial deposit amount (in the payment token’s base unit) pre-funded into each MPP session
`--mode`	`all`	Proxy mode: all, forward, or mitm
`--mitm-port`	`8403`	Listen port for MITM proxy (used when mode=all)
`--ca-cert`	—	Path to CA certificate for MITM (default: ~/.cobo-agentic-wallet/proxy/ca.crt)
`--ca-key`	—	Path 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

Option	Default	Description
`--wallet`	—	Wallet UUID to export (from caw wallet list); falls back to the active profile default
`--output-dir`	—	Directory for exported CSV (defaults to profile directory)

`caw status`

Show a compact wallet snapshot: whether the backend is reachable (healthy), the current wallet lifecycle state (wallet_status, e.g. active or pending), whether ownership pairing has been completed (wallet_paired boolean), active pact count, and pending transaction count.

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. Pass numeric arguments as decimal strings (e.g. “1000000”), not raw integers. Tuple arguments must be encoded as nested JSON arrays. Token amounts must always be in the token’s smallest unit (e.g. 0.001 WETH = 1000000000000000). Always verify the result with caw util abi decode before submitting. 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

Option	Required	Default	Description
`--method`	Yes	—	Function signature, e.g. transfer(address,uint256) (required)
`--args`	No	—	Function 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

Option	Required	Default	Description
`--calldata`	Yes	—	Hex calldata or return value to decode (required)
`--method`	No	—	Function signature, e.g. transfer(address,uint256)
`--output-types`	No	—	JSON array of Solidity types for decoding return values, e.g. ’[“string”]‘
`--abi`	No	—	ABI 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

Option	Required	Description
`--signature`	Yes	Function 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

Option	Required	Default	Description
`--chain-id`	Yes	—	Cobo chain ID (e.g. SETH, BASE_ETH) [required]
`--to`	Yes	—	Contract address to call [required]
`--data`	Yes	—	ABI-encoded calldata as hex (use ‘caw util abi encode’ to build) [required]
`--from`	No	—	msg.sender override (optional)
`--block`	No	`latest`	Block 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

Option	Default	Description
`--data`	—	Data to encode: hex (0x-prefixed) or raw string
`--raw`	—	Treat the input as a raw string instead of hex (0x-prefixed input is treated as hex by default)
`--stdin`	—	Read input from stdin instead of —data
`--url`	—	Use 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

Option	Default	Description
`--data`	—	Base64 string to decode
`--raw`	—	Include the decoded bytes as a raw UTF-8 string in the output
`--stdin`	—	Read the base64 string from stdin instead of —data
`--url`	—	Use URL-safe base64 decoding

`eth-call`

Read on-chain contract state by calling a view function: encodes calldata, calls the contract via eth_call, and decodes the return value automatically. Use —abi erc20 to query standard ERC-20 methods (name, symbol, decimals, balanceOf, allowance) without writing a full ABI. —args is a JSON array of positional arguments; omit for zero-argument methods. 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

Option	Required	Default	Description
`--chain-id`	Yes	—	Cobo chain ID (e.g. SETH, BASE_ETH) [required]
`--to`	Yes	—	Contract address to call [required]
`--abi`	Yes	—	ABI JSON array [required]
`--method`	Yes	—	Function name or signature (e.g. balanceOf or balanceOf(address)) [required]
`--args`	No	—	Function arguments as a JSON array, e.g. ’[“0x1234…”]’
`--from`	No	—	msg.sender override (optional)
`--block`	No	`latest`	Block 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. Defaults to —status active. Filter by —status (e.g. pending_approval, completed, expired, revoked) to see other states. Results are paginated.

caw pact list

Option	Default	Description
`--status`	`active`	Filter by pact status: pending_approval, active, rejected, completed, expired, or revoked
`--limit`	`50`	Maximum 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

Option	Required	Description
`--pact-id`	Yes	Pact 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

Option	Required	Description
`--pact-id`	Yes	Pact 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

Option	Required	Default	Description
`--pact-id`	Yes	—	Pact UUID [required]
`--limit`	No	`50`	Maximum 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. 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

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.

Type	Threshold	Description
tx_count	string (integer)	Complete after N successful transactions (across all operation types). E.g., “5”
amount_spent	string (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_usd	string (decimal)	Complete after cumulative USD spend reaches threshold. E.g., “3000”. Note: transactions without price data won’t increment progress.
time_elapsed	string (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
  }
}

Field	Required	Description
name	Yes	Human-readable policy name for identification
type	Yes	Operation type: transfer, contract_call, or message_sign
rules.effect	Yes	Always set to “allow”.
rules.when	Yes (unless always_review=true)	Allowlist conditions — which chains/tokens/contracts/domains to permit
rules.deny_if	Optional	Hard-block conditions — usage limits that trigger an automatic deny.
rules.review_if	Optional	Soft-block conditions — thresholds that require owner approval before proceeding
rules.always_review	Optional	When true, every operation matching when requires owner approval. Use for sensitive or high-risk tasks.

Allowlist Conditions (when) For transfer policies:

Field	Type	Description
chain_in	string[]	Restrict to specific chains (e.g. [“BASE_ETH”, “ETH”])
token_in	ChainTokenRef[]	Restrict to specific tokens, e.g. [{“chain_id”:“BASE_ETH”,“token_id”:“BASE_USDC”}]
destination_address_in	ChainAddressRef[]	Restrict to specific destination addresses

For contract_call policies (EVM):

Field	Type	Description
chain_in	string[]	Restrict to specific chains
target_in	ContractTargetRef[]	ALL contracts the tx touches: primary contract + ERC-20 token (approve target) + factory/quoter. E.g. [{“chain_id”:“BASE_ETH”,“contract_addr”:“0xRouter…”},{“chain_id”:“BASE_ETH”,“contract_addr”:“0xUSDC…”}]. Missing entries cause silent policy denials.

For contract_call policies (Solana):

Field	Type	Description
chain_in	string[]	Restrict to specific chains
program_in	ProgramRef[]	Restrict to specific program IDs

Usage Limits (deny_if)

Field	Type	Applies to	Description
amount_gt	string (decimal)	transfer only	Deny if single operation token amount exceeds this
amount_usd_gt	string (decimal)	transfer only	Deny if single operation USD value exceeds this
usage_limits.rolling_24h.amount_gt	string	transfer only	Deny if cumulative token amount in the 24h window exceeds this
usage_limits.rolling_24h.amount_usd_gt	string	transfer only	Deny if cumulative USD value in the 24h window exceeds this
usage_limits.rolling_24h.tx_count_gt	integer	transfer, contract_call	Deny if transaction count in the 24h window exceeds this

Review Threshold (review_if) Matching operations require owner approval before execution.

Field	Type	Applies to	Description
amount_gt	string (decimal)	transfer	Require approval if token amount exceeds this
amount_usd_gt	string (decimal)	transfer	Require approval if USD value exceeds this

Message Sign Policies message_sign policies control EIP-712 typed-data signing.

Rule	Field	Type	Description
when.domain_match[]	param_name	string	EIP-712 domain field to match (e.g. “name”, “verifyingContract”)
	op	string	eq, neq, in, not_in
	value	any	Value to compare against
deny_if	usage_limits.rolling_24h.request_count_gt	integer	Max 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

Option	Required	Default	Description
`--intent`	Yes	—	Natural language description of the pact’s purpose. Distill into action + asset + chain: “buy $500 ETH weekly\" → \"Weekly DCA:$ 500 ETH on Ethereum”.
`--original-intent`	No	—	Raw user message(s) that triggered this request. Capture as typed; concatenate chronologically for multi-turn sessions. E.g. “Help me transfer 1000 USDC to 0xABC…123 on Base”
`--execution-plan`	Yes	—	Concrete on-chain steps the agent will perform after approval (markdown). Sections: # Summary (one-line goal), # Operations (calls/transfers), # Risk Controls (caps/limits). E.g. ”# 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”
`--completion-conditions`	Yes	—	JSON 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. E.g. [{“type”:“tx_count”,“threshold”:“1”}]
`--policies`	Yes	—	JSON array of policy objects. For contract_call type: target_in MUST cover ALL contracts the tx touches — primary contract + ERC-20 token (approve target) + factory/quoter. Missing entries cause policy rejections.
`--name`	No	—	Human-readable name for this pact (optional)
`--recipe-slugs`	No	`nil`	Recipe slugs to link this pact to the authoritative recipe (recommended). Run ‘caw recipe search’ first to get the slug. E.g. uniswap-v3-swap,aave-supply

`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

Option	Required	Default	Description
`--pact-id`	Yes	—	Pact UUID [required]
`--confirm`	No	—	Ask 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

Option	Default	Description
`--watch` / `-w`	—	Poll until all entries reach terminal status
`--interval`	`5*time.Second`	Poll 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`

Search the recipe knowledge base before executing DeFi operations to load domain knowledge: contract addresses, ABIs, execution steps, and risk notes for the target protocol. Use —keywords to specify protocol name or token symbols, and —chain to filter by chain. Always run this before contract calls on unfamiliar protocols.

caw recipe search

Option	Required	Default	Description
`--keywords`	Yes	`nil`	Keywords to search for (e.g. uniswap, USDC) [required]
`--limit`	No	`0`	Max results to return
`--chain`	No	—	Filter by chain symbol (e.g. ethereum, solana, bitcoin)

​Global options

​Config file

​Output format

​Error output

​caw update

​caw version

​caw wallet

​list

​current

​get

​balance

​rename

​pair

​pair-status

​archive

​caw tx

​transfer

​call

​list

​get

​estimate-transfer-fee

​estimate-call-fee

​drop

​speedup

​sign-message

​caw address

​list

​create

​caw meta

​chains

​chain-info

​tokens

​search-tokens

​prices

​caw faucet

​tokens

​deposit

​caw pending

​list

​get

​approve

​reject

​caw node

​status

​info

​health

​start

​stop

​restart

​logs

​caw onboard

​bootstrap

​health

​self-test

​caw fetch

​caw payment

​session

​list

​close

​close-all

​withdraw

​gateway

​caw export-key

​caw status

​caw util

​abi

​encode

​decode

​selector

​call

​base64

​encode

​decode

​eth-call

​caw pact

​list

​status

​show

​events

​submit

Global options

Config file

Output format

Error output

`caw update`

`caw version`

`caw wallet`

`list`

`current`

`get`

`balance`

`rename`

`pair`

`pair-status`

`archive`

`caw tx`

`transfer`

`call`

`list`

`get`

`estimate-transfer-fee`

`estimate-call-fee`

`drop`

`speedup`

`sign-message`

`caw address`

`list`

`create`

`caw meta`

`chains`

`chain-info`

`tokens`

`search-tokens`

`prices`

`caw faucet`

`tokens`

`deposit`

`caw pending`

`list`

`get`

`approve`

`reject`

`caw node`

`status`

`info`

`health`

`start`

`stop`

`restart`

`logs`

`caw onboard`

`bootstrap`

`health`

`self-test`

`caw fetch`

`caw payment`

`session`

`list`

`close`

`close-all`

`withdraw`

`gateway`

`caw export-key`

`caw status`

`caw util`

`abi`

`encode`

`decode`

`selector`

`call`

`base64`

`encode`

`decode`

`eth-call`

`caw pact`

`list`

`status`

`show`

`events`

`submit`