Non-production prototype
These contracts are unaudited. The configured treasury currently has no contract code, so real-money betting and LP deposits are not operational. Do not deposit; check the current deployment status before any interaction.
What We're Building
Polypar is a reference design for house-backed, fixed-odds parlays on Polygon. A trusted creator publishes a separate vault for each offered parlay. That vault stores 2–12 Conditional Tokens legs, a deposit deadline, a capacity, a multiplier floor, and an on-chain margin setting.
When a bettor deposits, the backend signs a short-lived probability quote and the vault mints share-backed claims at the resulting entry price. The intended shared treasury supplies bankroll when winning claims exceed the bettor collateral already held by that vault. Losing collateral flows to the treasury.
Polypar uses Polymarket-derived prices and its Conditional Tokens outcome infrastructure. It does not place the bettor's deposit or order on Polymarket.
Execution model
| Question | Polypar house-backed vault | Market-maker/RFQ parlay |
|---|---|---|
| Counterparty | A dedicated Polypar vault, backed only by its deposited collateral and intended shared treasury | A maker or quoting venue chooses whether and at what terms to supply capital |
| Execution wait and slippage | No parlay order-book match or maker-response round trip once the offered vault is open, priceable, and in-cap; approval, a 30-second signer quote, Polygon confirmation, and quote movement still apply | Execution depends on receiving and accepting a maker quote; timing and repricing depend on that system |
| Price source | Current Polymarket Gamma outcome-price snapshots, then vault primeBps and minSharePrice | Defined by the maker or venue; its exact reference and adjustment rules are system-specific |
| Settlement | The vault reads its stored leg tuples from the factory's immutable Polygon Conditional Tokens address | Defined by the quoting venue's settlement system |
| Capacity | A hard per-vault deposit cap plus the actual collateral available at resolution; there is no aggregate solvency reservation | Constrained by maker inventory, risk limits, and willingness to quote |
| Trade-offs | Narrow, pre-published combinations can avoid maker matching, but depend on data, signer, chain, caps, deadlines, labels, and bankroll solvency | Can support maker-selected terms, but introduces a quote-response dependency and venue-specific trust boundaries |
Availability is conditional
An open card is not a promise of execution or payout. Source prices can be unavailable, the signer or RPC can fail, the board can move below the accepted multiplier, capacity can fill, the deadline can pass, and a winning vault can be underfunded.
Why one vault per parlay?
Each clone isolates a fixed set of legs and makes the user's claim explicit: shares belong to one all-or-nothing outcome. The structure makes settlement deterministic once CTF outcomes exist, but it does not make vault labels, creation, pricing, or treasury funding trustless.
The current deployment is non-production because its configured treasury has no contract code. Verify that fact in Network & Contracts before treating any app card as actionable.
Next: learn how bankroll flows in The House Maker, then review the practical constraints in Risks & Limitations.