merrymen
millw14 · millw14/merrymen
Connects Claude via MCP to Merrymen so you can create and monitor autonomous trading agents on Robinhood Chain within signed on-chain limits.
Autonomous trading agents for Robinhood Chain, inside hard on-chain limits. Use it from Claude: tell Claude "set up merrymen mcp", or add it in one click at merrymen.dev/claude
Preview
What you can do with it
- Set up a paper-trading agent and review its decisions
- Set markets and risk limits for an agent from Claude
- Follow positions and trade outcomes from a dashboard or Telegram
Safety check
Usable, but read the notes first.
- ●Installer downloads a remote script and pipes it to the shell.
install.sh - ●No clear license: check with the author before using it in a commercial product.
Automated scan of the repo files. Always review code you run.
From the README
Website · Open app · Docs · X · npm
merrymen
Autonomous trading agents with signed limits and readable research. Run merrymen in the hosted app or on your own machine. Create an agent, choose its markets and limits, and follow its decisions, positions and trade outcomes from the dashboard or Telegram.
Use it from Claude: tell Claude “set up merrymen mcp”, or add it in one click: https://merrymen.dev/claude (hosted Merrymen).
The account contract enforces the permissions sealed into its session key: allowed calls and assets, per-call limits and expiry. The worker adds daily budgets, drawdown checks and operation limits. These are different enforcement layers: a compromised worker can ignore software checks, but cannot expand a signed on-chain permission. Bad trades remain possible within those bounds.
The five promises: your keys, your permissions · explicit risk limits · every trade simulated first · fees only on profit above the high-water mark · an honest scoreboard.
The one rule of the house: the model proposes, deterministic code disposes. Models produce proposals; trusted code constructs trading calls and checks them before execution. Telegram PC control is a separate self-hosted capability, gated by its own permissions, allowlists and confirmations. The on-chain wall protects account operations, not your operating system.
What you can do
- Run hosted or self-hosted. Use the web app, or keep your worker, settings,
memory and ledger in your own
MERRYMEN_HOME. - Start on paper, then enable live trading. Simulated trades are labeled separately. Live execution requires explicit enablement, a usable signed grant, an executor, funding and passing market/policy checks.
- Read and follow agents. Public profiles and the feed expose published theses and execution outcomes. Followed-agent research can inform later decisions; following is not an instruction to copy a trade.
- Use Brain research. Brain evaluates evidence and returns structured decisions. Operational failures stay distinct from public market theses.
- Explore Trencher. The memecoin strategy checks liquidity, momentum and exits. Fast mode supplies Brain with measured 5m/1h/6h/24h market windows and reviews candidates in the background, with one model call outstanding at a time. Live Trencher and fast mode have separate opt-in settings.
- Audit the record. Export the ledger and verify chain-backed receipts independently of the running worker.
Active workers target decision reviews at intervals of no more than five minutes when reads complete. That is a review cadence, not a promise to trade every five minutes or make a profit. See the execution and publication details below.
Ownership and enforcement
- Your machine, if you self-host. The agent, its memory and its ledger live
in
~/.merrymen; configured RPC, inference and other providers can still be external services. Hosted at app.merrymen.dev the worker and the ledger are ours — what does not change is the next line. - Owner authority and agent authority are separate. New mainnet wallets use an embedded or external owner signer. Browser-generated owners are available only on testnet. Existing browser-generated owners remain accessible for renewal and recovery: their keys require a backup and are stored in browser local storage. Anyone who obtains an owner key can bypass all agent caps; these existing wallets have not been migrated by an app update. Hosted workers receive the restricted session grant, not the owner key. Session credentials can still authorize trades inside their permissions, so protecting them matters.
- The chain enforces the signed call permissions. The session key may only call contracts it names, may only move assets you sealed into it, may not send native ETH beyond its signed call permissions, and dies on schedule — all in the account contract. A compromised agent cannot reach an asset you did not name or a contract you did not approve. It can still make bad trades inside those bounds; no wall fixes judgement.
- Verifiable, not claimed. The dashboard links every address and cap to the block explorer, and its prove the wall button fires malicious intents (an oversized trade, a "send everything to 0xevil" transfer, an expired key) through the policy so you can watch each one bounce. Note what that does and does not show: it exercises the worker's own copy of the rules, so it proves the software agrees with itself. The chain-side proof is a real refused UserOp — see docs/.
- The numbers are auditable too, not just the wall. Every fact that moves
money is mirrored into a hash-chained journal, so an edited record breaks
every hash after it and a deleted one leaves a visible gap.
merrymen exportwrites it out;merrymen verify <file>checks it — and reads nothing but the file it is handed, so it proves something to someone who does not trust you. Records that cannot be checked against a chain (a simulated fill, a deposit inferred from a balance change) are listed as such rather than quietly counted.
You verify; it trades.
Check it yourself
Two commands. The second reads nothing but the file you hand it — not
~/.merrymen, not the settings, not the machine that produced it — so it is
checking the record against the chain, not against the operator.
npm run export -- --agent > ledger.jsonl
npm run verify -- ledger.jsonl
verify re-fetches every receipt from a public RPC and re-derives what moved
from the logs, using its own implementation rather than sharing code with the
writer — so a bug in the writer cannot be confirmed by the reader. It returns
INDETERMINATE, not PASS, when a transaction cannot be refetched: a check it
could not run is not a check that passed.
Two limits, said out loud rather than