Skip to main content
Use the Create Market API when you want to create events and markets outside the admin UI. The API prepares metadata, images, on-chain calldata, and final registration, while your integration signs and sends the wallet transactions from the creator EOA.
Production base URL: https://create-market.kuest.com. Self-hosted deployments can point the app to another worker with CREATE_MARKET_URL.

​
Prerequisites

Creator EOA

The same EOA address must be used in the payload, EIP-712 signature, transaction sender, and finalize calls.
The prediction-market admin and scheduler can enforce your allowed creator policy before calling this API. The create-market worker itself requires the creator to have an on-chain proposer whitelist registered before preparation can complete.
The creator needs POL for gas and the required USDC funding shown by GET /market-config. The transaction plan may include USDC approvals and fee or reward payments.
POST /prepare requires an event image. Optional option images and sports team logos can also be uploaded in the same multipart request.

​
Creation Sequence

1

Fetch runtime config

Call GET /market-config to read the default chain, supported chains, contract addresses, funding requirements, and image limits.
2

Build the prepare payload

Create the JSON payload for the event and markets. Serialize it once, then compute payloadHash = keccak256(stringToHex(payloadJson)).
3

Request an auth challenge

Call POST /prepare-auth with creator, chainId, and payloadHash.
4

Sign EIP-712

Sign the returned challenge from the creator EOA. The signed message binds requestId, creator, payloadHash, nonce, expiresAt, and chainId.
5

Prepare the request

Call POST /prepare as multipart/form-data with the exact payloadJson, the signed auth envelope, and image files. The API returns prepare_in_progress.
6

Poll until prepared

Call GET /pending?requestId=...&creator=...&chainId=... until request.prepared.txPlan is present.
7

Execute the transaction plan

Send every item in txPlan from the creator wallet using the returned to, value, and data.
8

Persist transaction hashes

Call POST /tx-confirm after each transaction or once with the full list. This makes the flow resumable.
9

Finalize

Call POST /finalize with the confirmed hashes. If the response is metadata_update_pending, execute metadataUpdateTxPlan, confirm those hashes, and call POST /finalize again.

​
Request Statuses

​
Security Model

Preparation requires creator consent

The worker validates creator signatures and on-chain proposer whitelist state. If you expose direct automation to third parties, enforce any site-specific allowed creator policy in your integration layer before calling POST /prepare-auth and POST /prepare.
POST /finalize validates submitted hashes against the saved transaction plan. It checks transaction sender, target, calldata, value, and successful receipt before advancing.
GET /pending can return operational details for a known requestId or creator address, including transaction plan, hashes, status, and error messages. Treat request IDs as operational identifiers and avoid posting them publicly.
POST /prepare-auth creates resumable request rows, and POST /prepare processes uploads. Public deployments should configure allowed origins and edge rate limits according to the audience they intend to support.
Scheduled or recurring automation should sign from a server-side wallet store. Never expose private keys in browser code or public environment variables.