Skip to main content
Your prediction market is a branded frontend and operational control plane connected to Kuest trading infrastructure. You own the site experience and deployment. Kuest provides the shared services used for market discovery, order matching, wallet operations, and market lifecycle data.
Multiple operator sites connected to the Kuest market network and shared trading services
The Kuest catalog can combine selected mirrored Polymarket markets, markets created by your team, and markets from another operator you explicitly choose as a source. Creating markets is optional: a site can launch using only the shared catalog. Trading activity remains attributed to the originating operator whether an order comes from the site interface or from a bot or SDK integration used by its traders. That attribution is what connects eligible trading fees to the operator’s configured fee wallet. The CLOB calculates the category-based Kuest fee off the matching hot path, grosses it up for the signed order’s operator share, and sends the deterministic total to the Exchange. The Exchange splits that total between Kuest, the operator, and any affiliate. Orders without an assigned builder use the configured default share, but the unassigned portion stays with Kuest and is accounted separately from amounts eligible to fund rewards.

​
Responsibility boundary

You manage

Hosting, domain, database, uploaded assets, secrets, admin wallets, brand, integrations, legal settings, support, and release operations.

Kuest provides

Authentication support, CLOB access, relayed wallet actions, market and account data, community services, market creation, and shared network configuration.
Your users interact with your domain and brand. Keep Kuest credentials and service secrets server-side; only public runtime URLs and explicitly public IDs should reach browser code.

​
Request path

​
Shared liquidity

Markets with the same outcome token IDs use the same Kuest order books. Orders submitted through your site can match compatible orders already resting in those books. Your frontend controls presentation and order entry, but it does not create an isolated matching engine.

​
Complementary outcome settlement

For a binary condition, the CLOB treats its two outcome tokens as complementary parts of one fully collateralized pair. Matching can therefore settle three ways: For example, BUY A @ $0.15 can match BUY B @ $0.85 without either order waiting for an existing seller. Likewise, complementary sell orders at $0.15 and $0.85 can settle by merging the paired positions. Only the common executable quantity fills; any remainder keeps its place in the order book. The CLOB classifies and batches the fills, while the exchange contract performs the corresponding transfer, split, or merge onchain. Public activity keeps each participant’s physical action—for example, a submitted SELL A remains displayed as SELL A, even when settlement uses a merge.
Do not describe a frontend deployment as its own exchange or promise isolated liquidity unless you have built and operate a separate matching and settlement stack.

​
Data you should back up

Database

User records, settings, categories, local order history, event state, integrations, and operational job data live in your PostgreSQL database.
Logos, event images, market covers, and uploaded legal files live in the Supabase or S3-compatible storage profile you configure.
Keep an encrypted, access-controlled copy of deployment secrets. Rotating BETTER_AUTH_SECRET invalidates sessions and encrypted trading credentials.
Keep environment values, domain records, scheduler definitions, and infrastructure code under change control without committing secrets.

​
Next step

Guided launch

Use the managed setup path for the fastest production start.

Manual installation

Compare hosting targets and choose your database, storage, and scheduler.