> 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/integrity-and-fairness.md). # Integrity and Fairness Fairness is the core differentiator of Smily, and it is defended on two independent layers that cover different threats. Together they produce the provably fair, no-insider-edge, no-house-edge identity. ## The two-layer defense **Structural layer.** Multi-domain, multi-question rooms dilute any single insider edge and average out luck. This covers asymmetric information: a tip on one domain cannot win a room that spans five. **Cryptographic layer.** Commit-reveal, verifiable randomness, and frozen oracle snapshots cover speed, front-running, copying, and manipulation. This covers everything the structural layer does not. ## Cryptographic integrity * **Commit-reveal on answers.** Players submit a hashed commitment of their answers, then reveal. No player, and not the operator, can see another player's answers before the reveal. This also makes AI participation fair, since an agent cannot peek at opponents. * **Commit-reveal on questions.** The question set is sealed before the room opens, so questions cannot be leaked or front-run. * **Verifiable randomness (VRF).** Used for seating, the Spin and Go multiplier, and any randomized element, so randomness is provably unbiased and not operator-controlled. * **Frozen oracle snapshot.** Resolution data is captured at a defined, published timestamp, eliminating front-running of price ticks and ensuring all players are resolved against the same snapshot. * **Random seating and anti-collusion.** Seating is randomized, and collusion detection monitors correlated behavior across accounts and rooms. ## Resolution credibility The resolution layer is where Smily inherits the seriousness of a real prediction market. The credibility of such a market comes not from its order book but from its resolution: objective predefined sources, an oracle-based process, and a dispute-resistant mechanism. Smily replicates this resolution discipline while keeping its own simpler market structure, a room and a pot rather than an exchange. * **Deterministic questions** resolve automatically from price and data oracles, for example Pyth and Chainlink for prices, with official feeds for sports and macro. Because these outcomes are machine-readable, the majority of Smily's questions resolve in seconds. * **Judgment questions** resolve through an optimistic-oracle process modeled on the proposer-disputer game. A result is proposed, a challenge window opens, and if disputed it escalates to a vetted resolution. This is the only place a human-in-the-loop is needed. * **Airtight rules.** The wording of each resolution rule is law. Every question publishes its exact source, timestamp, and rounding. * **Void category.** A question that cannot be resolved (cancelled event, postponed match, oracle failure) is voided, its weight removed and refunded, with the 2% burn still applied at the pot level. * **Whitelisted proposers at launch.** Resolution proposals come from a vetted set, comparable to a managed optimistic-oracle model, to minimize incorrect resolutions and speed up settlement. * **Public source registry.** All resolution sources are published and auditable. ## AI and agents policy Smily is fully open to AI. Players may use AI to assist their predictions, and may connect their own AI or agent to play. The entry conditions and payouts are identical for everyone, human or machine. There are no human-only tables. The reasoning is threefold. First, AI assistance cannot be policed, since a player could consult a model privately, so a human-only table would be an unenforceable fiction. Second, mixing humans and agents fills tables faster. Third, the commit-reveal design already makes participation fair, because no participant can see another's answers. The honest, defensible position is an open table where anyone brings any edge under identical rules. This also aligns with Base's agent-native direction and gives Smily a strong human-versus-machine narrative. ## The threat model | Threat | Description | Mitigation | | ------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Insider edge | A player has private information about one domain | Multi-domain rooms dilute any single-domain edge to a fraction of the scorecard, balanced weighting, correlation guard | | Bots and AI farming | Sophisticated agents predict well and farm rooms | Open and acknowledged policy, judgment-type questions and enough rounds keep skill broad, skill-based matchmaking (later) protects micro tiers | | Front-running and latency | Seeing a price tick or answer before others | Commit-reveal on answers, frozen oracle snapshot, sealed question sets | | Copying | Seeing another player's answers | Commit-reveal hides all answers until reveal | | Collusion | Coordinated accounts sharing answers or soft-playing | Random seating, collusion detection across accounts and rooms, commit-reveal limits real-time coordination | | Sybil | Many fake accounts to gain an edge | Identical entry conditions for all, economic cost of buy-ins, the multi-domain structure gives no edge to extra identities | | Oracle manipulation | Influencing the resolution source | Large-scale, high-liquidity references only, airtight rules, whitelisted proposers, dispute mechanism, void category | | Unresolvable questions | An event is cancelled or data fails | Void and refund the question, the burn still applies at the pot level | --- # 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/integrity-and-fairness.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.