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.

Opinion markets have two outcomes, commonly YES and NO. AMM quotes account for virtual reserves, quantity, trade premiums, rounding, and execution controls; the displayed probability alone is not the executable trade price.

What the engine handles

Operators do not maintain order books or run a market-maker service. 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 uses the same reserve-aware engine. A wallet reversal compensates a money movement; it is not a new AMM sell.
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.

Per-share trade fees round up in Credits. Buy collateral rounds up to Credits; sell collateral rounds down before fees. The wallet FX layer separately floors conversion to buying power or native payout. See FX fees and rounding; do not apply a universal “always floor” rule to quotes.

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.

This does not mean execution and wallet movement are atomic. Uncertain outcomes require ledger reconciliation, not an automatic replay.

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

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

Operational and economic boundaries

Market visibility controls what an operator can show from eligible markets; it cannot override another operator's permanent private-market ownership. Where approved operator-requested markets are available, the requesting operator explicitly underwrites principal gains, losses, and winning redemption obligations. Engine hosting does not remove that financial risk.

Use Market PnL for user cash results, Resolutions for resolution exposure, and Settlement Reports for the operator's monthly amount due. They answer different questions.

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