DEV Community

Benjamin-Cup
Benjamin-Cup

Posted on

How a Polymarket Momentum Bot Calculates Position Size

#polymarket #tradingbot #tutorial #btc

From BTC momentum signals to dynamic share sizing

In automated prediction-market trading, detecting a momentum signal is only half of the problem.

The next question is:

How many shares should the bot actually trade?

In this video, you can see the bot operating in real time.

In this article, I’ll explain the position-sizing architecture behind a Polymarket momentum-arbitrage bot, including the active fixed-clip system and the more advanced Signal Strength (SigS) model.

GitHub: [Polymarket Trading Bot Python V2]

GitHub logo Benjam1nCup / Polymarket-trading-bot-python-V2

polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket bot

Polymarket Trading Bot | Polymarket Arbitrage Bot | Polymarket TWAP Trading Bot

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.

Polymarket-benjamincup-bot-dashboard

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…

View on GitHub

1. Two Position-Sizing Systems

The codebase contains two different approaches.

Active: Clip Engine

The current execution engine primarily uses fixed-size clips:

size = min(
    clip_shares,
    room_shares,
    room_usdc / ask
)
Enter fullscreen mode Exit fullscreen mode

With a default clip of 20 shares, the bot can still reduce the order if:

  • inventory is near its limit
  • available USDC is insufficient
  • the current ask is expensive

For example:

clip size       = 20
inventory room  = 15
USDC room       = $10
ask             = $0.60

USDC capacity = 10 / 0.60 = 16.67

final size = min(20, 15, 16.67)
           = 15 shares
Enter fullscreen mode Exit fullscreen mode

So the active system prioritizes capital and inventory controls rather than scaling directly with momentum strength.

2. How Momentum Controls the Side

Although the clip size is mostly fixed, BTC's relationship to the strike price determines which outcome receives more allocation.

Conceptually:

target_up_ratio =
clamp(
    0.5 +
    tilt_extra_pct *
    tanh((spot - strike) / sensitivity),
    0.35,
    0.65
)
Enter fullscreen mode Exit fullscreen mode

Therefore:

BTC > strike → favor UP
BTC < strike → favor DOWN
Enter fullscreen mode Exit fullscreen mode

The bot tries to buy the underweight side first.

The strategy also changes behavior depending on the remaining market time:

Phase Approx. behavior
Early ~20-share clips
Expensive pair Tilt toward favored side
Late window Smaller favorite/hedge clips

3. The Advanced SigS Model

The more interesting position-sizing system is the Signal Strength (SigS) architecture.

Instead of using a fixed number of shares, it evaluates six market factors:

Factor Weight
Momentum 25%
Cross-exchange agreement 15%
Order-book imbalance 20%
Liquidity 15%
Token price 15%
Market activity 10%

These factors produce a composite score between:

0.0 → 1.0
Enter fullscreen mode Exit fullscreen mode

The architecture becomes:

BTC / Order Book Data
        ↓
Momentum Detection
        ↓
6-Factor Composite Score
        ↓
Signal Strength
        ↓
Share Calculation
        ↓
Risk Limits
        ↓
Execution
Enter fullscreen mode Exit fullscreen mode

4. Momentum Detection

The strategy evaluates BTC movement across multiple timeframes.

A simplified UP signal requires:

short-term BTC move > threshold
AND
longer-term BTC move > threshold
AND
order-book confirmation
Enter fullscreen mode Exit fullscreen mode

The momentum component normalizes the price movement:

short_norm =
min(abs(coin - prev_coin) / 0.1, 1.0)

long_norm =
min(abs(prev_coin - prev_1s) / 1.0, 1.0)
Enter fullscreen mode Exit fullscreen mode

Then:

momentum_score =
    0.6 × short_norm +
    0.4 × long_norm
Enter fullscreen mode Exit fullscreen mode

This gives greater importance to the immediate BTC move while still considering the previous movement.

5. Order-Book Imbalance

The bot also examines liquidity across the top levels of the Polymarket order book.

A simplified imbalance calculation is:

imbalance =
(bid_depth - ask_depth)
/
(bid_depth + ask_depth)
Enter fullscreen mode Exit fullscreen mode

This helps determine whether the order book is confirming or contradicting the BTC momentum signal.

The strategy also considers:

  • top-five-level liquidity
  • token price
  • book update activity
  • Coinbase/Binance agreement

6. From Composite Score to Shares

The composite score is converted into a signal-strength multiplier:

sig_s =
    sig_s_min +
    composite ×
    (sig_s_max - sig_s_min)
Enter fullscreen mode Exit fullscreen mode

Default parameters:

sig_s_min = 0.3
sig_s_max = 1.5
base_shares = 20
Enter fullscreen mode Exit fullscreen mode

Therefore, the theoretical position range is:

20 × 0.3 = 6 shares

20 × 1.5 = 30 shares
Enter fullscreen mode Exit fullscreen mode

So the dynamic sizing model can produce approximately:

6 → 30 shares
Enter fullscreen mode Exit fullscreen mode

before risk and execution constraints.

7. Example

Suppose the composite score is:

0.85
Enter fullscreen mode Exit fullscreen mode

Then:

sig_s =
0.3 + 0.85 × (1.5 - 0.3)

= 1.32
Enter fullscreen mode Exit fullscreen mode

With 20 base shares:

shares = 20 × 1.32
       = 26.4
Enter fullscreen mode Exit fullscreen mode

A weaker signal might produce:

composite = 0.20

sig_s = 0.54

shares = 20 × 0.54
       = 10.8
Enter fullscreen mode Exit fullscreen mode

The important idea is:

Not every momentum signal receives the same position size.

The desired size reflects the broader market state.

8. Two-Leg Execution

The advanced strategy uses a two-leg structure.

Leg 1

Enter on the momentum side:

BTC momentum ↑
      ↓
UP signal
      ↓
Buy UP
Enter fullscreen mode Exit fullscreen mode

Leg 2

After a BTC retracement condition:

BTC retracement
      ↓
Buy opposite side
Enter fullscreen mode Exit fullscreen mode

The same calculated share quantity can be used for both legs.

The hedge trigger uses a dynamic distance:

diff =
max(
    abs(crypto_price - price_to_beat) × 0.57,
    5.2
)
Enter fullscreen mode Exit fullscreen mode

This combines a proportional threshold with a minimum distance.

9. Signal Size Is Not Final Order Size

A critical design principle is that the SigS result should be treated as a requested position size, not an unconditional order size.

For example:

SigS requested = 30 shares
Inventory room = 18
Budget capacity = 15

Final executable size = 15
Enter fullscreen mode Exit fullscreen mode

The execution layer should still enforce:

  • maximum inventory
  • available USDC
  • market liquidity
  • order state
  • stale-data checks
  • remaining market time

The architecture is therefore:

Signal Size
    ↓
Risk Limits
    ↓
Inventory Limits
    ↓
Budget Limits
    ↓
Final Order Size
Enter fullscreen mode Exit fullscreen mode

10. Active vs Advanced System

The distinction is important.

Clip Engine SigS
Status Active In code, not wired into live engine
Size Mostly fixed Dynamic
Base size ~20 20
Momentum affects size No Yes
Momentum affects side Yes Yes
Composite scoring No Yes
Dynamic range Limited by caps ~6–30 shares
Risk controls Yes Should be applied before execution

So it would be inaccurate to say that the current bot dynamically changes its share size on every momentum event.

The more precise description is:

The active bot uses fixed clips with inventory, budget, timing, and directional-tilt controls, while the codebase also contains a more advanced SigS architecture for dynamic momentum-based position sizing.

11. Final Architecture

The complete concept looks like:

Market Data
    ↓
Momentum Detection
    ↓
Signal Validation
    ↓
6-Factor Scoring
    ↓
Signal Strength
    ↓
Requested Shares
    ↓
Risk / Inventory Limits
    ↓
Order Execution
    ↓
Hedge / Second Leg
Enter fullscreen mode Exit fullscreen mode

The interesting part isn't the final multiplication:

shares = base_shares × signal_strength
Enter fullscreen mode Exit fullscreen mode

The important part is how the signal strength is constructed from:

momentum + exchange confirmation + order-book structure + liquidity + token price + market activity.

That creates a position-sizing framework that can respond to changing market conditions instead of treating every signal identically.

Explore the Code

The implementation and related research code are available here:

[GitHub — Polymarket Trading Bot Python V2]

GitHub logo Benjam1nCup / Polymarket-trading-bot-python-V2

polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket trading bot polymarket bot polymarket twap bot polymarket arbitrage bot polymarket bot

Polymarket Trading Bot | Polymarket Arbitrage Bot | Polymarket TWAP Trading Bot

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.

Polymarket-benjamincup-bot-dashboard

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…


View on GitHub


For technical discussion, collaboration, or questions:

Telegram: [@BenjaminCup]
Contact: Telegram: https://t.me/BenjaminCup

Educational and research content only. This is not financial advice, and trading automated prediction-market strategies involves significant risk.

Top comments (0)