> For the complete documentation index, see [llms.txt](https://docs.souless.fun/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.souless.fun/community/governance.md). # Governance Governance coordinates limited Community Mode policy. It does not control the ERC-20 or market. ``` PENDING ──→ ACTIVE ──┬──→ DEFEATED ├──→ VETOED └──→ QUEUED ──┬──→ EXECUTED └──→ EXPIRED ``` Voting power comes only from the canonical `sTOKEN` balance recorded immediately before proposal creation. The same snapshot fixes total voting supply, proposal threshold, quorum, and each wallet's maximum vote weight. Unstaked tokens and unapproved external receipts do not vote in V1. Deployment parameters define proposal threshold, quorum, voting delay, period, and execution delay; the UI shows them for each proposal. ## Launch-time policy comes first A Community-enabled market does not have to begin at the default 60% Creator / 10% Community split. During launch, the creator can choose the market's starting policy: * **Community:** 10%–70% of collected USDC-side LP fees. * **Creator:** the remainder of the fixed 70% creator/community pool, or `70% - Community`. * **Staking:** 20%–80% of the selected Community allocation. * **InfoFi:** the remainder of Community. The selected values are initialized as the genesis Community policy and apply from **epoch 1**. No proposal or vote is required to establish that starting policy. Governance begins from that launch-selected state. The Community share can later move only upward from its established floor, while Creator falls by the same amount inside the fixed 70% pool. The Staking/InfoFi split can later move in either direction within its 20%–80% bounds. Governance changes are scheduled for future eligible epochs. ## Creator alignment and veto The immutable launch-time governance wallet can retain veto only while its wallet balance plus recognized liquid stake meets **3% of total supply**, with up to **0.1% tolerance** in the current design. An unresolved shortfall has a seven-day grace period, after which veto is permanently removed for that token. ## Governance can * Propose one typed future policy containing `communityShareBps`, `stakingShareOfCommunityBps`, and `effectiveEpochId`. * Increase, but never decrease, the Community share from the market's established floor. Creator share remains derived as `70% - Community`. * Set the staking share inside Community rewards from 20% through 80%; InfoFi receives the derived remainder. * Schedule changes only for future eligible epochs. * Record votes, vetoes, and execution publicly. ## Governance cannot * Mint, blacklist, pause, tax, or seize the token. * Move or reduce official LP principal. * Rewrite launch identity, referral rights, Launch Partner rights, or finalized epochs. * Redirect the protocol, referral, or Genesis Launch Partner allocations. Those destinations are outside the fixed creator/community pool governed here. * Redirect token-side fees or unrelated protocol funds. * Reduce the Community share below the launch/current policy floor, postpone an already pending policy, or reduce either Staking or InfoFi below 20% of Community rewards. The fee system's protocol share is a residual, not a governance-controlled fixed percentage. In the fully loaded case with Community Mode, an active referral, and the Genesis Launch Partner campaign, protocol receives **20%** while Creator + Community remain fixed at **70%**. The default policy produces 60% Creator, 10% Community, 20% protocol, 5% referral, and 5% Launch Partner pool; a custom launch policy changes only the split of that 70% Creator/Community block. See [Fees and economics](/economics/fees.md). Policies persist until a later successful proposal replaces them. One proposal may change both independent Community variables. Empty Staking and InfoFi allocations remain feature-specific carryover; governance cannot silently move an empty pool across features. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.souless.fun/community/governance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.