Signing an order gives permission to trade under specified terms. It does not mean the trade has happened. The API can accept it, the book can match part of it, and the settlement transaction can still fail.
This fifth article in How Polymarket and Kuest work follows the authorization behind the connected YES and NO books. We trace the system’s separate layers: what the participant signs, what the matching service enforces and what the blockchain actually records.
Start with an instruction, then follow the assets
Keep 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?” Buying its YES token means acquiring the specified outcome asset; signing a BUY order only authorizes acquiring it.
We use a standard binary Conditional Tokens Framework (CTF) market and generic collateral units. Amount examples assume six decimals, sufficient funds and permissions, and no gas or financing costs; fees appear separately where stated.
The explanations below use public signature standards, public CTF Exchange examples and hypothetical asset flows. Platform-specific supported wallets, order types and fees must come from the venue’s current public integration documentation.
Three authorizations do different jobs
An order signature authorizes a particular exchange instruction. API authentication identifies an authorized requester to a service. A wallet batch signature authorizes a separate bundle of wallet calls, such as setting an allowance.
An API credential identifies an authorized requester to a service; it is not the participant’s private key and does not replace an order signature. Polymarket’s public wallet and authentication guide provides one documented product example.
Separate objects, separate checks. A wallet batch has its own nonce and deadline; those fields do not become part of the exchange order.
EIP-712 defines structured message hashing and signing. Its domain can bind an instruction to a chain, application name, version and verifying contract, preventing a signature intended for one domain from validating under a different one.
The public CTF Exchange V2 signing code illustrates an application-specific EIP-712 domain. A domain name or version is part of the signed context; it is not proof that another exchange accepts the same message. Replay limits also depend on the actual contract’s state and validation rules.
The amounts contain the price
In the public CTF Exchange V2 order definition, the signed instruction includes the token, side, maker and taker amounts and account identities, among other fields. The signature authorizes that defined message, not whatever price an interface happens to display afterward.
Here, maker names the account supplying assets, even when its order immediately takes liquidity. That field name differs from the trading role maker, meaning an order that rests before another order trades against it.
For a BUY, makerAmount is collateral offered and takerAmount is shares requested. An order offering 60 for 100 YES encodes a limit of 60 ÷ 100 = 0.60; for a SELL offering 100 YES for 60, price is takerAmount ÷ makerAmount instead.
There is no independent signed price field to override that ratio. Changing the displayed price without rebuilding and signing the corresponding amounts cannot change the authorized terms.
A timestamp can describe when an order was created without being an enforceable expiration deadline. An integration must distinguish signed fields from service instructions and check their meaning in the current public order specification.
Validation decides whether the order can enter the book
Before placing an order, verify the intended asset, price limit, size, account and supported order type. Client checks and an API acknowledgment do not replace successful contract settlement.
A price tick is the permitted increment between quoted prices. Check current published market specifications before signing. A client-side check, service response and contract rule establish different things; a displayed minimum alone proves no on-chain constraint.
Funds and permissions are different checks: a BUY needs usable collateral and an adequate allowance to the settlement contract; a SELL needs the outcome tokens and transfer approval. A signature alone provides neither, and an admission-time balance check cannot freeze every later change to that account.
Post-only means an instruction is intended to add resting interest rather than immediately take liquidity. Check the venue’s documented combinations and rejection behavior; the label alone does not define every implementation.
Time-in-force tells the matching service what to do with unexecuted quantity:
- GTC — good till cancelled: leave eligible remaining quantity on the book.
- GTD — good till date: allow it to rest until a specified expiry.
- FAK — fill and kill: execute available quantity immediately and discard the rest.
- FOK — fill or kill: require the whole requested quantity to be executable or execute none.
An expiring service order and a signed contract deadline are different commitments. Verify where the current specification enforces expiry and what happens to already submitted transactions. The presence of a field in a request does not itself establish a contract guarantee.
A match still needs successful settlement
Consider these teaching checkpoints: signed → accepted/resting → matched → submitted → confirmed. An order can be rejected before admission; one accepted order can produce several partial matches and settlement transactions. These labels explain responsibilities rather than define a universal API enumeration.
A partial match leaves quantity for later matching when its time-in-force permits. A failed settlement requires reconciliation before any retry.
The public CTF Exchange V2 contract illustrates authorized matching and contract checks before asset movement. The direct, mint and merge examples in Article 4 explain the possible asset movements and their funding requirements.
The transaction is atomic: if a required transfer or check reverts, its state changes are rolled back. That does not undo a different transaction that already succeeded, and a reverted transaction may still consume gas.
A transaction hash identifies a submitted transaction, not a successful purchase. Check its receipt and the confirmation state required by the chosen network. Until the outcome is known, an interface should preserve that uncertainty instead of reporting delivered assets.
For an operator’s interface, retain the order identifier, matched quantity and transaction reference separately. If a transaction fails or remains uncertain, reconcile its actual outcome before retrying; changing a local label cannot move assets.
Partial fills consume the asset offered
Suppose the resting BUY offers 60 collateral for 100 YES, and a first fill receives 40 YES at exactly 0.60. Ignoring fees, it consumes 24 collateral, leaving 36 collateral of signed capacity, equivalent to 60 YES at that same price.
A resting SELL offering 100 YES for 60 collateral consumes 40 YES in that fill and receives 24 collateral. Its remaining maker amount is 60 shares, not 36 collateral. Both orders have 60 YES left to trade, but their on-chain remaining counters use different assets.
Same 40-share fill, different counter units. Exact limit-price execution; fees excluded.
The public CTF Exchange V2 arithmetic works in integer base units. Under the proportional floor-division model used below, taking amount equals making amount × signed taker amount ÷ signed maker amount, rounded down. Exact reconciliation requires the actual route’s rounding rules.
For example, selling 1.000001 shares from a signed 3-share order for 1.8 collateral computes 1,000,001 × 1,800,000 ÷ 3,000,000, flooring to 600,000 collateral base units. Small fills and fees therefore need the implementation’s rounding rules; multiplying rounded display prices is insufficient for exact reconciliation.
Fees belong in their own ledger
Assume a direct purchase of 100 YES for 60 collateral and a hypothetical 0.60 fee on each participant. The buyer needs 60.60 collateral; the seller receives 59.40. The remaining 1.20 is total fees, so all buyer cash is accounted for.
Hypothetical fees, not a current rate. Buyer outflow 60.60 = seller receipt 59.40 + total fees 1.20; 100 existing YES move to the buyer.
In this explicit example, the BUY fee is added to the buyer’s cash requirement and the SELL fee is deducted from proceeds. Actual charges, recipients and rounding must be checked for the selected venue and route; the example is not a fee schedule.
Cancellation has a boundary
A request to remove an open order concerns its remaining unexecuted quantity. It does not reverse completed fills. Treat cancellation confirmation and any outstanding settlement transaction as separate records; check both before reusing the funds.
If settlement was already submitted, a later book cancellation cannot promise to stop it. Check the transaction outcome before assuming the assets remain available, especially when the original order was partially filled.
Cancelling the remainder and settling an earlier match can both occur. Neither delayed protection reverses a successful transaction.
A broader account restriction is not the same as cancelling one order. Recovery controls can have different scopes, delays and authorities. Use the published contract and product documentation for the actual account instead of assuming every control is an immediate stop.
The Deposit Wallet has a separate pause and emergency waiting period before emergency withdrawals or approval revocations. Wallet pause alone does not disable batch execution or signature validation in that source; it is not an instant trading kill switch.
Version names do not define an integration
Polymarket’s legacy CTF order signed taker, expiration, nonce and feeRateBps. Its separate CTF Exchange V2 order removes those fields and adds timestamp, metadata and builder; price remains an amount ratio.
The V2 repository also removes fillOrder/fillOrders, retaining operator matching through matchOrders. This CTF Exchange V2 is distinct from the Protocol V2 position architecture in polymarket-v2-external; Kuest does not automatically inherit either repository’s updates.
Missing expiration in a contract struct does not mean a product lacks expiring orders. Polymarket’s current lifecycle documentation describes GTD at the product level; its positions guide distinguishes CTF and Protocol V2 ledgers. Verify the actual market’s route before building an integration.
What a Kuest operator should disclose
Kuest’s public owner guide separates the operator’s application from shared services. For participants, disclose the supported account flow, complete fee estimate and distinct accepted, matched and confirmed states; these are observable product requirements rather than implementation details.
Kuest’s public fee documentation describes operator participation in trading fees and configurable affiliate sharing. An allocation of a fee is different from an additional charge on trade notional. Use the current public configuration and settlement records when explaining what a participant pays.
For a branded operator, that creates a concrete integration decision: preserve the correct builder identity, display the actual total charge, and reconcile its allocation against settlement records. A code or branded frontend alone guarantees neither admission, a fee entitlement nor revenue.
Launch your own prediction market with Kuest with an execution policy your participants can understand: intended audience jurisdictions, precise market rules and resolution route, required trading sizes, supported wallet flow, fee disclosure and separate accepted, matched and confirmed states.