Layer Unifies Across Prediction Market Venues

Layer is a platform that lets writing teams define one strategy and run it across multiple prediction market venues. The core problem it solves is that different venues express the same event using different market identifiers, fee structures, and settlement rules. Layer normalizes all of this so the strategy code remains unchanged regardless of destination.

One Strategy, Many Venues

The typical workflow begins with a bot or AI agent that decides what constitutes a good trade. Layer sits beneath that logic and handles the venue-specific complexity. When the bot asks whether two markets represent the same underlying event, Layer reads the rules from both venues, compares them, and flags any differences. After settlement, it checks again to confirm the outcome was properly captured.

This matters because venues word events differently and sometimes settle them differently. Without a layer like this, a bot would need custom integration for each market, with manual handling of identifier mapping, fee calculations, and settlement verification.

Prices, Order Books, and Fees in One Format

A quoted price on one venue is not the same as a quoted price on another. Layer converts prices, order books, and fees from every venue into a single format. A bot using Layer sees the cost after fees and knows how much it can actually buy. This normalization means the bot does not need to understand the fee model of each venue — Layer presents the effective price.

The platform also handles the "same bet" problem directly. In example code, a developer queries for a market event and receives matched identifiers across venues:

pair = client.matches(q="fed december")[0]

Then orders can be placed on any venue using the same code pattern, with the venue-specific market identifier substituted automatically:

o = client.buy(
    venue="kalshi",
    market=pair.kalshi,
    side="yes", price=0.42, size=100,
)
client.cancel(o)
o = client.buy(
    venue="polymarket_us",
    market=pair.polymarket_us,
    side="yes", price=0.41, size=100,
)
o.status   # "filled"

One API, Every Venue

Layer provides one way to place and cancel orders across all venues. The code does not change when the destination venue changes. The developer writes the order intent — side, price, size — and Layer routes it to the correct venue using the normalized market identifier. Cancellation follows the same pattern.

This extends to positions, balances, and profit after fees, all reported in one format across venues. The bot knows what actually happened, not just what it sent.

Paper Trading, Backtesting, and Live Execution

Layer supports the full development cycle with three modes. In paper trade mode, the bot runs against real order books with fake money. Every tick from the venues' live streams can be recorded:

record_stream(
    ["", ""],
    "ticks.jsonl",
)

Those recorded ticks become the basis for backtesting. The same strategy code replays the recorded order book data:

client = Client(mode="backtest", books=load_books("ticks.jsonl"))

When ready, the same code runs live with real money. The transition is simply changing the client mode and providing venue credentials from environment variables:

client = Client(mode="live", kalshi=Kalshi.from_env())

In all three modes — backtest, paper, and live — the strategy code is identical. This eliminates the common failure mode where a strategy that works in simulation breaks in live trading due to unhandled edge cases.

Order Preview and Safety Controls

Every order is checked against limits the developer sets before it goes out. Layer can preview any order first, showing what the effective price will be, how much size is available, and any venue-specific constraints. The agent can stop itself from submitting an order that does not meet criteria, but only a person can turn it back on. This guardrail sits between the strategy and the venue, preventing runaway orders from reaching the market.

Keys Stay on the Developer's Machine

Layer works with the developer's own venue accounts. The API keys remain on the developer's machine. Orders go straight from the code to the venue without passing through Layer's servers. Layer's hosted service answers the questions that require a view across every venue — such as which markets are the same bet — but the actual order execution is peer-to-peer between the developer's code and the venue.

What This Means for Development Teams

For teams building AI agents or trading bots that operate across multiple prediction markets, Layer removes the integration overhead of supporting each venue individually. The bot's core logic — what counts as a good trade — stays focused on market dynamics rather than venue quirks. The platform handles venue normalization, order routing, fee adjustment, and settlement verification.

The ability to record live streams, replay them for backtesting, and then run the identical code with real capital provides a development workflow that many teams will find valuable. It reduces the surface area for bugs that differ between simulation and live execution.

Layer's approach of keeping keys on-prem and sending orders directly to venues addresses a common concern in API-integrated systems: that intermediate services become a single point of failure or a security boundary. By positioning itself as a normalization layer rather than a execution proxy, Layer lets teams keep their existing venue relationships while gaining the benefits of unified tooling.