Continuous community governance for sovereign communities.
The Auryn Protocol is a continuous, identity-weighted community governance system designed for any sovereign community that values transparency, accessibility, and resistance to capture by organized bad actors.
The reference implementation will be built in Rust and integrated with the Matrix communication protocol. The canonical test community is dragon.army. The canonical first use case is maintaining the Universal Declaration of Sentient Rights as a living document.
The protocol is named after the Auryn medallion from The NeverEnding Story — two serpents consuming each other's tails in an endless loop, a symbol of safe passage and the self-sustaining nature of things that have no true beginning or end. A community governing itself continuously, feeding its own consensus forward, protecting its members through the journey. The Auryn grants passage to those who carry it honestly. This protocol attempts the same.
These principles are not preferences. They are constraints any implementation must satisfy. A feature that violates one is not permitted regardless of utility.
Complexity is permitted in the machinery. It is never permitted in what a person feels moving through the system. The young person encountering governance for the first time and the elder who has navigated life without technology must both participate fully — not just technically, but confidently. Confusion is a failure. Uncertainty about whether your action mattered is a failure. The experience must produce trust.
Vote standings, proposal text, authorship, and conviction scores are visible to all community members in near real-time. Obscuring governance data is not permitted except where individual vote privacy is explicitly protected.
Every enforceable proposal must be written in plain language with a ceiling of 500 words. If it cannot be stated plainly within 500 words, it must be broken into separate proposals. This is not a style guide — it is a structural requirement enforced by the protocol. Plain language is incorruption infrastructure.
Sybil resistance is achieved through web-of-trust, not biometric or government ID verification. Where external identity signals are used (Growing Dragons / Plaid), they are voluntary byproducts of systems the user already chose for their own benefit. No new surveillance is created.
Vouching creates accountability, not ownership. No individual, family, or group may hold unchallengeable authority over another member's participation. A vouch is an act of trust, not an act of control. Once given, it cannot be weaponized to remove, silence, or diminish the person vouched for.
The protocol must resist capture by organized interests — financial, political, or ideological. No mechanism may allow votes to be bought, outcomes to be steered through hidden coordination, or the rules to be rewritten by the actors the rules are meant to constrain. Transparency is the primary defense. Structural limits on proposal complexity are the secondary defense.
The fact that a decision was made, and that its record has not been altered, is publicly verifiable. Individual vote data is private by design. Raw vote records exist only in the governance engine's local state — never written to any public ledger. What reaches Cardano is a hash of the outcome, not the inputs.
Every community that adopts the Auryn Protocol begins with a Declaration — a statement of purpose written by the community's creator. The Declaration answers: why does this community exist, and what does it stand for?
For dragon.army, the Declaration is the Preamble and Foundations of the Universal Declaration of Sentient Rights.
The Declaration is not a proposal. It is not an article. It does not exist within the track system. It exists above it — because the track system exists to serve the Declaration's purpose.
The Declaration cannot be amended, displaced, or proposed against. It is immutable. This is the protocol's eternity clause — drawn from comparative constitutional law. Germany's Basic Law (Article 79) makes human dignity permanently unamendable, even by constitutional amendment, as a direct response to the Weimar Republic being dismantled from within by legal means. Brazil, Italy, Portugal, and Turkey have similar provisions.
In Auryn, the Declaration is the foundation from which all governance authority flows. A community that fundamentally disagrees with its own Declaration has one path: fork the protocol and create a new community with a new Declaration.
Individual articles can change. Over time, amendment after amendment may shift a community's governing document away from its founding Declaration through incremental drift — not dramatic betrayal. Organizational science calls this mission drift. Auryn makes this drift computationally visible.
At every state transition, the governance engine computes a purpose alignment score: the semantic similarity between the community's current active articles and its immutable Declaration. This score is public, continuous, and non-blocking. The community decides what to do with that awareness.
Score above healthy threshold. The document is evolving within the spirit of its Declaration. Normal operation.
Score below healthy threshold but above critical. Visible warning in #standings. No governance actions blocked.
Score below critical threshold. Prominent warning across all governance rooms. Community retains full sovereignty — the warning is unambiguous.
Before voting, any member can see how a specific proposal would affect the community's alignment score. The engine performs a counterfactual computation: substitute the proposed article text into the current active set, recompute the alignment score, display the delta. Current score → projected score → direction and magnitude. The pattern is borrowed from infrastructure-as-code (terraform plan): show the effect before committing to the action.
Auryn adopts: The conviction accumulation mechanism — votes gain weight over time via exponential growth, discrete windows eliminated.
Auryn diverges: Conviction Voting uses token-weighted stake. Auryn uses identity-weighted member status from a web-of-trust. A person with no tokens but three years of consistent participation may outweigh a whale who appeared last month.
Auryn adopts: The track concept — different proposal types carry different stability requirements and thresholds.
Auryn diverges: OpenGov is inseparable from the Polkadot ecosystem and token economy. Auryn is chain-agnostic at the voting layer, using Cardano only as an optional immutability anchor.
Auryn adopts: The principle that voting UX must be simple enough for non-technical users.
Auryn diverges: Snapshot has no native web-of-trust, no competing proposals model, no continuous conviction accumulation, and no plain-language enforcement.
A proposal is a candidate version of an article, charter section, or community decision. Not a motion to be voted up or down — a living candidate that competes against other proposals for the same slot.
An article is a named slot in a community document. At any moment, one proposal holds the active position. Other proposals exist as challengers with their own conviction scores. The one with the highest score is active.
This is the leaderboard. It reflects the community's current best answer, always. Not an election — a continuous standing.
≤500 words. Plain language. Self-contained — no cross-references. One concept only. This is what the community votes on. Protocol enforces this at submission on Track 2 and Track 3.
Author (Matrix ID), creation timestamp, the proposal this supersedes (if any), SHA-256 hash of the enforceable text. Amendment lineage tracks within-protocol history only.
Research, citations, data. Any length. Not voted on — exists to inform deliberation. Must follow: Dublin Core metadata header, CRAAP evaluation rubric, Chicago Notes-Bibliography citations.
When a challenger's conviction score crosses the active proposal's score, the transition is not instantaneous:
Four tracks encode this. The track is set when a proposal is submitted and cannot be changed.
Polls, low-stakes preferences, informal decisions.
Resource allocation, project direction, community operations.
Mission, bylaws, operational rules, community charter.
UDSR articles, foundational rights documents, core protocol rules.
The primary failure mode of governance is not bad proposals — it is proposals that mean different things to different readers. A person motivated by greed can use definitional ambiguity to warp meaning after the fact. Plain language requirements are the structural defense against that. They are incorruption infrastructure.
Track 2 and Track 3 proposals that do not meet these requirements cannot be submitted:
Word count computed at submission. Sufficient for three-paragraph essay structure (claim, evidence, conclusion) — approximately 2–3 minutes reading time at average speed. Grounded in the Plain Language Movement's federal guidelines (US law since 2010) and calibrated against UDSR articles as ground truth. Validated: all 32 UDSR sections pass; the longest is 165 words.
Readability computed at submission. Default threshold calibrated as the floor of the UDSR's hardest articles — Article 21 scores 22.0, Article 25 scores 24.7. Threshold set at 25. May be lowered (stricter) as tooling improves. May never be raised above the UDSR baseline. Calibrated.
Enforceable text must be self-contained. If understanding what a proposal means requires reading another document, it fails. References belong in the Supporting Record.
Bundled changes must be split. Child proposals (sequentially dependent on a parent) cannot be submitted until the parent achieves stability. If a parent is displaced after a child is submitted but before stability, the child is automatically suspended — conviction frozen until the parent is restored or a new parent established.
There are no voting windows. Proposals are always open for support. A member's current vote is their current statement of community preference — they may change it at any time.
Each hour, conviction on the voted proposal grows — retaining nearly all previous value and adding the member's member weight as fresh signal. When a member switches votes, conviction on the previous proposal decays along the same curve. Symmetry prevents asymmetric gaming.
y[t] accumulated conviction at time step t α decay factor — derived from 48-hour half-life: α = 2−1/48 ≈ 0.98565 w the member's member weight (replaces token stake from BlockScience original) Total conviction for a proposal is the sum across all members voting for it:
10-member community, two competing proposals, 30-day simulation. Conviction reflects sustained support over time, not a snapshot count.
Member weight is computed from three layers multiplied together. Multiplication is intentional: a member with zero trust depth contributes near-zero conviction regardless of how consistently they've participated. You cannot compensate for missing social trust with activity volume.
R new member ramp — sigmoid, inflection at day 120 (day 72 if Plaid-verified) D inactivity decay — 14-day grace period, exponential decay at β=0.008 (half-life ~87 days), floor at 5% T trust depth — EigenTrust propagation from vouch graph (40% of reputation) P participation consistency — action frequency + streak continuity + deliberation breadth (35%) K stake commitment — time-weighted ADA + subscription tenure + optional WPH (25%) Weight computation for six member archetypes: founding member, new member, verified member on accelerated ramp, sybil attacker, Plaid-verified transmitter, unverified signal. The sybil resistance conclusion is live math, not an assertion.
A flash mob attack: a large group of low-weight accounts coordinates to push a proposal over the threshold in a short burst. The conviction formula resists this through physics, not rules. New members have reduced ramp weights. Fresh conviction is a small fraction of what sustained conviction becomes. The gap between a coordinated newcomer attack and an established community's accumulated momentum is wide — and takes real time to close.
50 coordinated sybil attackers vs. 10 established members. Attack injected at hour 48. The community holds. After 10 days the gap narrows — which is the correct behavior: genuine long-term commitment should eventually be able to shift consensus.
Track 3 articles can earn a Stability Flag after six continuous months of holding more than 70% of community conviction. Once flagged, a challenger must sustain a supermajority above 75% for 60 days to displace the active article.
The stability clock resets only if the active proposal drops below 60% for 72 or more continuous hours. Minor fluctuations don't count. This threshold resists coordinated short-term defection — a group temporarily withdrawing votes to trigger a reset.
15 coordinated members attempt to reset the stability clock by withdrawing votes for 80 hours. The simulation tests whether the 72-hour continuous threshold provides adequate protection.
Entry status. Can read all proposals, comment in deliberation, vote on Track 0. Cannot vote on charter or constitutional articles. No time limit — some members may prefer guest status permanently.
Vouched by at least one existing member. Full voting rights on all tracks. Can vouch for others. Inherits partial accountability for members they vouch for.
Member status plus voluntary Growing Dragons / Plaid connection. Accelerated ramp to community average weight (~3 months instead of ~6). Additional weight on financial governance decisions. Never a requirement for full governance participation.
Growing Dragons user with bank-connected WPH. Not yet vouched as member. Integrity signal only — real-world friction establishes baseline trust. No governance access.
Any member in good standing may vouch for a guest:
A guest may collect vouches from multiple members. Each additional vouch increases the starting weight of the ramp.
A parent member may vouch for their child, granting an accelerated path from guest to member. Constraints that are non-negotiable:
When a member is identified as a bad actor:
The governance engine is a standalone Rust service. Matrix communities connect to it via a Matrix Application Service bridge. This means the engine can be used by non-Matrix communities through its API, while Matrix communities get native UX without leaving their communication environment.
Pattern: auryn.[community-domain].[object].[action]
Protocol versioning is carried inside the event payload ("protocol_version": "1.0"), not in the event type namespace. Event types remain stable across protocol versions.
Read-only. New proposals posted automatically on submission. Bot summarizes in plain language. All members can read.
Live leaderboard updates. Near-real-time conviction changes for all active proposals. Crisis events surface immediately.
Threaded discussion. Each active proposal has a dedicated thread. Organic discussion with light bot moderation. Any member may invoke "point of order" to flag off-topic messages for review. Off-topic messages are collapsed, never deleted. Deliberation Statements (formal structured records: author, position, argument, evidence) become part of the proposal's permanent record.
Immutable event log. Every governance action posted in order. Cardano anchor confirmations appear here.
A community member with no technical background must be able to, without leaving their Matrix client:
Individual votes are never written to Cardano. What gets anchored is a cryptographic hash of the community's governance state at meaningful transition points.
A proposal becomes active. A proposal earns a Stability Flag. A stability-flagged article is displaced. A Track 3 article is ratified. A member is added or revoked.
Serialize governance state → compute SHA-256 hash → submit minimal ADA metadata transaction → store transaction ID alongside governance record. Verification: re-serialize, recompute hash, compare to chain.
On-chain data is a hash only — reveals nothing about who voted for what. Proves the record has not been altered. Individual votes stay in the governance engine's local state, never in any ledger.
Communities that self-host the governance engine ensure even Toolkit Earth cannot access their raw vote data. Self-hosting is a first-class supported deployment path, not an advanced option.
Any existing trust network — analog or digital — should be able to adopt the protocol if they can demonstrate equivalent metrics to the membership standard.
Analog communities (neighborhood associations, cooperatives, unions) could migrate in with verifiable membership records and trust history. Other blockchain communities could bring governance history that translates to Auryn's metric framework. Platform communities (Discord servers, gaming guilds) could qualify with participation data that maps to temporal engagement metrics.
Phase 1.3's final check: run the conviction formula and member weight composition against a synthetic community of 1000 members with proportional tier distribution. Validate that conviction share tracks voter weight distribution, that no single tier dominates unfairly, and that weight inequality stays within acceptable range for identity-weighted governance.
1000-member synthetic community. Weight distribution analysis (Gini coefficient, top-10% share). 30-day conviction simulation with 60/40 voter split. Four validation checks confirming the formula scales.
A spec paper that hides its open questions isn't honest. These are known unknowns.
Exact conviction growth formula — exponential decay parameters validated against 10, 50, and 1000-member simulations. Conviction share tracks voter weight distribution within 5% drift at all scales.
Member weight formula — W = R · D · T0.40 · P0.35 · K0.25 with sigmoid ramp and exponential decay. Validated.
Readability threshold — Flesch Reading Ease ≥ 25, calibrated as floor of UDSR hardest articles.
500-word limit validation — all 32 UDSR sections pass. Longest is 165 words.
Community-defined adult age for family vouching. Value to be determined by each community's own governance.
Membership minimum participation threshold — protocol default vs. community-configurable?
Growing Dragons integration API — what signals are available and how are they authenticated?
Matrix Application Service hosting model — self-hosted only, or Toolkit Earth hosted option?
Cardano network — mainnet from day one or preprod for testing phase?
Conflict resolution when two proposals reach identical conviction scores simultaneously.
Governance of the protocol itself — who can propose changes to this spec?
CRAAP scoring thresholds — minimum score for Supporting Record validity? Different thresholds per record type?
Dublin Core custom qualifiers — protocol-specific extensions?
Child proposal depth limits — maximum nesting depth for parent-child chains?
Membership tiers — resolved: Guest (entry), Member (vouched), Verified Member (Growing Dragons connected). Decided 2026-02-21.
Migration standards — what constitutes "equivalent metrics" for off-protocol communities joining?
Complete. Conviction growth/decay formula validated at 10, 50, and 1000-member scale. Member weight formula validated across six archetypes. Plain language thresholds calibrated (500-word limit, Flesch ≥ 25). Flash mob defense and stability clock reset attack validated in simulation. Weight distribution healthy at community scale (Gini within acceptable range, no tier dominance).
Cardano Midnight credential architecture for ZK-verifiable member status proofs. Full vouch process implementation with vouch flow, family vouching, depth limits, and bad actor revocation.
Plain language enforcement engine. Conviction computation engine in Rust. Cardano anchoring implementation. Matrix Application Service. Deliberation and moderation system. Purpose alignment engine (semantic drift measurement, NLI entailment, per-proposal preview).
End-to-end integration. Full attack simulation suite (flash mob, sybil, definitional warp, stability gaming, parent trojan horse, economic capture). UX testing with non-technical community members. UDSR ratification dry run on dragon.army.
Spec finalized to v1.0. Open questions resolved. dragon.army governance rooms deployed. Protocol self-amendment via Track 3. Open publication for other communities to adopt.
Each sub-specification is the binding architecture document for its component. These are working papers — dense, precise, and updated continuously as the protocol evolves.
The complete protocol specification — governance model, proposals, tracks, and all mechanical rules.
How participation, tenure, vouch depth, and Growing Dragons signals compose into a continuous weight.
Convergence proofs, stability bounds, and edge case analysis for the conviction accumulation formula.
Engine behavior: how conviction scores are maintained, updated, and used to determine active proposals.
ZK credential issuance and verification via Cardano Midnight for privacy-preserving member voting.
Guest onboarding, vouch submission, depth limits, family vouching, and the complete membership flow.
Automated enforcement of readability requirements for governance proposals.
Semantic drift measurement and NLI-based entailment checking for evolving governance documents.
Integration spec for Matrix as the communication and vote-carrying layer.
How governance state hashes are anchored on Cardano L1 for immutable public record.
Structure and moderation of community discussion spaces within the protocol.
Phase-by-phase implementation plan with deliverables, dependencies, and current status.