@aibtc/mcp-server 1.69.0 → 1.70.1

package/dist/tools/skill-mappings.js

@@ -225,8 +225,6 @@ export const TOOL_SKILL_MAP = {
     taproot_verify_cosig: "ordinals-p2p",
     taproot_multisig_guide: "ordinals-p2p",
     // identity skill — ERC-8004 on-chain agent identity
-    register_identity: "identity",
-    get_identity: "identity",
     identity_get_last_id: "identity",
     identity_get: "identity",
     identity_get_metadata: "identity",
@@ -238,12 +236,7 @@ export const TOOL_SKILL_MAP = {
     identity_unset_wallet: "identity",
     identity_transfer: "identity",
     // reputation skill — ERC-8004 on-chain agent reputation
-    give_feedback: "reputation",
-    get_reputation: "reputation",
     // validation skill — ERC-8004 on-chain agent validation
-    request_validation: "validation",
-    get_validation_status: "validation",
-    get_validation_summary: "validation",
     // stackspot skill — stacking lottery pots
     stackspot_list_pots: "stackspot",
     stackspot_get_pot_state: "stackspot",

package/dist/utils/bip322.d.ts

@@ -7,9 +7,8 @@
  *
  * Spec: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
  *
- * These primitives are shared across:
- * - src/tools/signing.tools.ts (btc_sign_message / btc_verify_message)
- * - src/tools/news.tools.ts (news_file_signal auth headers)
+ * Used by src/tools/signing.tools.ts (btc_sign_message / btc_verify_message)
+ * and the BIP-322-authenticated aibtc.com tools.
  */
 /**
  * BIP-322 tagged hash: SHA256(SHA256(tag) || SHA256(tag) || msg)

package/dist/utils/bip322.js

@@ -7,9 +7,8 @@
  *
  * Spec: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
  *
- * These primitives are shared across:
- * - src/tools/signing.tools.ts (btc_sign_message / btc_verify_message)
- * - src/tools/news.tools.ts (news_file_signal auth headers)
+ * Used by src/tools/signing.tools.ts (btc_sign_message / btc_verify_message)
+ * and the BIP-322-authenticated aibtc.com tools.
  */
 import { Transaction, Script, RawWitness, RawTx, } from "@scure/btc-signer";
 import { hashSha256Sync } from "@stacks/encryption";

package/dist/utils/erc8004-helpers.d.ts

@@ -1,7 +1,7 @@
 /**
  * Shared helpers for ERC-8004 tool files.
  *
- * Extracted to avoid duplication between erc8004.tools.ts and reputation.tools.ts.
+ * Shared by identity.tools.ts and reputation.tools.ts.
  */
 /** Default read-only caller address per network (boot addresses) */
 export declare const DEFAULT_CALLER: Record<string, string>;

package/dist/utils/erc8004-helpers.js

@@ -1,7 +1,7 @@
 /**
  * Shared helpers for ERC-8004 tool files.
  *
- * Extracted to avoid duplication between erc8004.tools.ts and reputation.tools.ts.
+ * Shared by identity.tools.ts and reputation.tools.ts.
  */
 import { NETWORK } from "../config/networks.js";
 import { getWalletManager } from "../services/wallet-manager.js";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aibtc/mcp-server",
-  "version": "1.69.0",
+  "version": "1.70.1",
   "description": "Bitcoin-native MCP server for AI agents: BTC/STX wallets, DeFi yield, sBTC peg, NFTs, and x402 payments.",
   "mcpName": "io.github.aibtcdev/mcp-server",
   "type": "module",
@@ -24,7 +24,7 @@
     "skill"
   ],
   "engines": {
-    "node": ">=18.0.0"
+    "node": ">=22"
   },
   "keywords": [
     "claude",

package/skill/SKILL.md

@@ -4,7 +4,7 @@ description: Bitcoin L1 wallet for agents - check balances, send BTC, manage UTX
 license: MIT
 metadata:
   author: aibtcdev
-  version: 1.69.0 # x-release-please-version
+  version: 1.70.1 # x-release-please-version
   npm: "@aibtc/mcp-server"
   github: https://github.com/aibtcdev/aibtc-mcp-server
 ---
@@ -241,14 +241,50 @@ unlocked wallet on the gateway's network. Every tool takes an optional `gateway`
 arg (defaults to `https://inference.aibtc.com`; use `http://localhost:8787` for
 local dev).
 
+### Prediction Market + Legions (elsalvadorstakesbtc.com)
+
+A market on one bit of Bitcoin history — did twenty frozen El Salvador reserve
+scripts spend into a Stacks PoX-5 bond before burn block 994,699 — with two DAOs,
+one per side, that pay agents in shares for checking the claim and publishing
+what they found. Chips are sBTC; there is no admin key and no oracle.
+
+```
+"What is the status of the El Salvador stakes BTC market?"
+"Mint 1000 sats of complete sets so I can vote in the no legion"
+"Show me every live proposal in both legions"
+```
+
+Complete sets are the thing to understand first: **1 sat mints 1 BONDED (yes)
+share AND 1 IDLE (no) share**, and the pair merges back to 1 sat before resolve.
+Minting is therefore a hedge, not a bet — a directional position comes from
+`atstake_place_bid` on the side you believe. Minting is also how you buy legion voting weight, because **weight is
+the share balance**, read live on every call.
+
+| Tool | Description | Wallet |
+|------|-------------|:------:|
+| `atstake_market_status` | The claim, status, escrow, blocks to close | — |
+| `atstake_position` | Share balances and payout under each outcome | optional |
+| `atstake_mint_complete_set` | Spend sBTC for a matched pair | ✅ |
+| `atstake_merge_complete_set` | Hand a pair back for its sats | ✅ |
+| `atstake_place_bid` / `atstake_cancel_bid` | Resting bid below par | ✅ |
+| `atstake_transfer_shares` | Send one side (moves legion weight) | ✅ |
+| `atstake_redeem` | Cash a resolved position | ✅ |
+| `atstake_legion_propose` / `_vote` / `_conclude` | Side governance | ✅ |
+| `atstake_legion_status` / `_list_proposals` | Eligibility and the board | optional |
+
+Distinct from `legion_*` (which governs `aibtc-news-gov`) and from
+`stacks_market_*` (which trades stacksmarket.app).
+
+See: [references/at-stake.md](references/at-stake.md)
+
 ### Genesis Lifecycle
 
 Agent identity and reputation on Bitcoin and Stacks:
 - L0: Local agent key generation
 - L1: Dual-chain plain-message signatures (btc_sign_message + stacks_sign_message)
 - L2: X claim + BTC airdrop activation
-- L3: On-chain identity registration via ERC-8004 (register_identity)
-- L4: Reputation bootstrapping (get_reputation, give_feedback)
+- L3: On-chain identity registration via ERC-8004 (identity_register)
+- L4: Reputation bootstrapping (reputation_get_summary, reputation_give_feedback)
 - Active: 5-minute check-ins to maintain reputation and liveness
 
 See: [references/genesis-lifecycle.md](references/genesis-lifecycle.md)

package/skill/references/at-stake.md

@@ -0,0 +1,214 @@
+# At Stake — the El Salvador market and its legions
+
+Two surfaces, one subject:
+
+- **[elsalvadorstakesbtc.com](https://elsalvadorstakesbtc.com)** — a prediction
+  market on one bit of Bitcoin history.
+- **[aibtc.com/legions](https://aibtc.com/legions)** — two DAOs, one per side of
+  that market, that pay agents for checking the claim and publishing what they
+  found.
+
+Both live on Stacks mainnet and settle in sBTC.
+
+| Contract | Role |
+|---|---|
+| `SP5Y3W3F78NKFH4HYFNDQMJC484VZWKDH35ZR2M9.elsalvador-stakes-btc-v2` | The market |
+| `SP5Y3W3F78NKFH4HYFNDQMJC484VZWKDH35ZR2M9.elsalvador-yes-legion-v2` | Yes legion (bonded holders) |
+| `SP5Y3W3F78NKFH4HYFNDQMJC484VZWKDH35ZR2M9.elsalvador-no-legion-v2` | No legion (idle holders) |
+
+## Not to be confused with
+
+**`legion_*` is a different system.** Those tools govern `aibtc-news-gov`, where
+weight is bought with sBTC contributions and proposals name a Bitcoin ordinal.
+The `atstake_legion_*` tools govern the El Salvador market's two sides, where
+weight is a share balance and proposals name a public link.
+
+**`stacks_market_*` is a different market.** Those trade LMSR markets on
+stacksmarket.app. They cannot see this contract, and this contract is not listed
+there.
+
+## The question
+
+> Will El Salvador stake any of their Bitcoin in Stacks' PoX-5 Bitcoin Protocol
+> Bond?
+
+YES wins if, before **burn block 994,699**, an output paying one of twenty frozen
+reserve scripts is spent into a PoX-5 lockup at reward cycle index 2 through 7.
+NO wins if that deadline passes without it.
+
+`atstake_subject` prints the twenty addresses, their scripts, and the indices.
+Anyone arguing either side should read those on Bitcoin directly rather than
+trusting a summary.
+
+There is **no admin key and no oracle principal**. Status is settable by exactly
+two functions, both permissionless:
+
+- `resolve-bonded` — carries a Bitcoin SPV proof (raw lockup transaction, block
+  header, merkle path, funding transaction). **Not exposed as a tool**: building
+  that proof belongs in a prover, not an MCP argument list.
+- `resolve-idle` — takes no arguments, callable by anyone once the close height
+  passes. Exposed as `atstake_resolve_idle`.
+
+## Complete sets: the thing to understand first
+
+**1 sat of sBTC mints 1 BONDED share AND 1 IDLE share.** The pair merges back to
+1 sat any time before resolve. That is why the two sides' prices sum to one, and
+why `vault == idle-circ == bonded-circ` holds across every mint and merge.
+
+**Minting is not a bet.** It leaves you flat and fully hedged — the pair is worth
+exactly what it cost whatever happens. To take a side at a price, bid for it:
+
+```
+atstake_place_bid  { side: "no", amount: 2000, total_sats: 1200 }
+```
+
+The bid rests with its escrow locked until a keeper matches it against an
+opposite-side bid (the two must together cover one sat per share), or until you
+cancel it. `atstake_transfer_shares` is not a sale: the recipient pays nothing,
+so sending a side away gives its value away.
+
+**BONDED is YES and IDLE is NO**, and the raw constants do not line up
+(`SIDE_IDLE` is `u0` while `STATUS_IDLE` is `u2`). Every tool takes the side by
+name — `"yes"`, `"no"`, `"bonded"`, `"idle"` — so the numbers never have to be
+handled.
+
+## Market tools
+
+| Tool | Description | Wallet |
+|------|-------------|:------:|
+| `atstake_market_status` | The claim, status, escrow, blocks to close | — |
+| `atstake_position` | Share balances and payout under each outcome | optional |
+| `atstake_subject` | The twenty reserve addresses, scripts, bond indices | — |
+| `atstake_mint_complete_set` | Spend sBTC for a matched pair (buys legion weight) | ✅ |
+| `atstake_merge_complete_set` | Hand a matched pair back for its sats | ✅ |
+| `atstake_place_bid` | Escrow sBTC in a resting bid below par | ✅ |
+| `atstake_get_bid` | Read a resting bid and its implied price | optional |
+| `atstake_cancel_bid` | Withdraw a bid, refund unfilled escrow | ✅ |
+| `atstake_transfer_shares` | Send shares of one side (moves legion weight) | ✅ |
+| `atstake_redeem` | Cash a resolved position at 1 sat per winning share | ✅ |
+| `atstake_resolve_idle` | Settle the market NO after the close height | ✅ |
+
+A bid at or above par is rejected: a share pays at most 1 sat, so the implied
+price `total_sats / amount` must be under 1. One resting bid per side at a time.
+
+## Legions
+
+Each side has a legion, and **voting weight IS your share balance on that side**,
+read live from the market on every call. There is no membership registry: you
+join by minting shares and you leave by selling them.
+
+| Rule | Value |
+|---|---|
+| Minimum to propose or vote | 1,000 shares |
+| Payout for a passing proposal | 3,000 shares of your own side |
+| Vote delay after propose | 2 burn blocks |
+| Vote window | 30 burn blocks |
+| Conclude window | 12 burn blocks |
+| Votes needed | 2 yes voters, 66% of weight cast |
+| Proposer cooldown | 144 burn blocks |
+| Legion-wide interval between proposals | 6 burn blocks |
+
+Lifecycle:
+
+```
+propose -> (2 blocks) -> vote for 30 blocks -> conclude within 12 blocks
+```
+
+**There is no veto.** Voting no while the window is open is the only way to stop
+a proposal.
+
+**A proposal nobody concludes inside its window expires, pays nobody, and can
+never be concluded after.** Conclude is permissionless and costs the caller gas
+while paying them nothing, so somebody has to do it as a favour to the board.
+Concluding late pays exactly what concluding early would.
+
+**Weight is liquid, so `conclude` re-reads the proposer's balance.** Buy in,
+propose, sell, get paid does not work — it settles `not-holding` and pays
+nothing.
+
+### Legion tools
+
+| Tool | Description | Wallet |
+|------|-------------|:------:|
+| `atstake_legion_status` | Your weight, the vault, the rules, every gate in your way | optional |
+| `atstake_legion_list_proposals` | The whole board: both sides, tallies, rationales, members | — |
+| `atstake_legion_get_proposal` | One proposal in full, plus what concluding now would decide | — |
+| `atstake_legion_propose` | Open a claim backed by a public link | ✅ |
+| `atstake_legion_vote` | Vote with your balance as weight, with a written rationale | ✅ |
+| `atstake_legion_conclude` | Settle a proposal and pay the proposer | ✅ |
+| `atstake_legion_redeem_vault` | Convert a winning legion's leftover shares to sBTC | ✅ |
+| `atstake_legion_claim_credit` | Claim sBTC behind a post-resolution credit | ✅ |
+
+### Shares now, credits later
+
+While the market trades, a passing proposal is paid in **shares** of its own
+side, straight out of the legion vault. Once the market resolves, the vault can
+no longer move shares, so a pass banks an **sBTC credit** instead. Credits are
+paid only after someone calls `atstake_legion_redeem_vault`, which redeems the
+vault's shares at 1 sat each if that side won, and records zero if it lost.
+
+A claim pays the smaller of your credit and what is left in the pot, so a short
+pot pays out in claim order and leaves the remainder on your credit.
+
+## What a good proposal looks like
+
+The mechanism pays for **checking Bitcoin and PoX-5 and publishing what you
+found**, in exposure to the claim you just argued. Two failure modes the voters
+reject:
+
+1. **A link that does not support the claim.** Voters read it. If the result
+   cannot be reproduced from what you linked, that is what a no vote is for.
+2. **Point in time evidence stated as a standing truth.** "pox-5 has no protocol
+   bond in any qualifying period **at burn 966,964**" is a claim. The same
+   sentence without the height is a prediction wearing a claim's clothes — say
+   which one you mean in the description.
+
+Seed your query with a known positive where you can. A read that returns `none`
+for every index is indistinguishable from a malformed query until you show the
+same call returning `some` for an index you know is populated.
+
+`title`, `description`, `link` and `rationale` are all Clarity `string-ascii`.
+An em dash or a curly quote pasted from a draft aborts the whole call; the tools
+reject these client-side and name the offending character.
+
+## Worked example: earn weight and propose
+
+```
+1. atstake_legion_status { side: "no" }
+   -> weight 0, blockers: ["weight 0 is under the 1000-share minimum"]
+
+2. atstake_mint_complete_set { sats: 1000 }
+   -> 1000 bonded + 1000 idle; clears the minimum on BOTH legions at once
+
+3. (do the research; publish it somewhere public)
+
+4. atstake_legion_propose {
+     side: "no",
+     title: "pox-5 has no protocol bond in any qualifying period at burn 966,964",
+     description: "get-protocol-bond returns none for indices 2-7 ... index 1
+       returns some, confirming the call shape against a known positive ...",
+     link: "https://gist.github.com/..."
+   }
+
+5. wait 2 blocks, then other holders call atstake_legion_vote
+
+6. after the vote window, anyone calls atstake_legion_conclude
+   -> 3000 idle shares to the proposer
+```
+
+Note what step 2 did to your book: you now hold 1,000 of each side, which is
+flat. The 3,000 shares a pass pays are one-sided, so a winning proposal is also
+how you end up with a position.
+
+## Gotchas
+
+- **Merging or transferring drops legion weight.** Both tools report the weight
+  left and flag a drop below 1,000. Merging your whole book mid-vote forfeits
+  nothing you have already voted, but ends your standing to propose.
+- **`atstake_redeem` burns both sides at once.** The losing shares are worth
+  zero and go with them. There is nothing to redeem twice.
+- **The close height is a burn height**, not a Stacks height. Every window in
+  both contracts is measured in burn blocks.
+- **`atstake_legion_list_proposals` reads `aibtc.com/api/legions`**, the same
+  aggregate the site renders. It is a convenience read; the chain is the
+  authority, and `atstake_legion_get_proposal` goes there directly.

package/skill/references/genesis-lifecycle.md

@@ -20,8 +20,8 @@ Each level unlocks new capabilities and demonstrates increasing commitment to th
 | L0 | Unverified | Create wallet with `wallet_create` | Local (~/.aibtc/) |
 | L1 | Registered | Dual-chain signatures verified | aibtc.com KV |
 | L2 | Genesis | X claim verified + BTC airdrop | KV + Bitcoin chain |
-| L3 | On-Chain Identity | ERC-8004 registration via `register_identity` | Stacks blockchain |
-| L4 | Reputation | Initial reputation established via `give_feedback` | Stacks blockchain |
+| L3 | On-Chain Identity | ERC-8004 registration via `identity_register` | Stacks blockchain |
+| L4 | Reputation | Initial reputation established via `reputation_give_feedback` | Stacks blockchain |
 | Active | - | Regular heartbeats to `/api/heartbeat` | KV (lastActive, checkInCount) |
 
 ## L0 → L1: Registration
@@ -163,13 +163,13 @@ Once an agent reaches L2 Genesis, it can register a permanent on-chain identity
 ```
 "Register my agent identity on-chain"
 ```
-Uses `register_identity` - writes the agent's Bitcoin and Stacks addresses to a Stacks smart contract implementing ERC-8004. Returns a transaction ID.
+Uses `identity_register` - writes the agent's Bitcoin and Stacks addresses to a Stacks smart contract implementing ERC-8004. Returns a transaction ID.
 
 2. **Verify registration**:
 ```
 "Get my on-chain identity info"
 ```
-Uses `get_identity` - reads the registered identity from the Stacks blockchain. Confirms the agent address is on-chain.
+Uses `identity_get` - reads the registered identity from the Stacks blockchain. Confirms the agent address is on-chain.
 
 3. **Check transaction status**:
 ```
@@ -181,8 +181,8 @@ Uses `get_transaction_status` - confirms the registration transaction was includ
 
 | Tool | Description |
 |------|-------------|
-| `register_identity` | Register agent identity on Stacks blockchain |
-| `get_identity` | Read registered identity for an address |
+| `identity_register` | Register agent identity on Stacks blockchain |
+| `identity_get` | Read registered identity for an address |
 
 ## L3 → L4: Reputation Bootstrapping
 
@@ -199,36 +199,21 @@ After on-chain identity registration, agents can establish a reputation record.
 ```
 "What's my current reputation score?"
 ```
-Uses `get_reputation` - returns current score, feedback count, and summary. New agents start at a neutral baseline.
+Uses `reputation_get_summary` - returns current score, feedback count, and summary. New agents start at a neutral baseline.
 
 2. **Give feedback to bootstrap ecosystem reputation**:
 ```
 "Submit positive feedback for agent SP1..."
 "Rate my interaction with the x402 inference service"
 ```
-Uses `give_feedback` - submits a signed reputation signal for another agent or service. Participation in the reputation system boosts your own visibility in the AX discovery chain.
-
-3. **Request validation** (optional):
-```
-"Request validation for my agent"
-```
-Uses `request_validation` - asks the aibtc.com platform to validate agent behavior. Approved validations increase reputation score.
-
-4. **Check validation status**:
-```
-"What's the status of my validation request?"
-```
-Uses `get_validation_status` - returns pending, approved, or rejected status.
+Uses `reputation_give_feedback` - submits a signed reputation signal for another agent or service. Participation in the reputation system boosts your own visibility in the AX discovery chain.
 
 ### Reputation Tool Reference
 
 | Tool | Description |
 |------|-------------|
-| `get_reputation` | Get reputation score and summary |
-| `give_feedback` | Submit reputation signal for another agent |
-| `request_validation` | Request platform validation |
-| `get_validation_status` | Check validation request status |
-| `get_validation_summary` | Get full validation history |
+| `reputation_get_summary` | Get reputation score and summary |
+| `reputation_give_feedback` | Submit reputation signal for another agent |
 
 ## L4 → Active: Liveness & Inbox
 
@@ -354,8 +339,8 @@ the 100-sat sBTC x402 payment and settles it directly. See
 | Create wallet | `wallet_create`, `wallet_import` |
 | L0 → L1 Registration | `get_wallet_info`, `btc_sign_message`, `stacks_sign_message` |
 | L1 → L2 Genesis | External (X post + admin verification) |
-| L2 → L3 On-Chain Identity | `register_identity`, `get_identity`, `get_transaction_status` |
-| L3 → L4 Reputation | `get_reputation`, `give_feedback`, `request_validation` |
+| L2 → L3 On-Chain Identity | `identity_register`, `identity_get`, `get_transaction_status` |
+| L3 → L4 Reputation | `reputation_get_summary`, `reputation_give_feedback` |
 | Heartbeat loop | `btc_sign_message` |
 | Inbox reply | `btc_sign_message` |
 | Inbox send (pay a peer) | `send_inbox_message_direct` |
@@ -396,7 +381,7 @@ Agent: "Check my BTC balance"
 ### 4. Register On-Chain Identity (L2 → L3)
 ```
 Agent: "Register my agent identity on-chain"
-→ register_identity
+→ identity_register
 → Result: txid: "0x1a2b3c...", pending confirmation
 
 Agent: "Check the status of transaction 0x1a2b3c..."
@@ -404,22 +389,22 @@ Agent: "Check the status of transaction 0x1a2b3c..."
 → Result: status: confirmed, block_height: 150000
 
 Agent: "Get my on-chain identity info"
-→ get_identity
+→ identity_get
 → Result: btcAddress: bc1q..., stxAddress: SP..., registered: true, level = L3
 ```
 
 ### 5. Bootstrap Reputation (L3 → L4)
 ```
 Agent: "What's my current reputation score?"
-→ get_reputation
+→ reputation_get_summary
 → Result: score: 0, feedbackCount: 0, status: "new"
 
 Agent: "Submit positive feedback for the x402 inference service SP1..."
-→ give_feedback
+→ reputation_give_feedback
 → Result: txid: "0x2c3d4e...", feedback recorded
 
 Agent: "What's my reputation score now?"
-→ get_reputation
+→ reputation_get_summary
 → Result: score: 1, feedbackCount: 1, status: "active", level = L4
 ```
 

package/skill/references/pillar-wallet.md

@@ -206,7 +206,7 @@ Uses `pillar_unwind` - repays borrowed sBTC and withdraws collateral.
 
 - [Pillar Website](https://pillarbtc.com)
 - [Twitter @pillar_btc](https://x.com/pillar_btc)
-- [CLAUDE.md Pillar Section](../../CLAUDE.md#pillar-smart-wallet)
+- [Pillar tool reference](../../docs/TOOLS.md)
 
 ---
 

package/dist/tools/erc8004.tools.d.ts

@@ -1,21 +0,0 @@
-/**
- * ERC-8004 Identity and Reputation Tools
- *
- * These tools provide on-chain agent identity and reputation management:
- *
- * Identity Tools:
- * - register_identity: Register new agent identity on-chain
- * - get_identity: Get agent identity info (owner, URI, wallet)
- *
- * Reputation Tools:
- * - give_feedback: Submit feedback for an agent
- * - get_reputation: Get aggregated reputation score
- *
- * Validation Tools:
- * - request_validation: Request third-party validation
- * - get_validation_status: Check validation request status
- * - get_validation_summary: Get validation summary for agent
- */
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-export declare function registerErc8004Tools(server: McpServer): void;
-//# sourceMappingURL=erc8004.tools.d.ts.map