@coinbase/coinbase-cli 0.0.7 → 0.0.9

package/dist/version.txt

@@ -1 +1 @@
-0.0.7
+0.0.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@coinbase/coinbase-cli",
-  "version": "0.0.7",
+  "version": "0.0.9",
   "description": "Coinbase for agents — CLI and MCP server for trading, wallets, payments, and onchain across the Coinbase platform",
   "type": "module",
   "bin": {
@@ -8,8 +8,10 @@
   },
   "scripts": {
     "build": "BUILD=external node scripts/embed-spec.mjs",
-    "gen:types": "BUNDLE_SKIP=1 BUILD=external node scripts/embed-spec.mjs && node scripts/gen-types.mjs specs/cli/coinbase-cli.yaml '' > generated/cli/types.ts && node scripts/gen-types.mjs dist/spec.json '' RetailBrokerageApi_ > generated/brokerage/types.ts && node scripts/gen-client.mjs > generated/brokerage/client.ts && node scripts/gen-surface.mjs specs/cli/coinbase-cli.yaml > generated/cli/surface.ts",
+    "gen:spec": "BUILD=external node scripts/resolve-agent-spec.mjs",
+    "gen:types": "pnpm run gen:spec && BUNDLE_SKIP=1 BUILD=external node scripts/embed-spec.mjs && node scripts/gen-types.mjs dist/agent-api.yaml '' > generated/cli/types.ts && node scripts/gen-types.mjs dist/spec.json '' RetailBrokerageApi_ > generated/brokerage/types.ts && node scripts/gen-client.mjs > generated/brokerage/client.ts && node scripts/gen-surface.mjs dist/agent-api.yaml > generated/cli/surface.ts",
     "gen:test": "node scripts/gen-mapping-tests.mjs",
+    "gen:check": "pnpm run gen:spec && node scripts/check-contract.mjs",
     "typecheck": "tsc --noEmit",
     "test": "node --experimental-strip-types --no-warnings --test 'src/**/*.test.ts'",
     "test:keyring": "node --experimental-strip-types --no-warnings --test src/lib/keyring/keyring.integration-test.ts",

package/skills/coinbase-trading/SKILL.md

@@ -63,17 +63,57 @@ coinbase orders create product_id=BTC-USD side=SELL type=stop_limit \
 
 Prefer native order types — they are durable and server-side. Only use a `--until` watcher (see `coinbase-watch`) when the trigger is something a single resting order cannot express (cross-product price, spread/volume, fill sequencing).
 
+## Advanced orders (bracket, TWAP, scaled, attached exits)
+
+Bracket, TWAP, scaled orders, and attached exits require the default Agent API
+transport.
+Attached exits require eligible market/limit parents: spot BUY or futures
+BUY/SELL, not equities. Stops do not guarantee a fill or cap losses.
+
+```sh
+# Attach take-profit/stop-loss exits to a limit order
+coinbase orders create product_id=BTC-USD side=BUY type=limit base_size=0.01 \
+  limit_price=50000 attached_take_profit_price=55000 attached_stop_loss_price=48000
+
+# Spot bracket: SELL exit (see orders create --help for futures eligibility)
+coinbase orders create product_id=BTC-USD side=SELL type=bracket \
+  base_size=0.01 limit_price=55000 stop_price=48000
+
+# TWAP: choose future start/end times for the requested execution window
+coinbase orders create product_id=BTC-USD side=BUY type=twap base_size=0.01 \
+  limit_price=55000 time_in_force=GTD start_time='<start-RFC3339>' end_time='<end-RFC3339>'
+
+# Scaled: 5 limit child orders spread between min_price and max_price
+coinbase orders create product_id=BTC-USD side=BUY type=scaled base_size=0.01 \
+  num_orders=5 min_price=48000 max_price=52000
+
+# Change or remove attached exits on an eligible unfilled limit order
+coinbase orders edit <order_id> attached_take_profit_price=56000 attached_stop_loss_price=47000
+coinbase orders edit <order_id> cancel_attached_order=true
+```
+
+Preview first for anything non-trivial — `orders preview` returns the TWAP
+slice schedule or scaled child-order plan before you place the order.
+Read `orders get` before changing attached exits: an attached update replaces
+both legs, so send both prices to retain both. Omit attached fields to keep
+existing exits unchanged.
+
 ## Manage orders
 
 ```sh
 coinbase orders list status==OPEN
 coinbase orders get <order_id>
+coinbase orders edit-preview order_id=<order_id> limit_price=50000
 coinbase orders cancel order_ids:='["id-1","id-2"]'
 coinbase orders edit <order_id> limit_price=50000
 coinbase orders fills order_id==<order_id>
-coinbase orders close_position product_id=BTC-USD
+coinbase orders close-position product_id=BTC-USD
 ```
 
+`orders edit-preview` reprices an open order without editing it — distinct from
+`orders preview`, which prices an order you have not placed yet. Supply at least
+one of `base_size` or `limit_price`.
+
 ## Portfolio scope
 
 CDP API keys derive portfolio scope from the key itself — no `retail_portfolio_id` needed in the body. To trade in a different portfolio, switch envs (`-e live-trading`); see `coinbase-portfolios`.

package/skills/coinbase-x402/SKILL.md

@@ -57,6 +57,29 @@ The header names are not interchangeable. Never send `X-PAYMENT` to a v2 resourc
 
 If the resource rejects the header, first verify that the challenge's `x402Version`, the `x402_version` passed to `pay`, and the HTTP header name agree. Do not create another payment merely to try the other header name.
 
+## Sign-In With X (SIWX)
+
+When a v2 challenge includes `extensions["sign-in-with-x"]`, a wallet that has already paid for the resource may use SIWX instead of creating another payment. SIWX is a separate HTTP authentication flow: never add it to `x402 pay`.
+
+`coinbase` cannot sign SIWX messages and `x402 fetch` cannot attach custom headers. Use the manual `x402 pay` flow only when the caller has a compatible external wallet signer and can make the resource request itself. Otherwise, omit `SIGN-IN-WITH-X` and pay normally.
+
+Do not manually serialize or sign the extension JSON. Select a `supportedChains` entry compatible with the wallet, then use an x402 SIWX client implementation to:
+
+1. Merge `extension.info` with the selected `chainId` and `type`.
+2. Build the required CAIP-122 message, including the signing wallet address.
+3. Sign that message with the matching wallet.
+4. Emit a proof containing the copied `info` fields, `chainId`, `type`, `address`, and `signature`.
+5. Base64-encode the proof JSON for `SIGN-IN-WITH-X`.
+
+Use a CAIP-122-compatible SIWX client or wallet SDK to construct and sign the proof.
+
+Reject redirects that leave the original catalog URL's origin. Only sign when `extension.info.domain` matches the final URL hostname and `extension.info.uri` exactly matches the final response URL. Preserve every challenge field unchanged. Send the SIWX header on the resource request, with the version-matched x402 payment header when payment is still required:
+
+```http
+PAYMENT-SIGNATURE: <payment_header>
+SIGN-IN-WITH-X: <base64-encoded SIWX proof>
+```
+
 ## Retry safety
 
 Use the smallest `amount` and `max_amount` that satisfy the requirement. Reuse the returned `idempotency_key` only when retrying the same logical payment after an outcome-unknown failure. Starting a retry without it can create another hold.