> 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/markets.md).

# Markets

## 4. Markets

### 4.1 NFT Floor Price Markets

The protocol's primary product. Each supported collection has exactly one active round running at all times, into which users submit PUMP or DUMP positions for the duration of the BETTING phase.

### 4.2 Custom Markets

<figure><img src="https://2744311952-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSMSeNSwHhGmoxl63JltC%2Fuploads%2FA5BCn8zIyL6rC1t6P62b%2Fkake_resolver_architecture_oracle_v2.png?alt=media&amp;token=b85dbc71-faf5-4a20-a143-21b956d76b5b" alt=""><figcaption></figcaption></figure>

Custom Markets allow any KinsmanNFT holder to propose a bespoke YES/NO prediction market around an arbitrary NFT-related event or claim — for example, whether a collection will release a new mint within a given window, or whether a floor price will cross a stated threshold within a stated timeframe.

A proposal goes through a Kinsman governance vote before it goes live (see the KinsmanNFT page for voting mechanics); once approved, anyone can bet on it — Kinsman holder or not.

#### 4.2.1 Resolver Types

Every Custom Market settles through one of the resolver types. In most cases the type is inferred automatically from the market's title and description (matching for keywords around trading volume, mint count, floor price, on-chain state, or a Kinsman governance vote); on-chain-state markets are the one exception, since a contract address and comparison operator can't be reliably inferred from free text the proposer sets those explicitly.

| **Resolver Type**           | **How it settles**                                                                                                                                                                                                                          |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Floor price                 | Compares a TWAP snapshot taken at market creation against the price at the market's end — same price feed as standard rounds (Section 2.2).                                                                                                 |
| Trading volume / mint count | Tracks a cumulative or sellout condition against OpenSea and Alchemy data. Because these conditions only move in one direction, a market can settle early the instant the condition is met, without waiting for the scheduled end time.     |
| On-chain state              | Checks total supply or a specific address's balance on a target contract. If the target is on the same chain as Kake, this settles trustlessly on-chain; otherwise the backend reads the target chain directly and submits the result.      |
| Kinsman governance          | For subjective or event-based questions no data feed can answer directly. Outcome is decided by a Kinsman holder vote, weighted by balance and reputation, running for a period the proposer sets (default 3 days). A tie refunds everyone. |

The backend checks every ended, unsettled market once a minute and dispatches it to whichever resolver logic applies.

#### 4.2.2 Early Resolution (Kinsman Governance Markets)

For a Kinsman governance market, waiting for the scheduled end time after the real-world outcome is already public knowledge lets anyone with that knowledge keep betting against people who don't have it. To close that window, any Kinsman holder can flag a market for early resolution by submitting evidence — a link, a description, or both. This opens a fixed 24-hour governance vote (or shorter, if the market's own scheduled end is closer than that). If the vote approves, betting locks immediately and the market settles with the community-approved result.

Submitted evidence is given an advisory AI plausibility score before the vote — cross-checked against an independent web search rather than the submitted link alone — so voters have a sanity check to read alongside the raw evidence. The score never blocks a vote either way; it's a second opinion, not a gate.

### 4.2.3 Creator Fee

* Bettors are charged the same 10% platform fee as standard rounds. Custom Markets do not increase the bettor-facing fee rate.
* Of the 10% fee collected on a settled market, 5% is paid to the market creator and the remaining 95% is retained by the protocol treasury. As a share of the total pool, this works out to the creator earning 0.5% of the pool and the treasury retaining 9.5%.

**Worked example:** if a Custom Market settles with a total pool generating $10,000 in collected platform fees (i.e. a $100,000 total pool at the 10% rate), the creator receives 5% of that $10,000 fee — $500 — and the protocol treasury retains the remaining $9,500. Bettor payouts are unaffected by this split; winners still receive their proportional share of the 90% distributable pool exactly as described in Section 2.1.

### 4.2.4 Creating a Custom Market

* Connect wallet (must hold a Kinsman NFT to propose).
* Navigate to Custom Markets.
* Select + Create Market.
* Provide title, description, duration, and resolution scenario — set the target contract and comparison operator explicitly if proposing an on-chain-state market.
* Confirm the on-chain creation transaction, which opens the proposal to a Kinsman governance vote.
* Once approved, the market goes live and anyone can bet.


---

# 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/markets.md?ask=<question>&goal=<endgoal>
```

`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.