Virtual AMM

OpenPoly is a whitelabel service from the Polynion team. It lets operators embed Polynion-style prediction markets without building market mechanics, share accounting, or settlement workflows themselves.

Polynion markets use pure dichotomy options: each market has two outcomes, commonly read as YES and NO. This keeps the user experience easier to understand than conventional order book prediction markets while still using transparent math-based pricing.

What the engine handles

Operators do not need to maintain order books, market makers, pool balances, or per-market share mechanics. Polynion handles:

• market state and outcome share dynamics
• price movement from buying and selling
• integer-based quote and settlement calculations
• market activity traces
• webhook events and reporting records

The operator controls the wallet adapter, callback endpoint, API keys, dashboard configuration, and user experience around the embedded Mini App.

High-level model

Each market keeps real trade state and virtual liquidity. Virtual liquidity gives the market depth, so prices can move smoothly without requiring an external liquidity provider or a central limit order book.

At a high level:

1. Initial market probability creates virtual depth for both outcomes.
2. Buying one outcome moves the market state.
3. Price updates deterministically from the updated state.
4. Selling or reversing uses the same stateful math path.
5. Activity is recorded and exposed through operator reporting and webhooks.

Prices are represented in basis points, where 10000 means 100 percent. Shares use integer micro-share units. This avoids floating-point drift and keeps quote and settlement behavior reproducible.

Why this matters for operators

Operators get prediction market functionality without managing many independent market systems. The Polynion engine handles market state, share dynamics, user trade accounting, and settlement-side events.

For users, this means no separate credits or balance conversion step in the OpenPoly docs flow. Balance movement happens through the operator wallet adapter in real time.

For operations teams, this means every key activity has traceable records:

• operator API requests
• wallet debit, credit, reversal, and lookup calls
• trade and redemption records
• webhook delivery attempts
• replay and failure evidence

What is intentionally abstracted

This page explains the operator-facing model only. Exact internal formulas, tuning choices, and edge-case controls are implementation details of the Polynion engine and are not required for integration.

Operators only need to implement the public contracts documented in:

• wallet adapter: /docs/wallet-adapter/overview
• operator API: /docs/operator-api/authentication
• webhooks: /docs/webhooks/overview
• production readiness: /docs/production-readiness/checklist