> For the complete documentation index, see [llms.txt](https://smily.gitbook.io/smily-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://smily.gitbook.io/smily-docs/the-pool-charter.md). # The Pool Charter The Pool Charter codifies the integrity and fairness principles into concrete rules for question selection. It is the credibility backbone of Smily, modeled on the discipline of a serious, resolution-grade prediction market. If a question does not satisfy the charter, it never enters a room. ## A. Question eligibility A question is allowed only if it satisfies all of the following: 1. **Objectively resolvable** from a predefined, public, authoritative source. Price and data oracles for markets, official league data for sports, official sources for events. 2. **Deterministic or oracle-verifiable** in its outcome. 3. **Non-manipulable.** Only large-scale, high-liquidity references are allowed: major crypto assets, major sports, macroeconomic releases. No low-cap tokens, no obscure events, nothing a single participant could influence or pre-know with certainty. 4. **Airtight resolution rules.** Exact source, exact timestamp or criteria, defined rounding, and a defined behavior for cancellation or postponement (void and refund the question). The wording of the rule is what resolves, not the headline. 5. **Time-boxed** to the room's duration. ## B. Domain mix per room * Each room draws from **four to six uncorrelated domains**. * The domain taxonomy is crypto markets, macro and traditional finance, sports, politics and geopolitics (resolvable events only), culture and entertainment (resolvable only), and on-chain and tech metrics. * **Balanced weighting.** Points are distributed roughly equally across domains. No single domain exceeds approximately 30% of the scorecard. * **Correlation guard.** Two highly correlated questions, for example two correlated crypto-price questions, are never counted as independent within the same room. ## C. Question-type mix Binary, multi-choice, and numeric-bucket questions are mixed within a room for richness, and they all score under the same rule. ## D. Genuine uncertainty Questions must carry real uncertainty at room start. A question whose answer is already known is dead weight. Market or forecast consensus is used to filter out near-certain questions, so every question in the room is a real test of reading. ## E. Timing and anti-front-run All questions are revealed at room start, sealed beforehand through commit-reveal. Oracle snapshots are frozen at defined timestamps. No question whose outcome is known before the commit deadline is ever used. ## F. Source governance At launch, questions are curated by the team from a vetted source list, comparable to a whitelisted-proposer model. A public registry of resolution sources is maintained and is auditable. Community-proposed questions, with vetting, may follow later in the roadmap. ## How the charter protects the game The charter is what lets Smily make its two strongest claims at once. Because every question is objectively resolvable and non-manipulable, the resolution is dependable and dispute-resistant. Because every room balances several uncorrelated domains with no domain dominating, no insider can buy their way to a win on a single tip. The charter is therefore both the credibility layer and the fairness layer, in one set of rules. --- # 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://smily.gitbook.io/smily-docs/the-pool-charter.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.