> For the complete documentation index, see [llms.txt](https://learn.trovemarkets.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.trovemarkets.com/trove-x-polymarket/polymarket-trading-architecture.md).

# Polymarket: Trading architecture

## Oracle design for Polymarket

For these listings, the external “Validator” leg is anchored to **Polymarket’s CLOB** [**midpoint** ](https://docs.polymarket.com/developers/CLOB/prices-books/get-midpoint?utm_source=chatgpt.com)(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**).

```
Premium index P: (Mark−Oracle)/Oracle
```

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)

```
Funding rate F:P+clamp(I−P,−0.0005,+0.0005)
(1-hour TWAP, tail trims, no self-trades)
```

**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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learn.trovemarkets.com/trove-x-polymarket/polymarket-trading-architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.