Radix Network DAO Charter

# Radix Network DAO Charter
 
> **Version:** 0.1.0 (Draft)
> **License:** [CC-BY-SA-4.0](LICENSE.md)
> **Adapted from:** [Aragon Network DAO Charter](https://github.com/aragon/network-dao-charter) (CC-BY-SA-4.0)
 
---
 
## Table of Contents
 
1. [Introduction](#1-introduction)
2. [Charter](#2-charter)
3. [Roles & Bindings](#3-roles--bindings)
4. [Governance Proposal Process](#4-governance-proposal-process)
5. [Voting Mechanism](#5-voting-mechanism)
6. [Treasury Management](#6-treasury-management)
7. [Checks & Balances](#7-checks--balances)
8. [Reputation System](#8-reputation-system)
9. [Temporary Provisions](#9-temporary-provisions)
10. [Update Pipeline](#10-update-pipeline)
11. [Community Guidelines](#11-community-guidelines)
12. [Lexicon](#12-lexicon)
13. [DAO Parameters](#13-dao-parameters)
 
---
 
## 1. Introduction
 
### To the Radix Community
 
This Charter establishes the governance framework for the Radix Network DAO — a community-governed organization responsible for stewarding the Radix ecosystem and managing assets transferred from the Radix Foundation.
 
By participating in DAO governance — whether voting, submitting proposals, or holding a role — you agree to be bound by the terms of this Charter and its associated documents.
 
### Purpose
 
The Radix Network DAO exists to:
 
- Provide decentralized governance for the Radix ecosystem
- Receive and responsibly manage assets from the Radix Foundation
- Fund development, growth, and community initiatives
- Ensure the long-term health and decentralization of the Radix network
 
### Document Hierarchy
 
The governance documents in this charter form a binding hierarchy. In case of conflict, higher-ranked documents prevail:
 
1. **Introduction** — foundational principles and hierarchy
2. **Charter** — mission, values, and vision
3. **Governance Proposal Process** — how decisions are made and executed
4. **Roles & Bindings** — who has authority and what powers they hold
5. **Voting Mechanism** — how the community expresses its will
6. **Community Guidelines** — standards of conduct
7. **DAO Parameters** — concrete on-chain configuration
 
Supporting sections (Treasury Management, Checks & Balances, Reputation System, Temporary Provisions, Update Pipeline, and Lexicon) carry the authority of the section they serve.
 
### Binding Nature
 
This Charter constitutes a social contract among DAO participants. It is enforced through:
 
- **On-chain mechanisms** — the Governance Registry Scrypto component enforces badge-gated operations and references the current version of each document.
- **Community accountability** — participants who violate the Charter may be subject to enforcement actions as described in [Community Guidelines](#11-community-guidelines).
- **Transparency** — all governance documents are public, version-controlled, and auditable.
 
### Dispute Resolution
 
Governance disputes should be resolved through the following escalation path:
 
1. **Community discussion** — raise the issue on a community communication channel for open debate.
2. **Formal proposal** — if discussion does not resolve the dispute, submit a governance proposal per the [Governance Proposal Process](#4-governance-proposal-process).
3. **Community vote** — the community votes on the proposal via the consultation dApp.
4. **Community arbitration** — for disputes that cannot be resolved by vote, the DAO may appoint an ad-hoc arbitration panel of trusted community members. `[TBD: formal arbitration mechanism]`
 
### Liability
 
Participation in the Radix Network DAO is voluntary. No participant — including RAC members — assumes personal liability for DAO operations beyond what is explicitly defined in their role agreements. The DAO operates as a decentralized, community-governed entity, not a legal corporation.
 
Participants acknowledge the inherent risks of decentralized governance and blockchain-based systems, including but not limited to smart contract vulnerabilities, network failures, and regulatory uncertainty.
 
---
 
## 2. Charter
 
### Mission
 
The Radix Network DAO exists to advance the Radix ecosystem through decentralized, community-driven governance. We steward shared resources, fund public goods, and ensure the network evolves in service of its participants — not any single entity.
 
### Values
 
#### Sovereignty
 
Every individual has the right to participate in the systems that govern them. The DAO empowers XRD holders to shape the future of the Radix network directly, without intermediaries or gatekeepers.
 
#### Transparency
 
All governance decisions, treasury movements, and rule changes are public, auditable, and version-controlled. No decision of consequence should be made behind closed doors.
 
#### Decentralization
 
Power must not concentrate. The DAO's governance structure is designed to distribute authority across the community, with safeguards against capture by any individual, faction, or entity — including the Radix Foundation during the transition period.
 
#### Stewardship
 
The DAO manages community assets as a fiduciary, not an owner. Every XRD spent from the treasury should advance the ecosystem's long-term health, not short-term interests.
 
#### Accessibility
 
Governance should be understandable and approachable. Complex processes exclude participants. The DAO favors simple, clear rules over elaborate frameworks, and invests in tooling that lowers barriers to participation.
 
#### Resilience
 
The DAO must be robust against failure — whether technical, social, or adversarial. Governance documents, on-chain components, and operating procedures should anticipate and mitigate failure modes rather than assuming good conditions.
 
#### Evolution
 
No governance framework is perfect at inception. The DAO explicitly plans for its own evolution, with clear processes for amending every document in this charter. Rigidity is a vulnerability.
 
### Vision
 
The Radix network pioneered asset-oriented programming and developer-friendly DeFi infrastructure. The DAO carries this forward by:
 
- **Funding ecosystem development** — grants, bounties, and partnerships that expand what can be built on Radix
- **Maintaining public infrastructure** — tooling, documentation, and services that benefit all builders
- **Growing the community** — education, outreach, and onboarding that bring new participants into the ecosystem
- **Governing responsibly** — making decisions through legitimate, transparent processes that reflect the community's collective will
 
The DAO is not the Radix network. It is one institution among many that serves the network. Its authority derives entirely from the community's ongoing consent.
 
---
 
## 3. Roles & Bindings
 
### Overview
 
The Radix Network DAO defines a minimal set of roles, each with explicit powers and constraints. Authority flows from the community to elected representatives through transparent processes.
 
### Roles
 
#### Community Member
 
Any person who participates in DAO governance activities.
 
**Rights:**
- Discuss proposals on DAO communication channels
- Submit governance proposals (subject to stake requirement)
- Participate in community votes via the consultation dApp
- Contribute to governance documents via GitHub pull requests
- View all treasury transactions and governance records
 
**Responsibilities:**
- Act in good faith per the [Community Guidelines](#11-community-guidelines)
- Respect the governance process even when outcomes are unfavorable
 
#### XRD Holder (Voter)
 
Any Community Member who holds XRD and uses it to vote in governance decisions.
 
**Rights:**
- All Community Member rights
- Vote on proposals via the consultation dApp (1 XRD = 1 vote)
- Nominate candidates for RAC elections
- Stake XRD to submit proposals
 
**Note:** XRD used for voting is not locked or consumed. The consultation dApp takes a snapshot of holdings at a defined block height to determine voting power.
 
#### Radix Advisory Council (RAC) Member
 
Elected representatives who execute the community's governance decisions.
 
**Rights:**
- All XRD Holder rights
- Hold a RAC Badge (Radix native resource) granting on-chain execution authority
- Update the On-Chain Governance Registry after approved votes
- Execute treasury transactions approved by community vote
- Merge approved pull requests to governance documents
 
**Responsibilities:**
- Execute community decisions faithfully and promptly
- Attend regular RAC meetings (schedule defined in [DAO Parameters](#13-dao-parameters))
- Report publicly on all actions taken with RAC authority
- Recuse from votes where a personal conflict of interest exists
- Safeguard the RAC Badge and report any compromise immediately
 
**Constraints:**
- RAC members may NOT act unilaterally — all actions require prior community approval via vote, except emergency actions defined in [Checks & Balances](#7-checks--balances)
- RAC members may NOT modify governance documents without a passing vote
- RAC members may NOT transfer or delegate their RAC Badge
 
### RAC Badge
 
The RAC Badge is a non-transferable Radix native resource that grants its holder the ability to call privileged methods on the On-Chain Governance Registry component. Specifically:
 
- `update_document_reference()` — point a governance document category to a new GitHub commit hash
- `execute_treasury_action()` — move funds per an approved proposal
- `update_parameters()` — modify on-chain DAO parameters per an approved proposal
 
The badge is minted to a member's account upon election and recalled upon term expiration or removal.
 
**Address:** `[TBD — resource address to be set at deployment]`
 
### Elections
 
#### Eligibility
 
Any Community Member may run for the RAC, provided they:
 
1. Have been active in governance discussions for at least `[TBD]` days prior to nomination
2. Submit a public candidate statement outlining their qualifications and platform
3. Disclose any conflicts of interest (e.g., employment by Radix Foundation, significant holdings in competing protocols)
 
#### Process
 
1. **Nomination period** — `[TBD]` days on a community communication channel, during which candidates self-nominate
2. **Community discussion** — `[TBD]` days for the community to ask candidates questions
3. **Election vote** — conducted via the consultation dApp, lasting `[TBD]` days
4. **Seating** — top candidates by vote count are seated, RAC Badges minted to their accounts
 
#### Term Limits
 
- **Term length:** `[TBD]` year(s)
- **Maximum consecutive terms:** `[TBD]` (after which a member must sit out at least one term before re-election)
- **Staggered terms:** to ensure continuity, not all seats expire simultaneously
 
#### Removal
 
A RAC member may be removed before their term expires if:
 
1. A removal proposal passes community vote with a supermajority of `[TBD]`% support and `[TBD]` XRD quorum
2. The member is found to have violated the Charter or Community Guidelines
3. The member becomes unresponsive for `[TBD]` consecutive days
 
Upon removal, the RAC Badge is recalled and the seat may be filled by special election or by the next runner-up from the most recent election, as the community decides.
 
### RAC Composition
 
| Period | Composition |
|--------|------------|
| Year 1 (transition) | `[TBD]` Foundation-appointed + `[TBD]` community-elected |
| Year 2 | `[TBD]` Foundation-appointed + `[TBD]` community-elected |
| Year 3+ | All community-elected |
 
See [Temporary Provisions](#9-temporary-provisions) for the full transition schedule.
 
### Compensation
 
RAC members receive `[TBD]` XRD per month for their service, paid from the DAO treasury. Compensation may be adjusted by governance vote.
 
---
 
## 4. Governance Proposal Process
 
### Overview
 
All consequential DAO decisions flow through a single proposal process: community discussion, formal proposal, vote, and execution. This process applies to spending, elections, governance amendments, and technical changes alike.
 
### Proposal Types
 
#### Financial Proposal
 
Requests to spend, allocate, or move treasury funds.
 
- **Examples:** grants, bounties, service contracts, infrastructure costs
- **Required fields:** amount, recipient, justification, milestones (if applicable), timeline
- **Approval threshold:** >50% support, `[TBD]` XRD quorum
 
#### Governance Amendment
 
Changes to any section of this charter.
 
- **Examples:** new provisions, role modifications, process changes, parameter updates
- **Required fields:** specific section(s) affected, pull request link, rationale
- **Approval threshold:** >66% support (supermajority), `[TBD]` XRD quorum
 
#### Technical Proposal
 
Changes to DAO infrastructure — the On-Chain Governance Registry component, consultation dApp, or associated tooling.
 
- **Examples:** component upgrades, new features, security patches
- **Required fields:** technical specification, security review (if applicable), rollback plan
- **Approval threshold:** >50% support, `[TBD]` XRD quorum
- **Additional requirement:** independent code review by at least `[TBD]` qualified community members
 
#### Election Proposal
 
Proposals to elect or remove RAC members.
 
- **Process:** see [Elections](#elections)
- **Approval threshold:** see [Roles & Bindings](#3-roles--bindings) for specifics
 
### Proposal Lifecycle
 
#### 1. Forum Discussion
 
**Duration:** minimum `[TBD]` days
 
- Author posts a discussion thread on a community communication channel with the proposal's intent and rationale
- Community provides feedback, raises concerns, suggests modifications
- Author iterates on the proposal based on feedback
- No formal structure required at this stage — the goal is to build consensus before committing to a vote
 
#### 2. Formal Proposal Submission
 
Once forum discussion reaches sufficient maturity, the author submits a formal proposal:
 
- **For governance amendments:** a GitHub pull request against this repository
- **For financial/technical/election proposals:** a structured post on a community communication channel using the proposal template
 
**Required for all proposals:**
 
| Field | Description |
|-------|-------------|
| Title | Clear, concise description |
| Type | Financial / Governance Amendment / Technical / Election |
| Author | Username and (optionally) Radix address |
| Summary | 2-3 sentence overview |
| Motivation | Why this change is needed |
| Specification | Detailed description of the proposed change |
| Impact | Who and what is affected |
| Forum Link | Link to the discussion thread |
 
**Stake requirement:** the author must stake `[TBD]` XRD to submit a formal proposal. The stake is returned after the vote concludes, regardless of outcome, unless the proposal is found to violate the Charter (in which case the stake is forfeited to the treasury).
 
#### 3. Review Period
 
**Duration:** `[TBD]` days after formal submission
 
- RAC members verify the proposal is well-formed and does not violate the Charter
- RAC does NOT evaluate the proposal's merit — only its procedural validity
- If the proposal is procedurally invalid, the RAC returns it to the author with a written explanation. The author may revise and resubmit.
- If valid, the RAC schedules the proposal for voting
 
#### 4. Voting Period
 
**Duration:** minimum `[TBD]` days
 
- Voting opens on the consultation dApp
- Eligible voters: all XRD holders as of the snapshot block height
- Voting power: 1 XRD = 1 vote
- Options: For / Against / Abstain (abstentions count toward quorum but not approval)
- See [Voting Mechanism](#5-voting-mechanism) for technical details
 
#### 5. Execution
 
If the proposal passes (meets both quorum and approval threshold):
 
- **Execution delay:** `[TBD]` days after the vote closes (allows time for community review of the result)
- **Execution:** RAC members carry out the approved action:
  - Financial: execute treasury transaction
  - Governance Amendment: merge the pull request, update the on-chain registry
  - Technical: deploy the approved changes
  - Election: mint/recall RAC Badges as appropriate
- **Transparency:** RAC publishes an execution report linking the vote result to the on-chain action taken
 
If the proposal fails:
 
- The author's stake is returned
- The proposal may be revised and resubmitted after a cooldown period of `[TBD]` days
 
### Emergency Proposals
 
For situations requiring urgent action (e.g., security vulnerabilities, compromised signers), see [Checks & Balances](#7-checks--balances). Emergency proposals follow an accelerated timeline but require higher approval thresholds.
 
---
 
## 5. Voting Mechanism
 
### Consultation dApp
 
The DAO's primary voting instrument is the **consultation dApp** — a Radix-native application that enables XRD-weighted voting on governance proposals.
 
**Component address:** `[TBD — to be set at deployment]`
 
#### Core Principles
 
- **One XRD, one vote** — voting power is proportional to XRD holdings
- **Non-custodial** — XRD is never locked, staked, or transferred to vote. The dApp reads a snapshot of on-ledger balances.
- **Transparent** — all votes are recorded on-ledger and publicly auditable
- **Permissionless** — any XRD holder can vote; no registration required
 
#### Snapshot Mechanism
 
For each vote, a **snapshot block height** is announced at the start of the voting period. XRD balances at that block height determine voting power.
 
- The snapshot is taken `[TBD]` hours before the voting period opens, to prevent last-minute balance manipulation
- XRD held in validator stakes counts toward voting power
- XRD held in liquidity pools or DeFi positions: `[TBD — community to decide whether to include]`
- XRD held by the DAO treasury does NOT count (the DAO cannot vote for itself)
 
### Thresholds
 
| Proposal Type | Approval Threshold | Quorum (minimum XRD voting) |
|---------------|-------------------|----------------------------|
| Financial | >50% For | `[TBD]` XRD |
| Governance Amendment | >66% For (supermajority) | `[TBD]` XRD |
| Technical | >50% For | `[TBD]` XRD |
| Election | Plurality (top N candidates) | `[TBD]` XRD |
| RAC Removal | >66% For (supermajority) | `[TBD]` XRD |
| Emergency | >75% For | `[TBD]` XRD |
 
**Quorum** is the minimum total XRD that must participate (For + Against + Abstain) for the vote to be valid. If quorum is not met, the vote fails regardless of the approval ratio.
 
**Abstentions** count toward quorum but do not count toward the approval threshold.
 
### Voting Period
 
| Proposal Type | Minimum Duration |
|---------------|-----------------|
| Standard (Financial, Technical) | `[TBD]` days |
| Governance Amendment | `[TBD]` days |
| Election | `[TBD]` days |
| Emergency | `[TBD]` hours |
 
### Vote Integrity
 
#### Prohibited Behavior
 
- **Vote buying or selling** — offering or accepting compensation in exchange for a vote is a violation of the [Community Guidelines](#11-community-guidelines) and grounds for enforcement action
- **Sybil voting** — creating multiple accounts to amplify voting power. The snapshot mechanism mitigates this, as total XRD remains constant regardless of account distribution.
 
#### Delegation
 
`[TBD — the community may choose to implement vote delegation in a future version. If implemented, delegates must be publicly identified and delegations must be revocable at any time.]`
 
### dApp Requirements
 
The consultation dApp must:
 
1. Be open-source with publicly auditable Scrypto code
2. Allow any XRD holder to cast a vote without transferring tokens
3. Record all votes on the Radix ledger
4. Display real-time vote tallies
5. Enforce voting period start/end times
6. Prevent double-voting (one vote per account per proposal)
7. Provide a public API for vote results
 
**Source code:** `[TBD — link to consultation dApp repository]`
 
---
 
## 6. Treasury Management
 
### Overview
 
The DAO treasury holds assets transferred from the Radix Foundation and any future revenues. The RAC manages treasury operations on behalf of the community, but all spending requires prior community approval through the [Governance Proposal Process](#4-governance-proposal-process).
 
### Treasury Structure
 
The DAO maintains a single on-ledger treasury account controlled by the RAC via multi-signature.
 
**Treasury address:** `[TBD — account address to be set at deployment]`
 
#### Multi-Signature Requirements
 
- Treasury transactions require `[TBD]` of `[TBD]` RAC member signatures
- No single RAC member can unilaterally move funds
- Signature thresholds are enforced by the treasury's Scrypto access rules
 
### Spending Categories
 
All treasury expenditures must fall into an approved category:
 
| Category | Description | Per-Proposal Limit |
|----------|-------------|-------------------|
| Grants | Funding for ecosystem projects, tools, and infrastructure | `[TBD]` XRD |
| Bounties | Rewards for specific deliverables (bug fixes, features, content) | `[TBD]` XRD |
| Operations | DAO operating costs (RAC compensation, tooling, hosting) | `[TBD]` XRD |
| Partnerships | Strategic collaborations with other protocols or organizations | `[TBD]` XRD |
| Emergency | Urgent expenditures per [Checks & Balances](#7-checks--balances) | `[TBD]` XRD |
 
Expenditures exceeding the per-proposal limit for a category require a supermajority (>66%) vote.
 
### Spending Process
 
1. **Proposal** — author submits a Financial Proposal per the [Governance Proposal Process](#4-governance-proposal-process)
2. **Vote** — community votes via the consultation dApp
3. **Execution** — if approved, RAC executes the transaction after the execution delay
4. **Reporting** — RAC publishes a transaction report linking the vote to the on-ledger transaction
 
#### Escrow for Milestone-Based Funding
 
For grants and contracts with milestones:
 
- Funds are held in an escrow component
- Releases are triggered when the community or RAC (as specified in the proposal) confirms milestone completion
- If milestones are not met within the agreed timeline, remaining funds return to the treasury
- Escrow terms must be specified in the original proposal
 
### Transparency
 
#### Reporting Requirements
 
The RAC must publish:
 
- **Monthly treasury report** — current balances, inflows, outflows, and categorized spending
- **Per-transaction receipts** — for every treasury transaction, a public record linking the approved proposal to the on-ledger transaction hash
- **Quarterly summary** — high-level overview of treasury health, spending trends, and funded project outcomes
 
#### Public Dashboard
 
A public dashboard (part of the Update Pipeline UI) displays:
 
- Real-time treasury balances
- Historical transaction log
- Spending by category
- Active escrow positions
- Links to approved proposals for each expenditure
 
**Dashboard URL:** `[TBD]`
 
### Asset Management
 
#### Permitted Assets
 
The treasury may hold:
 
- XRD (primary)
- Other Radix-native resources received as part of approved partnerships or grants
- `[TBD — community to decide whether the DAO may hold non-XRD assets, and under what conditions]`
 
#### Investment Policy
 
`[TBD — the community may choose to define an investment policy for idle treasury funds in a future governance amendment. Until then, treasury funds are held as XRD and not deployed into yield-generating positions.]`
 
### Foundation Asset Handover
 
See [Temporary Provisions](#9-temporary-provisions) for the schedule and process by which Radix Foundation assets are transferred to the DAO treasury.
 
---
 
## 7. Checks & Balances
 
### Overview
 
This section defines safeguards against failure modes — compromised signers, malicious proposals, network outages, and other emergencies. These mechanisms override normal governance timelines when the DAO's integrity is at immediate risk.
 
### Emergency Proposals
 
When normal proposal timelines are too slow to address an immediate threat, any RAC member or `[TBD]` Community Members acting jointly may invoke the emergency process.
 
#### Qualifying Emergencies
 
- Active exploitation of a DAO-controlled Scrypto component
- Confirmed compromise of a RAC member's private keys or badge
- Critical vulnerability in the consultation dApp or treasury component
- Network-level failure affecting DAO operations
 
#### Emergency Process
 
1. **Declaration** — the initiator posts a public emergency declaration on DAO communication channels, describing the threat
2. **Accelerated vote** — voting opens immediately with a shortened period of `[TBD]` hours
3. **Elevated threshold** — emergency proposals require >75% approval and `[TBD]` XRD quorum
4. **Immediate execution** — if approved, the RAC executes without the standard execution delay
5. **Post-mortem** — within `[TBD]` days of resolution, the RAC publishes a full incident report
 
#### Interim Protective Actions
 
Before the emergency vote concludes, the RAC may take **interim protective actions** — limited, reversible measures to prevent ongoing damage:
 
- Pause treasury withdrawals (but not deposits)
- Disable a compromised signer's badge
- Halt consultation dApp voting if the dApp itself is compromised
 
Interim actions must be:
 
- **Reversible** — they freeze state but do not alter it
- **Publicly announced** — posted to DAO communication channels within 1 hour
- **Time-limited** — they expire automatically after `[TBD]` hours unless ratified by emergency vote
- **Reported** — included in the post-mortem
 
### Compromised Signer Protocol
 
If a RAC member's private keys or badge are believed compromised:
 
1. **Any RAC member** may trigger the compromised signer protocol
2. The compromised member's badge is immediately disabled via interim protective action
3. An emergency proposal is submitted to formally revoke the badge and, if necessary, elect a replacement
4. The compromised member's access to all DAO systems (GitHub merge rights, dApp admin) is suspended pending investigation
5. If the compromise is confirmed, a new badge is minted to the replacement and the signature threshold is updated
 
### Network Failure Contingency
 
If the Radix network experiences an outage affecting DAO operations:
 
- **Voting in progress** — the voting period is automatically extended by the duration of the outage
- **Treasury operations** — all non-emergency transactions are paused until network recovery
- **Governance registry** — document references remain at their last known-good state
- **Communication** — the RAC communicates status updates via DAO communication channels (off-chain channels that remain available during network outages)
 
### Veto Mechanism
 
To prevent the execution of a proposal that passes but is later discovered to violate the Charter:
 
1. **Veto window** — during the execution delay period (after a vote passes, before RAC executes), any `[TBD]` Community Members may file a formal veto challenge
2. **Veto review** — the challenge is posted publicly, and a snap vote is held: "Does this proposal violate the Charter?"
3. **Veto threshold** — if >66% vote Yes (it violates), the proposal is blocked
4. **Resubmission** — the original author may revise and resubmit the proposal
 
The veto mechanism exists solely to catch Charter violations. It is NOT a mechanism for overturning proposals that were simply unpopular.
 
### Separation of Powers
 
To prevent concentration of authority:
 
- No individual may hold more than one RAC seat
- RAC members may not simultaneously serve as paid contractors of the DAO
- RAC members must recuse from votes where they have a direct financial interest
- The consultation dApp code must be maintained by parties independent of the RAC
 
### Audit Requirements
 
- The On-Chain Governance Registry and treasury components must undergo an independent security audit before deployment and after any significant upgrade
- Audit reports must be published publicly
- The community may mandate additional audits via governance proposal
- `[TBD — qualified auditor requirements and funding mechanism]`
 
---
 
## 8. Reputation System
 
### Overview
 
The reputation system provides a lightweight trust-weighting mechanism that elevates the voices of consistent, constructive community contributors. Reputation does not replace XRD-weighted voting — it complements it by surfacing trusted perspectives during discussion and deliberation phases.
 
### Principles
 
- **Earned, not bought** — reputation accrues through contributions, not token holdings
- **Non-transferable** — reputation is bound to a community identity and cannot be sold or delegated
- **Transparent** — reputation scores and their derivation are publicly visible
- **Non-binding** — reputation influences visibility and advisory weight, but does not override voting outcomes
 
### Reputation Dimensions
 
Reputation is tracked across multiple dimensions to prevent gaming:
 
| Dimension | Earned By |
|-----------|-----------|
| Governance | Submitting proposals, voting consistently, participating in forum discussions |
| Technical | Contributing code, reviewing pull requests, identifying vulnerabilities |
| Community | Mentoring newcomers, moderating discussions, organizing events |
| Stewardship | Serving on the RAC, completing funded milestones, publishing reports |
 
### Accrual
 
Reputation accrues incrementally based on verifiable actions:
 
- **Forum participation** — meaningful contributions to governance discussions (not volume-based; spam or low-effort posts do not accrue reputation)
- **Proposal authorship** — submitting well-formed proposals that proceed to vote (regardless of outcome)
- **Voting participation** — consistent participation in governance votes
- **Code contributions** — merged pull requests to DAO repositories
- **Milestone completion** — delivering on funded project milestones
 
`[TBD — specific point values and accrual rates to be determined by community governance]`
 
### Decay
 
Reputation decays over time to ensure it reflects current, active participation rather than historical contributions:
 
- Reputation in each dimension decays by `[TBD]`% per `[TBD]` if no new contributions are made in that dimension
- Decay ensures that long-absent members do not retain outsized influence
- Decay pauses during announced leaves of absence (up to `[TBD]` months)
 
### Effects
 
#### Discussion Phase
 
- High-reputation contributors' posts may be highlighted or surfaced in governance forums
- Reputation scores are displayed alongside forum usernames
 
#### Advisory Weight
 
- When the RAC seeks community input on non-vote matters (e.g., selecting auditors, prioritizing grants), reputation-weighted signals may be used as a non-binding advisory input
- Advisory polls are distinct from formal governance votes and do not carry binding authority
 
#### Eligibility
 
- Minimum reputation thresholds may be set for specific governance actions:
  - `[TBD]` — minimum reputation to submit a proposal without the standard XRD stake
  - `[TBD]` — minimum reputation to serve as an election candidate
  - `[TBD]` — minimum reputation to file a veto challenge
 
### Anti-Gaming Measures
 
- Sybil resistance: reputation is tied to verified community identities, not addresses
- Quality over quantity: forum reputation accrues based on community endorsements (upvotes, reactions) not post count
- Cooldowns: rapid-fire actions (e.g., many small PRs) have diminishing reputation returns
- Review: the RAC may flag and investigate anomalous reputation accrual patterns
 
### Implementation
 
`[TBD — the reputation system will be implemented in phases. Phase 1 is a simple off-chain tracking system (spreadsheet or database). Phase 2 integrates reputation as a non-transferable Radix native resource (soul-bound token). The community will vote on each phase before implementation.]`
 
---
 
## 9. Temporary Provisions
 
### Overview
 
These provisions govern the transition from Radix Foundation stewardship to full community governance. They are designed to expire — each provision has an explicit sunset condition, after which it is removed from the charter.
 
### Transition Principles
 
- **Graduated decentralization** — authority transfers incrementally, not all at once
- **Safety rails** — the Foundation retains limited veto power during early phases to prevent catastrophic governance failures
- **Transparency** — every transition milestone is publicly announced and verifiable on-ledger
- **Irreversibility** — once authority is transferred, it cannot be reclaimed by the Foundation without a community supermajority vote
 
### Transition Phases
 
#### Phase 1 — Bootstrap (`[TBD]` months)
 
**Goal:** Stand up the DAO infrastructure and seed initial governance.
 
| Item | Status |
|------|--------|
| Deploy On-Chain Governance Registry | Foundation-led |
| Deploy treasury component | Foundation-led |
| Deploy consultation dApp | Foundation-led or community-built |
| Publish initial charter (this repository) | Community-written, Foundation-reviewed |
| Appoint initial RAC | Foundation appoints `[TBD]` members + `[TBD]` community-elected |
| Initial asset transfer | `[TBD]` XRD transferred to DAO treasury |
 
**Foundation powers during Phase 1:**
- Veto any proposal that would compromise the DAO's ability to function (e.g., draining the entire treasury, dissolving the RAC)
- Appoint the majority of initial RAC members
- Pause the DAO if a critical infrastructure failure is discovered
 
**Sunset:** Phase 1 ends when all items above are complete and the DAO has successfully executed at least `[TBD]` proposals.
 
#### Phase 2 — Growth (`[TBD]` months)
 
**Goal:** Shift authority from Foundation-appointed to community-elected representatives.
 
| Item | Detail |
|------|--------|
| RAC composition | `[TBD]` Foundation-appointed + `[TBD]` community-elected |
| Asset transfer | Additional `[TBD]` XRD transferred to DAO treasury |
| Foundation veto | Narrowed to existential threats only (treasury drain, Charter dissolution) |
| Consultation dApp | Community assumes maintenance responsibility |
 
**Sunset:** Phase 2 ends when scheduled elections produce a majority community-elected RAC.
 
#### Phase 3 — Maturity
 
**Goal:** Full community governance. Foundation has no special powers.
 
| Item | Detail |
|------|--------|
| RAC composition | All community-elected |
| Asset transfer | Remaining Foundation-designated assets transferred |
| Foundation veto | Expired — Foundation is a regular community participant |
| Governance | Fully governed by this charter without Foundation overrides |
 
**Sunset:** Phase 3 is the steady state. These Temporary Provisions are removed from the charter by governance vote once Phase 3 is achieved.
 
### Foundation Veto
 
During Phases 1 and 2, the Foundation retains a limited veto power:
 
- **Scope:** only proposals that would render the DAO non-functional or violate its core mission
- **Process:** the Foundation must publicly state the reason for a veto within `[TBD]` hours of the vote closing
- **Override:** the community may override a Foundation veto with a supermajority of >80% and `[TBD]` XRD quorum
- **Reporting:** all Foundation vetoes are logged in a public registry
- **Expiry:** Foundation veto power expires automatically at the start of Phase 3
 
### Asset Transfer Schedule
 
| Milestone | Amount | Condition |
|-----------|--------|-----------|
| Phase 1 launch | `[TBD]` XRD | DAO infrastructure deployed and operational |
| First successful proposal | `[TBD]` XRD | DAO executes its first community-approved proposal |
| Phase 2 transition | `[TBD]` XRD | Majority community-elected RAC seated |
| Phase 3 transition | Remaining assets | Full community governance achieved |
 
The Foundation may accelerate the transfer schedule if the DAO demonstrates sound governance ahead of the planned timeline.
 
### Amendments to Temporary Provisions
 
These provisions may be amended through the standard [Governance Proposal Process](#4-governance-proposal-process), with one exception: during Phases 1 and 2, amendments that would remove Foundation safety rails require Foundation consent in addition to community supermajority.
 
---
 
## 10. Update Pipeline
 
### Overview
 
The update pipeline connects governance document changes (on GitHub) to community approval (via the consultation dApp) to on-chain registry updates (via RAC execution). It ensures that the documents governing the DAO are always versioned, auditable, and community-approved.
 
### Architecture
 
```
GitHub Repository          Consultation dApp          On-Chain Registry
    (source)            (community approval)         (canonical reference)
       │                        │                          │
  Fork & PR ──→ Forum Discussion ──→ Vote ──→ RAC Merge ──→ Registry Update
       │                        │                          │
  Version tag               Vote record              Document hash
```
 
### Step-by-Step Process
 
#### 1. Author Drafts Changes
 
- Fork the charter repository
- Make changes on a feature branch
- Submit a pull request with a clear description
 
#### 2. Forum Discussion
 
- Author posts on a community communication channel linking the PR and explaining the rationale
- Community reviews the diff and provides feedback
- Author iterates on the PR based on feedback
- Minimum discussion period: `[TBD]` days
 
#### 3. Formal Proposal
 
- Once discussion matures, the author submits a Governance Amendment proposal per the [Governance Proposal Process](#4-governance-proposal-process)
- The proposal references the specific PR (by number and commit hash)
 
#### 4. Community Vote
 
- The consultation dApp opens voting on the proposal
- Approval requires >66% supermajority and `[TBD]` XRD quorum
- Voting period: minimum `[TBD]` days
 
#### 5. RAC Merge & Registry Update
 
If the vote passes:
 
1. **Merge** — a RAC member merges the approved PR into the main branch
2. **Tag** — the merge is tagged with the new semantic version (e.g., `v1.2.0`)
3. **Registry update** — the RAC calls `update_document_reference()` on the On-Chain Governance Registry, storing:
   - Document category (e.g., `charter`, `roles`, `voting`)
   - GitHub commit hash of the new version
   - Version number
   - Link to the approved vote
   - Brief change summary
 
#### 6. Public Dashboard Update
 
The public dashboard (UI layer) automatically reflects the new registry state, showing:
 
- Current version of each document
- Link to the GitHub source
- Link to the approving vote
- Change history
 
### On-Chain Governance Registry
 
The registry is a Scrypto component that serves as the canonical, on-ledger reference for the DAO's governance documents.
 
**Component address:** `[TBD]`
 
#### Data Structure
 
For each document category, the registry stores:
 
| Field | Type | Description |
|-------|------|-------------|
| `category` | `String` | Document identifier (e.g., `charter`, `roles`, `voting`) |
| `github_url` | `String` | Full URL to the document on GitHub at the specific commit |
| `commit_hash` | `String` | Git commit hash of the approved version |
| `version` | `String` | Semantic version (e.g., `1.2.0`) |
| `vote_reference` | `String` | Reference to the consultation dApp vote that approved this version |
| `summary` | `String` | Brief description of the change |
| `updated_at` | `Instant` | Ledger timestamp of the update |
 
#### Access Control
 
- **Read:** public (anyone can query the registry)
- **Write:** restricted to RAC Badge holders via Scrypto access rules
- **Admin:** parameter changes (e.g., adding new document categories) require a governance vote
 
### Version Bumping Rules
 
| Change Type | Version Bump | Examples |
|-------------|-------------|---------|
| Fundamental restructuring, new roles, mission changes | MAJOR (1.0.0 → 2.0.0) | Replacing RAC with a new structure, changing the mission |
| New provisions, modified processes, parameter changes | MINOR (1.0.0 → 1.1.0) | Adding a new spending category, changing voting thresholds |
| Typos, clarifications, formatting | PATCH (1.0.0 → 1.0.1) | Fixing a broken link, rewording for clarity |
 
**PATCH changes** may be merged by the RAC without a community vote, provided:
- The change is purely cosmetic (no semantic content change)
- The PR is reviewed by at least `[TBD]` community members
- The change is announced on a community communication channel
 
All MAJOR and MINOR changes require a full community vote.
 
### Rollback
 
If a merged change is later found to be problematic:
 
1. A new Governance Amendment proposal is submitted to revert the change
2. The standard voting process applies
3. If approved, the RAC reverts the commit, tags a new version, and updates the registry
 
For emergency rollbacks (e.g., a merged change introduced a Charter contradiction), the [emergency process](#emergency-proposals) applies.
 
---
 
## 11. Community Guidelines
 
### Purpose
 
These guidelines establish standards of conduct for all participants in Radix Network DAO governance — on all DAO communication channels, GitHub, the consultation dApp, and any other DAO-affiliated platforms.
 
### Standards
 
#### Act in Good Faith
 
Engage with governance honestly. Present your positions transparently, acknowledge uncertainty, and argue for what you believe serves the ecosystem — not just your own interests.
 
#### Be Respectful
 
Disagree with ideas, not people. Personal attacks, insults, and dismissiveness erode the trust that governance depends on. You can be direct without being hostile.
 
#### Be Constructive
 
Criticism is welcome; unconstructive negativity is not. If you oppose a proposal, explain why and suggest alternatives. If you identify a problem, propose a solution.
 
#### Be Inclusive
 
Governance benefits from diverse perspectives. Welcome newcomers, explain jargon, and avoid clique behavior that makes participation feel exclusive.
 
#### Align with the Charter
 
Proposals, discussions, and actions should be consistent with the DAO's [mission and values](#2-charter). Pursuing goals that contradict the charter undermines the entire governance system.
 
### Prohibited Behavior
 
The following behaviors are violations of these guidelines:
 
#### Vote Buying or Selling
 
Offering or accepting compensation (XRD, other tokens, services, or any form of value) in exchange for a specific vote. This is the most serious violation and results in immediate permanent ban.
 
#### Harassment
 
Targeted, unwelcome behavior directed at a specific individual, including but not limited to: threats, intimidation, stalking, doxxing, or sustained personal attacks.
 
#### Hate Speech
 
Content that promotes violence or discrimination against individuals or groups based on race, ethnicity, nationality, gender, gender identity, sexual orientation, religion, disability, or other protected characteristics.
 
#### Spam and Manipulation
 
- Flooding channels with repetitive, low-effort, or off-topic content
- Using bots to artificially amplify messages or proposals
- Creating sockpuppet accounts to simulate consensus
- Astroturfing (disguising coordinated campaigns as organic community sentiment)
 
#### Misrepresentation
 
- Impersonating RAC members, Foundation staff, or other community members
- Falsely claiming official endorsement or authority
- Knowingly presenting false information as fact in governance discussions
 
#### Abuse of Governance Process
 
- Submitting proposals in bad faith (e.g., to waste community attention or block legitimate proposals)
- Exploiting procedural loopholes to circumvent the community's intent
- Using emergency mechanisms for non-emergency purposes
 
### Enforcement
 
Enforcement follows a graduated escalation model. The severity of the response matches the severity and frequency of the violation.
 
#### Level 1 — Correction
 
**For:** first-time minor violations (off-topic posts, mildly disrespectful language)
 
**Action:** a moderator or RAC member privately contacts the individual, explains the concern, and requests a change in behavior. No public record.
 
#### Level 2 — Warning
 
**For:** repeated minor violations or a single moderate violation
 
**Action:** a formal public warning is issued, noting the specific guideline violated. The warning is logged.
 
#### Level 3 — Temporary Suspension
 
**For:** continued violations after warning, or a single serious violation
 
**Action:** temporary ban from DAO communication channels for `[TBD]` days. The individual retains their XRD voting rights but cannot participate in discussions or submit proposals during the suspension.
 
#### Level 4 — Permanent Ban
 
**For:** extreme violations (vote buying, doxxing, sustained harassment) or repeated serious violations
 
**Action:** permanent ban from all DAO communication channels. If the individual holds a governance role (e.g., RAC membership), a removal proposal is initiated. On-ledger voting rights are not affected (XRD holdings cannot be revoked), but the individual is excluded from all off-chain governance participation.
 
### Reporting
 
Community members can report guideline violations through:
 
- **Community communication channel** — flag the post or message a moderator
- **Email** — `[TBD — DAO governance email address]`
- **Anonymous form** — `[TBD — link to anonymous reporting form]`
 
Reports are reviewed by `[TBD — moderators, RAC, or a designated conduct committee]`. The reviewer must not be involved in the reported incident.
 
### Appeals
 
Any enforcement action at Level 2 or above may be appealed:
 
1. The individual submits a written appeal to `[TBD]`
2. The appeal is reviewed by a party not involved in the original decision
3. The appeal decision is final
 
Permanent bans may be reviewed after `[TBD]` months upon petition.
 
---
 
## 12. Lexicon
 
### Acronyms
 
| Acronym | Full Form |
|---------|-----------|
| DAO | Decentralized Autonomous Organization |
| DeFi | Decentralized Finance |
| MVD | Minimum Viable DAO |
| PR | Pull Request |
| RAC | Radix Advisory Council |
| XRD | Radix native token |
 
### Definitions
 
**Badge** — A Radix native resource used for access control. In the context of this DAO, the **RAC Badge** grants its holder the ability to execute privileged operations on DAO-controlled Scrypto components. Badges are non-transferable and are minted/recalled by governance processes.
 
**Community Member** — Any person who participates in DAO governance activities — discussion, voting, proposal authorship, code contribution, or any other form of engagement. No minimum token holding is required to be a Community Member.
 
**Component** — A Scrypto smart contract deployed on the Radix ledger. The DAO's on-chain infrastructure consists of several components: the Governance Registry, the treasury account, and the consultation dApp.
 
**Consultation dApp** — The Radix-native voting application used for governance decisions. It reads XRD balance snapshots and records votes on-ledger.
 
**Execution Delay** — The waiting period between a vote's conclusion and the RAC's execution of the approved action. Exists to allow the community to review results and file veto challenges if necessary.
 
**Foundation** — The Radix Foundation — the entity currently stewarding Radix ecosystem assets and development. The DAO is designed to progressively receive authority and assets from the Foundation.
 
**Governance Amendment** — A proposal to modify any section of this charter. Requires a supermajority (>66%) vote.
 
**Governance Registry** — The on-chain Scrypto component that stores canonical references to the current version of each governance document, including GitHub commit hashes, version numbers, and vote references.
 
**Multi-Signature** — A security mechanism requiring multiple RAC members to authorize a transaction. The treasury component enforces multi-sig requirements via Scrypto access rules.
 
**Native Resource** — An asset defined at the Radix ledger level (not by a smart contract). XRD is the primary native resource. Badges, tokens, and NFTs are all native resources on Radix, each with ledger-enforced properties like transferability, supply caps, and access rules.
 
**On-Chain** — Recorded on the Radix ledger, publicly visible and verifiable by anyone.
 
**Proposal** — A formal request for DAO action, submitted through the Governance Proposal Process. Proposals may be Financial, Governance Amendment, Technical, or Election type.
 
**Quorum** — The minimum total XRD that must participate in a vote (For + Against + Abstain) for the result to be valid. If quorum is not met, the vote fails regardless of the approval ratio.
 
**Radix Advisory Council (RAC)** — The elected body responsible for executing community-approved governance decisions. RAC members hold RAC Badges granting on-chain execution authority.
 
**RAC Badge** — A non-transferable Radix native resource held by RAC members. Grants the ability to call privileged methods on DAO Scrypto components (registry updates, treasury transactions, parameter changes).
 
**Reputation** — A non-transferable, non-tradeable score reflecting a community member's history of constructive participation. Accrues through governance activity and decays with inactivity.
 
**Scrypto** — The programming language for Radix smart contracts (components). Built on Rust, Scrypto uses an asset-oriented paradigm where resources are first-class objects with ledger-enforced properties.
 
**Snapshot** — A record of XRD balances at a specific block height, used to determine voting power for a particular vote. Prevents vote manipulation through last-minute token transfers.
 
**Supermajority** — An approval threshold higher than simple majority. In this charter, supermajority means >66% unless otherwise specified (e.g., >75% for emergency proposals, >80% for overriding a Foundation veto).
 
**Treasury** — The DAO's on-ledger account holding community assets. Controlled by RAC multi-signature. All expenditures require prior community approval.
 
**Veto** — A mechanism to block execution of a passed proposal that is found to violate the Charter. Distinct from voting against a proposal.
 
**XRD** — The native token of the Radix network. Used as the DAO's governance token (1 XRD = 1 vote) and primary treasury asset.
 
**XRD Holder** — A Community Member who holds XRD and is eligible to vote in governance decisions. Voting power is determined by XRD balance at the snapshot block height for each vote.
 
---
 
## 13. DAO Parameters
 
### Overview
 
This section contains the concrete, configurable values that govern DAO operations. All parameters are set by community vote and stored on-chain in the Governance Registry.
 
### On-Chain Addresses
 
| Component | Address | Description |
|-----------|---------|-------------|
| Governance Registry | `[TBD]` | Scrypto component storing document references |
| Treasury Account | `[TBD]` | Multi-sig account holding DAO assets |
| Consultation dApp | `[TBD]` | Voting component |
| RAC Badge Resource | `[TBD]` | Non-transferable badge resource definition |
| Reputation Token | `[TBD]` | Non-transferable reputation resource (Phase 2) |
 
### RAC Configuration
 
| Parameter | Value |
|-----------|-------|
| Total RAC seats | `[TBD]` |
| Multi-sig threshold | `[TBD]` of `[TBD]` |
| Term length | `[TBD]` year(s) |
| Max consecutive terms | `[TBD]` |
| Monthly compensation | `[TBD]` XRD |
| Meeting frequency | `[TBD]` |
| Inactivity threshold (removal trigger) | `[TBD]` days |
 
### Voting Parameters
 
#### Thresholds
 
| Proposal Type | Approval | Quorum |
|---------------|----------|--------|
| Financial | >50% | `[TBD]` XRD |
| Governance Amendment | >66% | `[TBD]` XRD |
| Technical | >50% | `[TBD]` XRD |
| Election | Plurality | `[TBD]` XRD |
| RAC Removal | >66% | `[TBD]` XRD |
| Emergency | >75% | `[TBD]` XRD |
| Foundation Veto Override | >80% | `[TBD]` XRD |
 
#### Timing
 
| Parameter | Duration |
|-----------|----------|
| Forum discussion (minimum) | `[TBD]` days |
| Review period | `[TBD]` days |
| Standard voting period | `[TBD]` days |
| Governance amendment voting period | `[TBD]` days |
| Election voting period | `[TBD]` days |
| Emergency voting period | `[TBD]` hours |
| Execution delay (standard) | `[TBD]` days |
| Execution delay (emergency) | 0 (immediate) |
| Failed proposal cooldown | `[TBD]` days |
| Snapshot offset (before vote opens) | `[TBD]` hours |
 
#### Proposal Requirements
 
| Parameter | Value |
|-----------|-------|
| Proposal stake | `[TBD]` XRD |
| Minimum reputation to skip stake | `[TBD]` |
 
### Treasury Parameters
 
| Parameter | Value |
|-----------|-------|
| Grant per-proposal limit | `[TBD]` XRD |
| Bounty per-proposal limit | `[TBD]` XRD |
| Operations per-proposal limit | `[TBD]` XRD |
| Partnership per-proposal limit | `[TBD]` XRD |
| Emergency spending limit | `[TBD]` XRD |
 
### Election Parameters
 
| Parameter | Value |
|-----------|-------|
| Nomination period | `[TBD]` days |
| Candidate discussion period | `[TBD]` days |
| Minimum governance activity (eligibility) | `[TBD]` days |
 
### Emergency Parameters
 
| Parameter | Value |
|-----------|-------|
| Interim protective action expiry | `[TBD]` hours |
| Post-mortem deadline | `[TBD]` days |
| Foundation veto statement deadline | `[TBD]` hours |
| Veto challenge signatories required | `[TBD]` Community Members |
 
### Reputation Parameters
 
| Parameter | Value |
|-----------|-------|
| Decay rate | `[TBD]`% per `[TBD]` |
| Max leave of absence (decay pause) | `[TBD]` months |
 
### Enforcement Parameters
 
| Parameter | Value |
|-----------|-------|
| Temporary suspension duration | `[TBD]` days |
| Permanent ban review eligibility | `[TBD]` months |
 
---
 
*All `[TBD]` values are to be set by community governance before or during Phase 1 of the [Temporary Provisions](#9-temporary-provisions). Once set, they can be modified through the standard [Governance Proposal Process](#4-governance-proposal-process).*