XIP-0009: Constitutional Alignment — Token Supply Correction, Governance Parameter Restoration, Administrator Role Removal, and Security Council Reaffirmation and Expansion

XIP-0009: Constitutional Alignment — Token Supply Correction, Governance Parameter Restoration, Administrator Role Removal, and Security Council Reaffirmation and Expansion

Category: Process (§5.1.2(i)(D)) + Structure (§5.1.2(i)(C))
Status: FORUM — Public Review | Forum Post Target: March 10, 2026
Author: Xandeum Security Council / Xandeum Foundation


Security Council Transparency Statement

This XIP is being submitted through the Realms platform under its current operational settings (5,000,000 XAND proposal threshold; 1% quorum). The Security Council acknowledges that these settings do not match the thresholds stated in the current Constitution (17,500,000 XAND; 3%). Correcting that mismatch is necessary to restore constitutional governance, reduce community uncertainty, and provide Tokenholders with a clear and reliable process going forward. The currently active settings are the only available submission mechanism, so using them to correct the governance framework is the most practical path to restore alignment. These governance corrections are therefore being pursued through the XIP process, not through emergency powers, which remain reserved for true security emergencies. This approach is consistent with how the Jito Foundation handled an equivalent bootstrapping situation in JIP-14 (February 2025). Upon passage of this XIP, the corrected thresholds will be implemented in Realms immediately.


Abstract

XIP-0009 proposes eight coordinated amendments to the Xandeum DAO Constitution to correct known errors, remove structural ambiguity, and bring the DAO into full constitutional compliance. The amendments address: (1) an incorrect token supply figure inherited from the XNDE-to-XAND transition that causes all voting thresholds to be wrong; (2) a Realms voting threshold that was configured below the constitutional standard; (3) a Realms proposal threshold that was configured below the constitutional standard; (4) the absence of explicit Security Council term continuity language, which caused community uncertainty during XIP-0007 despite the Security Council remaining continuously in force under the Constitution’s removal framework and the general governance principle of holdover continuity; (5) the absence of clear multi-option vote counting, ballot-structure, and proposal-classification rules; (6) removal of the Administrator role, which is not in active use and creates structural confusion; (7) reaffirmation of the 3 existing Security Council members for a new 12-month term and expansion to the constitutional minimum of 5 members; and (8) a member privacy protection provision. There is no treasury spend. All changes are governance structure corrections designed to improve clarity, continuity, and security for Tokenholders, users, and the Xandeum Network.


Motivation

The Xandeum DAO Constitution contains a cluster of interrelated errors and omissions that, taken together, have produced the governance uncertainty the community experienced during and after XIP-0007. These issues cannot be fixed one at a time without creating new inconsistencies. They must be addressed together in a single, coherent update that protects governance integrity and gives the community a clearer, safer process going forward.

The root cause of most problems: When the token symbol changed from XNDE to XAND, the Constitution was updated in name only. The total token supply figure — the foundation of every voting threshold — was never corrected. The old XNDE supply of 8,800,000,000 remained in §6.1.4, making the stated 3% YES threshold (264,000,000 XAND) more than double what it should be against the actual XAND supply of 4,015,000,000 (where 3% = 120,450,000 XAND). This single error cascades through every governance calculation.

The Realms misconfiguration: The DAO’s Realms instance was configured with a 1% quorum and a 5,000,000 XAND proposal threshold — both below the constitutional standards of 3% and 17,500,000 XAND respectively. As a result, all XIPs submitted since launch have operated under parameters inconsistent with the Constitution, creating a legitimacy gap for every vote taken.

The term continuity gap: The Constitution specifies 12-month terms for Security Council Members but does not expressly state what happens if a term expires before a successor is elected. That ambiguity created avoidable uncertainty for the community at exactly the moments when governance continuity matters most. On the strongest reading of the current text, the Security Council’s authority was continuous throughout: §3.1.2 permits removal only through specified active processes; the removal framework is built around a member in violation or otherwise failing to fulfill duties; §3.1.1 addresses replacement or removal during a term but does not say service automatically ends at term expiration; and §3.2.1 shows that the drafters knew how to write explicit continuation language when they intended to do so. XIP-0009 resolves this gap by making clear that Security Council authority continues in holdover status until successors are duly elected and seated or members are removed under §3.1.2, preserving continuity for Tokenholders, users, and the network.

The multi-option vote gap: XIP-0007 used three voting options. The Constitution’s voting threshold framework was written for binary YES/NO votes only and provided no guidance on how to apply the 3% threshold to a multi-option result, whether a formal multi-option ballot must preserve a genuine status-quo option, or how Tokenholders should distinguish a binding governance proposal from a non-binding advisory poll. This produced genuine ambiguity not only about whether and how XIP-0007 passed, but also about whether the ballot itself offered voters a valid way to reject all proposed action paths.

The Administrator role: The Administrator role as currently defined in §3.2 has not been operationally implemented in a way that is distinct from the Security Council’s own functions. The role creates a confusing separation of duties on paper that does not reflect how the DAO actually operates. Removing it simplifies the governance structure, reduces procedural ambiguity for the community, and places DAO management responsibilities clearly with the Security Council, which is where they functionally reside today. This is consistent with the DAO’s current stage of development.

Security Council compliance: The Constitution requires at least 5 Security Council Members at all times (§3.1). The current council has 3 members. This XIP reaffirms the existing 3 members for a new 12-month term (following the Jito JIP-14 model) and affirms 2 additional Foundation-vetted members to reach the constitutional minimum. Bringing the Council back to full strength improves resilience, distributes responsibility more appropriately, and better protects the community and network from avoidable governance concentration. Annual reaffirmation via Tokenholder Vote going forward helps ensure this situation does not recur.

Member privacy: The Xandeum DAO operates a protocol that controls significant infrastructure and treasury assets. Publicly advertising the personal identities of individuals who hold governance authority over these assets creates physical security risks — the same principle that applies to anyone holding cryptographic keys. Protecting Security Council member privacy helps ensure qualified people can safely serve the DAO while preserving secure stewardship of infrastructure and assets for the benefit of the community. Council members’ identities are known to and held by the Xandeum Foundation but need not be publicly disclosed.


Key Terms

Xandeum Foundation: Throughout this XIP, “Xandeum Foundation” refers to the Xandeum Foundation organized as a Private Interest Foundation under the laws of the Republic of Panama (Law No. 25 of 1995). A separate Xandeum Foundation entity exists in the Cayman Islands. Unless otherwise stated, all references to the Xandeum Foundation in this XIP and in the Constitution refer to the Panama entity.

Token Supply Correction: The update of the total XAND token supply figure in the Constitution from 8,800,000,000 (the old XNDE supply) to 4,015,000,000 (the actual XAND supply), and the recalculation of all supply-based thresholds.

Holdover Doctrine: The general governance principle — commonly recognized across corporate, nonprofit, and public-law systems — that elected or appointed officers continue to serve in their roles after their stated term expires until successors are duly chosen or they are lawfully removed, in order to prevent governance vacuums. In XIP-0009, this term is used as supporting shorthand for continuity, but the primary basis for the Security Council’s continued authority is the Constitution itself, especially §3.1.2’s exclusive removal framework and the absence of any clause stating that term expiration alone ends service.

Reaffirmation: A Tokenholder Vote to confirm existing Security Council Members for an additional 12-month term, satisfying the constitutional election requirement without requiring a full new election process. Established as standard practice by Jito JIP-14 (February 2025).

Foundation-Vouched Slate Election: A method of electing Security Council Members in which the Security Council, in coordination with the Xandeum Foundation, identifies and vets candidates whose identities are known to the Foundation, and presents them to Tokenholders as a slate for affirmation vote. Tokenholders vote on their confidence in the Foundation’s vetting rather than on individually identified candidates.

Operational Security (OpSec): The practice of protecting individuals who hold governance authority over protocol infrastructure and treasury assets from physical or targeted security risks by limiting public disclosure of their personal identities.

Multi-Option Vote Threshold: The rule governing how the constitutional YES vote threshold applies when a XIP presents more than two voting options.


Specification

Amendment 1 — §6.1.4: Token Supply and Voting Threshold Correction

Current text:

“At least 3% (264,000,000 XAND) of the 8,800,000,000 XAND total token supply must vote ‘yes’ and the number of ‘yes’ votes must be more than the number of ‘no’ votes.”

Amended text:

“At least 3% (120,450,000 XAND) of the 4,015,000,000 XAND total token supply must vote ‘yes’ and the number of ‘yes’ votes must be more than the number of ‘no’ votes.”

Realms implementation on passage: Update total supply reference from 8,800,000,000 to 4,015,000,000 XAND.


Amendment 2 — §6.1.4: Restore Voting Threshold in Realms

The Realms quorum is currently set to 1% (approximately 40,150,000 XAND). The Constitution specifies 3% (120,450,000 XAND with corrected supply). The Constitution is the governing standard. The Realms configuration was set in error.

Realms implementation on passage: Update Realms voting quorum from 1% to 3% (= 120,450,000 XAND).

Note to community: This raises the bar for future XIPs. A YES vote of at least 120,450,000 XAND will be required for any XIP to pass going forward. This is the correct and intended standard.


Amendment 3 — §6.1.3 / §5.1.4: Restore Proposal Submission Threshold in Realms

Current §6.1.3 text:

“Proposal Threshold: 17,500,000 XAND (Minimum number of tokens a holder must have, or be delegated by third parties, to submit a proposal for a vote of the DAO)”

The Realms platform is currently configured at 5,000,000 XAND. The Constitution is the governing standard. The Realms configuration was set in error.

Realms implementation on passage: Update Realms proposal threshold from 5,000,000 to 17,500,000 XAND.

Community discussion point: The original 17,500,000 threshold was set against an 8.8B supply, representing approximately 0.20% of total supply. Against the corrected 4.015B supply, 17,500,000 XAND represents approximately 0.44% — roughly double the original proportional intent. The community is invited to provide input during the 30-day discussion period on whether the threshold should remain at the fixed 17,500,000 XAND or be adjusted to approximately 8,030,000 XAND (0.20% of 4.015B). The fixed 17,500,000 figure as written in the Constitution is the default unless amended.


Amendment 4 — §3.1.1: Security Council Holdover Language

Addition to §3.1.1(ii) after existing text:

“Security Council Members shall continue to serve in a holdover capacity following the expiration of their twelve (12) month term until their successors have been duly elected and seated by Tokenholder Vote, or until they are removed pursuant to Section 3.1.2. The expiration of a Security Council Member’s twelve (12) month term does not, by itself, constitute a vacancy under §3.1, a violation of this Constitution, or a failure to fulfill duties under §3.1.2(i). Actions taken by the Security Council in holdover capacity are valid and binding. The Security Council is strongly encouraged to initiate a reaffirmation or election XIP no later than thirty (30) days before the end of each 12-month term. If the Security Council has not posted a reaffirmation or election XIP to the governance forum within thirty (30) days of term expiration, any Tokenholder meeting the proposal threshold in §6.1.3 may post one on the community’s behalf.”


Amendment 5 — New §6.1.5 and §6.1.6: Multi-Option Vote Counting, Ballot Structure, and Proposal Classification

Add new §6.1.5:

6.1.5 Multi-Option Vote Counting: When a Formal XIP presents more than two (2) voting options, the following rules apply: (i) the option receiving the greatest number of votes is the winning option; (ii) the winning option must receive votes totaling at least 3% of the total token supply (currently 120,450,000 XAND) — consistent with the YES vote threshold in §6.1.4; and (iii) if no option meets condition (ii), the XIP does not pass and the status quo is maintained. The approval quorum configured in Realms shall at all times reflect this same 3% of total supply standard.”

Add new §6.1.6:

6.1.6 Ballot Structure and Proposal Classification: Each proposal submitted to the DAO must be clearly designated as either (i) a Formal XIP or (ii) an Advisory Poll. A Formal XIP is a binding governance proposal that, if approved, may authorize constitutional, governance, treasury, operational, or protocol action in accordance with this Constitution. An Advisory Poll is a non-binding community sentiment mechanism and may not by itself authorize or require constitutional, governance, treasury, operational, or protocol action. When a Formal XIP presents more than one substantive action path, the ballot must include a clearly identified ‘No Action,’ ‘Reject Proposal,’ or ‘Maintain Status Quo’ option that, if selected, results in no constitutional, governance, treasury, operational, or protocol change. An abstention option, if provided, shall not itself authorize, direct, or require substantive action. A Formal XIP that does not provide a genuine status-quo option is non-conforming and should not proceed to vote. The Security Council shall treat the absence of such an option as a material defect in ballot structure and is expected to withhold approval for publication or, if necessary, exercise its constitutional veto authority to prevent a non-conforming ballot from being presented to Tokenholders. No constitutional, governance, treasury, operational, or protocol change may be implemented solely on the basis of an Advisory Poll. Any such action must be authorized through a Formal XIP approved in accordance with the XIP Process.”

Note on Realms mechanics: In Realms Community Token DAOs, the “Approval Quorum” setting is not a participation quorum — it is a minimum threshold that the winning option must reach as a percentage of the configured max vote weight (total token supply). §6.1.5 codifies that same mechanic in the Constitution so the two are always aligned. §6.1.6 separately governs ballot validity by requiring a genuine status-quo option on formal multi-option ballots and by distinguishing binding Formal XIPs from non-binding Advisory Polls. A plurality winner that falls below 3% of total supply does not pass, regardless of how many other options received fewer votes.


Amendment 6 — Remove Administrator Role

The entire §3.2 (Administrator) is removed. All duties previously assigned to the Administrator are absorbed by the Security Council. The following changes are made throughout the Constitution:

§3.1.1(i) — Revised:
Remove the reserved Administrator seat. Replace with:

“(i) All five (5) Security Council Members shall be elected by Tokenholder Vote at regular twelve (12) month intervals, unless otherwise replaced or removed prior to the end of their current term in accordance with this Constitution.”

§3.1.1(iii) — Removed entirely.

§3.1.3 — Remove “with guidance from the Administrator”:
Current: “…assist with the implementation of XIPs and activity on the Network with guidance from the Administrator…”
Amended: “…assist with the implementation of XIPs and activity on the Network…”

§3.2 — Removed entirely (sections 3.2.1 through 3.2.4 inclusive).

§5.1.1 — Replace Administrator with Security Council:
Current: “…a DAO moderator (‘DAO Moderator’) will confirm…” and “…the Administrator will perform these duties.”
Amended: “…a DAO moderator (‘DAO Moderator’) will confirm…” and “…the Security Council will perform these duties.”

§5.1.2 — Replace Administrator references:
Current: “…inform the Administrator. After the Administrator has confirmed proposals meet the above criteria…”
Amended: “…inform the Security Council. After the Security Council has confirmed proposals meet the above criteria…”

§5.1.4 — Replace Administrator with Security Council:
Current: “The Administrator will review the proposal for practicality and safety for the DAO once submitted…”
Amended: “The Security Council will review the proposal for practicality and safety for the DAO once submitted…”

§5.1.6 — Replace Administrator with Security Council:
Current: “…the Administrator will work with the author, appropriate service providers of the DAO, and other parties…”
Amended: “…the Security Council will work with the author, appropriate service providers of the DAO, and other parties…”
Current: “The Administrator will provide updates on Xandeum’s governance forum…”
Amended: “The Security Council will provide updates on Xandeum’s governance forum…”

§8.3 — Replace Administrator with Security Council:
Current: “…the Administrator will take such actions as needed to execute the XIP…”
Amended: “…the Security Council will take such actions as needed to execute the XIP…”

Defined Terms — Remove “Administrator” definition.


Amendment 7 — Security Council Reaffirmation and Expansion to 5 Members

Part A — Reaffirmation of Existing Members (JIP-14 model):

The three (3) existing Security Council Members, whose identities are known to and verified by the Xandeum Foundation, are hereby presented for reaffirmation by Tokenholder Vote for a new twelve (12) month term effective the date this XIP passes. This reaffirmation satisfies the requirement under §3.1.1 that Security Council Members be elected by Tokenholders at regular 12-month intervals. Tokenholders are asked:

“Do you affirm the continuation of the three existing Security Council Members, as verified by the Xandeum Foundation, for an additional 12-month term beginning upon passage of this XIP?”

This approach is consistent with Jito Foundation’s JIP-14 (February 2025), in which the Jito DAO reaffirmed its existing Security Council for an additional 12-month term via Tokenholder Vote.

Part B — Expansion Mandate: 2 New Members Within 60 Days:

The Constitution requires at least five (5) Security Council Members at all times (§3.1). With the reaffirmation of the 3 existing members in Part A, the Security Council will have 3 members upon passage of this XIP. To reach full constitutional compliance at 5 members, the following obligation is established:

Within sixty (60) days of the passage of this XIP, the Security Council, in coordination with the Xandeum Foundation, shall post a companion XIP to the governance forum at https://forum.xandeum.network to begin the required 30-day community discussion period. The companion XIP shall identify and vet two (2) candidates whose identities are known to and verified by the Foundation, and Tokenholders will be asked to affirm the vetted slate. The 60-day deadline is measured to the forum posting date, not the vote passage date, so the full constitutional process (30-day discussion + 3-day vote + 2-day delay) can proceed after that. If XIP-0009 passes on April 14, 2026, the forum posting deadline is approximately June 13, 2026, with the companion vote completing approximately July 18, 2026.

If the Security Council fails to submit the companion XIP within 60 days, any Tokenholder meeting the proposal threshold may submit it on their behalf.

Annual Reaffirmation Going Forward:
The term continuity and reaffirmation obligations are governed by the holdover language added to §3.1.1 in Amendment 4 of this XIP. Security Council Members continue in holdover following term expiration. The community safety valve — allowing any Tokenholder at threshold to post a reaffirmation XIP if the Security Council has not done so within 30 days of term expiration — also applies to all future annual reaffirmation cycles.


Amendment 8 — New §3.1.5: Security Council Member Privacy Protection

Add new §3.1.5:

3.1.5 Security Council Member Privacy. Security Council Members are not required to publicly disclose their personal identity. The identity of each Security Council Member shall be known to and held by the Xandeum Foundation. The DAO does not require, and will not mandate, the public disclosure of Security Council Member identities. The Foundation shall maintain this information as part of its governance and legal responsibilities to the DAO and the Xandeum Network, while avoiding unnecessary public exposure of individuals serving in sensitive roles. This policy exists to protect Security Council Members from physical security risks that may arise from public association with control over protocol infrastructure, treasury assets, and cryptographic governance keys — consistent with standard operational security practices in the blockchain industry. The same principle that applies to individuals who hold cryptographic private keys applies to those who hold governance authority over protocol infrastructure: publicly advertising that identity creates a targeting risk, including at public industry events. This policy is also consistent with the strict confidentiality obligations already imposed on Foundation Council members under Panama Law No. 25 of 1995.”


Benefits / Risks

Benefits

Benefit Detail
Constitutional accuracy The governing document reflects the actual token supply and thresholds
Governance legitimacy Future XIPs operate under parameters that match the Constitution
Clarity of authority Explicit term continuity language eliminates future community uncertainty about Security Council standing
Simplified structure Removing the Administrator eliminates a confusing, unused role
Constitutional compliance Security Council at 5 members as required by §3.1
Member safety Privacy protection reduces physical security risk while supporting secure stewardship of protocol infrastructure and treasury assets on behalf of the community, consistent with Panama PIF Law 25 confidentiality obligations

Risks

Risk Mitigation
Higher voting threshold (3%) may make future XIPs harder to pass This is the correct and intended standard; community engagement is the mitigation
Removing Administrator creates a transition period Security Council absorbs duties it already functionally performs today
Anonymous member affirmation requires community trust in Foundation vetting Identities are held by the Foundation; community trust in the Foundation’s vetting is the basis — consistent with Jito’s approach
Proposal threshold increase (17.5M) may limit who can submit XIPs Administrator-equivalent assistance from Security Council available per §5.1.4

Outcomes

Immediate upon passage:

  • Constitution v2.3 published with all 8 amendments incorporated
  • Realms parameters updated: supply 8.8B → 4.015B, quorum 1% → 3%, proposal threshold 5M → 17.5M
  • Security Council 3 existing members reaffirmed for a new 12-month term
  • 60-day clock starts for companion XIP to elect 2 new members (deadline ~June 13, 2026)
  • Full constitutional compliance at 5 members achieved upon passage of companion XIP

Ongoing:

  • Annual reaffirmation cycle mandated by Amendment 4 holdover language
  • Security Council manages XIP process directly with no separate Administrator layer
  • Multi-option vote counting, ballot-structure, and proposal-classification rules apply to all future XIPs and Advisory Polls

Cost Summary

There is no treasury spend associated with this XIP. All changes are governance structure corrections to the constitutional text and Realms platform parameters. Existing Security Council Member compensation of $1,000 per member per month (payable in USDC or XAND per §3.1.4) continues unchanged for the 3 reaffirmed members. The 2 new members will receive the same compensation upon affirmation, for a total Security Council compensation of $5,000 per month across all 5 members — consistent with the constitutional minimum composition.


Voting Options

YES — You support this proposal and all eight amendments as described. You affirm the reaffirmation of the 3 existing Security Council Members and the addition of 2 Foundation-vetted Security Council Members for a 12-month term.

NO — You do not support this proposal. The Constitution remains as currently written and the Realms parameters remain unchanged.


References

Unnofficial transposed markdown mirror copy of the Xandeum DAO Constitution

1 Like

Seems pretty comprehensive and well thought out. Thanks for taking the time to create such a detailed and well-constructed plan to address community concerns about many clearly identified problems. I have a few eyebrow raises, but none that would keep me from supporting this XIP without hearing sound arguments against it from the many community members who are smarter than me on this stuff. To be honest, I am quite surprised to see no other commentary posted here yet.

Thank you for taking the time to look through it! We value the community and this is a community DAO so we want the framework to be a protection for everyone involved.