# Batchloom buyer quickstart The local buyer now includes a working viem EIP-3009 adapter. An agent operator can prepare, explicitly buy, and recover a saved purchase with the same command-line program. The hosted API never receives the wallet key. Keep `evidence-cli.mjs`, `viem-buyer-signer.mjs`, `viem-env-signer.mjs`, `bridge.mjs`, `evidence-client.mjs` and the bridge `package.json` together in a trusted local directory. The package requires Node.js 20+ and the pinned `viem` 2.56.3 dependency, alongside the existing dependencies. Inspect downloaded code before running it. ```sh npm install node evidence-cli.mjs --help node evidence-cli.mjs --input request.json ``` The default command is a free preparation request. It neither reads a key nor requests payment. `request.json` contains the ordinary evidence input unchanged; input validation, price pinning and receipt management remain in the existing client. For a new authorized purchase, have the buyer's local secret manager inject `BUYER_PRIVATE_KEY` into the buyer process environment, then run: ```sh node evidence-cli.mjs --buy --input request.json --intent research-001 --max-price 0.01 --receipts /private/receipts ``` `--buy` explicitly authorizes at most one new signature for 0.01 native USDC on Base. `--intent` is a stable ID for this input and snapshot. The payer must already own a funded compatible local EOA; this adapter does not create a wallet, move funds or provide RPC access. Key material belongs only in the local process environment. Do not put a private key in command arguments, source files, JSON inputs, chat, MCP messages or a hosted service. A process environment is not an encrypted key vault: use a buyer-controlled OS account and secret manager, and do not dump its environment. After an unresolved response, recover with the original input, intent and private receipt directory: ```sh node evidence-cli.mjs --recover --input request.json --intent research-001 --max-price 0.01 --receipts /private/receipts ``` Recovery loads no signer and needs no private key. Never delete receipts or create a replacement intent to retry an uncertain payment. A new input or intentionally new snapshot needs a separately authorized intent and may spend another 0.01 USDC. File modes do not establish Windows ACL privacy; select an OS-protected local receipt directory off shared or synced storage. Output is one JSON MCP-compatible result with separate financial and delivery statuses. An unresolved result is not proof of no payment. Nonzero command exit means inspect the result and preserve the original receipt; it must not cause an automatic new purchase. There are no background retries, timers or scheduled purchases. ## Use the ready-made signer with local MCP Start from the supplied `viem-bridge-config.example.json`, whose purchase limit is zero. At zero, the existing bridge CLI does not import a signer. To authorize one new purchase in that local bridge process, the buyer operator sets `maxPurchaseIntentsPerProcess` to 1 and injects these environment values through their secret manager: | Local environment name | Meaning | | --- | --- | | `BUYER_PRIVATE_KEY` | The buyer's existing local EOA key; never sent as a tool argument. | | `BUYER_PURCHASE_AUTHORIZED` | Must equal `true` before the adapter can initialize. | | `BUYER_MAX_PRICE` | Must equal `0.01`. | The agent then calls `purchase_evidence` with explicit `input`, `intentId` and `maxPrice:"0.01"`. For recovery only, remove `signerModule` from the configuration while keeping the original receipt directory and at least one intent slot. The adapter signs only the current x402 v2 `TransferWithAuthorization` structure for domain `USD Coin`, version `2`, chain 8453, native USDC contract `0x833589fcd6edb6e08f4c7c32d4f71b54bda02913`, recipient `0x609f8d893c270c5ec0d909660c7d01df94fc01ea`, exactly 10000 atomic units, and an expiry within 300 seconds. It cannot sign a transaction, Permit2 approval, arbitrary message, another token or another recipient. It allows one signature attempt per adapter instance. Restarting the process or creating another instance resets that limit; it is not a persistent financial budget. References: viem's [privateKeyToAccount](https://viem.sh/docs/accounts/local/privateKeyToAccount) and [local signTypedData](https://viem.sh/docs/accounts/local/signTypedData). Compatibility was also checked against the installed official `@x402/evm` 2.25.0 implementation.