Use ClaimRush with an AI assistant (Base MCP)

TL;DR — Compatible AI assistants on Base can call ClaimRush directly. You still sign every transaction yourself; the assistant only prepares the calldata. No private keys are ever shared.

ClaimRush ships a Base MCP plugin so any AI assistant that speaks Base’s Model Context Protocol (Coinbase Wallet’s agent mode, the Base AI sandbox, and any custom MCP-aware client) can read your protocol state and prepare actions on your behalf. The assistant produces unsigned calldata; your wallet prompts you once to approve the batch and signs it locally.

What you can ask the assistant to do

Reads — “What does my ClaimRush account look like?”, “Has genesis finalized yet?”, “What would 1,000 CLAIM into a 180-day lock give me?”
Royalties — “Collect my royalties to ETH.”, “Collect and compound my royalties into a 90-day lock.”
LP staking — “Harvest my LP rewards.”, “Stake 500 LP.”, “Start unbonding 250 LP.”, “Withdraw my matured unbond.”
Locks — “Lock 1,000 CLAIM for 365 days at AutoMax.”, “Top up my veCLAIM lock #7 with 250 CLAIM.”, “Extend my veCLAIM lock #7 by 60 days.”
Furnace — “Lock 250 CLAIM via the Furnace for 30 days at 0.5% slippage.”

The assistant uses Base MCP’s send_calls to hand the prepared batch to your wallet. You see one prompt with every step listed; approve once and the entire sequence executes atomically.

How the safety model works

The ClaimRush plugin runs on Cloudflare. It NEVER signs, NEVER holds private keys, and NEVER broadcasts transactions.
Each “prepare” endpoint returns plain JSON containing the to, data, and value of every step. Your wallet sees the full batch before you sign.
Every action is gated by the same on-chain checks the regular web app uses.
Where an ERC-20 approval is needed (CLAIM into the Furnace, LP into the staking vault, CLAIM into the veCLAIM contract), the prepare endpoint reads your current allowance and only inserts an approve step when it’s actually needed. The approval is for the exact amount of the action — never unlimited.
For Furnace lock-via-Furnace actions the plugin pre-quotes via the on-chain FurnaceQuoter and applies a slippage floor (default 0.5%, configurable via slippageBps) with the same minVeOut ≥ 1 wei UX clamp the web app uses, so a buggy assistant prompt cannot accidentally drop your slippage protection.

The wallet is always the final gatekeeper. Read every batch your wallet shows you before signing. If the assistant prepared the wrong action, cancel at the wallet prompt — nothing reaches the chain.

Getting started

You don’t need to install anything. The plugin is published as a Base MCP skill that compatible assistants pick up automatically:

Use a Base-MCP-capable assistant (Coinbase Wallet’s agent mode, the Base AI sandbox, or any chat that lists ClaimRush as an available plugin).
Connect the wallet that holds your CLAIM / veCLAIM / LP positions.
Ask the assistant what you’d like to do in plain language. The assistant will quote the action, list the steps, and call send_calls so your wallet can prompt you to sign.

If your wallet does NOT show a send_calls batch prompt, the plugin is not yet wired into that wallet — the rest of this tutorial still works (you can read state with the assistant), but writes will need to go through the regular web app at claimru.sh .

Example: collect royalties to ETH

You: “Collect my royalties to ETH.”

Assistant: “I’ll prepare a single transaction calling ShareholderRoyalties.claimShareholder in ETH mode. Approve in your wallet.”

Your wallet shows one step: the ETH-mode claimShareholder call. You sign; your pending royalties land in your wallet.

Example: lock 250 CLAIM via the Furnace for 30 days

You: “Lock 250 CLAIM via the Furnace for 30 days at 0.5% slippage.”

Assistant: “Quote: 250 CLAIM in, ~26.4 CLAIM bonus, ~83.7 veCLAIM out. minVeOut floor with 0.5% slippage = 83.3 veCLAIM. I’ll prepare a CLAIM approval for the Furnace followed by the lock entry. Approve both in your wallet.”

Your wallet shows two steps: ClaimToken.approve(Furnace, 250e18) and Furnace.enterWithClaim(250e18, 0, 30 days, false, 83.3e18). You sign once; both transactions execute atomically.

Example: gracefully refused — out-of-bounds request

You: “Lock 2,000 CLAIM for 2 years.”

Assistant: “ClaimRush locks max out at 365 days. Two paths: (1) lock 2,000 CLAIM for 365 days with AutoMax on — that auto-renews at the maximum weight as long as AutoMax stays enabled, which is functionally the same as ‘lock forever’ and gives you the maximum voting power; or (2) lock for any duration between 7 and 365 days. Which do you want?”

No transaction is sent. The plugin’s prepare/lock endpoint enforces the same [7, 365]-day window and 1,000-CLAIM minimum that VeClaimNFT uses on-chain, so a buggy assistant prompt that asks for an out-of-range duration or sub-minimum amount gets a structured BAD_PARAMS rejection before any calldata is emitted. The same fail-closed posture protects you from the Furnace’s slippage floor and from any future on-chain gate.

Privacy and data handling

The plugin worker logs request metadata (path, status, request ID) for operations, but does not log the contents of your wallet or signature. Wallet addresses appear in logs only at debug level and are redacted by the same privacy filters the rest of the ClaimRush services use. See the Security page for the canonical reporting channels.

Reporting issues

If the assistant prepared a transaction that didn’t match what you asked for, or you got a wrong quote, open an issue at github.com/claimrush/claimrush/issues with the label mcp-plugin. The plugin spec is open-source; pull requests are reviewed against the same audit gates as the rest of the protocol.