Where YES and NO Tokens Come From: Split, Merge and Redeem

YES and NO tokens begin as two claims backed by one complete set of collateral. Splitting creates those claims, merging recombines them, and redemption pays them according to a recorded result. Buying a token from another trader is a separate operation.

This third article in How Polymarket and Kuest work follows the assets underneath the interface, exchange and contracts. If payout and price still feel interchangeable, start with what a prediction market price means.

Start with collateral, not a price

Use our hypothetical question: “Will Observatory A publish a temperature of at least 30.0°C for City B at 12:00 UTC on Date C?” Assume its source, rounding, fallback and cancellation rules have been specified. We will model a standard binary Conditional Tokens Framework (CTF) condition, with YES first and NO second.

Collateral is the asset committed to back the positions. In this example, one winning token pays one collateral unit; a unit is not automatically a dollar. A stablecoin introduces issuer, transfer and value risks even when an interface displays a dollar symbol.

All balances below ignore fees, gas and financing. They use one condition, one collateral asset and no parent position. These assumptions let us reconcile every unit without mixing another market’s assets into the calculation.

CTF normally uses an ERC-20 token for collateral and ERC-1155 balances for outcomes. ERC-1155 lets one contract track many token IDs: a YES balance for the temperature question and a YES balance for an election are separate assets, even if both appear under the same ticker.

A complete set has a precise identity

Preparing a condition registers its oracle, question identifier and outcome count. It does not deposit collateral or create anyone’s outcome balances. In the inspected Kuest CTF source, preparation and splitting are separate functions.

For CTF, the condition ID is keccak256(abi.encodePacked(oracle, questionId, outcomeSlotCount)). The oracle address is part of that identity: the same question identifier assigned to a different oracle produces a different condition.

A collection identifies a set of outcomes, including any parent collection. The collateral address and collection ID then identify the position. Collection derivation has its own algorithm; use the contract’s getCollectionId helper rather than inventing a hash of the labels. The CTF developer guide explains that construction.

For our binary example, the partition is [1, 2]: bit masks selecting the first and second outcome slots separately. Together they cover all outcomes without overlap. The parent collection is 32 zero bytes, meaning this split starts from collateral rather than an already conditional parent position.

Consequently, matching titles are insufficient for merging. Check network, token contract, condition, collateral and collection path. A Polymarket YES and a Kuest NO cannot become a local complete set merely because the questions read alike.

Split: lock 100, receive 100 of each outcome

Start with 100 collateral units. A successful split transfers them into the CTF contract and mints 100 YES plus 100 NO to the caller. The split implementation validates the partition and performs these asset changes in one transaction; failure reverts the operation.

The wallet now has 200 outcome tokens, but only 100 complete pairs. Each YES–NO pair is backed by one collateral unit. In an ordinary YES result, its YES pays one and its NO pays zero; an ordinary NO result reverses that allocation. Splitting has created inventory, not doubled wealth.

Holding both sides also does not express a directional forecast. A market maker might split to obtain inventory to offer on both sides. Selling some YES afterward leaves a different exposure because the wallet still holds the corresponding NO; the split alone did not supply a buyer or lock in trading revenue.

An ordinary purchase can instead transfer existing tokens between accounts. If another trader sells you 10 existing YES, their YES balance falls and yours rises; that transfer need not mint new YES or NO. The source of inventory and the price paid for it are different questions.

Merge: burn 40 pairs, release 40 collateral

Before resolution, you can merge equal quantities of the matching outcomes. From 100 YES and 100 NO, merge 40 pairs: the contract burns 40 of each and returns 40 collateral. You retain 60 YES, 60 NO and 40 spendable collateral.

This ledger follows only our wallet and the backing attributable to its complete sets; it is not the contract’s entire balance. Fees, gas and financing remain excluded.

Wallet balances are listed as collateral / YES / NO.

The last row is one possible next step, not a step we take before the redemption example below. It returns the wallet to its starting balances before costs, demonstrating conservation rather than profit.

With 60 YES and only 20 matching NO, you can merge at most 20 pairs. The remaining 40 YES still have outcome exposure. A single YES cannot release a full unit before resolution because it does not cover the NO outcome.

The merge implementation does not require a payout result. Complete-set recombination works before resolution; the function is not restricted to that period. It uses the pair’s backing rather than finding an order-book buyer.

Redeem: use the result, not the latest quote

Now take the earlier state with 40 collateral and 60 of each token. If the recorded result is YES, redeeming those selected balances pays 60 collateral for YES and zero for NO. The wallet reaches 100 collateral before costs; the redeemed tokens are burned.

A wallet holding only the 60 YES would receive the same 60-unit YES payout. Redemption does not require its owner to supply NO as well. That is the key difference from a pre-resolution merge: a recorded result determines which individual claims pay.

In the inspected redemption function, the amount for each selected position is its balance multiplied by the relevant payout numerator, divided by the denominator. The denominator is the sum of the recorded numerators. Selecting a position redeems its whole balance in this CTF function; there is no partial-amount argument.

For 100 of each token, [1, 0] pays 100 YES / 0 NO, and [0, 1] pays 0 YES / 100 NO. A supported normal CTF payout of [1, 1] has denominator 2 and pays 50 to each side. These are collateral receipts, not net profit; acquisition costs still matter.

That fractional payout capability is not a universal cancellation-refund promise. The market’s rules and resolver must permit the result. A linked NegRisk event needs its own supported payout and recovery rules; do not assume an ordinary binary fallback applies.

The contract calculates with integer base units and rounds division down. If a collateral token has six decimals, 100 units means 100000000 base units; one base unit under a half payout rounds to zero. Display decimals must never be passed as raw contract integers.

A clock reaching the market’s end time does not establish a payout. Redemption requires a nonzero recorded payout denominator; the oracle and its configured process must first supply the result. That can introduce waiting time even when trading has ended.

Selling and redeeming are different exits

Selling requires executable buying interest. You transfer outcome tokens to a buyer for the agreed price, subject to available size, execution costs and successful settlement. It can close a position before the result, but a displayed midpoint is not an available bid.

Redeeming uses the recorded payout and the appropriate contract route after resolution. It requires no new order-book buyer. A 0.60 acquisition followed by a winning one-unit payout produces a 0.40 gross gain per token; a losing result produces a 0.60 loss, before costs in either case.

Buying both outcomes below their merge value only supports a gross spread after equal quantities actually fill in the same complete set. Unfilled legs, incorrect identifiers, fees, approvals, transaction failure and collateral risk can erase that spread or leave directional exposure. A quote alone is not a completed strategy.

How Kuest differs: creator context follows the positions

Kuest retains these CTF asset mechanics and extends condition preparation with a creator address and an external metadata reference. Its metadata update function restricts updates to the creator or an admin and records the old reference, new reference and updater.

For an operator, that creates a source-level way to associate a condition with its creator and trace metadata-reference changes. It does not store the full market document in the CTF ledger, freeze every displayed rule or decide the payout. Operators still need accessible documents and a clearly identified resolution route.

The public CTF guide separates the position ledger’s split, merge and redemption operations. A NegRisk adapter is a different contract route; identify its published interface and collateral before attempting the same inventory operation.

Permissions follow that route: splitting needs collateral allowance to the relevant CTF or adapter target. Negative-risk merge/redeem also needs the adapter’s permission to handle the CTF positions. Exchange trading approvals do not automatically authorize these inventory operations.

Version check, as of 30 October 2026: Polymarket’s current position-management documentation distinguishes CTF collateral adapters from the Protocol V2 Router and PositionManager. A version number or similar method name does not establish compatibility with another platform. Use the documented route for the actual position.

The Kuest CTF explanations above can be checked against its publicly verified Polygon contract. They do not establish the live collateral, permissions or resolver for every listed market. Before enabling inventory actions, confirm those details and show split, merge and redeem as distinct asset movements.

Planning that experience for your audience? Create your own prediction market with Kuest, and bring the market rules, intended audience jurisdictions and liquidity requirements needed to choose the right operating setup.