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]

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.

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
)

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

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
)

Therefore:

BTC > strike → favor UP
BTC < strike → favor DOWN

The bot tries to buy the underweight side first.

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

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:

These factors produce a composite score between:

0.0 → 1.0

The architecture becomes:

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

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

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)

Then:

momentum_score =
    0.6 × short_norm +
    0.4 × long_norm

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)

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)

Default parameters:

sig_s_min = 0.3
sig_s_max = 1.5
base_shares = 20

Therefore, the theoretical position range is:

20 × 0.3 = 6 shares

20 × 1.5 = 30 shares

So the dynamic sizing model can produce approximately:

6 → 30 shares

before risk and execution constraints.

7. Example

Suppose the composite score is:

0.85

Then:

sig_s =
0.3 + 0.85 × (1.5 - 0.3)

= 1.32

With 20 base shares:

shares = 20 × 1.32
       = 26.4

A weaker signal might produce:

composite = 0.20

sig_s = 0.54

shares = 20 × 0.54
       = 10.8

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

Leg 2

After a BTC retracement condition:

BTC retracement
      ↓
Buy opposite side

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
)

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

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

10. Active vs Advanced System

The distinction is important.

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

The interesting part isn't the final multiplication:

shares = base_shares × signal_strength

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]

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.