Kuest: white-label prediction market infrastructure on Polygon

An operator brings the brand, the infrastructure does the rest

Kuest is open-source prediction market infrastructure, described in the repository as white-label infrastructure built on Polygon, with the promise of deploying it, branding it and earning trading fees in under fifteen minutes.

The division of labour in that sentence is the product. The operator brings a brand and an audience, and the infrastructure supplies the market machinery: a matching engine, a CLOB, the contracts, the frontend, the wallet connection, the fee accounting and the APIs that bots use. The README summarises it as your own branded prediction market with a custom domain, logo, categories and fee rate, shared liquidity from day one through mirrored Polymarket markets with live order flow, a multi-language interface with built-in internationalisation and theme customization, and what it calls a full Web3 stack with zero backend work.

The chain and the settlement asset are fixed. The stack is Next.js and TypeScript on the frontend, Polygon for the chain, USDC for settlement, Safe for the multisig, the Reown AppKit for wallet connection, Li.Fi for cross-chain routing, and wagmi with viem for the Ethereum client layer. The contracts are described as derived from Polymarket's audited CLOB architecture and adapted to support shared liquidity across multiple operator frontends, and the reason given for the choice of Polygon is that most prediction market liquidity already lives there, with the bots, the market makers and the USDC balances already in that environment.

The repository is not archived, the last push was on 2026-10-14, and the primary language is TypeScript. The homepage is `kuest.com`, with a live demo at `demo.kuest.com` and operator documentation at `docs.kuest.com`. The licence is not classified by GitHub under a standard name, so the `LICENSE` file in the root is the text that matters.

Shared liquidity and a fee share that is the operator's business model

Two mechanisms define the economics, and both are documented with unusual precision.

The first is the operator fee share. It is 30 percent by default of the final taker fee, and configurable from 20 to 45 percent, with the final taker fee itself varying by category and execution price. So the operator does not set the fee outright, it takes a share of a fee that the venue computes, and the share is the number an operator negotiates with its own business case.

The second is shared liquidity. The roadmap records shared liquidity across operator sites as completed, along with operator-created markets with opt-in network sharing, so a market created by one operator can be exposed to the network only if its creator opts in. That is the mechanism that lets a white-label product have a book on day one without a market-making team, and it is also the mechanism that makes the operators depend on each other.

The trading machinery underneath is the same shape as the reference venue. The dependency list includes `@polymarket/clob-client-v2` at version 1.2.0, and the completed roadmap items include a CLOB engine with a relayer, a matching engine, deposit wallet trading flows, a PnL system with a trader leaderboard, outcome and Polymarket arbitrage trading features, and a Gamma metadata API that is site-isolated. There is also a public bot SDK in Python and Rust, described as compatible with existing Polymarket tooling, which is what makes the venue usable by the automation that already exists.

The fee sharing is on-chain, per the roadmap item for on-chain affiliate and trustless fee sharing, and the operator fee is credited without the operator having to run a payment reconciliation job. That is the part of the design that removes the most operational work from a small team.

Three ways to launch, from a form to Kubernetes

The README offers a table of three launch routes, and the audience for each is stated, which is unusual and useful.

The no-code launch is a guided setup form at `kuest.com/launch`, and it is described as the fastest route and the one for most operators. The Vercel and Supabase route is a hosted deployment with full codebase control, for technical operators, and the manual installation covers Docker, a VPS, Cloud Run, Fly.io, Kubernetes and Terraform, for advanced and enterprise use.

The middle option is the interesting one, because it is the difference between running a service and running a product. With the no-code path the operator gets a deployment without a codebase, which is what an operator without an engineering team needs, and with the manual path the operator has a repository to fork, a Dockerfile to build and a Terraform configuration to apply, which is what an operator who wants to change the contracts needs.

The infrastructure directory in the repository is the evidence for that last route. There is an `infra/` directory, and the deployment targets the README lists, Docker, a VPS, Cloud Run, Fly.io, Kubernetes and Terraform, all live in the operator documentation rather than in the application code.

The application itself is a standard Next.js project. The scripts in `package.json` are `bun run --bun next dev` and `bun run --bun next build`, a standalone start that runs `bun scripts/start-standalone.ts`, a migration script at `bun scripts/migrate.ts` for `db:push`, and a test setup with `bun test --parallel tests/unit` and Playwright for the end to end tests. The project manager is Bun, the lockfile is `bun.lock`, and the tooling is a modern one: oxlint for linting, oxfmt for formatting, knip for unused code, husky for the git hooks, and Sentry for server error reporting through `@sentry/nextjs`.

The environment file is where the operator's configuration lives

The `.env.example` in the repository is the most informative file in it, because it lists everything an operator has to decide.

The required section starts with the CLOB credentials, `KUEST_ADDRESS`, `KUEST_API_KEY`, `KUEST_API_SECRET` and `KUEST_PASSPHRASE`, which the file says are obtained by connecting an EVM wallet on Polygon at `auth.kuest.com`. Then come `ADMIN_WALLETS` as a comma-separated list of admin addresses on Polygon, `SITE_URL` which is used for canonical links, wallet metadata, embeds and callbacks, the Reown AppKit project id, the Better Auth secret, the cron secret and `POSTGRES_URL` for the runtime database.

The comment on the Better Auth secret deserves attention. It has to be random 32 characters, and changing it invalidates all user sessions and encrypted credentials, which means every user has to log in again and re-authenticate for trading. That is the kind of consequence that a deployment note in an example file is better at communicating than a support page.

The optional section is where the chain and the policy decisions live. `CHAIN_ID` is empty or 80002 for the Amoy test network, and 137 for Polygon mainnet. `POLYGON_RPC_URL` takes comma-separated RPC endpoints used for on-chain reads in fallback order, which is a resilience choice for a node that has to keep serving reads. `RESOLUTION_REPORT_MIN_TRADED_MARKETS` defaults to 5 and sets the minimum number of distinct traded markets required to propose a resolution, which is a market manipulation rule expressed as a configuration value.

The last of these is the one to read twice. A rule that requires five distinct traded markets before a resolution can be proposed is a crude but real defence against a resolution being decided on thin activity, and it is configurable, which means the responsibility for the value sits with the operator.

Who the README says this is for

The operator table in the README is the clearest statement of the commercial intent, and it is worth reading as positioning rather than as a feature list.

Brokerages and investment platforms are the first group, on the argument of adding a new asset class for clients, with event contracts on rates, elections and macro indicators, and the example given is that XP just did this with Kalshi. Financial media and news groups are the second, on the argument of turning an audience's market conviction into a tradeable product, embedding live markets and earning fees instead of running ads. Fintech and neobrokers are the third, on the argument of differentiating with an instrument competitors do not offer. Crypto projects and DAOs are the fourth, with community prediction markets and on-chain fee distribution. Creators and communities are the last, for any niche with a passionate audience, and the examples are sports, politics and entertainment.

The market case in the README is made with numbers that a reader should treat as claims rather than as measurements, since the repository is the vendor's own. Prediction markets are described as processing more than 18 billion dollars in monthly trading volume, with 66 percent of that demand coming from outside the US, and Kalshi is described as CFTC-regulated with 200 times annual volume growth, having signed its first international brokerage deal with XP Inc, described as Brazil's largest investment platform with 4.7 million clients, with a quote from its co-founder and chief operating officer in a Bloomberg piece from March 2026.

The argument the README draws from that is structural rather than numeric. A regulated venue can sign such a deal one broker at a time, and a white-label infrastructure layer makes the same capability available to any operator without a bilateral negotiation. Whether that reasoning holds for a specific operator, in a specific jurisdiction, is a question the documentation does not answer.

The regulatory surface is part of the product

Running a venue where people trade contracts that resolve on real-world events is a regulated activity in many jurisdictions, and the repository contains a compliance-shaped layer that a reader should understand before deploying.

The completed roadmap includes Sumsub identity verification, that is KYC, integrated through `@sumsub/websdk`, and country access restrictions, which are a mechanism for refusing users from jurisdictions the operator has decided not to serve. The stack also includes the Reown AppKit with its sign-in-with-ethereum variant for wallet authentication, and Better Auth with a Drizzle adapter, with the database schema in Postgres.

The resolution layer is where the legal exposure concentrates, and the README is explicit that UMA resolution is coming, listed as soon in the stack summary. Until then, resolution proposals are made by operators and, by the configuration value, require a minimum number of distinct traded markets. A dispute process for an operator that has no automated resolver is a human process, and that is where the cost and the exposure sit.

The alternative approach, for an operator that wants a prediction product without operating a venue, is to build a client against the CLOB client the repository already depends on, `@polymarket/clob-client-v2`, and to provide the interface and the audience without taking on the matching engine, the relayer, the fee accounting and the resolution workflow. The difference in approach is that Kuest is a venue with an operator fee share and shared liquidity, and the alternative is a front end on someone else's venue with no fee share and no book of your own.

None of this is legal advice, and the licence file in the repository is the place to start reading, because GitHub cannot classify it and a white-label deployment will involve a contract between the operator and the platform.

Editorial conclusion

Kuest fits an operator who wants a prediction market product in weeks rather than months, who can run a Next.js application with a PostgreSQL database and a wallet-connected frontend, and who wants the order flow and liquidity that already exists on Polygon rather than starting with an empty book. It is the wrong choice for an operator who needs a regulated venue, because a white-label deployment puts the regulatory question on the operator while the repository only provides a compliance-shaped surface, and it is the wrong choice if you want a single venue you control alone, because the shared liquidity model is the point. Before deploying, read the `LICENSE` file yourself, since GitHub cannot classify it, and treat the KYC integration and the country access restrictions as the start of a compliance programme rather than the end of one.

Frequently asked questions

Official sources

1. Issues
2. kuest/prediction-market on GitHub
3. Project website
4. README