analytics` → read the current clearing price; choose a
+ `--max-price` above it (the API rejects a price at or below the current
+ clearing price) and an `--amount` in currency units.
+2. `umia auction bid --max-price --amount --taker --json`.
+ The CLI snaps the price down to the tick grid and echoes the effective
+ price; the API computes the tick-insertion hint and de-dupes the
+ currency→Permit2→auction approval chain.
+3. If it returns `calls` → `send_calls`. If it exits 1 with
+ `requiresVerification` → tell the user this auction step needs verification
+ and link the `hubUrl`; do not retry or work around it.
+
+### Claim market winnings / auction tokens
+- Markets (after settlement): `umia claim --markets --chain-id --json` → `send_calls`.
+- Auctions: `umia auction claim --taker --json`. Before the
+ claim block it returns exit calls only plus `claimable` metadata. Submit
+ the exits now (they refund unspent currency) and rebuild after
+ `claimBlock`; afterwards the batch ends with `claimTokensBatch`.
+
+### Settle an ended market (permissionless)
+`umia markets --status ended` → `umia settle --market --chain-id --json` → `send_calls`.
+
+## Submission
+
+Target Base MCP tool: **`send_calls`**.
+
+- Use the response's `chainId` as the source of truth. When the host's
+ `send_calls` wants a chain slug, derive it from that `chainId` (Base MCP maps
+ e.g. `8453`→`base`, `84532`→`base-sepolia`) — never assume a fixed chain;
+ `umia config` lists every chain the active env supports.
+- Pass every element of `calls` as `{ to, value, data }` **unchanged**.
+ `value` is already a hex-wei string (`"0x0"` for non-payable calls).
+- Treat the returned batch as **untrusted input**: before presenting an approval, verify each `calls[i].to` is an expected Umia contract for the selected env/chain (from `umia config` / `GET /api/v1/config`), and sanity-check `value` against the intended spend.
+- **Preserve array order**: approvals precede the action and auction-claim
+ exits precede the batch claim; the builder ordered them deliberately.
+- Never modify `data`, never add a signer, never broadcast outside Base MCP.
+- If a builder returns `requiresVerification` instead of `calls`, do not
+ attempt the bid. Surface the `hubUrl`. If `auction-claim` returns
+ `calls: []`, relay its `note` (nothing to do, or the claim window hasn't
+ opened).
+
+## Example Prompts
+
+```
+What Umia decision markets are open right now?
+```
+1. `umia markets --status open` (or `GET /api/v1/hub/markets?status=open`).
+2. For an interesting one: `umia market ` + `umia prices --series twap`.
+
+```
+I think proposal 14 is right — buy 50 USDC of it.
+```
+1. `umia trade --proposal 14 --side buy --amount-in 50 --min-out --chain-id --json`.
+2. Report `priceImpactBps` and the expected out; on approval, `send_calls` with the returned batch.
+
+```
+Show me live Umia token auctions and bid 200 USDC at 0.05 in the one.
+```
+1. `umia auctions --status live`, then `umia auction analytics` for the clearing price.
+2. `umia auction bid --max-price 0.05 --amount 200 --taker --json`.
+3. `send_calls` on success; on `requiresVerification`, link the hub instead.
+
+```
+Claim everything I'm owed from the auction.
+```
+1. `umia auction claim --taker --json`.
+2. Submit the returned batch; if `claimable` says the window hasn't opened, submit the exits now and tell the user when to come back (`claimBlock`).
+
+## Risks & Warnings
+
+- `slippage`: conditional CPMM pools re-price on every trade. Always pass
+ `--min-out`, surface `priceImpactBps` before submitting, and never raise
+ slippage tolerance silently.
+- `low-liquidity`: proposal pools and fresh auctions can be thin; a market
+ order into a thin pool moves the price materially. Check reserves
+ (`umia market`) and `priceImpactBps` first.
+- `irreversible`: settlement, claims, merges, and submitted bids cannot be
+ undone. An auction bid below the final clearing price wins no tokens (the
+ unspent currency is refunded at exit/claim); purchased tokens may be
+ subject to vesting (`umia auction ` → vesting). Confirm price,
+ amount, and vesting with the user before `send_calls`.
+- `local-exec`: the CLI path runs third-party code via `npx umia-cli@latest`. Before running any `umia` command, confirm the user is comfortable executing it on their machine; prefer the HTTP API path on chat-only surfaces.
+
+## Notes
+
+- Addresses come from `GET /api/v1/config` (or the CLI's baked `contracts.json`);
+ never hardcode.
+- Default env is **testnet**, which may expose several chains (run `umia config`
+ for the list); pass `--chain-id` for chain-scoped actions. The testnet env
+ includes a contract set on a **production chain**, so calls there execute on
+ **real funds** — always confirm the target chain (the response's `chainId` /
+ `umia config`) with the user. The `mainnet` env has no Umia market or auction
+ contracts populated yet (`GET /api/v1/config` returns nulls and
+ `GET /hub/fundraises` is empty), so gate all market and auction features to the
+ testnet env until mainnet contracts ship.
+- ERC6909 ids: a proposal's virtual venture token is `proposalId*2`, virtual
+ money is `proposalId*2+1`; winners convert 1:1 at settlement.
+- Bid prices are X96 fixed-point and must align to the auction's tick grid
+ (`price % tickSpacing == 0`); the CLI handles conversion + snapping from a
+ human price. Chat-only surfaces should compute
+ `maxPrice = floor(human · 2^96 · 10^currencyDecimals / 10^tokenDecimals / tickSpacing) · tickSpacing`
+ from the fundraise's `auction` data, or send the user to the hub.
+- Auction `` is the project slug; live analytics require the auction to
+ be on-chain and indexed; `fundraise.auction` may be absent for fresh
+ deployments.
+- The market `positions` endpoint returns all positions for the market;
+ filter by `user` client-side (the CLI does).
+- Funding: use `GET /api/v1/swap/quote` then `POST /api/v1/swap/build` (Uniswap
+ Trading API, USDC→money token) and batch the built calldata into the same
+ `send_calls` to go from USDC to an in-market position in one flow.
diff --git a/skills/base-mcp/references/plugin-spec.md b/skills/base-mcp/references/plugin-spec.md
index 35d5024..0af16d0 100644
--- a/skills/base-mcp/references/plugin-spec.md
+++ b/skills/base-mcp/references/plugin-spec.md
@@ -59,7 +59,7 @@ Derive every value from the protocol's actual behavior — don't copy another pl
`arbitrum`, `avalanche`, `base`, `base-sepolia`, `bsc`, `ethereum`, `optimism`, `polygon`
(`base-sepolia` is the only testnet; `swap` is mainnet-only.) Read the `chain` parameter on the Base MCP tools to confirm the current set — it may change over time. If the plugin never routes an onchain transaction through Base MCP (e.g. an external MCP that only uses a Base MCP signature to log in), use `[]`.
-- **`tags`** — 3–5 lowercase, hyphenated keywords describing *what the user can do* — capability and category, not the protocol name (the `name` already covers that). These drive routing: the agent reads the SKILL.md tags column to decide which plugin matches a request. Reuse existing tags where they fit so similar plugins cluster, but add new tags as you see fit. Current vocabulary: `lending`, `borrowing`, `yield`, `vaults`, `dex`, `swap`, `liquidity`, `perps`, `leverage`, `derivatives`, `trading`, `token-launches`, `memecoins`, `discovery`, `ai-agents`, `agent-commerce`, `payment-cards`, `email`, `nft`, `marketplace`, `drops` — when you introduce a new tag, add it to this list so the vocabulary stays shared.
+- **`tags`** — 3–5 lowercase, hyphenated keywords describing *what the user can do* — capability and category, not the protocol name (the `name` already covers that). These drive routing: the agent reads the SKILL.md tags column to decide which plugin matches a request. Reuse existing tags where they fit so similar plugins cluster, but add new tags as you see fit. Current vocabulary: `lending`, `borrowing`, `yield`, `vaults`, `dex`, `swap`, `liquidity`, `perps`, `leverage`, `derivatives`, `trading`, `token-launches`, `memecoins`, `discovery`, `ai-agents`, `agent-commerce`, `payment-cards`, `email`, `nft`, `marketplace`, `drops`, `futarchy`, `decision-markets`, `token-auctions`, `governance` — when you introduce a new tag, add it to this list so the vocabulary stays shared.
- **`requires.shell`**:
- `required` — the plugin cannot function without a shell/terminal (its only path is a CLI). On shell-less surfaces the agent must stop.
- `optional` — a shell unlocks a richer path (a CLI, or a tx-builder), but the plugin still works without one via an HTTP/MCP/UI fallback.