Xandeum DAO Constitution v2.3

General
1

Xandeum DAO Constitution v2.3

1. Xandeum DAO Constitution

1.1 This Constitution provides an overview of the governing framework for the holders of XAND (each, a “Tokenholder”, and collectively, the “DAO”), which is the governing body for the Xandeum Network (as defined below). Defined terms in this Constitution shall have the meaning ascribed to those terms in the Schedule hereto.

1.2 Some of the rules and procedures in this Constitution will be enforced directly on a blockchain, and some will not. All rules are equally binding. Actions taken under this Constitution may be on-chain or off-chain actions. On-chain actions are those that are actuated directly by the governance parameters of the DAO as transactions on a blockchain. Off-chain actions are those that are actuated by other means.

1.3 The “Xandeum Network” is the decentralized Solana-based protocol that enables users to stake SOL to validators participating in Xandeum’s scalable storage layer and receive a liquid staking token (xandSOL) representing accumulated validator rewards, tips, and storage rewards. The DAO can direct changes to the protocol source code or related parameters. Anyone can access the Xandeum Network. The DAO maintains a browser-based dashboard facilitating easy access at Realms.

2. Governing Principles

2.1 All representatives and members of the DAO are expected to act in accordance with the following governing principles:

  • 2.1.1 act in the best interest of the Solana and Xandeum network;
  • 2.1.2 act in the best interest of Tokenholders;
  • 2.1.3 the DAO strives to create a safe and welcoming environment for all would-be community members, regardless of age, gender, ethnicity, religion, disability, sexual orientation, education, national origin, or any other differentiating factors. The DAO is committed to maintaining an environment in which all individuals are treated with respect and dignity. The DAO expects that all relationships among DAO Representatives, the DAO, and Tokenholders will be free of unlawful bias, prejudice, and harassment. DAO Representatives are strictly forbidden from engaging in any type of discrimination or sexual harassment;
  • 2.1.4 in evaluating XIPs and other issues, DAO Representatives should focus on the substance of such discussions without criticizing individuals or engaging in personal attacks;
  • 2.1.5 consistency with the DAO’s mission, which is to facilitate the growth of the Network and the Solana validator economy; and
  • 2.1.6 DAO Representatives should not use their role in a way that conflicts with the DAO’s governing principles and the DAO’s mission.

2.2 As part of their service the DAO, as applicable, each DAO Representative will:

  • 2.2.1 Adhere to this Constitution.
  • 2.2.2 Attend meetings and unofficial DAO events hosted by the DAO and Tokenholders. DAO Representatives may choose the frequency with which they perform these activities at their own discretion, bearing in mind that if they fail to adequately represent the DAO, as applicable, due to infrequency of participation, they may be removed from their position in accordance with this Constitution.
  • 2.2.3 Ensure that they are adequately informed on XIPs.
  • 2.2.4 Share their contact information with the other DAO Representatives.
  • 2.2.5 Announce as soon as possible if they will be unable, even temporarily, to fulfill their duties, for example, due to vacation, illness, or personal emergencies.
  • 2.2.6 Understand Applicable Law, obey and act in accordance with Applicable Law, and act ethically at all times. DAO Representatives should ask their own legal counsel for advice when they are uncertain about Applicable Law. For the avoidance of doubt and notwithstanding anything in the contrary here, no DAO Representative may take actions, directly or indirectly, which violate the laws of the Republic of Panama or any other Applicable Law.
  • 2.2.7 Maintain and monitor relevant websites, forums, or other governance mediums and communications of the DAO.
  • 2.2.8 As appropriate, elect, nominate, promote, hire, or contract with individuals or organizations into important administrative, governance, engineering, legal, or other roles established to serve the DAO.
  • 2.2.9 No DAO Representative should speak on behalf of the DAO, unless explicitly authorized by the DAO. This provision does not in any way restrict a DAO Representative from publicly discussing their personal opinion about a XIP or other matter affecting the DAO, provided that such communication is clearly presented as a personal opinion in light of the circumstances or context.

3. Service Providers of the DAO

3.1 Security Council

A Security Council should be established by the DAO. The Security Council are agents of the DAO and shall be initially appointed by Xandeum Foundation (Panama). At all times, the Security Council shall be composed of at least five (5) Security Council Members who are appointed in accordance with below.

If a Security Council Member position is or will become vacated, such that the Security Council would be less than five (5) Security Council Members, the Tokenholders shall elect a replacement by Tokenholder Vote as quickly as is practical. The Security Council may use discretion to bypass ordinary Tokenholder Vote or XIP procedures to implement emergency proposals and actions necessary to preserve the safety or security of the DAO, the DAO and/or the Xandeum Network, its users, or the DAO’s assets. Examples of emergencies include but are not limited to security breaches, violations of core principles, network attacks, etc.

3.1.1 Appointment of Security Council Members

Thereafter, at all times the Security Council shall be comprised of at least five (5) Security Council Members who are appointed in the following manner:

(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.

(ii) 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.

3.1.2 Removal of Security Council Members

A Security Council Member may only be removed:

(i) by the Tokenholders in connection with their violation of this Constitution or their failure to fulfill their duties to the DAO (in each case as determined by the Tokenholders), including those described in this Constitution; or

(ii) pursuant to a Security Council Vote or a Tokenholder Vote (such Security Council Member in violation, the “Breaching Member”).

In respect to (ii), a Breaching Member may be removed as a Security Council Member (1) pursuant to a vote of all other Security Council Members or (2) by Tokenholder Vote. If removed by the Tokenholders, such removal of a Breaching Member shall be conditioned by a thirty (30) day notice.

(iii) If removed pursuant to a Security Council Vote:

  • An action to remove a Security Council Member for violation of this Constitution may be presented as a Proposal by a non-breaching Security Council Member (a “Removal Proposal”) at a Regular Meeting.
  • A Removal Proposal will pass in accordance with the voting procedures set forth in this Constitution.
  • If the Removal Proposal passes, the Security Council may choose to replace the Breaching Member with a new, interim Security Council Member to serve until the end of term of the replaced Security Council Member’s term. An action to add a new Security Council Member must be presented at a Regular Meeting (a “Replacement Proposal”).
  • A Replacement Proposal will pass in accordance with the voting procedures set forth in this Constitution.

(iv) If removed by Tokenholder Vote:

  • An action to remove a Breaching Member may be presented by Tokenholders as a XIP (a “Tokenholder Removal Proposal”).
  • If the Tokenholder Removal Proposal passes in accordance with the XIP Process, the Tokenholders may choose to replace the Breaching Member with a new Security Council Member. An action to add a new Security Council Member may be presented as a XIP and in accordance with the XIP Process.

3.1.3 Role of the Security Council

The Security Council shall operate pursuant to the rules in this Constitution as may be amended in accordance with their terms going forward. The Security Council plays a supporting and coordinating role for the DAO, as set forth in this Constitution. The Security Council serves to represent the Tokenholders and assist with the implementation of XIPs and activity on the Network, in accordance with this Constitution. Security Council Members should act in the best interest of the DAO. Neither the Security Council nor the Security Council Members owe any fiduciary duties to the DAO or the Tokenholders.

3.1.4 Compensation of Security Council Members

Initially, the Security Council Member position will be paid an amount equal to $1,000, which shall be paid, at the election of the DAO, in (a) USDC or (b) XAND. If paid in XAND, the Security Council Member compensation shall be calculated on an as-converted to U.S. dollars basis, with such amount being the number of XAND that is the equivalent of USD $1,000, at a conversion price equal to the trailing seven (7) day time weighted average price of XAND recorded on https://coinmarketcap.com/. Any changes to the Security Council Member compensation shall be subject to approval by Tokenholders by Tokenholder Vote.

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.

3.1.6 Transitional Reaffirmation and Expansion Under XIP-0009

Upon passage of XIP-0009 and adoption of this Constitution v2.3, the three (3) individuals then serving as Security Council Members, whose identities are known to and verified by the Xandeum Foundation, are reaffirmed by Tokenholder Vote for a new twelve (12) month term effective immediately upon such passage.

Notwithstanding the minimum composition requirement stated in Section 3.1, the Security Council shall consist of those three (3) reaffirmed members upon passage of XIP-0009 and shall, within sixty (60) days of such passage, in coordination with the Xandeum Foundation, post a companion XIP to the governance forum to begin the required community discussion period for the affirmation of two (2) additional Foundation-vetted Security Council Members. The identities of those additional members shall be known to and held by the Xandeum Foundation in accordance with Section 3.1.5. The sixty (60) day deadline applies to the forum posting of the companion XIP, not to final vote completion. If the Security Council fails to submit the companion XIP within sixty (60) days, any Tokenholder meeting the proposal threshold in Section 6.1.3 may submit it on the community’s behalf.

This Section 3.1.6 is a transitional provision specific to the implementation of XIP-0009. Following that transition, Security Council elections, holdover service, and future reaffirmation cycles shall continue to be governed by Section 3.1.1 and the other applicable provisions of this Constitution.

4. Tokenholder Voting Matters

4.1 The Tokenholders have the authority to engage in the following activities:

  • 4.1.1 appoint or remove Security Council Members subject to the provisions of this Constitution;
  • 4.1.2 approve grants that further the purpose of the Governing Principals;
  • 4.1.3 approve changes to the parameters of the protocol; and
  • 4.1.4 any other vote that is lawful and consistent with the purpose of this Constitution.

5. DAO Governance Procedures

5.1 Xandeum Improvement Proposals (XIPs)

Xandeum Improvement Proposals (“XIPs”) are the primary mechanism for introducing, discussing, and implementing changes to the DAO’s governance and operations, and the Xandeum Network. XIPs serve as a means of fostering community discourse and decision-making within the organization. The XIP procedures consist of the following stages (the “Governance Procedures”):

5.1.1 Community Discussion

Ideas are discussed in a public governance forum (as designated by the DAO from time to time which initially shall be the website located at the following link: https://forum.xandeum.network) by the community, with the author addressing feedback, questions, and suggestions. Upon an author’s request, a DAO moderator (“DAO Moderator”) will confirm that an idea generally conforms to proposal guidelines (including that it fits within one of the categories initially enumerated below, which categories may be subject to further changes in accordance with a XIP related to the governance process). Once confirmed, and subject to the then applicable proposal threshold, the author(s) may move on to the next stage.

5.1.2 Proposal Drafting

Authors shall use the XIP outline below to write their proposal:

(i) Title and Category — The name must be descriptive enough to understand what is being suggested but no longer than 4 sentences. The category must be one of the following:

  • (A) Treasury (allocation of developer grants, funds, incentives, etc. from the DAO’s on-chain treasury (the “Realms Treasury”))
  • (B) Protocol Development (protocol upgrades via code contributions, developer relations and growth etc.)
  • (C) Structure (changes to committees, special working groups, existing/new positions)
  • (D) Process (changes to voting procedure, governance tools, guidelines, etc.)
  • (E) Operations (special initiatives relating to branding, marketing, and operations)

(ii) Abstract — A summary of the entire proposal, no more than a single paragraph.

(iii) Motivation — A statement on why the DAO should implement this proposal.

(iv) Key Terms — Definitions of terms specific to the proposal or industry related jargon.

(v) Specification — A detailed breakdown of what the proposal aims to change, the technologies/route of change needed to implement changes, and a concrete plan which outlines the steps and timeline required to make the change.

(vi) Benefits/Risks — A brief analysis of the benefits and risks involved with the proposal.

(vii) Outcomes — A brief summary of the desired goals and outcomes of the proposal.

(viii) Cost Summary — The total cost of the proposal, broken down if needed.

(ix) Performance Milestones, if applicable — The performance milestones for any XIPs submitted in the Treasury category.

The author should incorporate any feedback received from the community and may alter the template if absolutely necessary to communicate effectively. It is recommended that the DAO Moderator confirm that the draft conforms to the proposal guidelines (https://xandeum.network/docs/governance) before submitting the proposal and inform the Security Council. After the Security Council has confirmed proposals meet the above criteria, the proposal will be posted on Xandeum’s governance forum (https://forum.xandeum.network/) for community discussion.

Until a DAO Moderator is initially appointed by the Security Council and in the event that at any point in time there is no appointed DAO Moderator, the Security Council will perform these duties. If a Tokenholder does not meet the minimum token threshold for submitting proposals, they may work with someone who does to submit their proposal on their behalf. See https://xandeum.network/docs/governance for more details.

5.1.3 Proposal Discussion

Once proposals have been posted to the forum, they will initially stay open for community discussion for 30 days (the “Discussion Period”).

5.1.4 Proposal Submission

Proposals can be submitted to Realms (as defined below) after the Discussion Period is complete. Realms has a 17,500,000 XAND token minimum for proposals to be submitted from the community. Any Tokenholder who meets this proposal threshold may submit their proposal directly. If not, the Security Council can assist to have the proposal submitted on their behalf.

The Security Council will review the proposal for practicality and safety for the DAO once submitted and will ensure the proposal strictly adheres to applicable laws and regulations. The XIP release will take place on the DAO’s interface.

5.1.5 Voting

Tokenholders will be allowed to vote on XIPs for three (3) days (the “Voting Period”), followed by a two (2) day delay period (the “Delay Period”).

5.1.6 Implementation

Approved proposals will be treated differently based on the nature of the change. For those including on-chain executable code, these can be executed by anyone via the Realms interface immediately following the conclusion of the Voting Period and Delay Period.

For proposals requiring implementation by the DAO, the Security Council will work with the author, appropriate service providers of the DAO, and other parties as needed to execute the proposal. The Security Council will provide updates on Xandeum’s governance forum (https://forum.xandeum.network/) no less than every two weeks on the status of any such implementation.

5.1.7 Proposal Requirements

By submitting your XIP to vote in accordance with the Governance Procedures, you agree to submit your grant to certain conditions, including any requirements under applicable laws and regulations and AML/KYC processes deemed necessary or advisable by the DAO.

6. Proposal Guidelines

Proposals should not break any of the governing principles of the DAO (as set out in this Constitution) and all proposals must strictly adhere to applicable laws and regulations. Furthermore, any actions or initiatives proposed must be within the permissible bounds as set forth by the laws of the Republic of Panama, under which the DAO operates. Non-compliance or contravention of these legal parameters may result in the immediate rejection or invalidation of the proposal.

Proposals that do not adhere to these guidelines may not be considered or vetoed by the Security Council. It is essential to review and ensure alignment with the DAO’s governing principles and legal constraints before submission.

Voting Parameters

The initial voting parameters for Tokenholders is as follows, which may be subject to further changes in accordance with a XIP related to the governance process (the “Voting Parameters”):

  • 6.1.1 Voting Period: 3 days (Length of the period during which people can cast “Yes” or “No” votes)
  • 6.1.2 Delay Period: 2 days. The delay period takes place after the voting period has ended and before the proposal is executed. During the Delay Period, token holders can only vote against open proposals. “Yes” votes cast during the Voting Period can be switched to “No” votes during this period. Upon completion of the Delay Period, if the number of “No” votes is greater than the number of “Yes” votes, the proposal will not pass.
  • 6.1.3 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)
  • 6.1.4 Voting Threshold: 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.
  • 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.
  • 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.
1 Like
2

7. Implementation Period

7.1 On-Chain Actions

For programmatic changes, token holders can execute approved proposals instantly following completion of the Delay Period.

7.2 Off-Chain Actions

Due to the nature of off-chain actions, execution may not be immediate following the passing of a XIP. Certain off-chain actions may require Security Council approval, which may be vetoed in accordance with applicable law or for other reasons including inconsistencies with the DAO’s purpose as set out in the DAO’s constitution. If the DAO exercises veto authority, disclosure and explanation for the veto shall be posted on the relevant XIP within two weeks of the proposal’s passing.

7.3 Voting Power

One (1) XAND token equals one (1) vote over any proposals submitted to the DAO (the “Voting Power”). This will allow Tokenholders to participate in the governance process proportionally to their holdings.

The DAO, by Tokenholder Vote, may establish guidelines for evaluating and approving the inclusion of additional tokens in governance in the future.

Tokenholders have governance power over components of the Xandeum Network such as Realms Treasury management to allocate funds for community growth, protocol fee splits, stake pool fees, and other features including the ability to adjust the on-chain functions outlined at https://xandeum.network/docs/governance.

8. Amendments to Governance

The XIP procedures, Voting Parameters, Voting Power and all other governance mechanics can be amended or modified through XIP and a Tokenholder Vote. The above describes only the initial state of governance mechanics. The community is encouraged to decide the future state of governance, the DAO and the Xandeum Network.

8.1 Proposal Conflicts

Should a proposal be in direct conflict with a proposal presently under consideration for voting, the latter proposal ought to be held back from voting until a resolution is reached on the initial proposal. This is to prevent the endorsement of contradictory stipulations.

In the event that a proposal is in direct opposition to an already approved proposal or identical to a previously unsuccessful proposal, it is not permitted to proceed to voting until three months post the implementation of the original proposal. This measure is in place to prevent the squandering of community resources.

8.2 On-chain Realms

XIPs that can be executed on-chain will be submitted and implemented via the DAO’s Realms interface located at Realms (the “Realms”). XIPs that require allocations from the Realms Treasury may be executed via Realms.

8.3 Off-chain

XIPs that must be executed off-chain will also be submitted via the Realms interface. In the event that a XIP requires actions be taken by the DAO to execute, the Security Council will take such actions as needed to execute the XIP, while adhering to this Constitution.

9. Emergency Actions

The Security Council shall have a veto right on XIPs put forward by the Tokenholders if such XIP:

  • 9.1.1 violates any provision of this Constitution or any other document, policy or regulation as may be adopted by the DAO;
  • 9.1.2 violates any applicable law or regulation; or
  • 9.1.3 is detrimental to the interests of the DAO (as determined by the Security Council).

The Security Council must not use its power to perform such Emergency Actions except in a true security emergency, such as a critical vulnerability that could significantly compromise the integrity, confidentiality or availability of the Xandeum Network or the Realms Treasury.

After performing any Emergency Action, the Security Council must issue a full transparency report (at an appropriate time after the security emergency has passed) to explain what was done and why such Emergency Action was justified. The DAO is able to curtail or eliminate the Security Council’s power to perform Emergency Actions via approval and implementation of a XIP.

10. Non-Emergency Actions

For legal or other reasons, including inconsistency with the DAO’s purposes, the Security Council shall also maintain the ability to act outside of an Emergency Action pursuant to XIPs that have been approved by Tokenholders in accordance with the XIP Process to perform protocol improvements and adjustments to certain parameters including, without limitation XAND validator delegations or technical upgrades to programs critical to Xandeum Network’s operation.

During the first six months of the DAOs existence, the Security Council is also permitted to execute regular course transactions, within reason, including (i) Realms Treasury transfers for incentivizing the Xandeum Network’s growth, (ii) other de minimis payments not related to incentivizing the Xandeum Network’s growth, which shall not exceed 500,000,000 XAND or (iii) technical upgrades. This provides operational flexibility as Tokenholders organize around the XIP process.

Any such non-Emergency Action shall be communicated to the DAO by the Security Council in the form of updates at https://forum.xandeum.network. Notwithstanding the above, the Security Council shall act in good faith and in accordance with the purposes of the DAO as set out in the DAO’s constitution and applicable XIP.

11. Security Council Meeting Procedures and Frequency

11.1 Regular Meetings

Regular Meetings (as defined below) enable the Security Council to vote on XIPs and take any other acts within the Security Council’s authority.

11.2 Scheduling

The Security Council may convene every four (4) weeks, or at its discretion, subject to a reasonable amount of notice to Security Council Members (each, a “Regular Meeting”). A Regular Meeting may take place via telephone, videoconference, or through a group chat application.

11.3 Attendees

Only Security Council Members will be permitted to attend Regular Meetings, provided that the Security Council may permit any DAO Representative to attend Regular Meetings, and may provide the DAO Representatives with any and all information relevant to the business of a Regular Meeting. The invited DAO Representatives will not be counted towards the satisfaction of a quorum for a Security Council Vote.

A Security Council Member may invite a non-DAO Representative third party to observe or participate in Security Council discussion or to take notes of the Regular Meeting, subject to a simple majority vote of the other Security Council Members. The third party must be bound by a non-disclosure agreement with the DAO or with the member that invited the third party. The third party will not be counted towards the satisfaction of a quorum.

11.4 Quorum

A quorum of a Regular Meeting consists of at least 3 Security Council Members. A Regular Meeting may not proceed without a quorum.

11.5 Procedures for Review of XIPs

For XIP review procedures, the DAO will post to https://xandeum.network/docs/governance a DAO Governance Work Instruction to be mutually agreed by the DAO and the Security Council.

11.6 Procedure for Proposals from Security Council Members

Any Security Council Member may raise proposals for actions to be taken by the Security Council Members (a “Proposal”), among the Security Council Members, outside of Regular Meetings, in any written medium, including a Telegram chat. After a Security Council Member makes a Proposal, the Security Council should discuss the Proposal, giving sufficient time for dissenting views. Security Council Members should also describe any conflicts of interest. Security Council Members may request that any Proposals made outside of Regular Meetings be deferred to a Regular Meeting for a fuller discussion. The Security Council may choose to discuss such Proposal during the next scheduled Regular Meeting or to schedule a Regular Meeting more immediately. After a discussion, the Security Council will vote on the Proposal according to the voting procedure described below.

11.7 Meeting Notes

The Security Council may appoint a Security Council Member, DAO Representative, or an authorized third party to take notes of the Regular Meeting (the “Meeting Notes”). Meeting Notes may exclude the following topics, which may be discussed at a Regular Meetings from time to time:

  • 11.7.1 individual financial or investment positions of Security Council Members;
  • 11.7.2 unremedied security vulnerabilities affecting the Network, or other projects therein;
  • 11.7.3 DAO activities that are subject to non-disclosure agreements with third parties; and
  • 11.7.4 compensation information of Security Council Members and DAO Representatives.

Subject to a reasonable Security Council review and comment period chosen by the Security Council, Meeting Notes will be shared publicly with the community on Xandeum’s governance documentation page (https://xandeum.network/docs/governance).

11.8 Advisory Meetings

A portion of the Security Council may convene irregularly scheduled advisory meetings (“Advisory Meetings”). Advisory Meetings enable the Security Council to discuss a specific subject matter among a smaller group of Security Council Members. The same rules that apply to Regular Meetings will apply to Advisory Meetings, except that:

  • 11.8.1 there is no quorum requirement for an Advisory Meeting;
  • 11.8.2 no Security Council Member may introduce a Proposal or vote on any outstanding Proposal at an Advisory Meeting; and
  • 11.8.3 the Security Council may or may not publish Meeting Notes from Advisory Meetings, at its discretion.

11.9 Emergency Meetings

In response to an imminent security threat to the Xandeum Network or the Xandeum Network community, any protocol utilizing the Token, or the DAO, the Security Council may convene irregularly scheduled emergency meetings (“Emergency Meetings”).

The same rules that apply to Regular Meetings will apply to Emergency Meetings, except that:

  • 11.9.1 an Emergency Meeting does not need to be convened with reasonable notice to Security Council Members;
  • 11.9.2 there is no quorum requirement for an Emergency Meeting;
  • 11.9.3 the Security Council will not publish Meeting Notes from Emergency Meetings until the underlying security threat has been remedied or judged to no longer be a threat, in the Security Council’s sole discretion; and
  • 11.9.4 each member of the Security Council shall have one (1) vote in Emergency Meetings.

Schedule — Defined Terms

“Applicable Law” means the legal and regulatory requirements and obligations applicable to the DAO, including U.S. federal, U.S. state, and non-U.S. laws, as well as the relevant regulatory schemes.

“DAO Constitution” means this Constitution of the DAO as available at https://xandeum.network/docs/governance, as may be amended from time to time in accordance with this Constitution.

“DAO” means, collectively, the on-chain decentralized community of individuals or entities that own a Token.

“DAO Representative(s)” means the Security Council Members and any other individuals or entities formally authorized by the DAO to serve in an administrative, governance, engineering, legal, or other role established to serve the DAO.

“Network” means the decentralized Solana-based Xandeum protocol that enables dApp developers to natively achieve random access to a layer of exabyte-scalable storage buckets (the Xandeum buckets) as well as storage-enabled staking that enables stakers to participate in the extra rewards generated by storage-enables dApps.

“Security Council” means the council established in accordance with this Constitution to represent the Tokenholders.

“Security Council Member(s)” means the person or entity elected by the Tokenholders to, among other things, facilitate the implementation of XIPs or other matters as the Tokenholders may direct from time to time.

“Security Council Vote” means a vote of the Council Members in accordance with this Constitution.

“Token” means the governing token of the DAO, known as XAND, represented on the Solana blockchain.

“Tokenholder” means any holder of the Token.

“Tokenholder Vote” means a vote of the Tokenholders passed pursuant to a successful XIP in accordance with the XIP Process.

“XIP” means a Xandeum Improvement Proposal, which is a proposal put forth by a Tokenholder to a vote of the Tokenholders in accordance with the XIP Process.

“XIP Process” means the rules and procedures of submitting and voting on XIPs as described in this Constitution.

1 Like