I spent the last few weeks building a Polymarket TWAP End-Cycle Sniper.
The original version had multiple entry strategies, several confirmation layers, and a fairly complicated risk engine.
After about two weeks of real-market testing, I ended up removing most of it.
The interesting part was that the simpler version gave me a much clearer trading signal.
This post explains what I changed, what I learned, and the entry condition I am currently testing.
Disclaimer: This is a technical write-up about a trading system I built and tested. The observations below are from my own testing and should not be treated as financial advice or as a guaranteed trading strategy.
What Is an End-Cycle Sniper?
The basic idea is to trade near the end of a short-duration Polymarket crypto market.
Instead of trying to predict the market several minutes before expiration, the bot waits until the market has developed a strong directional signal.
The key window I found interesting is approximately:
60 seconds before market expiration.
At that point, I want to know:
- What is the current TWAP doing?
- Is Chainlink confirming it?
- Is Binance momentum moving in the same direction?
- Is Coinbase confirming the move?
- Are other market/on-chain signals aligned?
- Is the corresponding outcome token already trading at a strong probability level?
The goal isn't to predict the future from one indicator.
It is to find agreement between multiple signals near the end of the market.
My First Mistake: Adding Too Much Logic
When I started the project, I assumed a more sophisticated system would perform better.
So I added:
- Multiple buy conditions
- Different momentum strategies
- Additional confirmation filters
- Reversal detection
- Risk-management conditions
- Different entry scenarios
- More data sources
On paper, this looked like a smarter trading system.
In reality, it made the system harder to reason about.
Every new condition created another question:
Does this actually improve the edge, or does it just make the code more complicated?
After running the bot against real market conditions for roughly two weeks, I started removing conditions instead of adding them.
That process eventually led to one primary entry strategy.
The Core Signal
The current concept is relatively simple.
Around 60 seconds before expiration, I look for strong directional agreement.
For example, suppose the UP side is being considered.
I want to see something similar to:
TWAP → UP
Chainlink → UP
Binance → UP
Coinbase → UP
Other data → UP
Token → > 0.70
When several independent signals agree, the setup becomes much more interesting.
The same logic applies in the opposite direction for DOWN.
Why TWAP Is Important
The system is specifically designed around the market's TWAP-based settlement mechanism.
The important point is that I don't want to treat the latest spot price as the entire story.
A short-term spot move can be noisy.
The TWAP provides information about the accumulated price path that matters for settlement.
Near expiration, that information becomes increasingly useful.
But there is one important exception.
Don't Trade When TWAP Is Near Zero
This became one of the most important filters in my testing.
If the TWAP movement is too close to zero, there isn't enough directional information.
In that situation, I don't want the bot to force a trade just because another signal looks bullish or bearish.
The rule is basically:
Clear TWAP direction?
|
+-- NO --> SKIP
|
YES
|
v
Continue confirmation
This is an important characteristic of the system.
No signal is also a signal.
A sniper doesn't need to trade every market.
The $0.70 Token Filter
Another condition I found useful was the price of the corresponding outcome token.
For the setup I'm testing, the target token should generally be above:
$0.70
For example:
UP = $0.72
DOWN = $0.28
If all the underlying signals are also pointing UP, the market is already pricing UP as the more likely outcome.
I'm not trying to buy a cheap token and hope for a reversal.
I'm looking for confirmation that the market has already developed a strong directional bias.
This also changes the nature of the strategy.
The objective becomes:
Find high-confidence late-cycle confirmation rather than predict an early move.
Why Multiple Data Sources?
One of the interesting parts of this system is that the signals come from different sources.
The idea is not that Binance is always right.
Or Coinbase is always right.
Or Chainlink is always right.
Instead, I am interested in what happens when they agree.
Conceptually:
┌───────────┐
│ TWAP │
└─────┬─────┘
│
┌─────▼─────┐
│ Chainlink │
└─────┬─────┘
│
┌────────────┼────────────┐
│ │ │
Binance Coinbase On-chain
│ │ │
└────────────┼────────────┘
│
▼
Signal Agreement
│
▼
Token > $0.70
│
▼
BUY
The interesting signal is therefore not one indicator.
It's convergence.
What Happened During Real Testing?
During approximately two weeks of real testing, I noticed that some of the more complicated strategies weren't providing enough additional value to justify their complexity.
I started removing them.
Eventually, the system became much more focused:
- Wait for the final part of the market.
- Check whether TWAP has a clear direction.
- Check whether external price feeds confirm that direction.
- Check the corresponding token price.
- Enter only when the conditions align.
- Otherwise, skip.
This was a useful reminder that more code does not necessarily mean more edge.
The Observed Win Rate
During my testing, the strongly aligned setups produced an observed hit rate of around 95% in the sample I was watching.
I want to be careful with this number.
I don't consider 95% to be a proven long-term win rate.
Two weeks is not enough data to establish that.
There are many variables that can change the result:
- Market regime
- Volatility
- Liquidity
- Execution latency
- Entry price
- Sample size
- Asset
- TWAP behavior
- Unexpected price movements
So the conclusion I am comfortable making is:
The aligned setup showed a very high observed hit rate in my current testing, and it deserves further investigation.
The next step is collecting a much larger sample.
Why I Removed Some Risk Logic
I also learned something about risk management.
Initially, I wanted the bot to continuously analyze the position and react to every short-term movement.
That sounds sophisticated.
But it can also create unnecessary reactions.
If the entry itself is based on strong confirmation, the first layer of risk management can happen before the trade.
Instead of constantly asking:
"How can I rescue this position?"
the system first asks:
"Is this position worth opening?"
That doesn't eliminate risk management.
It simply moves more of the decision-making to the entry layer.
The Current Decision Flow
The current concept can be summarized like this:
Market approaching expiration
|
v
~60 seconds remaining
|
v
Check TWAP direction
|
┌────────┴────────┐
│ │
unclear clear
│ │
v v
SKIP Check external signals
|
v
┌─────────────────────────┐
│ Chainlink │
│ Binance momentum │
│ Coinbase │
│ Other market/on-chain │
└────────────┬────────────┘
|
v
Signals agree?
|
┌─────────┴─────────┐
│ │
NO YES
│ │
v v
SKIP Token > $0.70?
|
┌────────┴────────┐
│ │
NO YES
│ │
v v
SKIP BUY
The important feature is that most paths end in SKIP.
That's intentional.
The Real Lesson: Complexity Isn't the Same as Edge
This was probably the biggest lesson from the project.
When building trading systems, it is easy to confuse:
more conditions
with
better strategy.
They're not the same thing.
A complicated strategy can look impressive while being extremely difficult to validate.
A simple strategy with a clear hypothesis is much easier to:
- Test
- Measure
- Debug
- Optimize
- Explain
- Monitor
- Improve
That's why I ultimately preferred the simpler architecture.
What I Want to Measure Next
The current strategy is still being tested.
The next step is to collect a significantly larger dataset and measure the strategy statistically.
Some of the metrics I want to track:
Total opportunities
Actual entries
Skipped opportunities
Win rate
Average entry price
Average payout
Expected value
Maximum losing streak
Drawdown
Performance by asset
Performance by volatility
Performance by remaining time
Performance by token-price threshold
The most important question isn't:
"Did this work for two weeks?"
It's:
"Does the edge remain after thousands of opportunities?"
That's the test that matters.
Building the Project
I've made the public version of the project available on GitHub:
Polymarket Trading Bot — Python V2
The public repository contains the project and implementation that I'm comfortable sharing.
The production strategy continues to evolve as I collect more data.
Final Takeaway
I started this project thinking I needed multiple strategies and a complicated risk engine.
Real testing pushed me in the opposite direction.
The current idea is much simpler:
Wait until the final part of the market.
Look for clear TWAP direction.
Confirm it with multiple independent signals.
Require the corresponding token to be above $0.70.
Avoid markets where TWAP is too close to zero.
If the signals aren't aligned, do nothing.
The most interesting part isn't that I found another indicator.
It's that after adding more and more logic, the testing process eventually showed me that removing logic was more valuable than adding it.
That's probably the biggest lesson I'll take into the next version of the bot.
Follow the Project
If you're interested in Polymarket infrastructure, algorithmic trading, market-data systems, or want to discuss the strategy:
GitHub:
[Benjam1nCup / Polymarket Trading Bot V2]
Polymarket Trading bot system
An open-source and Strong Strategy collection of Polymarket trading bot and Polymarket arbitrage bot and Polymarket TWAP trading bot in Python for high-performance automated trading on polymarket crypto 5min and 15min markets.
This repository is primarily intended for educational and research purposes. It includes strategy concepts, implementation approaches, and selected performance screenshots to help developers understand how different automated trading strategies can be designed and tested.
The repository does not provide a complete production-ready trading bot source code. Instead, it provides strategy descriptions and research materials that you can use as a foundation for developing your own system.
If you are interested in building a Polymarket Trading Bot, you can follow my tutorials and use the concepts in this repository to develop your own implementation.
For users who prefer a ready-to-deploy solution or require custom strategy development, commercial bot development and customization are also available.
Features
…Telegram:
@BenjaminCup
I'm continuing to test the strategy and will share another update when I have a larger dataset.
Top comments (0)