> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kuest.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How Kuest Works
> Understand what your deployment owns, which Kuest services it uses, and how orders reach shared liquidity.
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.
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
Hosting, domain, database, uploaded assets, secrets, admin wallets, brand, integrations, legal settings, support, and release operations.
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
| User action | Your deployment | Kuest service | Settlement or source |
| --------------------------- | --------------------------------------------------------- | ---------------------------------------------- | ------------------------------------- |
| Browse markets | Renders discovery and event pages | Gamma, Data API, community, and price services | Indexed market data |
| Sign in and prepare trading | Stores the local account and encrypted credentials | Auth and relayer services | User wallet and Deposit Wallet |
| Place or cancel an order | Builds the request and obtains user signatures | CLOB | Polygon exchange contracts |
| Create a market | Collects content, creator approval, and wallet signatures | Create Market worker | Market and resolution contracts |
| Resolve a DRO market | Guides an approved proposer through the result | Resolution data and sync services | Direct Resolution Oracle and adapters |
## 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:
| Matching orders | Settlement |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `BUY` and `SELL` for the same outcome token | Transfers the outcome tokens to the buyer and collateral to the seller. |
| `BUY` for outcome A and `BUY` for outcome B | **MINT:** splits $1 of collateral into one complete pair and sends each buyer the outcome purchased. The limits cross when their prices sum to at least $1. |
| `SELL` for outcome A and `SELL` for outcome B | **MERGE:** receives one complete pair, merges it back into $1 of collateral, and pays each seller. The limits cross when their prices sum to at most $1. |
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
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
Use the managed setup path for the fastest production start.
Compare hosting targets and choose your database, storage, and scheduler.