Polymarket Integration

Polymarket is the largest decentralized prediction market by volume, operating on the Polygon (PoS) blockchain. Integrating Polymarket into the Oraclyst Terminal requires a hybrid approach: fetching metadata via their hosted API (Gamma) while executing trades via their specialized layer on top of the Gnosis Conditional Token Framework (CTF).

1. Data Ingestion: Gamma API

We do not query the Polygon blockchain directly for market discovery as it is inefficient. Instead, we utilize the Gamma API, a hosted indexer provided by Polymarket.

• Endpoint: https://gamma-api.polymarket.com/events

• Sync Frequency: Every 10 seconds.

• Mapping Logic:

  • id: Maps to Oraclyst external_id.

  • title: Used for Semantic Matching.

  • markets.id: The specific Condition ID for "Yes" or "No" tokens.

  • volume: Used to calculate liquidity depth.

Note on Resolution Sources: The Gamma API response contains a field ancillaryData which includes the IPFS hash of the UMA resolution rules. The Oraclyst Semantic Engine parses this text to ensure the market matches the resolution criteria of other venues.

2. Execution Logic: CTF & CLOB

Polymarket does not use a standard AMM (Automated Market Maker). It uses a Central Limit Order Book (CLOB) for execution, which then settles on-chain.

The Proxy Wallet Model: To enable users on Base (Oraclyst's home chain) to trade on Polygon (Polymarket's home chain) without bridging manually, we use a system of Relayer Proxy Wallets.

1. User Action: User signs an intent on Base: "Buy $100 of Poly-Trump-Yes".

2. Solver: The Oraclyst Solver detects this intent.

3. Execution: The Solver uses its own inventory of MATIC and USDC on Polygon to execute the order via the Polymarket CLOB API.

   • Library: py-clob-client.

   • Auth: EIP-712 signatures.

4. Tokenization: The Solver locks the resulting Conditional Tokens in the Oraclyst Polygon Vault.

5. Minting: The Oraclyst Protocol mints the corresponding SOT on Base for the user.

3. Bridging & Settlement

We utilize a "Just-In-Time" (JIT) bridging mechanism. Solvers are required to rebalance their inventory between Base and Polygon periodically using fast bridges (e.g., Stargate or Across) to ensure they always have sufficient USDC on Polygon to cover user demand.