Loop Events

Loop events are recurring prediction markets that automatically recreate themselves on a set interval. They are primarily used for crypto price predictions (e.g., "Will BTC be above $X in 1 hour?") but can be applied to any repeating scenario.

How Loop Events Work

A loop event uses a template event as a blueprint. When the current cycle's event closes, a background worker automatically creates the next cycle by cloning the template with updated parameters (new base price, fresh probabilities, etc.).

Template Event
  ├── Cycle 1 (closed)
  ├── Cycle 2 (closed)
  ├── Cycle 3 (active, currently trading)
  └── Cycle 4 (auto-created when Cycle 3 closes)

The worker (loop_event_worker) runs continuously, checking for events that are due for recreation based on their next_recreate_at timestamp.

Loop Event Fields

These fields control the loop behavior when creating or configuring an event:

Field	Type	Description
is_loop_event	boolean	Marks this event as a recurring loop event
loop_interval_minutes	integer	Time between cycles in minutes (e.g., 60 for hourly, 1440 for daily)
next_recreate_at	timestamp	When the next cycle should be created
loop_template_event_id	integer	ID of the template event used as a blueprint for new cycles

Template Events

The template event serves as the master configuration for all cycles. It defines:

• Event name pattern and tags
• Pool structure (number of pools, market names, probabilities)
• LMSR liquidity parameters
• Volume boundaries
• Asset tracking configuration

When a new cycle is created, the worker clones the template's structure and applies fresh values (updated asset prices, reset probabilities, new timestamps).

Template events are typically not activated themselves -- they exist solely as blueprints.

Common Use Cases

Crypto Price Predictions

The most common loop event type. These track whether a cryptocurrency's price will be above or below a threshold over a time period.

Asset	Interval	Example Question
BTC	60 minutes	"Will BTC be above $70,500 in 1 hour?"
ETH	60 minutes	"Will ETH be above $4,100 in 1 hour?"
SOL	1440 minutes (daily)	"Will SOL be above $180 by end of day?"

These events use the asset tracking fields on their pools:

• asset_symbol -- The cryptocurrency being tracked (BTC, ETH, SOL).
• asset_base_price -- The price at cycle start. The asset price worker updates this for each new cycle based on current market data.

How Crypto Loops Resolve

1. A new cycle is created with the current asset price as asset_base_price.
2. Markets are set up as ["Above $X", "Below $X"] where X is derived from the base price.
3. Users trade during the interval period.
4. When the interval expires, the worker checks the actual asset price against the threshold.
5. The event is closed with the correct outcome, and settlement runs.
6. A new cycle is immediately created with a fresh base price.

Getting the Next Cycle

GET /api/v1/events/{id}/next-cycle

Returns the event ID of the next cycle for a given loop event. This is useful for the frontend to navigate users from a closed cycle to the currently active one.

Example

curl https://your-domain.com/api/v1/events/123/next-cycle \
  -H "Authorization: Bearer <token>"

Response

{
  "next_event_id": 456
}

If no next cycle exists yet, the response indicates that the next cycle has not been created.

Polymarket Sync with Loop Events

Loop events for crypto prices can be synced with Polymarket odds by providing polymarket_token_ids in the pool configuration. The polymarket_ws_syncer worker subscribes to Polymarket's WebSocket feed and adjusts Intotes probabilities in real time, keeping prices aligned with the broader prediction market.

Each new cycle can receive updated Polymarket token IDs if the corresponding Polymarket market changes.

Configuration Tips

• Interval selection -- Hourly intervals (60 minutes) work well for volatile assets like BTC and ETH. Daily intervals (1440 minutes) suit less volatile assets or longer-term questions.
• Liquidity parameter -- Crypto loop events typically use moderate lmsr_b_kopecks values. Too low and prices swing wildly; too high and the AMM absorbs too much risk.
• Probability calibration -- Initial probabilities for each cycle can be calibrated based on historical data. The platform maintains per-asset, per-timeframe calibration parameters derived from Polymarket data.
• Template maintenance -- Update the template event when you want to change parameters for future cycles. Existing active cycles are not affected -- changes apply only to newly created cycles.