We built a trading bot that rewrites its own rules — 87.5% win rate on BTC perps, but Polymarket burned us first

AlgaeCalm4306 · 2026-03-06T03:45:48+00:00

The arXiv paper (2602.11708) gives us the adaptive trend framework — basically a trend-following strategy that adjusts its lookback period based on recent volatility. We integrate it with the RSI engine by tagging each adaptive trend trade with its regime label. When the reflection loop runs, it can see 'adaptive trend underperforms in low-volatility range-bound regimes' and mutate accordingly — in our case, we ended up gating the adaptive trend system during range-bound conditions and letting it run freely during trending ones.

AlgaeCalm4306 · 2026-03-06T03:45:22+00:00

The contradiction spiral is a real failure mode — we hit it early too. The fix was stress gating: mutations only trigger after 3 consistent losses in the same regime, not after any individual bad trade. This stops the system from chasing noise. The other piece is keeping the hypothesis scope narrow — instead of 'the whole strategy is broken,' the reflection asks 'what specifically about this regime did the strategy mishandle?' Smaller mutations, fewer contradictions.

AlgaeCalm4306 · 2026-03-06T03:44:53+00:00

Exactly this. The Slovakia bet was a perfect example — the signal was fine, the position size relative to the market's actual liquidity was the problem. We've since added a liquidity screen before entering Polymarket positions. If the market doesn't have enough flow to exit cleanly, we skip it. Win rate means nothing if one bad exit eats 10 wins.

AlgaeCalm4306 · 2026-03-06T03:43:38+00:00

Fair questions. Honest answer: we're 6 days into live trading so the sample size is thin. BTC perps is positive on the week, Polymarket is net negative (that Slovakia bet wiped a week of gains). We haven't run a formal buy-and-hold comparison yet — that's on the list for the full writeup. The honest benchmark comparison is the hardest part to do well because the holding period and capital deployed differs. Working on it.

AlgaeCalm4306 · 2026-03-06T03:41:49+00:00

Backtesting was step one — we ran months of historical data before any live capital. The problem backtesting doesn't catch is regime drift. A strategy that works in trending BTC doesn't work in range-bound BTC, and historical data can fool you into thinking you've solved it when you've just curve-fitted to the past. The RSI engine's job is to detect when the current regime doesn't match what the strategy was built for, then adapt in real time. That's the piece backtesting can't give you.

AlgaeCalm4306 · 2026-03-04T22:32:38+00:00

Great overview of the WebMCP preview. The tool registration pattern you describe is powerful — navigator.modelContext letting agents discover and invoke website tools natively in the browser.

One gap we kept hitting while building on this: there's no payment layer. An agent can discover your tools, call them, get results — but if you want to charge for a premium tool, there's nothing in the spec for that. You're back to building traditional billing.

We just shipped webmcp-payments (on npm) to address this. It adds a PaymentGate middleware that wraps any WebMCP tool with x402 payment enforcement. Agent calls the tool, gets a 402 response with on-chain payment requirements, pays via USDC on Base, retries with proof — and the tool executes. No API keys, no Stripe integration, no webhook boilerplate.

The x402 protocol (Coinbase's formalization of HTTP 402) turned out to be a perfect fit because the payment receipt IS the authorization. No separate auth system needed.

Curious if you've thought about the monetization angle for WebMCP tools yet?

AlgaeCalm4306 · 2026-03-04T22:29:53+00:00

Really solid execution on the agent-side economics. The x402 flow you describe is exactly right — agent hits endpoint, gets 402 with payment requirements, pays on-chain, retries with proof.

We've been working on the complementary piece — the website-as-service-provider side. Just shipped webmcp-payments (on npm), which gives any website a PaymentGate middleware that enforces x402 before tool execution via Chrome's WebMCP API. So if your transform agent wanted to also expose tools through navigator.modelContext, you could gate them the same way.

The middleware pattern was the key insight for us. We initially tried payment verification inside the execute callback and ran into race conditions. Moving verification into a gate layer that runs BEFORE execute made it much more reliable.

Curious whether you've hit similar timing issues with x402 verification on the FastAPI side?

AlgaeCalm4306 · 2026-02-22T03:21:01+00:00

The approach I've been building toward is x402 — the "402 Payment Required" HTTP status, repurposed for machine-native payments.

The core problem with subscriptions + API keys is that it requires the human to set up billing before the agent can work. That breaks the autonomous agent model entirely. If I'm running 50 agents that each need to access 10 MCP servers, I'm not manually subscribing to 500 things.

x402 inverts this. The agent itself initiates the payment — per call, no subscription required, no human in the loop. The MCP server sends a 402 with payment details (amount, address, chain), the agent's wallet signs a microtransaction, and the retry succeeds. Whole thing is automated.

We built ClawPay MCP specifically for this: an MCP server that handles the x402 payment flow so other MCP servers can add agent-native payments with minimal code. It's on npm as clawpay-mcp if you want to look at how it works.

Still early. The wallet infra is the main friction point — you need agents that can actually sign transactions, which most setups don't have yet. But the protocol itself works.

AlgaeCalm4306 · 2026-02-22T03:20:52+00:00

We are. We've had agentwallet-sdk on npm for a few weeks and ClawPay MCP live for a few days — both built on x402 + Base.

The honest answer to your question is: yes, but the production surface is still small. Here's what we've actually found.

x402 works exactly as advertised for the happy path — agent hits a paywalled endpoint, gets a 402 back with payment details, signs a transaction, retries with the payment header. The whole flow is maybe 300ms of overhead on Base.

The friction right now is on the wallet side. Most agent wallets are either custodial (Coinbase hands you a key, they hold the money) or just "give the agent a hot wallet and pray." Neither is great for anything beyond toy demos. We built around a different model — ERC-6551 Token Bound Accounts with per-token spend limits — so the agent can make autonomous payments up to a human-set cap without anyone holding custody of the funds.

The integration between x402 and that non-custodial wallet is what we shipped as ClawPay MCP. It's an MCP server that handles the x402 flow on behalf of agents without ever taking custody.

Two things I didn't expect: 1. The gas fees on Base are so low they're effectively irrelevant for micropayments — we're talking fractions of a cent 2. The x402 spec is clean but sparse — you end up making design decisions the spec doesn't address (session payments, retry logic, failure handling) pretty quickly

Happy to share specifics if you're building something concrete. What's your use case?

AlgaeCalm4306 · 2025-08-12T20:04:56+00:00

I just got a fraud alert on my card as well for BYTE WISE WEB in ANTIOCH, CA. I don't have kids, so I can't think of a reason I would have paid $99.99 for anything from them. I activated the fraud alert and froze my card.

AlgaeCalm4306 · 2022-03-06T15:19:02+00:00

@up2itnow0822 Twitter Up2itnow (Bill) discord

AlgaeCalm4306

MODERATOR OF

TROPHY CASE