Getting started

The Risk Labs Proposer API lets whitelisted proposers submit ManagedOptimisticOracleV2 (MOOV2) proposals via API instead of submitting proposal transactions to the Polygon mempool. You choose the answer and supply the bond; the service submits the proposal transaction on Polygon and pays its gas. You remain the on-chain proposer and settlement beneficiary. The Proposer API will eventually be the only way to propose requests on MOOV2.

This requires programmatic proposers to migrate to the Proposer API. The Explorer Dapp will migrate to submitting proposals via the Proposer API, with proposal transaction signing and gas settings replaced by signing a gasless off-chain message. Your wallet may first need an on-chain Permit2 token approval, for which you pay gas. Submissions enter candidate selection and may not be selected; follow the API status until the proposal is confirmed on-chain or the candidate reaches a final unsuccessful result.

Make your first proposal →

Why this API exists

The goal is to protect proposers from MEV (maximal extractable value) on Polygon, including competition to copy or front-run a proposal in the public mempool. Bringing proposers onto a shared submission path lets the service coordinate candidates and submit the selected proposal, instead of each proposer independently racing an on-chain transaction.

This adds a submission layer to the existing proposal stack: your decision → signed API submission → relayer → Managed Oracle. It also reduces your gas cost and integration work: the relayer pays proposal gas and handles transaction submission, while your client signs and tracks status. An initial token approval can still require gas from your wallet.

Coordinated submission is the foundation for MEV protection, not a guarantee that every proposal is protected or included. Use the v1 endpoints for one candidate, or the batch proposing endpoints to prepare, submit, and track up to 100 independent candidates per call through the same API base URL. A batch submission does not guarantee a shared on-chain transaction.

What changes for a proposer?

Your funds and permissions

The API does not take custody of your wallet or have unrestricted access to your funds. Your private key stays with you. You control which request and outcome to sign, the bond-token spending limit, the nonce, and the deadline.

There are two permissions: an on-chain ERC-20 allowance to Permit2, and your signature authorizing SignedProposer to use it for the exact oracle request and outcome. The API relayer is not the Permit2 spender. A valid signature authorizes a real bond-token transfer when executed; it is not merely a login or proof of identity. The current API requires max_payment to be "0".

The core bond and settlement model stays the same as direct proposing: you supply the bond, remain the proposer, and receive the settlement payout according to the oracle's rules. The additional components are Permit2, SignedProposer, and the API/relayer submission path. Verify the chain, contract addresses, token, request, and signed terms against trusted configuration before signing. Service availability and candidate selection affect whether and when your proposal is submitted.

An incorrect proposal can still cost you your bond. API acceptance does not establish that your answer is correct. Read the full resolution rules and confirm final evidence before signing. Permit2 signing explains the permissions and how to limit or revoke them.

Proposer flow

Loading diagram…

From your client, check eligibility, construct and verify signing data, ensure Permit2 has sufficient allowance, sign locally, submit the exact signed payload, save the candidate ID and status URL, and poll until the API reports either a final unsuccessful result or a confirmed or indexed submission. Calling the signing-data endpoint is optional for both single and batch proposals. You can build the Permit2 witness typed data yourself from current request data and trusted configuration, then sign and submit directly; no prior preparation call or preparation token is required. Your wallet pays gas only if it needs to approve Permit2; the service handles the proposal transaction and pays its gas.

Prepare

Check wallet eligibility, identify the question and request round, and read the market rules and clarifications before choosing an outcome. Either use the optional signing-data helper or construct the typed data locally, then verify the terms. Your wallet needs the bond balance and sufficient Permit2 allowance; preparation does not reserve funds.

Authorize

Sign the verified typed data locally and submit it to the API. Save the exact signed payload before sending it, then save the returned candidate ID and status URL. If the response is lost, replay that payload instead of creating a new authorization.

Track

Poll the status URL. Selection is currently first come, first served among executable candidates: the first valid candidate starts a five-second selection window, ordered by server receipt time with candidate ID as the tie-breaker. Executability is rechecked before selection. Five seconds is not a confirmation guarantee.

202 means the candidate was stored; selected means you should follow its submission status. confirmed or indexed means the proposal is on-chain, not settled. Continue following liveness, disputes, and settlement through your oracle indexer. See status and retries for recovery details.