CoopEverything
HomeDashboardFeedGroupsWikiForumProposalsEconomyBridge

About

  • Manifesto
  • Cooperation Paths

Learn

  • Wiki
  • Articles
  • Glossary
  • Modules
  • Contributing

Community

  • GitHub
  • Forum
  • Groups

Tools

  • Bridge Assistant
  • Design System
  • Search

ยฉ 2025 CoopEverything. Powered by TogetherOS.

Privacy|Terms
  1. Wiki
  2. /
  3. Threat Model: What Could Go Wrong
๐Ÿ“–
Wiki Article

Threat Model: What Could Go Wrong

TogetherOS is designed to resist specific threats: plutocracy, populist capture, coordinator corruption, sybil attacks, and burnout. Understanding threats helps us build defenses.

โ—Evolvingยท Active refinement, open to input
5 min read1 contributorLast edited November 30, 2025

Threat Model: What Could Go Wrong

Why Think About Threats?

Every system has vulnerabilities. Pretending otherwise leads to failure. TogetherOS explicitly names threats so we can build defenses.

Threat 1: Plutocracy (Money Buys Power)

Attack: Wealthy members try to buy influence over decisions.

Defense: Support Points cannot be purchased. Ever. The firewall between money and governance power is absolute.

Remaining risk: Wealthy members could donate time to earn SP. This is acceptable โ€” time investment shows genuine commitment.

Threat 2: Populist Capture

Attack: Charismatic individual manipulates community into following them.

Defense:

  • No permanent leadership positions
  • All roles recallable
  • Minority reports preserve dissent
  • Mental flexibility as cultural value

Remaining risk: Charisma is hard to defend against. Culture of questioning helps.

Threat 3: Coordinator Corruption

Attack: External entity bribes or threatens coordinators.

Defense:

  • Coordinators have no independent power
  • Can be recalled at any time
  • Corrupting a coordinator gains nothing
  • Another coordinator takes their place

Remaining risk: Minimal. The design makes corruption unprofitable.

Threat 4: Sybil Attack (Fake Accounts)

Attack: Someone creates many fake accounts to gain voting power.

Defense:

  • Onboarding process requires real engagement
  • SP earned through contribution (can't fake contribution at scale)
  • Verification options for high-stakes decisions
  • Community moderation catches suspicious activity

Remaining risk: Small-scale sybil attacks possible but not profitable.

Threat 5: Burnout

Attack: Active members exhaust themselves, system collapses.

Defense:

  • Task distribution algorithms prevent overload
  • Recognition systems acknowledge contribution
  • Role rotation prevents entrenchment
  • Culture of sustainable pace

Remaining risk: Burnout is always possible. Systems help but can't fully prevent.

Threat 6: External Pressure

Attack: Powerful external entities (governments, corporations) pressure the community.

Defense:

  • No single point of failure (distributed leadership)
  • Transparent decision-making hard to secretly influence
  • Legal structure designed for resilience
  • Multiple instances can exist independently

Remaining risk: Determined attackers with resources are hard to stop. But distributed systems are harder to kill.

Threat 7: Apathy

Attack: Members stop participating. Decisions made by tiny minority.

Defense:

  • Gamification rewards participation
  • Regular communication about impact
  • Low-barrier participation options
  • Notification of important decisions

Remaining risk: Apathy is always possible. Can't force engagement.

Living Document

This threat model will evolve. As we learn about new vulnerabilities, we'll add defenses. Security is a process, not a destination.

Tags

securitythreatssafeguardsgovernance

Cooperation Paths

Collective GovernanceCooperative Technology

Key Terms in This Article

๐Ÿ“–
Coordinator
Implements collective decisions. Doesn't hold power โ€” executes the will of the community.
3 min read
๐Ÿ“–
Recall
The ability for the community to remove any coordinator at any time through voting.
3 min read
๐Ÿ“–
Anti-Plutocracy
Design principle ensuring money can never buy governance power. SP can only be earned.
5 min read

Related Articles

๐Ÿ“–
Coordinator
In TogetherOS, a coordinator is a role that implements collective decisions. Unlike traditional leaders, coordinators execute the will of the community.
๐Ÿ“–
Recall Mechanism
Any coordinator can be recalled (removed) by the community at any time. This ensures accountability and prevents entrenchment.
๐Ÿ“–
Support Points (SP)
Your way to say "this matters!" SP earns attention and priority for proposals โ€” not decision power, but voice in what gets focus. Cannot be bought or traded.
Discuss This ArticleBack to Wiki

This is community knowledge. If you have suggestions, corrections, or want to contribute, start a discussion in the forum. Wiki articles evolve through collective deliberation.