$NTDO | $PMRT markets live on beta now
Ctrlk

Polymarket: Trading architecture

Oracle design for Polymarket

For these listings, the external “Validator” leg is anchored to Polymarket’s CLOB midpoint (venue-normalized).

Normalization: 0–1 to 0–100

Polymarket prices are in 0–1 terms; Trove uses 0–100, so:

  • Validator_100 = 100 × midpoint_01

This normalization is intentionally lossless: the instrument is still “probability-priced,” just mapped to a scale that is operationally convenient for perp systems (margining, liquidation bands, and UI).

Tri-blend oracle

The full oracle follows your tri-blend:

Oracle = (Mark + Validator + EMA) / 3

  • Validator: Polymarket midpoint (cleaned for staleness; midpoint or last-trade fallback within guardrails)

  • Mark: Trove last traded price (our internal market)

  • EMA: Smoother on Trove internals (HyperPS)

  • Dynamic weights (Beta): Guardrails allow higher Validator influence while Trove depth is young

Why a blend is required (not just “use Polymarket”)

A pure-validator oracle is fragile under:

  • staleness windows

  • abrupt book gaps

  • venue pauses A pure-mark oracle is fragile when internal depth is still maturing.

So the blend gives you a continuous oracle that:

  • respects the external reference venue

  • reduces single-venue failure modes

  • can continue operating under degraded conditions

Staleness and pause behavior (degradation mode)

If Polymarket is stale or paused:

  • Validator weight reduces automatically

  • Mark/EMA weights rise within published limits This is a controlled degradation, not an on/off switch.

Circuit breakers and deviation bands apply.

Funding & convergence

Funding is the control loop that aligns Trove’s Mark to the Oracle (which reflects Polymarket).

Interpretation:

  • If Mark > Oracle, premium is positive → shorts should be paid (to pull Mark down)

  • If Mark < Oracle, premium is negative → longs should be paid (to pull Mark up)

What the “1-hour TWAP / tail trims / no self-trades” actually means

  • 1-hour TWAP: funding uses a time-weighted average over the hour so one spike can’t dominate the rate

  • Tail trims: extreme prints are clipped/trimmed so the premium signal reflects the median regime, not micro-outliers

  • No self-trades: removes wash-like activity from impacting Mark-derived inputs

This is how you get stable convergence in a market that is naturally jumpy around narratives.

Arbitrage intuition

  • If Trove < Polymarket (discount): longs on Trove receive funding; classic long Trove / short Polymarket basis trade

  • If Trove > Polymarket (premium): shorts on Trove receive funding; short Trove / long Polymarket hedge

As expiry approaches, both prices should converge toward {0, 100}; funding accelerates this.

Hedging & settlement liquidity (vault / MM)

To ensure liquidity at resolution, Trove’s vault/MM can run a delta-neutral hedge against Polymarket.

Core principle

Trove wants to avoid being structurally “long or short the outcome” at settlement.

So when users take directional risk on Trove, the vault/MM can maintain an opposing exposure on Polymarket such that net event exposure is approximately neutral.

Automated hedge flow

When a trader opens a leveraged position on Trove, the vault/MM can automatically open the corresponding notional hedge on Polymarket for that market (batched/netted where possible).

Example:

  • Trader opens 5× with $1,000 margin → $5,000 notional

  • Vault/MM opens an opposing ~$5,000 notional position on Polymarket (automated)

Why “batched/netted” matters

If you hedge per-fill, you create:

  • unnecessary transaction churn

  • worse average execution

  • higher operational overhead

So the hedge system is designed to track:

  • net Trove exposure per market

  • and target an opposing net hedge on Polymarket

This means Trove is not relying on “last-minute” liquidity at settlement — the exposure is continuously hedged into the reference venue.

Last updated