> For the complete documentation index, see [llms.txt](https://kake-1.gitbook.io/kake-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kake-1.gitbook.io/kake-docs/core-concept.md). # Core Concept ## 2. Core Concepts ### 2.1 Parimutuel Betting In a parimutuel system, all bets placed on a given round are pooled together regardless of direction. When the round settles: * The total pool is divided into a winning-side pool and a losing-side pool, determined by the settlement outcome. * The losing pool, net of fees, is distributed across winning participants in direct proportion to their stake in the winning pool. * There are no house-set odds. Implied odds emerge dynamically from the ratio of PUMP stake to DUMP stake at the moment betting locks. * The platform extracts a fixed percentage fee from the total pool at settlement (see Section 3.3, Fee Structure). Except on a TIE, where no fee is taken and all stakes are refunded in full #### 2.1.1 Payout Formula For a settled round, an individual winning bettor's payout is calculated as follows: ``` payout = userStake + (userStake / winningPool) × losingPool × (1 − feeRate) ``` Where: * userStake — the amount the individual bettor staked on the winning side. * winningPool — the total USDG staked on the winning side (PUMP or DUMP) across all bettors. * losingPool — the total USDG staked on the losing side. * feeRate — the platform fee rate taken from the pool, 10% in all cases. For Custom Markets, the platform shares a portion of this collected fee with the market creator after settlement rather than charging an additional rate (see Section 3.3) — this does not change the 10% deduction applied to bettors' payouts. Equivalently, the fee can be applied once to the full pool before distribution: ``` totalPool = winningPool + losingPool distributable = totalPool × (1 − feeRate) payout = userStake / winningPool × distributable ``` Both forms are mathematically equivalent ways of expressing the same parimutuel split; the protocol's contracts take fees from the total pool prior to distribution rather than from each individual payout. #### 2.1.2 Worked Example Assume a round locks with 700 USDG in the PUMP pool and 300 USDG in the DUMP pool (1,000 USDG total pool), and the round settles PUMP: * Total pool: 700 + 300 = 1,000 USDG * Platform fee (10%): 100 USDG deducted from the total pool * Distributable amount: 1,000 − 100 = 900 USDG * A bettor who staked 70 USDG on PUMP holds 70 / 700 = 10% of the winning pool * That bettor's payout: 10% × 900 USDG = 90 USDG (a net gain of 20 USDG on their 70 USDG stake) If the same round instead settled DUMP, PUMP bettors would receive nothing beyond what is refunded under a TIE outcome, and DUMP bettors would split the 900 USDG distributable amount proportionally to their share of the 300 USDG DUMP pool — meaning each DUMP USDG staked would return roughly 3 USDG (900 / 300), reflecting the smaller size of the winning pool relative to the losing pool. **Custom Markets:** bettor payouts on Custom Markets use the identical formula and the identical 10% fee rate as standard rounds — a Custom Market does not charge bettors a higher fee. What differs is where the collected fee goes afterward: a portion of the platform's 10% fee is shared with the market's creator rather than being retained entirely by the protocol treasury. See Section 4.2.1 for the creator fee mechanics and worked example. ### 2.2 Floor Price Oracle Floor price refers to the lowest active listing price for a given NFT collection. Kake sources this via a time-weighted average price (TWAP) drawn from multiple upstream sources, rather than a single spot read. This is specifically to resist someone manipulating the price right at the instant of settlement. The same TWAP-based price feed backs both standing rounds and floor-price Custom Markets. The Kake backend acts as the oracle: it fetches the floor price at round start (snapshot) and again at round end (settlement price), then submits the settlement price on-chain via the protocol's automation wallet for the smart contract to compare against the snapshot. ### 2.3 Rounds & Round Lifecycle Each supported NFT collection runs a continuous sequence of prediction rounds. Every round progresses through a fixed state machine: | **Phase** | **Name** | **Description** | | --------- | --------- | ---------------------------------------------------------------------------------- | | 0 | BETTING | Open window — users submit PUMP or DUMP positions with USDC. | | 1 | LOCKED | Betting window closed; a floor price snapshot is recorded as the round's baseline. | | 2 | LIVE | Price is being tracked toward the settlement window; no new bets accepted. | | 3 | SETTLED | Round complete; oracle has submitted the final price; payouts are claimable. | | 4 | CANCELLED | Round invalidated (e.g. oracle failure); no activity. | A new round is automatically initiated for a collection immediately following settlement of the previous round, ensuring continuous market availability.\ \ **Zero-bet cancellation:** if a round closes its BETTING window with no bets placed, it cancels automatically instead of settling. The scheduler restarts a fresh round, but backs off exponentially on collections that keep cancelling empty — waiting 30 minutes, then 2 hours, then 6, then 24. So a dead collection doesn't burn gas redeploying a round every 90 minutes indefinitely ### 2.4 Settlement Logic At the end of the LIVE phase, the smart contract compares the settlement-time floor price against the LOCKED-phase snapshot: * Settlement price higher than snapshot → PUMP side wins. * Settlement price lower than snapshot → DUMP side wins. * Settlement price unchanged → round is a TIE and all stakes are refunded without fee deduction. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://kake-1.gitbook.io/kake-docs/core-concept.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.