The complete rules the Governance page runs on — eligibility, how votes are counted and kept private, quorum, approval thresholds, anti-abuse, and the hard boundary between a passed vote and anything actually executing.
Governance Module v1 · last substantive update 2026-07-20 (v1.1 hardening 2026-07-12) · applies to /governance/, /governance/proposal/, /governance/submit/
Gives verified $WinLEW holders a structured, server-verified, permanent, public way to weigh in on community, feature, reward, and burn-program decisions — fulfilling the original roadmap's Phase 5 promise ("$WinLEW holders vote on feature proposals," "$WinLEW holders vote on token-burn schedules") without pretending a website vote executes a treasury or burn transaction by itself.
Governance v1 applies to WinLEW community matters only. It explicitly does not govern:
Those are separate products with their own boundaries. A WinLEW governance vote has no authority over them.
Checked server-side, every time — never trusted from the browser, never cached indefinitely (60s TTL only, to avoid hammering RPC). The default v1 rule lives in exactly one canonical place, GOVERNANCE_CONFIG:
/mole link → /verify/ → select-role walkthrough. No new wallet connector was built for governance.Every eligible verified wallet gets one free vote on every proposal. Beyond that free vote, a wallet may add up to 10 further votes on the same proposal through the Governance Vote Fund — so the most any single wallet can ever carry on one proposal is 11. Results are tallied by that weight.
This platform has no historical-balance indexer — there is no way to answer "what did every wallet hold at block N" after the fact. Every live-balance feature (Transparency Center, Burn Center, governance) reads the current on-chain balance. Given that constraint, the options were:
Eligibility is no longer purely "live at whatever moment you happen to check." Each proposal has a snapshot boundary (defaulting to when voting opens). The first successful eligibility check for a wallet on that proposal, at or after the boundary, is recorded immutably and reused for every later check on that same proposal-and-wallet pair — so a wallet cannot change its own recorded eligibility by acquiring or disposing of tokens after that first check.
There are 17 defined statuses with an explicit map of valid transitions between them, so a proposal can never jump silently between states. For example draft → executed is not a legal transition; it must pass through review, discussion, scheduled, active, passed, awaiting-ratification/approved-for-execution, executing, then executed. archived is a true terminal state.
Every status change records a timestamp, the actor or system, the previous status, the new status, and a reason. In v1 there is no admin UI, so that record is a maintainer's public commit history and message rather than a separate audit-log feature — see Proposal publishing.
A fixed, controlled list of 14 categories: Community, Features, Quiz, Faucet, Games, Events, Rewards, Proof of Value, Burn Program, Treasury Allocation, Partnerships, Grants, Governance Rules, Platform Policy.
No free-form categories, so terminology never fragments across proposals.
Every proposal declares one of four modes. Governance is never presented as uniformly "binding":
A voter may update their choice until voting closes — the latest valid choice replaces the prior one. This is enforced by construction rather than by duplicate-detection logic: votes are stored keyed by wallet address within a proposal, so a second vote from the same wallet overwrites the first entry. The original cast time is preserved alongside the time of the latest change.
Proposal-specific, expressed as a fixed count of eligible votes — never a percentage of all holders. This platform does not have reliable total-holder-count data, and inventing one to make a quorum look rigorous would be fabricating a figure.
| Attack | Why it fails |
|---|---|
| Duplicate votes | Impossible by construction — wallet-keyed storage, see Vote-change rule. |
| Voting for another user | Impossible — the wallet is always resolved server-side from the session, never accepted from the client request body. |
| Session replay / client-side eligibility bypass | Eligibility is re-checked server-side on every single vote request. It is never cached client-side or trusted from a prior response. |
| Concurrent submissions | Every read-modify-write happens synchronously within one request handler, with no await between the read and the write, so two near-simultaneous requests cannot interleave. Tested with two concurrent votes from different wallets (both preserved) and two from the same wallet (exactly one survives — a vote change, not a duplicate). |
| Voting outside the window, or on a cancelled proposal | The vote path checks votable status and the voting window independently of whatever the frontend believes. |
| Malformed choices | Any choice not in the proposal's own list is rejected. |
| Duplicate proposal IDs | Checked against the seeded data by a dedicated test. |
| Result manipulation by frontend code | Impossible — the results calculation is the only source of truth and runs server-side. The frontend only ever displays what the API returns. |
There is no CMS and no unauthenticated public proposal-creation endpoint. Real proposals are a maintainer-edited record, published the same way burn events, partners, and events already are: edit the file, run the validation test to confirm the record is valid, commit, push.
v1.1 added a community submission review queue that lets anyone with a verified wallet submit a proposal idea for maintainer review — but a submission can never publish itself. Turning an approved submission into a real proposal is still that same manual, maintainer-owned step.
Every successful submission also best-effort-posts a summary to a Discord webhook. A webhook outage never fails the submission itself, because the record is durably written before the notification is attempted.
Because a submission's title and summary are user-supplied free text — unlike every other value this platform's webhook messages contain, which are all server-resolved — the payload explicitly blocks mention parsing. A submitter cannot embed @everyone, @here, or a role mention in their own title or summary and have it actually fire, while the one legitimate system-controlled "credit the submitter" mention still works. This is covered by its own test.
A burn-program proposal must carry a burn-details object — proposed amount, source, benchmark or date, reason, effect on the 100M goal, execution authority, and execution deadline — and this is enforced at the data-model level. The proposal detail page fetches the canonical, live Burn Center totals rather than ever restating a second hardcoded figure, so it shows current verified-burned, staged, and remaining-to-target alongside the proposal's own ask.
A successful vote never executes a burn. The lifecycle is exactly:
Proposal → Vote → Result → Maintainer safety review → Approved for execution
→ Separate, manually authorized burn transaction (outside this system)
→ On-chain confirmation → Burn Center event → Governance execution recordNo signing capability, private key handling, or transaction-broadcast code exists anywhere in Governance v1 — see Execution boundaries. A "Donate to Burn" flow is explicitly not implemented.
A feature proposal captures problem, proposed change, community benefit, affected systems, scope, risks, estimated effort, dependencies, alternatives, and success criteria as fields on the proposal record.
A vote never forces an unsafe or impossible implementation. After passage a maintainer classifies it — accepted, accepted-pending-prerequisites, requires-revision, unable-to-execute, or rejected-on-safety-or-legal-grounds — and any refusal requires a public reason.
The maintainer-ratified and binding-within-defined-policy modes both require a human decision after a vote closes, reflected in the awaiting-ratification → approved-for-execution transition. There is no code path that skips this step.
Governance has no relationship to incident response. An active security threat is handled entirely outside governance, by maintainers, exactly as established platform-wide. A vote-gated emergency response would be a contradiction: emergencies need speed, not a multi-day voting window.
No signing, no treasury access, and no burn-execution capability exists anywhere in Governance v1. Concretely:
Rejected, quorum-not-met, and cancelled proposals are never deleted. They remain visible in the governance archive exactly like passed and executed ones. Governance credibility requires preserving the unsuccessful decisions too.
<script in text fields at the data-model level — defense in depth, since the render layer escapes everything regardless.Prompted by the project owner's explicit request to audit governance for exploit vectors — "evidence over assumptions" — rather than trust the design documents at face value. Findings were verified against the actual code, not against this document's prior claims.
Vote casting and submission creation really do read-check-write synchronously with no await in between; both have concurrent-write tests rather than a comment claiming safety. Submission detail and withdraw routes return "not found" to non-owners, never a distinguishing "not yours". The maintainer gate has no bypass path, and maintainers vote through the identical eligibility path as anyone else — no special-cased privilege. RPC-failure handling never collapses to a false "ineligible" and never caches a failure.
The proposal-submission Discord webhook now explicitly guards against mention-injection from user-supplied free text.
Wallet linking has no check preventing a Discord account from relinking to a different wallet at any time, and the v1.1 snapshot lock-in records only the first balance check at or after a proposal's boundary — it has no minimum holding duration. In principle a wallet could be funded briefly right at a proposal's snapshot boundary and drained afterward. This is now weaker than it was between 2026-07-17 and 2026-08-06, and that is a deliberate trade. While voting required 1,000,000 WinLEW, funding a wallet briefly at a snapshot boundary cost a million tokens per vote. With the free-vote bar back at 1, that cost is gone — a sybil vote now costs a Discord account and a verified wallet, not a large holding. What it buys is capped at one vote, purchased weight still requires 1,000,000 held, and quorum still has to be met. The bar was moved to restore a deliberate incentive; the cost is that low-value sybil voting is cheaper, and this page says so rather than leaving it for someone else to find.
A duration-based fix is not buildable without a historical-balance indexer this platform does not have. Rather than ship a partial heuristic that could falsely exclude a genuine holder who happens to re-verify near a snapshot boundary, the limitation is stated plainly here and on the Governance page itself.
Wallet-based one-vote can never fully prevent one person controlling multiple funded wallets and Discord accounts. No KYC exists or is planned. This was already true before the review; it is stated explicitly rather than left implicit.