Skip to content
SORA Codex Community-curated documentation

SORA Governance

Governance is the process by which a decentralized network makes collective decisions. In SORA, this means deciding how newly minted XOR is allocated, which runtime upgrades are approved, and how the ecosystem evolves over time.

SORA’s governance model is designed to be democratic, transparent, and resistant to plutocracy—ensuring that no single entity or wealthy minority can control the network’s future.

The SORA network currently operates under Governance V1, a system adapted from Polkadot’s original governance framework (prior to OpenGov). This system provides stability and predictability while the more advanced SORA Parliament is developed.

Governance V1 consists of three primary bodies:

Council

Elected representatives who propose referenda, cancel dangerous proposals, and represent the community’s interests.

Technical Committee

Experts who can fast-track urgent proposals (like security fixes) without the normal voting period.

Parliament

All XOR holders who vote on referenda to make final decisions on proposals.

  1. Proposal Creation

    Anyone can submit a proposal by bonding XOR. Proposals can include runtime upgrades, parameter changes, treasury spending, or other network modifications.

  2. Council Review

    The Council reviews proposals and decides which ones to put forward as referenda. They can also create their own proposals.

  3. Referendum Period

    Approved proposals enter a voting period where all XOR holders can vote. Votes are weighted by the amount of XOR held and the conviction (lock-up period) chosen.

  4. Enactment

    Passed referenda are enacted after a delay period, giving the network time to prepare for changes.

Governance V1 uses stake-weighted voting with conviction multipliers:

Lock PeriodConvictionVote Weight
No lock0.1x10% of stake
1 week1x100% of stake
2 weeks2x200% of stake
4 weeks3x300% of stake
8 weeks4x400% of stake
16 weeks5x500% of stake
32 weeks6x600% of stake

This system rewards long-term commitment: voters who lock their XOR for longer periods have more influence on decisions.


The SORA Parliament represents the future of SORA governance—a sophisticated multi-body system designed to be more inclusive, fair, and resistant to manipulation than traditional token-weighted voting.

Most blockchain governance systems use simple token-weighted voting, which leads to:

  • Plutocracy — Wealthy holders dominate decisions
  • Voter apathy — Small holders feel their vote doesn’t matter
  • Centralization — Exchanges and funds accumulate voting power
  • Short-termism — Speculation over long-term ecosystem health

The SORA Parliament addresses these issues through sortition-based democracy.

Sortition is a governance mechanism where participants are randomly selected rather than elected or self-selected based on token holdings. This is how ancient Athenian democracy worked and has several advantages:

  • Fair representation — Anyone can be selected, not just the wealthy
  • Prevents plutocracy — Token holdings don’t determine power
  • Resistant to bribery — Random selection is harder to corrupt
  • Encourages participation — Everyone has a real chance of being chosen

The SORA Parliament will consist of multiple specialized bodies:

To participate in the SORA Parliament, individuals become citizens by posting XOR bonds:

  1. Bond XOR — Lock XOR tokens as a commitment to good governance
  2. Become Eligible — Enter the pool of potential governance participants
  3. Random Selection — Be sortitioned into governance bodies
  4. Serve Terms — Participate in governance duties
  5. Recover Bond — Get your XOR back after honest participation

Bonds can be slashed for malicious behavior, creating economic incentives for honest participation.

The Parliament’s primary responsibility is allocating newly minted XOR to productive projects. This includes:

  • Development grants
  • Ecosystem initiatives
  • Infrastructure funding
  • Community programs
  • Strategic investments

Rather than arbitrary inflation, new XOR is directed toward value-creating activities chosen by the community through the Parliament.


All SORA governance happens on-chain, meaning:

  • Transparency — Every proposal and vote is publicly recorded
  • Immutability — Past decisions can be audited and verified
  • Automation — Approved changes execute automatically
  • No gatekeepers — Anyone can participate according to the rules
graph LR
A[Draft Proposal] --> B[Bond XOR]
B --> C[Submit On-Chain]
C --> D[Council Review]
D --> E[Referendum]
E --> F{Vote Passes?}
F -->|Yes| G[Enactment Queue]
F -->|No| H[Proposal Fails]
G --> I[Execute Changes]
Proposal TypeDescriptionTypical Timeline
Runtime UpgradeCode changes to the network2-4 weeks
Parameter ChangeAdjust network settings1-2 weeks
Treasury SpendingAllocate community funds2-3 weeks
Emergency FixCritical security patchesFast-tracked

Key parameters that governance can modify:

  • Transaction fees — Base fee levels and burn percentages
  • Staking parametersValidator counts, reward rates
  • Bridge settingsCross-chain configurations
  • Token parameters — TBC reserve ratios, fee structures

The transition to SORA Nexus brings significant governance enhancements:

SORA v3 governance will be a hybrid model:

  • Parliamentary Structure — Maintained for strategic oversight
  • Modular Logic — Governance encoded in Iroha Special Instructions (ISIs)
  • Domain-Specific — Different governance for different areas

Governance surfaces in SORA Nexus define where and how governance applies:

  1. Configurationiroha_config is the source of truth
  2. Parameter Sets — Versioned, on-chain governance parameters
  3. Attestations — Cryptographic certificates for governance actions
  4. Data Spaces — Each data space can have customized governance

The Nexus governance structure includes:

  • Council — Fixed seats filled by NPoS/appointment
  • Assembly — Stake-weighted or one-person-one-vote participation

Selection uses VRF (Verifiable Random Function) sortition with defined thresholds, ensuring fair and verifiable randomness.

Governance-controlled runtime upgrades in SORA Nexus:

  1. Governance Manifest

    Proposal includes hashes, ABI versions, config, and activation slot

  2. Stage and Verify

    Network prepares for upgrade, verifies manifests match

  3. Atomic Activation

    At the specified slot, upgrade activates atomically

  4. Reject Mismatches

    Any manifest mismatch causes rejection


Any XOR holder can participate in Governance V1:

  1. Navigate to the governance portal
  2. Review active proposals
  3. Choose your vote (Aye/Nay)
  4. Select conviction (lock period)
  5. Submit your vote

To create a proposal:

  1. Draft your proposal clearly
  2. Bond the required XOR
  3. Submit on-chain
  4. Engage with the community
  5. Respond to Council feedback

Council members are elected by the community and have additional responsibilities:

  • Review incoming proposals
  • Propose new referenda
  • Cancel dangerous proposals
  • Represent community interests

Q: Can I change my vote? A: Yes, during the voting period you can update your vote.

Q: What happens to my locked XOR? A: It remains locked for the conviction period you selected, then becomes available.

Q: How do I get on the Council? A: Council members are elected by XOR holders. Announce your candidacy and campaign.

Q: What’s the minimum XOR needed to vote? A: There’s no minimum, but gas fees apply to voting transactions.


SORA governance evolves through three phases:

PhaseSystemKey Feature
CurrentGovernance V1Council + referendum model
TransitionEnhanced V1Preparation for Parliament
FutureSORA ParliamentSortition-based democracy

The goal is a governance system that is:

  • Fair — No plutocracy, everyone has a voice
  • Efficient — Decisions made in reasonable timeframes
  • Secure — Resistant to attacks and manipulation
  • Transparent — All actions visible on-chain
  • Evolutionary — Can adapt and improve over time