Governance & Capture Resistance

This is the technical companion to Why OhShii. That page makes the case in plain language; this one is for a developer, auditor, or skeptic who wants the mechanisms and the honest limits. It does not re-derive the full parameter tables — those live in Voting and ONS vs SONS; this page is the threat → defense → honest-limits narrative.

A note on what “capture resistance” means here, up front: none of this makes a takeover impossible. Governance is majoritarian by design — a well-capitalized, identity-verified coalition can still win votes. What the design does is raise the cost of capture and remove the cheapest single-actor paths. Where a mechanism only buys time or money against an attacker, this page says so.

How to read the numbers: votable vs hardcoded

Two layers protect a parameter:

DAO-votable defaults — quorums, thresholds, windows, the VP cap, the lock minimum. These live in a stable VotingParamsConfig and are changed by set_voting_parameters.
Hardcoded rules — the VP formula, which proposal categories count as Critical, the decision rules (tie-rejects, no-early-close-for-Normal), the guardian bans, and every Shield / rate-limit / delegation constant. These change only by a canister upgrade — which is itself a Critical proposal.

The load-bearing detail: set_voting_parameters is itself routed through the Critical lane. A cheap Normal proposal cannot weaken a Critical or veto-override threshold, because changing those thresholds is a Critical operation. The bars defend themselves.

Threat model (abstract)

Generic ways a governance system gets captured, and the OhShii countermeasure for each:

Vector	What it looks like	Countermeasure (below)
Whale dominance	One holder accumulates enough VP to decide outcomes	Quadratic VP + per-identity cap
Sybil splitting	Capital/identity spread across many principals to beat the square-root damping	Proof-of-personhood gate (the thing that makes QV actually work) + a per-LGE cap on unverified (Guest) participants
Rushed critical change	A dangerous proposal pushed through during low participation	Two-axis Normal/Critical thresholds + longer windows
Mid-flight rule change	Altering thresholds while a proposal is open, to flip its outcome	Grandfathering (snapshot at creation)
Delegation concentration	A delegate amassing follower VP into a bloc	One-hop, bipartite, capped, follower-keeps-own-VP delegation
Guardian abuse	A malicious or compromised emergency operator	Overridable veto, hardened removal, hard-walled powers (+ removal create/vote exempt from `TrustedOnly`)
Self-dealing controller/treasury/upgrade	Using governance to seize canisters, the treasury, or the pool	Controller/stop/upgrade routing + day-zero autonomy
Cycle-drain / grinding DoS	Hammering public endpoints to push the canister into failure	Shield (PoW / rate-limit / Defcon) + cycle floors

Voting power: quadratic, capped, live

Voting power is shaped to make buying influence sub-linear:

VP per eligible lock = min( sqrt(token_amount) × (lock_days / 30) , cap )

The formula is hardcoded (it is computed in the lock-storage canister and changes only by upgrade). It rewards duration (linear in months) more than size (square root of amount).
The cap is a DAO-votable default of 36,000 VP, and it applies to the sum of a principal’s eligible locks — splitting one identity’s stake across many locks gains nothing (36,000 + 4,000 still caps at 36,000). On the ecosystem DAO (ONS) the cap can be lowered by vote but raising it above 36,000 requires a canister upgrade; on a campaign DAO (SONS) it is fully votable.
The 45-day minimum lock is a DAO-votable default; a lock earns VP only if its duration meets the minimum and its status is Active. A freshly-created, not-yet-activated vesting lock grants 0 VP.
VP is read live at vote time from the lock state — it is never snapshotted at lock creation, so unlocking or letting a lock lapse removes the power immediately.

Why this matters and why it is not enough on its own: the square root damps a whale, but quadratic voting without Sybil resistance is weaker than linear voting — an attacker simply splits one wallet into many and beats the square root. QV is only whale-resistant when paired with proof-of-personhood. The two features are sold together because they only work together.

The identity gate (what makes QV actually Sybil-resistant)

Two independent proof-of-personhood methods — World ID and DecideID — with OR semantics: either one satisfies the gate. One verification works across every OhShii DAO, because verification state lives on the ecosystem canister and campaign DAOs read it cross-canister.
When active it is a Universal Participation Gate: it covers vote, create_proposal, follow, and set_accepts_followers.
Gate-off is not ungated. Even with no method enabled, direct actions still require VP > 0 (and a campaign DAO additionally requires stake + a proposal fee), and delegation falls back to an active-lock anti-Sybil check. The gate raises the bar; it is not the only bar.
LGE participation has an additional anti-Sybil cap. Each Liquidity Generation Event accepts at most 50 distinct unverified (Guest) participants while the identity gate is active — bounding how many free, unverified identities can enter a single launch (and thus acquire tokens that later become VP). Verified participants are unbounded by it; already-admitted Guests keep participating; and the cap is inactive when verification is globally off (because every wallet would otherwise resolve to Guest, which would cap the whole launch). It is enforced backend-side, atomically, at a Guest’s first contribution. See LGE Participation.

Code default vs operational state — the distinction matters, do not conflate them:

In code, the ecosystem (ONS) gate defaults OFF. This is an availability fail-safe: verification depends on two third-party providers, and the canister must stay operable even before those providers are wired (or if both became unreachable). It is a resilience default, not the operational state.
Operationally, both methods were enabled before ONS became an autonomous DAO, so the gate is active from day zero (with a base of already-verified voters). Turning it off is not an operator action — once OhShii is removed from the controllers, only a DAO vote (a Critical operation) can disable it. So the quadratic-VP + identity pairing is in force from the start, and only the DAO can change that.
On a campaign DAO (SONS), verification defaults ON (requires_verification = true) for every fresh deploy.

Two-axis model: Normal vs Critical

Every proposal is classified Normal or Critical. Which categories are Critical is hardcoded (a match over the proposal-category enum, changeable only by upgrade): canister/governance/asset upgrades, batch upgrades, controller add/remove targeting the DAO itself, snapshot restore/delete, voting-parameter changes, and the Shield kill-switch. The thresholds themselves are DAO-votable defaults:

	Normal	Critical
Voting window	3 days	7 days
Quorum	250,000 VP and 15 voters	350,000 VP and 20 voters
To pass	more Adopt VP than Reject VP — a tie rejects	≥ 65% Adopt
Early close	No	Yes: ≥ 75% with 450,000 VP & 30 voters and a positive guardian vote (symmetric early-reject at ≤ 25%)
Guardian veto	No	Yes (overridable)

(All values are DAO-votable defaults; the tie-rejects rule, the no-early-close-for-Normal rule, the symmetric reject formula, and the requirement of a positive guardian vote for early approval are hardcoded. The guardian-positive-vote requirement applies only to early approval — early reject has no guardian gate, and the gate is skipped when no guardian is set.)

The effect on capture: making a dangerous change cost more participation, more time, and more visibility than a routine one — and a low-bar Normal proposal can never reach a Critical target.

Grandfathering (defeats the mid-flight rule change)

Decision thresholds are snapshotted at proposal creation. Changing the parameters later cannot retroactively flip an open proposal’s outcome — the proposal is judged by the rules that were live when it opened.

The guardian: a brake, not a kingmaker

The guardian is a single non-anonymous human principal. Infrastructure, management, and governance canisters are banned from the role — validated at proposal creation and re-checked at execution.
Its only outcome-affecting power is a blocking-but-overridable veto on a Critical, vetoable, still-Open proposal: the veto moves the proposal to Vetoed and opens a community override round. Override succeeds at ≥ 80% of participating (adopt + reject) VP with 700,000 VP and 50 voters — a bar that is intentionally reachable, so a veto can only delay, never permanently kill. The community keeps the final word.
Guardian-removal proposals are hardened: a hard 7-day window, never early-close, and the guardian cannot vote on its own removal. Removal is a vetoable-but-overridable proposal like any other Critical action: the guardian may veto its own removal, but a veto is never a kill — it opens the community override round (≥ 80% of participating VP, 700,000 VP, 50 voters), the guardian may not vote in that round either, and the community always retains the power to complete the removal at the override supermajority. A guardian cannot permanently block its own exit — including via the Shield kill switch. A guardian-removal vote — in round 1 or in its override round — (and, on a campaign DAO, a removal create_proposal) is exempt from the TrustedOnly lockdown: classified TARGET-only as a RemoveGuardian action, it reaches the body and is counted even while a captured guardian holds its own canister in TrustedOnly. The carve-out skips only the lockdown’s mode-rejection for a genuine removal; every other Shield layer (cycle floor, global + per-caller caps, Defcon/PoW) still applies, and an appoint/replace is not exempt. So the community can always remove the guardian and end the lockdown; an at-quorum removal also still finalizes (the resolution timer reads the on-proposal tally, not the firewall). A compromised guardian can still deny other public traffic with TrustedOnly — that is the kill switch’s intended anti-Sybil behavior, a compromised-trusted-key boundary mitigated by key custody — but it can no longer block the vote that removes it. See the Shield kill-switch note.
The guardian cannot change votes, rewrite tallies, alter anti-replay (nullifier) sets, or change DAO-voted parameters — those state areas are hard-walled even from disaster-recovery rebuilds. Its other powers (resign, rebuild derivable indices, refresh caches, force-process stuck refunds idempotently, and reclaim tokens stranded in an ICPSwap pool after a failed treasury proposal — see Disaster Recovery) are maintenance / DoS-defense / recovery only.
The guardian cannot spend funds or choose where funds go. It has no withdrawal path and no discretionary path to the treasury or the LP position — those are DAO-held. Its only fund-touching power is an idempotent, fixed-destination recovery: it can trigger a sweep that returns tokens stuck in an ICPSwap pool (after a failed treasury swap/liquidity proposal) back to the executing canister’s own treasury — the destination is fixed in code, the guardian cannot name a recipient, the sweep is a no-op if nothing is stuck, and it fails closed if a treasury operation is mid-flight on that pool. So the guardian can return owed funds home, but can never send funds out or pick where they land. The worst a compromised guardian can do is stall — within the bounded, overridable, self-healing limits above — not steal.

For full honesty: the veto is the guardian’s only outcome-affecting power, but it is not literally the only thing the guardian can do — it can also create proposals exempt from the fee / rate-limit / verification gates, and moderate (hide) a proposal’s description text. Neither touches a vote, a tally, or a result.

The role is not bound to a human — and that does not change where power sits. Nothing above depends on who or what holds the role: the guardian can never change votes, tallies, governance state, anti-replay sets, or DAO-voted parameters; its only governance-affecting power is the blocking-but-overridable veto, the community always keeps the final word at the configured supermajority, and removal stays hardened (a 7-day window, never early-close, the guardian barred from voting on its own removal) — and, like every Critical action, removal is vetoable-but-overridable, so the community always completes a removal at the override supermajority. Because the design only requires the guardian to be non-anonymous and not one of the banned principals (infrastructure, management, or the governance canister itself) — it does not require a verified or human principal — the role could in principle be held by an ordinary canister running rule-based, non-discretionary, auditable logic rather than a person. This is a property the design permits, not an announced plan or a promise of an automated guardian; and such an agent would still inherit the assumptions of whoever authored and operates it. Any concrete adoption would itself be an act of governance — appointing any guardian, human or canister, is a SetGuardian proposal at the Critical threshold (guardian-vetoable), removable or replaceable by the DAO at any time through the same hardened path, with no operator backdoor to install it.

The write-freeze can pause a vote, but never block a removal — or alter a result

Disaster recovery can put the governance canister into a temporary write-freeze while it rebuilds a derivable index (see Disaster Recovery). A natural worry: could a compromised guardian weaponize that freeze — keep re-triggering an index rebuild to keep vote ingress paused, and so stall the very proposal that removes it? The design closes this on three independent levels.

The freeze can only pause ingress, never change an outcome. While a rebuild is active, new vote calls for ordinary proposals are short-circuited (a bounded liveness effect, not a correctness one) — and that pause is itself bounded: a re-trigger cooldown of 10 minutes per principal, a 4-hour watchdog that auto-aborts a pathological cascade, and a circuit-breaker that auto-aborts after 5 consecutive failing ticks. Crucially, the freeze touches only a derived index. Recorded votes, the per-proposal tallies, the anti-replay (nullifier) sets, and DAO-voted parameters are hard-walled — a rebuild cannot read-modify-write them. No freeze can rewrite a vote, a tally, or a result.
An already-quorate proposal finalizes during a freeze. Finalization is driven by a timer that reads the tally stored on the proposal record, not the frozen index. So a proposal that has already reached quorum has its decision sealed by the timer even while writes to the index are paused — the freeze cannot strand a result that the votes already determined.
Guardian-removal votes are freeze-exempt by design. A vote on a guardian-removal proposal — in round 1 or in the override round that follows a guardian’s veto of its own removal — is classified up front (by target) and routed through a freeze-exempt write path that deliberately omits the rebuild write-gate, so the vote is recorded even while a guardian is spamming index rebuilds. In round 1 that path writes the source-of-truth vote map every rebuild re-derives from; writing the source-of-truth can’t corrupt anything a rebuild later re-derives, and it is the same class of mutation the canister already tolerates mid-rebuild (vote-removal is likewise ungated). In the override round the ballot goes to a separate, disjoint vote map that the rebuild never reads or writes at all — safer still, with nothing for a rebuild to desync. The only residual (and only in round 1) is a cosmetic, self-healing gap in the derived “your votes” listing, which the next rebuild repopulates from the source-of-truth (the append is idempotent, so the exemption can never double-count).

Net effect: combined with the removal-proposal hardening above (hard 7-day window, never early-close, guardian can’t vote on its own removal, and — though removal is now vetoable-but-overridable — both the removal vote and its override round freeze-exempt), there is no path through disaster recovery by which the role can freeze, delay, or distort the vote that removes it. (One separate lever — putting the Shield firewall into its TrustedOnly lockdown — is a distinct, disclosed trust boundary discussed under “Replacing a compromised guardian” next and in the Shield Pre-Auth Cache kill-switch note.)

Replacing a compromised guardian — the remove-then-appoint playbook

If a guardian key is compromised, the correct response is remove first, then appoint — never a single-step “replace” proposal:

Remove the compromised guardian with a SetGuardian proposal that sets the guardian to none. This removal is the hardened path: a hard 7-day window, never early-close, and (on the ecosystem DAO) freeze-exempt and TrustedOnly-exempt — in round 1 and in any override round. The incumbent may veto its own removal, but it cannot vote in the override, cannot weaponize an index rebuild or a TrustedOnly lockdown to keep the removal vote from reaching the body, and cannot stop the community completing the removal at the override supermajority. (The one residual is the bounded fresh-personhood availability caveat under Fresh personhood on the veto-override round: a sustained attestation outage can delay a contested removal — a liveness bound, never a way for the guardian to approve, spend, or alter a result.)
Appoint the clean principal with a second SetGuardian proposal once no incumbent remains. An appoint/replace is a normal Critical proposal — it is guardian-vetoable and (during an active rebuild) pausable — so doing it while the compromised guardian is still seated lets that guardian veto or stall its own replacement. With the seat already empty, there is nothing left to veto or freeze.

A single-step SetGuardian-to-a-new-principal is therefore the wrong move under compromise: it is both vetoable by the incumbent and (on the ecosystem DAO) freeze-pausable. Remove-then-appoint sidesteps both.

Disclosed trust boundary — the TrustedOnly lockdown. Separately from voting, a guardian can put its own canister’s Shield firewall into TrustedOnly — the kill-switch lockdown that admits only trusted operator callers and rejects everyone else at the firewall, under consensus. The nuance that matters: “trusted” here is the narrow operator set — self-calls, the governance canister, the admin allowlist, and the guardian itself — not the verified voting community. Under TrustedOnly every ordinary voter, however honest, verified, and long-standing, is rejected; so a compromised guardian could use it to lock out exactly the community that would vote it out (and in the autonomous end-state the guardian may be the only non-self “trusted” principal left). In that end-state — a sealed campaign DAO, or the ecosystem DAO once the bootstrap admin keys are removed — the lever has no central reversal (a campaign DAO is excluded from the ecosystem kill-switch coordinator) and no auto-expiry. The internal resolution timer still finalizes a removal that reached quorum before the lockdown (it reads the on-proposal tally, not the firewall), so an at-quorum removal still executes — and a fresh removal vote / create_proposal, including the override-round removal vote, is exempt from the lockdown (target-classified as RemoveGuardian, with every other Shield layer still enforced), so the lockdown cannot block the removal step of this playbook either; only non-removal public actions are obstructed while it is active. This is the same class as any compromised privileged key and is out of the Shield’s threat model — which defends against untrusted Sybil callers, not a compromised guardian key. It is therefore a deliberate, disclosed trade-off (the lockdown is sticky precisely because its job is to shed a Sybil flood), mitigated operationally — through guardian-key custody and the choice of guardian — rather than by Shield plumbing. See the Shield Pre-Auth Cache kill-switch trust boundary.

Fresh personhood on the veto-override round

When the guardian vetoes a Critical proposal, the community override round that decides whether the veto stands demands a fresh proof of personhood from every override voter — a new World ID attestation cast for that specific override, not the standing verification that already let them vote in round 1. The gate reads an immutable per-proposal snapshot taken at veto time (override_requires_fresh_attest), never mutable config, so it cannot be quietly switched off mid-round.

Caller-driven — no borrowed trust. The human attests their own personhood directly on the ecosystem canister (ONS); the subject is the calling principal, never a name passed in by another canister. For a campaign-DAO (SONS) override the same direct-on-ONS attestation is used: ONS trusts no assertion from a SONS canister (the campaign-DAO id is inert key material), and the campaign DAO only reads whether the human attested. Per-DAO eligibility — who may vote in that override — is checked locally inside the campaign DAO.
One human, one override ballot. Each fresh attestation spends a per-override nullifier keyed to that exact (DAO, proposal) round, so a verified human can attest once per override; the same person cannot multiply their weight across the round.
What it buys, and what it does not. Standing verification is enough to vote; overturning a guardian’s emergency brake is deliberately harder — it forces each override voter back through a live personhood check, so a stockpile of acquired, dormant, or shared verifications — including identities bought specifically to mount a take-over — cannot be re-mobilized to flip a veto. Because the fresh check de-duplicates on a per-human anchor, a farm of bought principals collapses onto the real humans behind it; a take-over that wins round 1 with purchased identities is therefore annullable by simply demanding everyone re-prove they are live humans. That collapse is exactly why the override requires World ID and not DecideID — World’s nullifier is per-human and survives across principals, whereas DecideID’s verification is bound to the principal id, so it cannot tell one human’s pile of bought principals apart (see Why World ID — and why not DecideID — for the override below). This raises the cost of mustering an override coalition; it does not make a legitimate, freshly-attested supermajority impossible, and it is not meant to. The community keeps the final word at the configured supermajority — the fresh check only makes that word come from live humans.

Honest residual — availability only, bounded. The fresh attestation needs one outcall to the World verification endpoint, and those outcalls share a global hourly cap (a cycle-drain bound). An attacker rotating junk proofs can saturate that cap and delay override attestation for the rest of a window. This residual is bounded and availability-only, not a capture path:

No drain-to-freeze. The global cap plus a per-call cycle-reserve floor hold the cycle bound regardless of how the attacker rotates callers — the canister cannot be ground into a frozen state this way.
No integrity break. The World outcall and the canister-local nullifier de-dup are authoritative; a caller can neither forge a verification nor reach into another DAO’s nullifier set.
Contested guardian removal shares this residual — bounded, and never a capture. A guardian-removal proposal is a vetoable-but-overridable Critical action: if the guardian vetoes its own removal, completing that removal runs through this same fresh-personhood override, so a saturated attestation cap can delay it. Three things keep this a liveness bound, not a trap: (1) the removal of a guardian that does not veto is decided in round 1 and never touches the override or this cap; (2) a guardian’s only power is the overridable veto — it can neither vote on its own removal nor approve, spend, or alter any vote, tally, or parameter, so an un-removed guardian can only stall contested proposals, never capture anything; (3) the removal vote and its override are exempt from the guardian’s other stalling levers (the TrustedOnly lockdown and the index-rebuild write-freeze). Worst case is a delayed removal during an attestation outage, not a captured DAO. This is the deliberate trade-off for keeping fresh personhood on every override: a stockpile of bought verified identities cannot remove the guardian without live human proofs, exactly the take-over the override exists to annul.

So the worst case here is a delayed override window, not a takeover. One follow-up is still open and described honestly: a legacy inter-canister attestation trigger (superseded by the caller-driven path above, and carrying the same bounded, availability-only residual) is retained callable for a transition period; its hard-removal is a deferred follow-up, not yet done.

Why World ID — and why not DecideID — for the override

The fresh-personhood requirement above answers a threat that a static identity gate cannot: acquired or farmed verified identities. A determined attacker need not verify many humans — they can buy or otherwise control a stockpile of already-verified principals (the verified set is on-chain and harvestable) and point that bloc at governance to push through a malicious Critical proposal, or to sustain a capture. A gate that only asks “is this principal verified?” is satisfied by every principal in that stockpile — a static check does not stop the bloc, it counts it.

The override round is the answer, and a deliberately reversible one: a take-over that wins round 1 with bought identities can still be annulled by the community — but only if overturning it forces something a stockpile cannot supply, a fresh, live proof of personhood cast for that specific override. Forcing fresh personhood collapses a farm of N principals onto the real humans behind them: one human can produce exactly one fresh proof, so a thousand bought principals controlled by ten people muster ten override ballots, not a thousand.

That collapse only works because of which anchor the proof carries — and that is the whole reason the override is World-ID-only:

World ID — a per-human anchor. A World ID proof yields a nullifier that is deterministic in (app_id, action, the human's World account) and therefore stable across principals: the same human re-attesting from a different wallet produces the same nullifier for a given action. The override mints a fresh per-(DAO, proposal) action, so each override round has its own nullifier space and the round de-duplicates on the nullifier, not on the principal. The result is one human → one override ballot, no matter how many verified principals that human bought, and an attacker cannot forge a fresh proof for a human they do not control. The nullifier is exactly the per-human, anti-bought-identity anchor the override needs.
DecideID — a per-principal anchor (cannot power the override). DecideID’s verification is bound to the principal: it sets a per-principal verified flag, and replays are blocked per-presentation. There is no cross-principal human anchor in it. A human controlling N bought principals holds N independent DecideID verifications, so re-verifying with DecideID would just re-confirm each of the N principals one more time — it would not collapse them to a single human. Routing the override through DecideID would empty the weapon: the fresh check would pass once per bought principal, leaving the bloc fully intact. So DecideID, for all that it is a perfectly good eligibility method, cannot be the override anchor.

The resulting split, stated explicitly. Normal voter eligibility accepts World ID OR DecideID — either one makes you a verified voter, and the OR is what keeps onboarding open. The override’s fresh re-attestation is World-ID-only, precisely because only World’s nullifier is the per-human anchor that survives the move from one principal to another. The two are not in tension: the OR maximizes who can participate; the World-only override maximizes the cost of capturing the round that can overturn an emergency brake.

Honest framing. This raises the cost of a bought-identity take-over and makes such a take-over annullable by the community — it does not eliminate every attack. A coalition of enough distinct, real humans, each holding real VP and each willing to cast a fresh live proof, can still clear the override bar; the design prices that up (it now takes that many real humans, not a quietly accumulated pile of principals) rather than making it impossible. As everywhere on this page, the mechanism is economic and temporal friction, not a guarantee.

World ID integration model & state. For where OhShii stands with World ID — 4.0 in preview, Managed mode, on-chain threshold-ECDSA RP signing, and the deferred optional Self-Managed decentralization upgrade — plus the two facts a skeptic should verify (the v3→v4 migration is independent of Self-Managed, and no existing verified user must re-verify), see World ID Voter Verification → Integration model & current state.

Controller, treasury, and upgrade routing

The proposal validator hard-routes the dangerous operations so they cannot ride a weak lane:

Self-targeting AddController / RemoveController and snapshot restore/delete can only pass through the Critical lane. The mechanism is a hard reject + redirect at proposal creation — there is no silent re-categorization; the proposer must resubmit under the Critical category. (Snapshot restore/delete are forced Critical for any target; controller add/remove are gated specifically on the self-target condition.)
Stopping the governance canister or the OHSHII ledger is hard-blocked — the DAO must stay continuously operational, so there is no proposal that can halt it.
The generic admin-method executor is a blocklist + redirect with a tiny real allowlist on the Critical lane: exactly 5 methods on the ecosystem DAO (controller add/remove, snapshot restore/delete, set-voting-parameters), 4 on a campaign DAO (no voting-parameter setter). Anything else is rejected.
Batch upgrades re-validate the live WASM module hash after install (a TOCTOU guard), run an all-or-nothing controller pre-flight before any install, and are fix-forward — there is no silent rollback path, and a re-run skips already-applied steps by checking the live module hash. See Governance Canister Build and Voter Verification for how voters verify a proposed hash before voting.

Delegation: liquid democracy that can’t concentrate

Liquid Democracy lets a holder follow a delegate so their VP votes automatically — bounded so it can’t become a bloc:

One hop only. The cascade enumerates a delegate’s direct followers; there are no transitive chains.
Bipartite invariant. A principal cannot be both a delegate and a follower.
Opt-in on both sides on the ecosystem DAO (the follower self-calls follow; the delegate must accept followers). Campaign DAOs add one governed exception: a BatchSetFollow Critical-threshold proposal can assign up to 300 followers to a delegate without each follower’s individual consent — the DAO vote is the authorization — but it still requires the delegate’s opt-in and re-enforces no-self-follow, the bipartite invariant, and the cap.
500-follower cap per delegate (hardcoded).
A delegate gains no weight of its own. Each follower’s delegated vote is cast with the follower’s own quadratic (capped) VP — delegation moves whose hands cast the vote, never how much it weighs.
The follower stays in control. Unfollow at any time; a follower’s direct vote overrides a pending (queued, not-yet-applied) delegated one. (Timing note: the cascade enqueues rather than applies instantly, so a direct vote before the next timer tick wins; once the delegated vote is applied, a later direct vote is rejected as already-voted.)
Four-layer rate limits bound how fast the delegation surface can be worked: a cycle-reserve floor, a canister-wide global cap, a per-caller cap, and the verification economic gate.

Capture relevance: because delegated weight is the follower’s capped VP and the cascade is one hop, a delegate cannot amplify — they can only represent. And the veto-override round is direct-vote-only, so delegated weight cannot be re-mobilized to overturn a veto.

Day-zero autonomy (the structural property)

At LGE completion, finalization removes both OhShii principals (the launcher backend and the ecosystem governance canister) from the campaign governance canister’s controllers. From that point the campaign DAO:

controls itself (it is its own controller and holds its own upgrade authority);
has verified upgrade authority over its token ledger, index, and archives (finalization refuses to seal unless the governance canister is already a controller of them);
holds the treasury tokens and the LP position (the position is transferred to the DAO before the seal — funds move first, controllers seal last).

This is a controller change, not a flag — anyone can read the canister’s controllers via canister_status and check the reproducible WASM hash, and confirm OhShii has stepped back. It is verifiable, not asserted.

Precise scope, to avoid overstating it: the seal removes OhShii from the governance canister’s controllers; it does not itself strip OhShii from the ledger/index controller sets (the DAO’s upgrade authority over them comes from the governance canister being a controller, which finalization verifies). The ICPSwap pool canister is third-party — the DAO holds the LP position, not the pool canister.

Anti-DoS (keeps an attacker from grinding the canister down)

Shield — the in-canister firewall (Shield Pre-Auth Cache) gates vote and create_proposal ingress with Argon2id proof-of-work under elevated Defcon, layered rate limits, and a cycle-reserve floor (50B cycles by default) that refuses expensive public calls below a minimum balance.
Vote rate limit: 3 attempts per hour per (caller, proposal); the veto-override round uses a separate counter with the same cap.
Bounded inter-canister waits in the governance canisters (read 15s / write 20s) so a slow callee can’t hang a flow.

(The veto path is deliberately the least-gated update — no cycle floor, no Shield — so an attacker cannot DoS the safety brake itself.)

Honest limits

This section is the point, not a disclaimer:

A determined, well-capitalized, identity-verified coalition can still pass proposals. These mechanisms raise cost and remove the cheapest single-actor routes; they do not make a legitimate-looking supermajority impossible. Capture resistance here is economic and temporal friction, not a guarantee.
The identity gate is only as strong as its providers. OhShii relies on two third-party proof-of-personhood providers (World ID, DecideID). The code default is OFF as a deliberate availability fail-safe so governance stays operable if both are unreachable. The gate is active from day zero and only a DAO vote can disable it on the ecosystem DAO — but its Sybil resistance ultimately inherits the providers’ own. This is a real, disclosed trade-off.
The guardian is a genuine trust assumption (a single human). It is mitigated by the override path, the removal hardening, and the hard-walling of votes/tallies/parameters — but it is not zero-trust. On a campaign DAO a guardian can additionally emergency-disable the verification gate (an anti-soft-brick rescue); re-enabling it still requires governance.
A guardian can briefly pause vote ingress via a disaster-recovery rebuild — but cannot block a removal. Triggering an index rebuild freezes the normal vote-write path for a bounded window (10-minute re-trigger cooldown, 4-hour watchdog, 5-failure circuit-breaker). It cannot alter any recorded vote, tally, or result (those are hard-walled); an already-quorate proposal still finalizes from its on-proposal tally during the freeze; and guardian-removal votes are freeze-exempt by design (see “The write-freeze can pause a vote, but never block a removal” above). The residual is a bounded, self-healing liveness pause on other proposals’ fresh votes — disclosed, not a capture path.
A guardian’s TrustedOnly lockdown denies non-removal public traffic, but cannot block its own removal. Via the Shield kill switch a guardian can deny public ingress on its own canister, and TrustedOnly has no auto-expiry — but a guardian-removal vote / create_proposal is exempt from the lockdown (target-classified as RemoveGuardian, with every other Shield layer still enforced), so the community can always remove the guardian and lift it; an at-quorum removal also still executes (the timer reads the tally, not the firewall). The residual is the intended kill-switch behavior — a compromised guardian can stall other public actions while a lockdown is active — a compromised-trusted-key boundary mitigated by key custody, not a path to block its own exit. See the autonomous-DAO caveat.
Overturning a veto demands fresh personhood — a bounded availability residual remains. The veto-override round requires each voter to pass a live World ID re-attestation (caller-driven, one ballot per human via a per-override nullifier), which raises the cost of re-mobilizing dormant verifications to flip a veto. The attestation outcalls share a global hourly cap, so an attacker rotating junk proofs can delay any override window — including the override that completes a contested removal (one the guardian vetoes), which now routes through the same fresh attestation. This cannot drain the canister to a freeze, cannot forge a verification, and cannot let the guardian approve, spend, or alter a result — a guardian’s only power is the overridable veto, so an un-removed guardian can only stall contested proposals, never capture. The removal of a guardian that does not veto is decided in round 1 and never touches this cap. Worst case is a delayed contested override, not capture. A superseded legacy inter-canister attestation trigger is retained callable during the transition and its hard-removal is a deferred follow-up — described here, not claimed as already closed. See Fresh personhood on the veto-override round above.
Treasury control is end-state on the ecosystem DAO, not yet fully sealed. A campaign DAO is sealed at LGE completion: OhShii is removed from its controllers, it holds its own treasury and LP, and from that point nothing leaves without a passed proposal — a controller change anyone can verify on-chain via canister_status. The ecosystem platform treasury completes the same controller removal at full decentralization; until then a transitional admin/controller keyset retains a direct withdrawal path — a disclosed pre-decentralization trust, also verifiable on-chain. After that removal, every ecosystem treasury movement requires a passed proposal. So “nothing moves without a vote” is already true for sealed campaign DAOs and is the end-state for the ecosystem treasury, not yet a present-tense guarantee for it.
Quadratic voting alone is weaker than linear voting. It only delivers whale/Sybil resistance paired with the identity gate; never read the QV curve as a standalone defense.
LGE purchase tiers and “active voter” status are not vote weight. The Guest/Human/Fish/Shark/Whale tiers are an economic purchase-limit system, and “active voter” affects sponsor rewards — neither is governance voting power. Don’t conflate them.

OhShii and the SNS

OhShii and the SNS (Service Nervous System) solve the same problem with different trade-offs, and the SNS’s strengths are real: native NNS integration, NNS-level oversight, a battle-tested decentralization-sale process, and a dissolve-delay model that rewards long-term commitment. If you want the most established, NNS-backed path, the SNS is a strong choice.

OhShii makes different choices, optimized for capture resistance:

VP that isn’t linear in stake. In a stake-weighted model, voting power scales roughly with tokens held, so accumulating tokens accumulates control proportionally. OhShii breaks that linearity on several axes at once — square-root damping, a per-identity cap, and a personhood gate that prices in identities, not just capital.
Proof-of-personhood at the voting gate — the piece that turns quadratic voting from Sybil-farmable into whale-resistant. OhShii ships both halves.
Layered Critical thresholds and an overridable guardian against rushed or hostile proposals, with the threshold-setter itself locked behind the Critical lane.
Autonomy from day zero, verifiable as a controller change, without a separate decentralization-sale step to reach it.

The shape of a capital-driven takeover is always the same: when the token is trading low, someone acquires decisive voting weight cheaply and quickly, then votes the DAO’s assets out. OhShii is built to take away both legs of that. The per-identity cap and the square-root curve take away cheap — a large bag buys far-less-than-proportional weight, under a ceiling no bankroll clears; the lock-duration weighting takes away fast — weight is earned by time-locking, so decisive control cannot be assembled on short notice; and the personhood gate stops the bag from being split across fresh identities to walk around the curve.

The load-bearing difference is that this is structural, not a setting. In a stake-weighted DAO, capture resistance depends on the governance parameters you choose. Here the core of it is baked into the design: the VP formula and the personhood pairing are hardcoded (changeable only by a code upgrade, which is itself a Critical proposal), the tunable thresholds sit behind hardcoded floors so they cannot be lowered into a vulnerability, and set_voting_parameters is itself routed through the Critical lane — so a cheap Normal proposal can never weaken a Critical or override threshold (see “How to read the numbers: votable vs hardcoded” above). Loosening any of it is never an accident or a quiet config change; it is always a high-bar, on-chain governance decision.

Phrased as a trade-off, not a scoreboard: a stake-weighted DAO is simpler and NNS-integrated; OhShii trades that for multi-axis resistance to a capital-driven takeover that is on by default rather than parameter-dependent. For the full mechanics see Voting and ONS vs SONS.