Building a Polymarket BTC Trading Engine with Claude- Full Guide cover

Building a Polymarket BTC Trading Engine with Claude- Full Guide

Aleiah avatar

Aleiah · @AleiahLock · Apr 10

View original post

Imagine waking up to thousands of dollars quietly deposited into your account - while you slept.

Your automated Polymarket BTC trading engine kept working 24/7, scalping profits from every swing between $65k and $70k.

No emotions. No panic selling. No FOMO buying at the top.While most traders are still getting wrecked by greed and fear - buying Bitcoin above $70k and then watching it crash back down - smart players with real edges are quietly stacking serious money.

Some top Polymarket traders have already cashed out over $22 million. Others are pulling in hundreds of thousands of dollars per month with automated strategies.

I used to be the complete opposite.I was a proud long-term investor. Dollar-cost averaging, lump-sum buys, and letting compounding do the heavy lifting. I read classics like A Random Walk Down Wall Street and The Intelligent Investor. I fully bought into Benjamin Graham’s warning: greed and emotional decisions are an investor’s worst enemies.

One reckless trade can wipe out months of gains.Yet here’s the truth most people won’t admit:Humans are greedy. Everyone wants fast money, and nobody wants to wait years for “maybe it will go up.”That’s exactly why I built my own Polymarket BTC Trading Engine - a fully automated system that trades Bitcoin prediction markets without emotions, without hesitation, and without the classic traps that destroy most retail traders.

This article is the full story: how a committed long-term holder like me switched gears, started actively trading on Polymarket, what I learned along the way, and why I now believe automated edges like this are one of the most powerful (and still under-the-radar) ways to scale capital in crypto in 2026.If you’re tired of waiting for the next bull run and want your money to work harder and smarter - keep reading.

BTC 5-Minute Markets

https://polymarket.com/event/btc-updown-5m-1775840100?r=aleiah

On Polymarket, there are 5-minute prediction markets for BTC, ETH, SOL, and XRP. Each market has a target price called the “Price to Beat.” If you correctly predict that the price will be above or below the target at the end of the 5-minute window, you win. It sounds simple, but that simplicity is an illusion. BTC is a highly volatile asset, and a 5-minute window is far too short for traditional indicators like RSI, MACD, or EMA to reliably predict direction. The time window may seem small, but when share prices drop significantly and you cannot explain why, that is when you start thinking more carefully about how these markets actually move.

I became very interested in this because I follow BTC price movements daily and I thought I could find a pattern that would give me an edge. It started as a fun experiment and then turned into something serious. Part of what pulled me in was the technology behind Polymarket itself. It uses blockchain internally for settlement, performs off-chain order matching for speed, and leverages smart contracts to manage the entire market lifecycle.

I wanted to understand how Polymarket creates these market contracts, how the Conditional Token Framework works, what happens to your USDC when you buy shares, why shares are not instantly available to sell after a purchase, where the Price to Beat comes from, and who resolves whether the outcome is UP or DOWN. I wanted to explore how trading works on a blockchain and go deep into Polymarket’s internals, because if you are going to use the platform seriously, you need to understand what happens at every step of a trade.

Polymarket - Under the Hood

After spending time digging into Polymarket’s internals, here is how everything fits together. At the foundation, Polymarket runs on Polygon, an Ethereum Layer 2 network that keeps transaction costs negligible. When a binary market is created, the Gnosis Conditional Token Framework handles the core mechanics. For every dollar of USDC you lock into the contract, it mints two conditional tokens: one for each outcome, say UP and DOWN. These tokens follow the ERC-1155 standard, meaning a single smart contract manages the balances for all positions. A complete set of tokens (one UP and one DOWN) can always be redeemed for exactly 1.00 USDC, which is the fundamental constraint that keeps prices rational through arbitrage.

When it comes to resolving markets, Polymarket originally relied on UMA’s Optimistic Oracle for event-based outcomes. UMA works on an optimistic model: someone proposes an outcome, and it is accepted as truth unless someone else disputes it within a challenge window. If a dispute is raised, it escalates to a decentralized vote among UMA token holders to determine the correct result. This works well for subjective or event-based questions like election outcomes, but for something like a BTC price market that resolves every five minutes, you need something faster and more objective. That is where Chainlink comes in. For BTC 5-minute markets, Polymarket uses Chainlink price feeds, which aggregate BTC prices from multiple exchanges and deliver them on-chain. The resolution is automatic and trustless: the smart contract reads the Chainlink feed at the end of the window, compares it to the Price to Beat, and settles the market without any human involvement.

The trading layer is equally interesting. Polymarket does not use an AMM (Automatic Market Maker) like most DeFi platforms. Instead, it uses a hybrid Central Limit Order Book (CLOB). When you place an order, it goes to an off-chain matching engine that pairs compatible buy and sell orders. Both parties sign their orders using EIP-712 typed signatures, and the matched pair is then submitted to the CTF Exchange smart contract on Polygon for atomic on-chain settlement. This is where the order lifecycle becomes visible: after matching, the transaction is submitted to the blockchain (MATCHED), waits to be included in a block (MINED), and finally receives enough block confirmations (CONFIRMED). This is also the reason why shares are not instantly available to sell after a buy. Your purchase needs to go through this full on-chain settlement cycle before the tokens appear in your balance and can be used in a new order. The hybrid design gives you the speed of a centralized exchange for order matching while preserving the security guarantees of blockchain settlement, where every trade is verifiable and non-custodial.

Reference

  • https://github.com/KaustubhPatange/polymarket-trade-engine/blob/master/docs/LEARNING.md

I knew I needed to build an automated trading bot because there is no way a human should be involved in this process. Emotions kick in and lead to more mistakes than any algorithm would make. I wanted to build a system around the patterns I identified, a script that would trade on my behalf. If I lose, I lose purely because my algorithm did not work, not because of some emotional decision or third-party interference.

A good friend of mine told me that the order book is always the source of truth for trading in these kinds of markets. So my first trading engine, called “late-entry,” was event-driven. The idea was to display the order book in the terminal and keep it continuously updated by subscribing to Polymarket’s order book WebSocket, so updates were real-time with no lag. I also wanted to minimize API calls and rely on the WebSocket wherever possible to reduce latency when placing orders. One thing worth noting about Polymarket is that there is no concept of a market order. Everything is a limit order. When you try to create a market order through the SDK or buy through the UI, it actually places a limit order at the best ask for that side. I wanted to keep API calls to a minimum and lean on the WebSocket for as much of the trading flow as possible. The initial version of the script looked like this,

The terminal view showed live order book coverage with real-time updates. I used to stare at it for hours trying to find patterns and observe how people reacted to price movements. I pulled BTC prices from multiple sources like Binance, Coinbase, and Chainlink itself to see how the divergence between them affected order book depth and positioning.

This continued for weeks as I built out the engine as an event-driven system. There was a component responsible for sending a signal on when to enter the market. I used indicators like RSI, ATR, and cross-source price divergence to detect whale dumps or pumps and trigger a buy signal. The engine would then place the order, and a separate component would monitor the position until the market slot ended. It placed the necessary stop losses, identified bell curve patterns, filtered out false signals, and only exited in the case of a stop loss being hit.

On the surface this approach looked like it worked, and it did about 95% of the time. But for that remaining 5%, I was losing a significant amount of money. That is when it clicked: the goal is not to always hold shares until the market resolves. As soon as you have an appropriate profit, you sell and exit. These markets are unpredictable at times, so even if a strategy works today, it may not work tomorrow.

My earlier engine had a few fundamental limitations. It was not capable of a buy-and-sell strategy. It was purely signal-based: one buy, hold to resolution, no intermediate sell. I also needed a simulation system that could test against the real market using a paper wallet. I could not afford to lose money while iterating on strategies, so I needed a simulation environment that mirrored real-world conditions: latency, partial fills, unexpected order cancellations, and the inability to sell immediately after a buy because the transaction needs on-chain confirmation. All of these had to be accounted for so that when I wrote a strategy and tested it, I could trust that what worked in simulation would work in production.

Planning the new Engine with Claude

I did not know how to get started or how to make the engine extensible. The idea was simple: you write a strategy and the engine trades for you. I used Claude Code (Opus 4.6) to plan the engine architecture, focusing on how to make it extensible and how simulation would work. I have to say, I was genuinely impressed with the results. I used the Plannotator plugin to plan with Claude, which provides a clean UI where you can read through the plan and give feedback to the agent. After several rounds of back and forth, we arrived at a final architecture that I was confident in.

The new engine is based on lifecycles. You always start in a future market slot, at least one ahead of the current one, which is why I named it “early-bird.” At no point can you start the engine in the current market. Every market is a lifecycle: it goes through start -> run -> end states. The engine’s job is to orchestrate these market lifecycles. Each market runs exactly one strategy when it is created. You pass a parameter specifying which strategy you want to run, and the market lifecycle creates it during the start state, executes it during the run state, monitors it, and waits for completion before transitioning to the end state. It then computes PnL and notifies the engine that it is done. The engine provides a set of APIs for building strategies. A strategy is simply a function that uses these APIs to place buy and sell orders. The full architecture diagram is shown below:

Once the planning was done, I asked Claude to create an initial skeleton based on this architecture, which it did quite well, including the simulation code. I also knew I needed a solid logging system so that when I win or lose, I have the necessary data to debug why a strategy failed. Claude helped with both the planning and implementation here as well. It suggested building a chart visualization tool that takes existing log files and generates an interactive chart for each market window. The output looks something like the image below. This makes it much easier to visually analyze what went wrong and find potential improvements.

Strategy and Final Thoughts

With the engine in place, I was ready to write my own strategy. I cannot share my specific findings because that would give away my edge, but I can tell you that no single strategy will win all the time. When you study the order book and indicators, you will find certain patterns that only appear during specific periods of the day and not always. Your edge is knowing when those windows are and only trade during that period. It is also not about winning every round. You will lose sometimes, but your strategy should have excellent exit signals that minimize how much you lose. The engine provides the necessary APIs and includes examples under the simulation and late-entry strategies (/engine/strategy/) that demonstrate how to exit without giving back significant profits.

One thing worth mentioning is that AI will not help you write a strategy directly. It is all about context. If you train a model on specific metrics like order book movements, gap behavior, and price divergence, you could potentially ask it to generate a strategy. That is an experiment I want to try, but it is something for another time.

The engine is open source and actively maintained. If you are interested, you can take a look at https://github.com/KaustubhPatange/polymarket-trade-engine. The README links to documentation covering market terminology and a full guide on how to develop strategies using the engine. The repository is the public-facing version of the engine and regularly syncs from my private repo. The only difference is the strategies: the public version ships with test strategies, while my private repo contains the actual strategies I trade with. Here is a screenshot of what the engine outputs,

If you are wondering whether this has been profitable, I have made a few hundred dollars from it. But continuing to develop strategies is a challenge. What worked three days ago, fails today, so you need to constantly look for new patterns and identify whatever edge you can find. I have a full-time job, and keeping this up every day is not sustainable, so I try to only trade during weekends when I have the time. I spent countless sleepless nights building the initial engine and finding patterns that actually worked for a while. I cannot say whether I will continue doing this long term given my job and the toll it takes, but I will not push myself the way I did before. My goal was never to become an active trader. It was to learn and explore a subject that genuinely interests me, and to write articles like this so others can learn from my experience.