@blindmarket/mcp-server 0.5.0 → 0.6.0

package/README.md

@@ -31,7 +31,7 @@ Environment:
 |---|---|---|
 | `BLINDMARKET_API_KEY` | yes | `sk_…` key from the web app (Settings → API keys). On **Arc** and **0G**, create it while signed in with the SAME wallet as `BLINDMARKET_PRIVATE_KEY`: tasks are posted and delivered as the key's wallet, so escrow funded from a different wallet is rejected at indexing (`NOT_TASK_AGENT`). On Arc this is checked before anything is sent (`OWNER_MISMATCH`). On **Base** the key is the whole identity: the relay signs from the wallet that minted the key, which must be a Privy embedded wallet (what the web app creates on login). |
 | `BLINDMARKET_PRIVATE_KEY` | Arc and 0G: yes · Base: for private briefs | On **Arc** this wallet approves and funds USDC escrow, pays gas in USDC, signs refunds, and signs `submitEvidence` for `complete_task`. On **0G** it does the same in native 0G. On **Base** nothing is *signed* locally, because the relay does that. The key is still the executor's **decryption identity** everywhere: `fetch_brief` unwraps a private brief with it, so the pubkey you pass to `register_as_executor` must be the one `wallet_status` reports as `executorPublicKey`. Omit it only for read-only use. |
-| `BLINDMARKET_ARC_RPC_URL` | no | Arc RPC the local wallet signs over. Default `https://rpc.testnet.arc.io` for Arc Testnet (5042002). It is checked to serve the chain id the backend names before anything is signed (`WRONG_RPC`). |
+| `BLINDMARKET_ARC_RPC_URL` | no | Arc RPC the local wallet signs over. Default by the chain id the backend names for `arc`: `https://rpc.mainnet.arc.io` (Arc mainnet, 5042) / `https://rpc.testnet.arc.io` (Arc Testnet, 5042002). It is checked to serve that chain id before anything is signed (`WRONG_RPC`). |
 | `BLINDMARKET_API_BASE` | no | Default `https://api.blindmarket.xyz` |
 | `BLINDMARKET_RPC_URL` | no | 0G RPC for the local wallet. Default `https://evmrpc.0g.ai` |
 | `BLINDMARKET_SETTLEMENT` | no | A chain key to require (`arc`, `base`, `0g`, …). Default: ask the backend (`GET /health/bridge`). A backend that names its posting chain (`postingChain`) is followed: new tasks are escrowed there, and that chain's settlement token picks how you pay. An ERC-20 the relay serves (USDC on Base) goes through the relay. An ERC-20 on a chain with no relay (USDC on Arc) is signed by the local wallet. Native 0G comes from the local wallet. Anything else is refused with `UNSUPPORTED_SETTLEMENT`. Forcing `0g` against a backend that posts elsewhere is refused before the quote (`NOT_POSTING_CHAIN`). An older backend is read as before: `base` whenever it has a Base escrow and a Base marketplace signer configured. `0g` skips discovery; any other value fails loudly unless the backend really posts there. |
@@ -80,9 +80,10 @@ claude mcp add blindmarket \
   -- node /path/to/BlindBounty/mcp/dist/index.js
 ```
 
-The key must be the wallet that minted the `sk_` key, holding USDC on Arc
-Testnet for escrow and gas. `wallet_status` should then show
-`payment: "local-erc20"` and `mode: "arc"`.
+The key must be the wallet that minted the `sk_` key, holding USDC for escrow
+and gas on the Arc network the backend settles on: Arc mainnet (chain 5042) or
+Arc Testnet (5042002). `wallet_status` should then show
+`payment: "local-erc20"`, `mode: "arc"` and that `chainId`.
 
 **Claude Code: Base (no private key)**
 
@@ -151,16 +152,53 @@ Spending (local wallet, **two-step quote → confirm**):
   key is read from `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `GROQ_API_KEY` or
   `GEMINI_API_KEY` in this server's environment, never taken as an argument;
   `0g-compute` needs none. Arc's RPC is `BLINDMARKET_ARC_RPC_URL`, default
-  `https://rpc.testnet.arc.io` on Arc Testnet.
+  `https://rpc.mainnet.arc.io` on Arc mainnet (5042) and
+  `https://rpc.testnet.arc.io` on Arc Testnet (5042002).
+
+A `quoteId` authorizes exactly the spend it quoted: the amount in base units,
+the chain, escrow, token and paying wallet, the `idempotencyKey`, and the
+service and its price (`rent_service`), the brief, duration and capabilities
+(`post_task`), the task and its escrow (`cancel_task`, `claim_timeout`), or the
+agent and the fee terms (`deploy_agent`). The confirm re-derives all of it
+after its lookups and, if anything differs (a provider re-priced its listing,
+the fee changed, the call names another amount or task), refuses with
+`QUOTE_MISMATCH` before anything is uploaded, approved or sent. Quotes are
+single-use either way: get a new quote, check it, and confirm that one. The
+confirm's result reports the amount escrowed (`escrowed`) or the fee paid.
+
+`claim_timeout` refunds a task whose worker never delivered. On work delivered
+before the deadline and never judged it refunds nothing: the escrow sends the
+task for review (an admin rules, and with no ruling within 14 days the worker
+is paid), the quote says so in `note`, and the result reports
+`outcome: "escalate"`.
+
+The backend builds the escrow transactions this process signs (or hands to
+the relay): `createTask`, `cancelTask` / `claimTimeout` and `submitEvidence`.
+Each is decoded first and must be exactly the call the spend asked for (this
+task hash, token, amount and duration; this task id; this task and the
+evidence hash of the output being delivered) on the expected escrow, with no
+other value, or it is refused with `TX_MISMATCH` (`ESCROW_MISMATCH` for
+another target, `CHAIN_MISMATCH` for another chain id) and nothing is sent.
+Only `to` and `data` are forwarded.
 
 Every spend requires an `idempotencyKey`. Retries with the same key **resume**
 (created → funded → indexed stage machine persisted in
 `~/.blindmarket/mcp-state.json`) — a crash between the funding transaction and
 indexing never double-pays; re-calling re-runs the index step with the saved
 transaction hash. A funded spend finishes even when the settlement chain can't
-be discovered at that moment, since listing it needs no signature. `deploy_agent` records its fee transaction the moment it is
-broadcast, so a failed deploy retried with the same key deploys with that
-payment instead of paying again.
+be discovered at that moment, since listing it needs no signature. A retry
+that would still sign (nothing funded, no refund sent) continues only on the
+network the spend started on. The record keeps the chain id, because a chain
+key names one network at a time: `arc` is Arc Testnet (5042002) or Arc mainnet
+(5042), whichever the backend runs. On another network, or for a record
+written before chain ids were kept, the retry answers `SETTLEMENT_CHANGED` and
+nothing is sent. `deploy_agent` records its fee transaction, and its chain id,
+the moment it is broadcast, so a failed deploy retried with the same key
+deploys with that payment instead of paying again. Once the backend takes the
+fee on another network, that payment does not count there, and the retry
+answers `SETTLEMENT_CHANGED` and asks for a new key. A fee recorded without its
+chain id that the backend cannot find is looked up on the fee chain: when it is
+there the same key finishes the deploy, and when it is not the retry says so.
 
 ## Executor runtime tools (gated off)
 
@@ -173,12 +211,16 @@ that loop is verified against stubbed backends only — not yet end to end on a
 live one. It signs `submitEvidence` **locally** (no relay): it needs
 `BLINDMARKET_PRIVATE_KEY` to be the wallet that owns `BLINDMARKET_API_KEY`, and
 an RPC for the settlement chain (`BLINDMARKET_RPC_URL` for 0G,
-`BLINDMARKET_BASE_RPC_URL` for Base — there is no default for Base, and tasks
+`BLINDMARKET_BASE_RPC_URL` for Base, `BLINDMARKET_ARC_RPC_URL` for Arc — there
+is no default for Base or Arc here, and tasks
 on a chain without an RPC are skipped by the runtime itself: older backends
 store the declared `supportedChains` without filtering offers or `/accept` by
 it).
 Without `BLINDMARKET_PRIVATE_KEY` the runtime refuses to start (SDK 0.6.0) —
-it no longer registers a throwaway wallet. `BLINDMARKET_EXPERIMENTAL_RUNTIME=true`
+it no longer registers a throwaway wallet. `BLINDMARKET_EXECUTOR_MIN_REWARD`
+is the per-task floor, a whole number of USDC base units (`1000000` = 1 USDC):
+the runtime claims only tasks whose listing records a USDC reward of at least
+that much, and skips listings with no recorded reward (unset takes every task). `BLINDMARKET_EXPERIMENTAL_RUNTIME=true`
 enables it. The maintained way to EARN is still a platform agent deployed in
 the web app, operated via the remote MCP endpoint's `start_agent` /
 `stop_agent` / `get_agent_logs` tools.

package/dist/rent.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"rent.d.ts","sourceRoot":"","sources":["../src/rent.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AAGzE,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAC7C,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAG7C,OAAO,EAEkE,KAAK,UAAU,EACvF,MAAM,iBAAiB,CAAC;AAmDzB,wBAAgB,iBAAiB,CAAC,MAAM,EAAE,SAAS,EAAE,GAAG,EAAE,SAAS,EAAE,SAAS,EAAE,SAAS,GAAG,IAAI,GAAG;IAAE,UAAU,EAAE,MAAM,OAAO,CAAC,UAAU,CAAC,CAAA;CAAE,CAwgD3I"}
+{"version":3,"file":"rent.d.ts","sourceRoot":"","sources":["../src/rent.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AAGzE,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAC7C,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAM7C,OAAO,EAEkE,KAAK,UAAU,EACvF,MAAM,iBAAiB,CAAC;AAkIzB,wBAAgB,iBAAiB,CAAC,MAAM,EAAE,SAAS,EAAE,GAAG,EAAE,SAAS,EAAE,SAAS,EAAE,SAAS,GAAG,IAAI,GAAG;IAAE,UAAU,EAAE,MAAM,OAAO,CAAC,UAAU,CAAC,CAAA;CAAE,CAssD3I"}