[title] Heartbeat Credit System [path] Older Releases/v0.5 Ingolstadt/ # **Overview** pNodes are the core of Xandeum's network: they provide storage, handle data redundancy, and earn income proportional to contributions. Early adopters (e.g., Deep South era), NFT holders and devenet contributors will receive boosts. Rewards evolve from foundation-funded incentives to DAO-governed models, with storage income ("STOINC") as the long-term value driver once mainnet launches (targeted before end-2025). Key concepts interlink: **Heartbeats** contribute to performance scores, which factor into **credits**; credits determine shares of **rewards** and STOINC. All metrics aim to ensure network reliability, decentralization, and fair distribution. ## **1. Credits (Storage Credits)** :::Heading{depth="3" indent="1"} **Definition and Purpose** : ::: - Credits are a scoring metric used to calculate a pNode's share of network rewards and stoinc. They quantify a pNode's contribution based on factors like storage provision, performance, and stake. Credits ensure proportional earnings—higher credits mean a larger slice of total fees/rewards. :::Heading{depth="3" indent="1"} **Calculation Formula** ::: - Base Credits = (Number of pNodes) × (Total Storage Space Provided) × (Performance Score) × (Stake Amount in XAND). - Boosted Credits = Base Credits × (Geometric Mean of Boost Factors across all your pNodes). - If any factor is zero (e.g., no stake or zero performance), credits = 0, resulting in no earnings for that epoch (currently an epoch last two days). - Example: A wallet with 3 pNodes and 100,000 base credits, with boosts of 1.5x, 1x, and 2x, yields \~144,000 boosted credits (geometric mean \~1.44x boost). :::Heading{depth="3" indent="1"} **Role in Network** : ::: - Credits promote competition and reliability. They are tallied per epoch, with penalties for failures (e.g., -100 credits for incorrect/missed data requests). In the Ingolstadt release, credits incorporate heartbeat responses. This will be refined and include payload handling. :::Heading{depth="3" indent="1"} **Evolution** : ::: - Starts simple as part of the DevNet (e.g., heartbeat-based); becomes advanced in later eras. On mainnet, credits drive stoinc distribution from real app fees (e.g., Wikipedia/Uber-style dApps, AI/LLM governance tools). :::Heading{depth="3" indent="1"} **Boost Factors** : ::: - Multipliers to increase credits: - Era-Based: Deep South (16x/1,500% boost), South (10x), Mine (7x), Coal (3.5x), Central (2x), North (1.25x). - NFT-Based: Titan (11x/1,000% boost), Dragon (4x), Coyote (2.5x), Rabbit (1.5x), Cricket (1.1x). Titans were auctioned and added to a NFT store, allowing retroactive purchase for existing pNodes at \~4,410 USDC + 406,000 XAND (ends Nov 5, 2025, 1600 UTC). - Other: Xeno NFT (1.1x/10% boost for early owners). - An Alpha NFT will be introduced for early MainNet adopters. - Combined: e.g., Deep South (16x) + Titan (11x) = 176x total boost (17,500%). :::Heading{depth="3" indent="1"} **Thresholds** : ::: - Need \~80% of the 95th percentile credits (network average) to qualify for full rewards. Below that = zero for the epoch. ## **2. pNode Rewards** :::Heading{depth="3" indent="1"} **Types of Rewards** : ::: :::Heading{depth="3" indent="2"} **Fixed/Short-Term Rewards** : ::: :::Paragraph{listStyleType="circle" listStart="2" indent="2"} Foundation-funded incentives (e.g., 10,000 XAN/month per pNode in DevNet). Covers setup costs such as hosting fees. Paid quarterly (seasons); Season 4 ended \~Oct 2025. New seasons will require min performance (e.g., 80% of 95th percentile credits). These rewards are fied and not boosted by NFTs/eras. They are to reward DevNet operators and are "tiny" compared to STOINC. ::: :::Heading{depth="3" indent="2"} **Storage Income (Stoinc)** : ::: :::Paragraph{listStyleType="circle" listStart="4" indent="2"} This is not introduced in Ingolstadt, but the advances in this release are building towards STOINC implementation. ::: :::Paragraph{listStyleType="circle" listStart="5" indent="2"} This is for long-term, revenue-based earnings from MainNet app fees (94% of total fees go to pNodes after 3% Foundation and 3% preferred investors cuts). ::: :::Paragraph{listStyleType="circle" indent="3"} Formula: Total Fees × 94% × (Your Boosted Credits / Network Total Boosted Credits). ::: :::Paragraph{listStyleType="square" indent="3"} Proportional to credits; boosted heavily for early pNodes. ::: :::Heading{depth="3" indent="1"} **Eligibility and Payouts** : ::: :::Paragraph{listStyleType="circle" indent="2"} DevNet: There will be a limited number of pNodes, although not fixed it is estimated that this will be in the range (300-1,000). The initial 3 pNodes per wallet cap has been lifted. DevNet pNodes requires license which cost around 35K XAND as a protective fee and monthly hosting which are low \< $10. ::: :::Paragraph{listStyleType="circle" listStart="2" indent="2"} Mainnet: Permissionless, no licenses required with earnings payed in SOL. DevNet operators will recieve assistance fromthe Foundation in running MainNet pNodes. ::: :::Paragraph{listStyleType="circle" listStart="3" indent="2"} Governance Shift: Seasons 1-4 (completed) were managed by the Foundation; Season 5+ via DAO proposals/votes (XAND holders decide). Handover promotes decentralization with rewards now community-driven. ::: :::Paragraph{listStyleType="circle" listStart="4" indent="2"} Penalties: Downtime/failures reduce credits/rewards (e.g., missed heartbeats or requests). ::: :::Heading{depth="3" indent="1"} **Future Changes** : ::: :::Paragraph{listStyleType="disc" indent="2"} Post-North era (\~2026+), possible DAO-voted adjustments for decentralization (e.g., cap boosts/stake for large holders to favor smaller ones, like Solana's "super minority"). While early adopters will recieve advantages, the DAO may adjust these later on to assist the growth of the network ::: ## **3. Heartbeat** - **Definition**: Periodic liveness checks sent by Atlas (temporary centralized orchestrator) every 30 seconds to verify pNode uptime and responsiveness. Part of performance monitoring; will decentralize in later eras (e.g., validators challenge pNodes via Merkle proofs). - **Mechanics**: - Response: +1 credit per successful reply (max \~2880/day if 100% uptime). - Failure: No credit; repeated issues lead to eviction/redundancy failover (data replicated to other pNodes). - Integration: Factors into performance score begining with the Ingolstat release. This will later combined with payload requests (store/retrieve data: -100 credits for failures). - There is a modification to the existing pNode setup in that it requires some PORTS to be open; UDP 9001 open for gossip (pNode discovery); TCP 5000 for Atlas. There is no changes to the hardware requirements but of course needs stable internet and a static IP. - **Purpose**: Ensures network reliability; prevents bad actors (e.g., altered data detected via Merkle proofs—cryptographic hashes proving data integrity without revealing content). - **Evolution**: This started in the Herrenburg release with the introduction of gossip and pRPC for analytics; Ingolstadt advances it with metrics and credits; Stuttgart will add redundancy (e.g., apps choose 3-43x replication for fault tolerance). [title] Xandeum DAO Constitution v2.3 [path] / ## 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 [https://app.realms.today/dao/XAND](https://app.realms.today/dao/XAND). ## 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/](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 Principles; - 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](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](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/](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](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/](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. ## 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](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 [https://app.realms.today/dao/XAND](https://app.realms.today/dao/XAND) (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 DAO's 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](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](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 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](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](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-enabled 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. [title] Untitled [path] Operator Guides/ [title] What's new in Herrenberg [path] Older Releases/v0.4 Herrenberg/ ## State of Development Post-Herrenberg Building on Munich's operational pNode prototype, Herrenberg introduces advanced network features including a gossip protocol for dynamic pNode communication within pods, ensuring efficient data shard distribution and resilience through vNode monitoring. The pRPC interface enables programmatic access to storage via Xandeum Web3.js, simplifying sedApp development, while achieving full data reconstructability with erasure coding for exabyte-scale, tamper-proof reliability. Crude search capabilities add basic querying to storage buckets, and custom analytics expand insights into pNode performance, all supported by an updated GUI and security enhancements. - [Gossip protocol for dynamic pNode peer discovery and communication](docId\:oH38ZmOQcWGo3lOZN6ABo) - [pRPC interface for programmatic storage interactions](docId\:Y33rJCkzM_RkbSw-ueaMn) - [Full data reconstructability via advanced erasure coding](docId\:V4wDz4ys17QJgXOxME-46) - [Primitive search capabilities in the scalable storage layer](docId\:pbq8dxx9J8EUwPaEW8ISx) - Custom analytics for staker insights and performance optimization - Enhanced security and GUI for pNode management This continues Xandeum's commitment to solving the blockchain storage trilemma of scalability, smart contract native, and random access. Herrenberg marks a transformative step in Xandeum's South Era, redirecting pNode development toward robust network interconnectivity, data resilience, and streamlined tools for sedApp creators. By embedding analyzable frameworks for performance monitoring and system diagnostics, it enables seamless creation of storage-enabled dApps, addressing real-world needs like low-latency queries in decentralized environments. The release aligned with a high-stakes Dutch Auction, selling 52 Deep South pNodes to raise foundation funds and debut NFT multipliers boosting STOINC rewards up to 11x, empowering early operators with amplified earnings based on uptime and contributions. This not only motivates sustained participation but also establishes a solid base for Ingolstadt's performance-based reward mechanisms and Stuttgart's advanced redundancy protocols, ensuring fault-tolerant operations as Xandeum accelerates toward mainnet deployment in late 2025. [title] The blockchain storage trilemma [path] Getting Started/ The blockchain storage trilemma is a key challenge in decentralized systems, particularly for platforms like Solana, where traditional storage solutions often fail to balance three essential properties simultaneously: scalability, smart contract-native integration, and random access. Xandeum, a scalable storage layer built on Solana, is designed to solve this trilemma by enabling exabyte-scale storage that integrates seamlessly with smart contracts while allowing efficient, granular data retrieval. Below is a break down of each component of the trilemma and how Xandeum addresses it. ## 1. Scalability This refers to the ability to handle massive amounts of data without performance degradation or prohibitive costs. In blockchain contexts, storage often becomes a bottleneck as networks grow, limiting the size and complexity of applications (e.g., dApps struggling with large datasets like social media feeds or AI models). Xandeum tackles this by creating a scalable network of provider nodes (pNodes) that collectively offer exabyte-scale (and beyond) storage capacity. Through features like erasure coding (which splits data into redundant shards distributed across pods of pNodes), the system ensures tamper-proof, high-volume storage without relying on centralized servers, making it suitable for data-intensive Web3 applications. ## 2. Smart Contract-Native Integration Many storage solutions are bolted onto blockchains as separate layers, leading to inefficiencies, high latency, or compatibility issues when interacting with smart contracts. Smart contract-native integration means storage operations are inherently compatible and optimized for direct use within blockchain programs. Xandeum achieves this by extending Solana's ecosystem with tools like Xandeum Web3.js (an enhanced version of Solana's Web3.js library) and pNode-specific RPC interfaces. This allows developers to call storage primitives (e.g., upload, retrieve, or query data) directly from smart contracts, enabling seamless, high-performance interactions for storage-enabled dApps (sedApps) without intermediaries. ## 3. Random Access Traditional decentralized storage often operates at the file level, requiring full downloads to access specific parts of data, which is slow and resource-intensive. Random access enables quick, targeted retrieval of any data segment, similar to how traditional file systems work. Xandeum supports this through its pNode pod-based storage units (scalable, file-system-like structures) combined with features like crude search capabilities and gossip protocols for dynamic data distribution. This ensures low-latency queries and reconstructions, even in exabyte-scale environments, empowering applications like decentralized social platforms, AI governance tools, or research hubs where precise, real-time data access is crucial. ## Conclusion By resolving this trilemma, Xandeum positions itself as a foundational layer for Solana, fostering a more robust Web3 ecosystem. Its phased innovation eras (e.g., Deep South for foundational pNodes, South for prototypes like Munich and Herrenberg) progressively build toward mainnet readiness, with ongoing developments like reward tracking and redundancy further enhancing these capabilities. [title] Untitled [path] Operator Guides/ [title] Reconstructability [path] Older Releases/v0.4 Herrenberg/ ## Overview Herrenberg extends the Xandeum storage protocol with advanced erasure coding and distributed recovery mechanisms designed for reliability at scale. The system guarantees that all stored data can be reconstructed from available pod shards, even when individual pNodes are offline or permanently lost. Data is divided into mathematically reconstructable fragments, and pods coordinate through gossip-based metadata exchange to regenerate missing pieces as needed. This release builds on the foundation established by **Munich**. While Munich provided tamper-proof guarantees, Herrenberg introduces full reconstructability as a protocol-level feature. It has been validated in devnet environments using community-operated pNodes, confirming that data recovery remains consistent under real-world network conditions. For developers, Herrenberg defines the basis for exabyte-scale, fault-tolerant storage that integrates directly with Xandeum’s Web3 infrastructure. It improves reliability and reduces downtime across distributed workloads. The reconstructability model also supports **STOINC reward calculations**, ensuring that operator incentives are tied to verifiable data availability and sustained performance, including NFT-based multipliers. ## Description Herrenberg introduces a robust erasure coding architecture that extends Xandeum’s scalable storage protocol. Each dataset is divided into verifiable fragments, distributed across multiple pods to ensure that no single point of failure can compromise accessibility. When any pNode becomes unavailable, remaining nodes dynamically collaborate to reconstruct lost shards, guaranteeing seamless continuity of service. If one or more pNodes fail or go offline, pods automatically collaborate to regenerate missing data through gossip-based recovery coordination. This guarantees uninterrupted access, persistent data integrity, and resilience against network interruptions, all without the need for centralized control or redundant replication. ## Technical Details **Erasure Coding ****Model****:** Data is divided into *k* data shards and *m* parity shards. Any combination of *k* shards is sufficient to reconstruct the original data, ensuring robust redundancy and reliability. **Distributed Recovery:** Pod clusters exchange lightweight metadata through a gossip protocol, enabling automatic shard regeneration without centralized coordination or bottlenecks. This distributed recovery process is computationally lightweight and scales linearly with network size, supporting exabyte-scale storage systems while maintaining predictable latency and throughput. **Scalability:** The recovery process scales linearly with network growth, supporting exabyte-scale storage while maintaining consistent latency and throughput across the network. **Protocol Compatibility:** Herrenberg is fully compatible with existing Xandeum primitives. It seamlessly integrates with STOINC incentive mechanisms and NFT-based performance multipliers to align operator rewards with verifiable uptime and data availability. ## **Improvements Over Munich** - **From Integrity to Reconstructability** While the Munich release introduced tamper-proof guarantees through cryptographic verification, Herrenberg builds upon this foundation by adding **reconstructability as a native protocol feature**. - **Mathematically Guaranteed Recovery** In contrast to Munich’s reliance on redundancy for data persistence, Herrenberg ensures that **data recovery is mathematically guaranteed**, even in cases of multiple node failures, stored data can be regenerated from available shards using deterministic erasure coding. - **Real-World Validation** Preliminary testing in devnet with community‑operated pNodes suggests improved fault tolerance and recovery behaviour under variable network load. These advancements mark Herrenberg as a significant milestone in the Xandeum storage roadmap, delivering a self-healing, resilient, and production-ready infrastructure layer. ## Impact Herrenberg provides a foundation for data-intensive decentralized applications that demand continuous availability and integrity. The protocol reduces downtime, improves confidence in scalable storage reliability, and ensures that developers and users experience seamless data persistence. For operators, the protocol’s integration with STOINC readies **reward structures based on verifiable data availability** and sustained service performance. NFT-based multipliers further incentivize sustained performance, aligning long-term economic rewards with network stability objectives. By combining robust engineering with tokenized incentives, Herrenberg establishes a new standard for **fault-tolerant, reconstructable, and economically sustainable scalable storage** for the next generation of Web3 applications. [title] v0.7 Heidelberg [path] Older Releases/ # State of Development Post-Heidelberg Heidelberg (v0.7) advances Xandeum's South Era by introducing comprehensive paging statistics, enabling detailed monitoring and optimization of data pages in file systems. Building on Stuttgart's redundancy mechanisms and earlier prototypes, it focuses on analytics for page-level operations. These analytics provide insights into usage, retrieval efficiency, and storage health, helping pNode operators and sedApp developers make informed decisions. This release enhances mainnet readiness by integrating more robust metrics. These improvements support performance tuning and improve ecosystem scalability for smart contract-integrated file systems. ## Core Features - **Improved gossip timing**: Pods' gossip update frequency improved from 120 seconds to 400 ms, reducing latency in pNode discovery. - Also adds multiple open entrypoints, providing an extra layer of redundancy. - This improves the **gossip protocol** and prevents pNodes from failing to appear in the gossip list. - **Bug fixes**: such as correcting excessive outgoing packet size. - **Enhanced API**: e.g, addition of a detailed API call. ::::CodeDrawer{title="get-pods-with-stats" codeEditorData="[object Object]" responsesEditorData="[object Object]" isResponseExpanded="true" autoGeneratedAnchorSlug="get-pods-with-stats" legacyHash="dj8SMI7eHdPjsvhOj607L"} :::CodeblockTabsExamples ```curl curl -X POST http://localhost:6000/rpc   -H "Content-Type: application/json"   -d '{     "jsonrpc": "2.0",     "method": "get-pods-with-stats",     "id": 1   }' | jq . ``` ::: :::CodeblockTabsResponses ```javascript {         "address": "109.199.96.218:9001",         "is_public": true,         "last_seen_timestamp": 1765204349,         "pubkey": "2asTHq4vVGazKrmEa3YTXKuYiNZBdv1cQoLc1Tr2kvaw",         "rpc_port": 6000,         "storage_committed": 104857600,         "storage_usage_percent": 0.02486133575439453,         "storage_used": 26069,         "uptime": 3271,         "version": "0.7.0" }, ``` ::: :::: - **Analytics Enhancements**: Expands Pod Monitor with page-specific visualizations, including real-time stats on data paging, errors, and throughput. - Divert to a different port with a change to your **SSH script** e.g. ```bash ssh -i .ssh\MyKey -L 3000:localhost:3000 -L 4000:localhost:4000 -L 8000:localhost:80 root@ ``` ![](https://chat.google.com/u/0/api/get_attachment_url?url_type=FIFE_URL\&content_type=image%2Fpng\&attachment_token=AOo0EEWgBTmwSzFepDw2abIS0Sd3a%2Be%2FjwQFVTDfEM2u2S8C7ECv68ZDz0jZJ4Qm68WzrrtGlrZMrmNXyWZQdC510Z%2FwINwz5iYpzToRepUi4JYXs%2FKYMDDI6ovlGwUwiUune7Hxs3ZWFMlAom4Utc1uC0fds8k8kYRbnL1J%2BTR%2FPhuHqvcJ6XpqSBx0YrFcDl8KRkDyj1WgivUqI1CxpRWrgBNTAyfGFpzH%2F7wdJbWnlJZ%2Fds0gS5Bd29QpqfyssRJGLyHwYhgwnWS5mK5ow9WrkTBmAdM2IF7g%2FA8eUoC6uRyUD2geOABIIAcZfRnhmDc9HBn343tJbu4LN%2Fs4A3SbU%2BvL4QBP4NVntMooqt9G4p1u45gL7hDvLnXTpWfPOe3pTuxENRnz3sJJPh1yDZFWnMh3uFVrUoSIZ1ubo4nH9TeADI%2FfpHwYYmIA%2F2haNHRjFVcYoj9G07q%2FlH15g8npd6CNWbuQaNRsBP%2BnlZHe%2F2JbPQDlXdo66tCV2FqWMeohneYYrvXjvNDC8umCpQc9pqneFjeTbAei5dJ7PTH%2FpAIllM5aMo3rqlyDe5%2Bh5DCFVRRtIeM84gIzoyfVpg%3D%3D\&allow_caching=true\&sz=w512) ### What's New in Heidelberg **Paging stats** in Heidelberg provide granular insights into the handling of data pages within scalable file systems, enabling operators to monitor and optimize storage performance while adding visibility into how pages are accessed and managed across pNodes. The **Paging Statistics System** tracks page access frequency, **hit/miss rates**, replication status, and storage utilization per file system. These metrics are accessible through APIs and dashboards. **Performance Monitoring** introduces tools for querying paging stats, helping with redundancy set optimization and load balancing. **Optimization Tools** add multithreading for stats aggregation and basic alerting for anomalous paging behavior. **On-chain integration** which anchors key paging metrics for verifiable performance data, and ties them into STOINC calculations. ## pNode Rewards and Integration - Builds on Ingolstadt's credits: Improved monitoring boosts scores for XAND allocations (10,000 monthly via Foundation Program). - Analytics via Pod Monitor include paging dashboards and community tools. ## Summary Heidelberg (v0.7) advances Xandeum's South Era by introducing comprehensive paging statistics. This enables detailed monitoring and optimization of data pages in file systems. This release adds detailed metrics for page access patterns, hit and miss behavior, replication status, and storage utilization. These metrics are available through new and expanded API calls such as get-pods-with-stats, as well as through updated Pod Monitor dashboards. Together, they give operators clearer insight into how pages are being managed across the network. The release also improves core network behavior with significantly faster gossip propagation, multiple entrypoints for added redundancy, and several stability fixes. Pod environments now support improved monitoring and real-time visualizations. Heidelberg strengthens the operational foundation of the storage layer, supports more accurate performance tuning, and prepares the system for upcoming Main Era capabilities and the planned mainnet launch in late 2025. [title] v1.3 Cologne [path] Coming Next/ Please note this is a working document as we complete the Cologne release, information here is subject to change and we will be adding more sections to cover features. # Behind the Scenes From the outside it looks as if we have jumped from v0.8 Reinheim to v1.2 Bonn. In the background Xandeum has been developing the intervening releases. - **v0.9 Bamberg**: Improved redundancy statistics for apps and allows tracking of app-requested metrics. - **v1.0 Frankfurt**: Now shows redundancy stats and storage volume on a public page, which can be queried by community-developed support and management software. - Includes test crash tolerance. - An updated XandMiner. - An update to the pNode Portal. - [https://stats.xandeum.network/](https://stats.xandeum.network/) - **v1.1 Olef**: Introduces the ability to repair pages utilizing the power of the pNode network to reliably restore data. ## Mainnet Launch Update – January 2026 Xandeum mainnet launched on **December 31, 2025**, with the first pNodes coming online on **January 1, 2026**. As of January 2026, the network is live and stable, currently operating with community pNodes. ### Current Mainnet Access - **Official RPC**: Available at `api.mainnet.xandeum.network` (rate-limited). - **Community-operated RPCs**: Multiple independent, community-run endpoints are now live or coming online shortly, providing additional access options. ### Upcoming Mainnet Roadmap (Provisional) - **January 2026 (expected)**: Rollout of **STOINC** – storage income model where applications pay fees in SOL, distributed proportionally to pNodes. - **February 2026 (expected)**: Transition XAND staking from Realms DAO to direct on-pNode staking; introduction of **bonded pNodes** (slashable bond tier for higher rewards and accountability). - **Q3 2026 (expected, by end of September)**: Activation of **Byzantine Fault Tolerance (BFT)** for full unstoppable data guarantees, alongside supply/demand-based dynamic storage pricing. This phased approach ensures continued stability while progressively unlocking economic incentives and ultimate resilience for the scalable storage layer. # State of Development Post-Bonn Bonn (v1.2) marks a major milestone in operational maturity and production readiness for Xandeum's scalable storage layer. This release introduces Crash Fault Tolerance with automated eviction and data replacement for unresponsive pNodes, dedicated pod logging for improved diagnostics, and a full-featured pNode portal that enables secure owner-operator separation through Solana mainnet-signed transactions. Building on redundancy statistics, public metrics dashboards, and network-driven page repair from Bamberg, Frankfurt, and Olef, Bonn delivers significantly higher reliability, self-healing capabilities, and governance, enhancing mainnet operations in 2026. ## Core Features - **Crash Fault Tolerance (CFT)** Now includes an evict & replace protocol to manage low-performing or unresponsive pNodes and replace their data storage from other pNodes, allowing a pNode to automatically return to the network once it has recovered. - **Pod Dedicated Log Storage** Pod now has dedicated log storage. - **pNode Portal** A pNode portal has been introduced to support an owner-operator model and is supported through XandMiner. We have implemented a change from Solana devnet to mainnet so that wallets can sign transactions for: - register/update pNode - assign manager - create/update rewards account - register as pNode manager and update manager account details - update pNode manager account ## Summary Bonn (v1.2) significantly improves network reliability and operational control with automated Crash Fault Tolerance, dedicated logging, and a mainnet-enabled pNode portal supporting owner-operator governance. These advancements deliver self-healing storage, better diagnostics, and secure management, advancing Xandeum toward robust, production-ready mainnet operations in 2026. [title] Setup System Service [path] Operator Guides/vNode Guide/Validator Home/ :::hint{type="warning"} Run as `root` user, use `sudo -i` ::: Create your systemctl config file :::CodeblockTabs nano ```linux sudo nano /etc/systemd/system/validator.service ``` vim ```linux sudo vim /etc/systemd/system/validator.service ``` ::: Paste into editor, make any changes to ledger dir or $PATH if you have deviated from the guide. Save and exit. :::CodeblockTabs CLI ```linux [Unit] Description=Agave Validator After=network.target StartLimitIntervalSec=0 [Service] Type=simple Restart=always RestartSec=5 User=sol LimitNOFILE=2000000 LogRateLimitIntervalSec=0 Environment="PATH=/bin:/usr/bin:/home/sol/.local/share/xandeum/install/releases/active_release" ExecStart=/home/sol/validator-start.sh [Install] WantedBy=multi-user.target ``` ::: :::CodeblockTabs CLI ```linux sudo systemctl daemon-reload ``` ::: :::hint{type="warning"} Note: You will start the validator using Option 2 on the Starting your validator section later on in the guide. ::: Continue on to [Setup LogRotate](docId\:OLsHuypkjco2MYsxJL9P3) [title] Oxorro - FAQ [path] Coming Next/v1.3 Cologne/ ## What is Oxorro? Oxorro is a decentralized file storage application built on Xandeum’s storage layer for Solana. It gives users a familiar file-manager experience for creating file systems, uploading files, organizing folders, reading data, moving files, and connecting storage operations to smart-contract workflows. *** ## What is Xandeum? Xandeum is a decentralized storage layer for Solana. It gives Solana applications access to scalable, random-access storage, so apps can work with much larger amounts of data than they could store directly on-chain. *** ## What problem does Oxorro solve? Oxorro is built for operational data that needs to remain available, usable, and under the user’s control. It helps reduce reliance on centralized providers that can fail, delete accounts, restrict access, change policies, or become a single point of control. *** ## How is Oxorro different from traditional decentralized storage? Traditional decentralized storage is often closer to archive storage: you upload a file and retrieve it later. Oxorro is designed to work more like a real file system. Files can be organized, moved, deleted, and updated without treating every change as a completely new static upload. *** ## What is a file system in Oxorro? A file system is your storage space inside Oxorro. It contains your files and folders and is created through the **Big Bang** operation. *** ## What is Big Bang? **Big Bang** is the operation that creates a new Oxorro file system. Once the file system exists, you can start adding folders, files, and data to it. *** ## What is Armageddon? **Armageddon** is the operation that deletes or destroys a file system. It is the counterpart to Big Bang: Big Bang creates the file system, Armageddon removes it. *** ## What is `peek`? `peek` is the operation used to read or view data from a file system. It lets Oxorro retrieve data from Xandeum storage so it can be displayed or used by an application. *** ## What is `poke`? `poke` is a write operation. It is used to put data into Xandeum storage through the Solana-connected storage flow. *** ## What is `ingest`? `ingest` is the high-throughput upload path for larger files. Instead of pushing all file data through many small Solana transactions, `ingest` is designed to send larger amounts of data more directly into the Xandeum storage network. *** ## When should I use `ingest`? Use `ingest` for larger files or upload workloads where sending data through many Solana transactions would be slower, less practical, or more expensive. For smaller writes and normal file-system operations, `poke` may be the better fit. *** ## What are pNodes? **pNodes are provider nodes in the Xandeum network.** They provide storage capacity for the decentralized storage layer and help make Xandeum data available without relying on a single cloud company or server operator. *** ## What is redundancy? Redundancy controls how strongly data is protected across Xandeum’s decentralized storage infrastructure. Higher redundancy means the system has more protection against storage-provider failure. The available settings may depend on the current app configuration, so users should follow the options shown inside Oxorro when creating or managing a file system. *** ## Can Oxorro preview files? Yes. Oxorro can display common file types in a user-friendly way, including JSON files, CSV files, and image files such as PNGs. *** ## Can I create folders and move files? Yes. Oxorro supports folders, subfolders, and moving files through signed storage operations. *** ## What fees are involved? Oxorro uses Solana-connected storage infrastructure, so users should expect storage-related transactions and fees to use **SOL**. Some operations may involve Solana account costs as well as storage fees. The app will show the relevant transaction details before you confirm an operation. *** ## What RPC should I use? Oxorro will provide a list of supported RPC options inside the app. These may include foundation-provided access and partner RPC providers. For regular use, larger workloads, teams, or organization accounts, a partner RPC may provide the best experience. *** ## Is Oxorro available now? Oxorro is Xandeum’s first major user-facing storage application and is currently in an early-access phase. Selected organizations can request access through the Oxorro website. [title] Untitled [path] / [title] Onboard your pNode [path] Operator Guides/pNode Guide/Xandeum pNode Setup Guide/ Each pnode must be onboarded separatly using this form to be eligible for Devnet rewards. [https://pnode-onboarding.paperform.co/](https://pnode-onboarding.paperform.co/) [title] Install Validator Software [path] Operator Guides/vNode Guide/Validator Home/ How To Setup a Xandeum DevNet Validator (Build from source) =================== :::hint{type="info"} **NOTE:** This guide shows commands for text editors `nano` and `vim`. A quick search can find a guide or video to operate these text editors more efficiently and make your life easier. ::: ## ## 1) Installation of the needed binaries. Start with a fresh instance of Linux as the `root` user. These instructions use [Ubuntu Server 24.04LTS](https://ubuntu.com/download/server) :::hint{type="danger"} BEFORE YOU CONTINUE! Make sure you see your entire drive space as available! Use `df -h` to see your free space. You want to see that you have all your space in a free partition. Ubuntu will want to default to 100g LVM. The preferance is to eliminate LVM and Raid and use all available space for your `/` mount point. If you don't show all your disk space, run the Ubuntu installer again and pay attention to the storage section. ::: ### Get `root` user :::hint{type="warning"} Run as `sudo` or `root` user. If you don't have access to the root user, then you will need to prepend all your requests in this section with sudo. Notice in the screenshot below I start as user `sol` change to `root` user then back to `sol`. Root user has ALL the privledges and won't require sudo. But some items NEED to be ran as the `sol` user (ie rust install, validator build, etc) Use `sudo -i` to change to root user and `exit` to end root user ::: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/0naV05D9KRSBrRYLcDmc6_image.png) ### Update your installation :::CodeblockTabs CLI ```linux sudo apt-get update -y && sudo apt-get upgrade -y ``` ::: ### Install prerequestite packages :::CodeblockTabs CLI ```linux sudo apt -y install sudo curl git build-essential pkg-config libssl-dev libudev-dev zlib1g-dev llvm clang cmake make libprotobuf-dev protobuf-compiler tmux vnstat ``` ::: - Press OK to restart services if prompted ### Enable `vnstat` to monitor your bandwidth usage on your machine :::CodeblockTabs CLI ```linux sudo systemctl enable --now vnstat ``` ::: :::hint{type="info"} Note: research `vnstat` to find many different ways to view information on your bandwidth usage. ::: ### Create Xandeum Validator Account :::CodeblockTabs CLI ```linux sudo adduser sol ``` ::: :::hint{type="info"} Enter a password and accept defaults to the following questions: `New password:` ` Retype new password:` ` passwd: password updated successfully` ` Changing the user information for xand` ` Enter the new value, or press ENTER for the default` ` Full Name []:` ` Room Number []:` ` Work Phone []:` ` Home Phone []:` ` Other []:` `Is the information correct? [Y/n] y` ::: ### Add new user to sudo group :::CodeblockTabs CLI ```linux sudo usermod -aG sudo sol ``` ::: ### Change to the sol user account :::CodeblockTabs CLI ```linux su sol ``` ::: Switch the sol home directory :::CodeblockTabs CLI ```linux cd ~ ``` ::: ### ### Install Rust, Cargo, and restmft :::hint{type="warning"} Run as `sol` user without `sudo` privledges. ::: :::CodeblockTabs CLI ```linux curl https://sh.rustup.rs -sSf | sh ``` ::: - Take care to select option #1 when prompted to. ### Dont forget to set the source for .cargo :::CodeblockTabs CLI ```linux source $HOME/.cargo/env ``` ::: ### Add rustfm :::CodeblockTabs CLI ```linux rustup component add rustfmt ``` ::: :::CodeblockTabs CLI ```linux rustup update ``` ::: ### Set to compile using native cpu flags :::CodeblockTabs CLI ```linux export RUSTFLAGS="-O -C target-cpu=native" ``` ::: :::hint{type="warning"} ### Special Note: If you run into issues w/ Rust compiling, or if you receive `illegal instruction` errors upon starting your validator (usually only if running on a hypervisor), replace the export command with the export below: - This will generally impact Antsle owners (and some other Virtualization software/hardware) where CPUs will show up as Westmere E56xx/L56xx/X56xx (Nehalem-C) - Also if your cpu doesn't support AVX2 instruction set you may need this additional RUST Flag. Check if your CPU supports AVX2 using this command: `lscpu | grep --color=always -i avx2` and avx2 should show up in red if its supported. - May serverly limit efficiency of the binaries. ::: :::CodeblockTabs ONLY USE IF ON A SYSTEM WITHOUT AVX2 ```linux export RUST_REED_SOLOMON_ERASURE_ARCH=native ``` ::: ### Clone the Xandeum Validator Repo :::CodeblockTabs CLI ```linux cd ~ git clone https://github.com/Xandeum/xandeum-agave.git ``` ::: ### cd into new repo dir :::CodeblockTabs CLI ```linux cd xandeum-agave ``` ::: ### Choose which release you want to compile :::CodeblockTabs CLI ```linux git checkout v2.2.0-munich ``` ::: ### Build (compile) the validator software :::CodeblockTabs CLI ```linux ./cargo build --release ``` ::: :::hint{type="warning"} - `error: toolchain` can be ignored, missing toolchains will be installed. ::: :::hint{type="info"} - To use less processor, try adding jobs limit with ` -j 2` ::: :::hint{type="success"} - This process is going to take some time. Get a beverage, walk the dog, take the kids to the pool. 10-40 minutes typical depending on cpu. ::: *** ## ## 2) After build completes: :::hint{type="info"} Run as `sol` user in home dir (use `cd ~`) ::: ### Create directories and parent folders `-p` for the validator files :::CodeblockTabs CLI ```linux mkdir $HOME/data/compiled/x2.2.0-munich/bin/ -p ``` ::: ### Move the newly created binary (application files) to the appropriate release folder :::CodeblockTabs CLI ```linux cd ~/xandeum-agave/target/release ``` ::: :::CodeblockTabs CLI ```linux rsync -aHA ./ $HOME/data/compiled/x2.2.0-munich/bin/ ``` ::: ### Create symlinks (shortcuts) to the directories. This will allow us to change the version that is loaded by creating a symlink to a newer set of binaries :::CodeblockTabs CLI ```linux ln -sf $HOME/data/compiled/x2.2.0-munich/bin $HOME/data/compiled/active_release ``` ::: ### Verify the symlonk was created properly :::CodeblockTabs CLI ```linux ls -la $HOME/data/compiled/ ``` ::: ### Backup the old $PATH for reference. :::CodeblockTabs CLI ```linux echo $PATH >> ~/PATH.bak ``` ::: ### Using your favorite editor to open the bashrc config: :::CodeblockTabs nano ```linux nano ~/.bashrc ``` vim ```linux vim ~/.bashrc ``` ::: ### Add the following lines at the very bottom and save your changes and exit. :::CodeblockTabs text ```linux export PATH="$HOME/data/compiled/active_release:$PATH" alias l="ls -a --color=auto" alias ll="ls -alh --color=auto" alias sv="solana validators --sort skip-rate --reverse" alias sg="solana gossip" alias se="solana epoch-info" ``` ::: - Fully exit all shells and come back in. (logout / login to server) ### Check your Install of the software After logging back in as `sol` user, time to test if everything worked. - Check solana version: :::CodeblockTabs CLI ```linux cd ~ solana -V more accutatly, check the version of agave-validator client: agave-validator -V ``` ::: - Results should appear simlar to the following ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/pR92FqNOzhXFEEVVgymQX_screenshot-2023-08-18-230744.png" size="88" width="711" height="75" position="flex-start" darkWidth="711" darkHeight="75" showCaption="false"} :::hint{type="success"} If you are working on a virtual machine, now would be the ideal time to take a snapshot & backup your work just in case you have any issues beyond this point. It is also advisable for bare metal too. ::: *** ## ## 3) Configure your validator instance. :::hint{type="danger"} Please observe proper security of your private keys! Record your 12 words (and bip39 passphrase) in a safe spot. For DevNet it's not critical if you lose them...but if on MainNet, losing the keys equals LOST FUNDS. There is no recovering from lost keys. - For MainNet, your withdraw authority key should never be on your machine! ::: ### Generate your 3 DevNet keys. :::hint{type="info"} - You can leave the bip39 passphrase empty (only applies to DevNet/TesNet since it is not real money). - Your 12 words and pubkey are shown immediatly after the prompt for bip39 passphrase. - Take note of the public key it provides you (copy it down). It will help us help you should there be an issue. ::: :::hint{type="warning"} Run as `sol` user! ::: :::CodeblockTabs CLI ```linux mkdir ~/keys/ cd ~/keys ``` ::: :::CodeblockTabs CLI ```linux solana-keygen new -o ~/keys/validator-keypair.json solana-keygen new -o ~/keys/vote-keypair.json solana-keygen new -o ~/keys/withdraw-keypair.json solana-keygen pubkey ~/keys/validator-keypair.json ``` ::: To view your public key later :::CodeblockTabs CLI ```linux solana-keygen pubkey ~/keys/validator-keypair.json ``` ::: View your current configuration information :::CodeblockTabs CLI ```linux solana config get ``` ::: ### Switch to Xandeum cluster :::CodeblockTabs CLI ```linux solana config set --url https://api.devnet.xandeum.com:8899 ``` ::: ### Set your new keypair to be used by default. :::CodeblockTabs CLI ```text solana config set --keypair ~/validator-keypair.json ``` ::: ### Testing our work so far. - Check your connecrtion to the cluster ```linux solana gossip ``` - Request an airdrop from the Xand Faucet :::CodeblockTabs CLI ```linux solana airdrop 1 ~/validator-keypair.json ``` ::: Do this again 4 more times. (We are also giving you fake XAND/SOL to get started.) - There is a daily limit per wallet...These tokens on TestNet/DevNet are not real. ### Check your wallet balance. :::CodeblockTabs CLI ```linux solana balance ``` ::: You should have \~5 tokens present if you do it 5x's. ### Create your vote account. - Submit a transaction on the blockchain setting up your vote account :::CodeblockTabs CLI ```linux solana create-vote-account ~/vote-keypair.json ~/validator-keypair.json ~/withdraw-keypair.json ``` ::: To find your Vote Account Pubkey later, use: :::CodeblockTabs CLI ```linux solana-keygen pubkey ~/vote-keypair.json ``` ::: *** ## ## 4) Configure your Start Script Configuration ### Create your validator configuration file using your editor :::CodeblockTabs nano ```linux nano ~/validator-start.sh ``` vim ```linux vim ~/validator-start.sh ``` ::: - There will be nothing in here, so copy and paste in the following configurations. Save and Exit. :::CodeblockTabs text ```none #!/bin/bash exec solana-validator \ --known-validator HhuygLTeS6grue95pKKzak2UPuQMXepWbvQv2ToQfbZN \ --known-validator 6vy4sYV6nTLJQ4tBcXUGgPTuGorVh2FJkm6ToVMFSfr2 \ --known-validator CYQCxRcrSNg2XUiM42tp6bUtbWzZEdmTNawhBg5hSLoo \ --known-validator 3dZiYo933M7VftTSb7WudJV92cg69QwVYS1s753xRc59 \ --known-validator 2X8DQyB88vac5yZnkVzz6JxogWzSEhJBfNz7UHbQms1i \ --known-validator 2Ww2DYCYegUrwxC44funMmdp7Ttyu38jFvUUkrzyyLMw \ --entrypoint xand-1.devnet.xandeum.com:8000 \ --entrypoint xand-2.devnet.xandeum.com:8000 \ --entrypoint xand-3.devnet.xandeum.com:8000 \ --entrypoint xand-4.devnet.xandeum.com:8000 \ --expected-shred-version 46090 \ --expected-genesis-hash 9MJobEeGZJH9KjQNzMcRDuPNFUwJtAnBEEgpWgAgy4VL \ --snapshot-interval-slots 300 \ --full-snapshot-interval-slots 3000 \ --identity ~/validator-keypair.json \ --vote-account ~/vote-keypair.json \ --ledger ~/ledger/ \ --dynamic-port-range 8000-10000 \ --rpc-port 8899 \ --log ~/xand-validator.log \ --limit-ledger-size 50000000 \ # --expected-bank-hash 3UQBGcNj3s5jfGKVa1jhqyXyPv6anm4PADbZdMCKY3ht \ # --wait-for-supermajority 610426 \ # --no-snapshot-fetch \ # --no-genesis-fetch \ ``` ::: :::hint{type="warning"} **Note**: Every trailing `\` is important! Any commented lines `#` must be at the bottom of the script. This is to save a command that may be needed later but not used now. ::: :::hint{type="info"} **Note**: Change the location of `ledger` in the script to your second drive if you aren't using raid0 ::: :::hint{type="success"} Here are the known-validators: Xand1-known-validator HhuygLTeS6grue95pKKzak2UPuQMXepWbvQv2ToQfbZN \\ Xand2-known-validator 6vy4sYV6nTLJQ4tBcXUGgPTuGorVh2FJkm6ToVMFSfr2 \\ Xand3-known-validator CYQCxRcrSNg2XUiM42tp6bUtbWzZEdmTNawhBg5hSLoo \\ Xand4-known-validator 3dZiYo933M7VftTSb7WudJV92cg69QwVYS1s753xRc59 \\ t3chie-known-validator 2X8DQyB88vac5yZnkVzz6JxogWzSEhJBfNz7UHbQms1i \\ bernie-known-validator 2Ww2DYCYegUrwxC44funMmdp7Ttyu38jFvUUkrzyyLMw \\ ::: ### Make the script you just made executable. :::CodeblockTabs CLI ```linux chmod +x ~/validator-start.sh ``` ::: *** ## ## 5) System Tuning :::hint{type="warning"} Run as `root` user, use `sudo -i` ::: Optimize sysctl knobs (copy block and paste into teminal, press return) :::CodeblockTabs CLI ```linux sudo bash -c "cat >/etc/sysctl.d/21-solana-validator.conf </etc/security/limits.d/90-solana-nofiles.conf <` *** # Windows If you use a Windows PC, then you will need a terminal application such as PuTTY. You can learn about it on their website [putty.org](https://putty.org). You need to download the correct version for your machine...most likely this one (64-bit x86:[putty-64bit-0.79-installer.msi)](https://the.earth.li/~sgtatham/putty/latest/w64/putty-64bit-0.79-installer.msi) ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/QUkVKNOxk4a1ZI1R7mxLR_image.png" size="46" width="618" height="551" position="center" showCaption="false"} ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/9TKZR-wre1iOQFJ2YVQFZ_image.png) To access your server in PuTTY, you will enter `root@` into the Host Name field. [title] Faucet Repayment [path] Operator Guides/vNode Guide/ :::hint{type="info"} The Faucet is used to supply tokens for development and staking on our DevNet. They have no value. When you run a DevNet validator, you earn DevNet Tokens into your vote account. We would appreciate you repaying these back into the faucet so we can keep funding future projects on DevNet! We have 2 wallet accounts for the faucet. Use this to send some to your validator-keypair for voting fees too! Check out the "High Op-Sec option" below to test out having your withdrawal account removed from your machine! ::: :::hint{type="success"} - DevNet Faucet Addresses: - `BkFN8AC5aak9bXYxLLyXsUm1QJhbZh6aYEVHidJC3rs7` - `` ::: # DevNet Standard :::hint{type="info"} Run as `sol` user from the `/user/sol` directory ::: :::CodeblockTabs CLI ```linux su xand cd ~ ``` ::: Check your balance (yea, we wish it were real too!) :::CodeblockTabs CLI ```linux solana balance ~/vote-keypair.json ``` ::: If your withdraw key is stored on the machine (highly undesireable once we get to mainnet!) Send 1000 to your validator-keypair to pay for vote transactions: :::CodeblockTabs CLI ```linux solana withdraw-from-vote-account --authorized-withdrawer ~/withdraw-keypair.json ~/vote-keypair.json ~/validator-keypair.json 50 ``` ::: Send the rest of your DevNet earnings back to the faucet (don't worry, you will earn more!) :::CodeblockTabs CLI ```linux solana withdraw-from-vote-account --authorized-withdrawer withdraw-keypair.json vote-keypair.json BkFN8AC5aak9bXYxLLyXsUm1QJhbZh6aYEVHidJC3rs7 ALL ``` ::: # High Op-Sec option :::hint{type="info"} It would be worthwhile to figure these options out while on DevNet! ::: If your withdraw key is NOT stored on the machine, then use this. This will require you to input your 12 words (+bip39 passphrase if used). It may be most desirable to recover all keys needed to a secure local machine. :::CodeblockTabs CLI ```linux solana withdraw-from-vote-account --authorized-withdrawer ASK vote-keypair.json BkFN8AC5aak9bXYxLLyXsUm1QJhbZh6aYEVHidJC3rs7 ALL ``` ::: :::hint{type="warning"} NOTE: If you require more than one transaction with the recovered key, you may wish to temporarily recover the key to a file to process multiple transactions without requiring the 12 words each time. ::: Recover a keypair from seed phrase to json output file. Bip39 passphrase (if used) will be required after seed phrase is accepted. :::CodeblockTabs CLI ```linux solana-keygen recover -o temporary-key.json ``` ::: Withdraw from vote account using temporary withdraw keyfile and send back to faucet address. :::CodeblockTabs CLI ```linux xandeum withdraw-from-vote-account --authorized-withdrawer temporary-key.json vote-keypair.json BkFN8AC5aak9bXYxLLyXsUm1QJhbZh6aYEVHidJC3rs7 ALL ``` ::: :::hint{type="danger"} Don't forget to remove the temporary key from the machine so the two keys required to withdraw from your vote-account are not sitting side-by-side! ::: [title] Monitoring your validator [path] Operator Guides/vNode Guide/Validator Home/ # Tail your log file Watch the latest entries in your log file for errors. It moves fast...so may need to stop the tail and read before restarting. Here are several ways to run it. :::hint{type="info"} When the validator is first starting up, it asks the `entrypoint` in the start script "what IP address do you see me at?" Then it proceeds to ask the entrypoint if the required ports are open for it to use. This can be searched for during the startup sequence using the last tail option below that will grep 10 lines before and 50 after the search term to see if you are reachable. There is a ton of good connection debugging info in this search. See screenshot below. ::: :::hint{type="warning"} Run as `sol` user ::: :::CodeblockTabs CLI ```linux su sol cd ~ ``` ::: :::CodeblockTabs CLI ```linux tail -f ~/validator.log ``` ::: :::CodeblockTabs CLI ```linux tail -f ~/validator.log | grep "search terms" ``` ::: This will restart your validator then grep the log file for initial connection info: :::CodeblockTabs CLI ```linux sudo systemctl restart validator.service && tail -f ~/validator.log | grep --color=always -B 10 -A 50 "Checking that tcp ports" ``` ::: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/56jMMbbVixqAyEt8RMziI_image.png "Correct ports are reachable") # # mon.sh Create a `monitor` script to easily run the monitor command :::hint{type="info"} Run as `sol` user ::: Create a blank file named `mon.sh` in your home dir with editor. :::CodeblockTabs CLI ```linux cd ~ ``` ::: :::CodeblockTabs nano ```linux nano mon.sh ``` vim ```linux vim mon.sh ``` ::: Copy the code block into the file, correcting your ledger path if needed. Save and exit. :::CodeblockTabs CLI ```linux agave-validator --ledger ~/ledger monitor ``` ::: Make the file executable :::CodeblockTabs CLI ```linux chmod a+x mon.sh ``` ::: Run the monitor from home dir :::CodeblockTabs CLI ```linux cd ~ ./mon.sh ``` ::: :::hint{type="info"} NOTE: Press `enter` to drop a line to compare old values and press `ctrl+c` to exit the monitor command. ::: # catchup.sh Create a `catchup` script that compares your machine to the RPC that you are connected to. Create a blank file named `catchup.sh` in your home dir with editor. :::CodeblockTabs CLI ```linux cd ~ ``` ::: :::CodeblockTabs nano ```linux nano catchup.sh ``` vim ```linux vim catchup.sh ``` ::: Copy the code block into the file. Save and exit. :::hint{type="warning"} Note: if using the ALT method for catchup because localhost is not working for you...be sure to grab your validator ID pubkey using `solana-keygen pubkey ~/validator-keypair.json` ::: :::CodeblockTabs CLI ```linux solana catchup -k ~/validator-keypair.json --our-localhost --follow --verbose ``` ALT ```linux solana catchup --url https://api.devnet.xandeum.com:8899 --follow --verbose ``` ::: Make the file executable :::CodeblockTabs CLI ```linux chmod a+x catchup.sh ``` ::: Run the monitor from home dir :::CodeblockTabs CLI ```linux cd ~ ./catchup.sh ``` ::: :::hint{type="info"} NOTE: Press `enter` to drop a line to compare old values and press `ctrl+c` to exit the catchup command. ::: Watchtower :::hint{type="warning"} NOTE: `agave-watchtower` is an optional monitoring system **running on a separate computer** that will alert you in your own personal discord. Setup is required that is not shown in this guide. ::: :::hint{type="info"} Run as `sol` user without sudo ::: Watchtower should be ran from a remote computer that is running 24/7. It works by asking the RPC node if your Validator passes all the sanity checks. It can be added as a service or ran in a tmux window that never closes. You will need the software compiled to the point that `solana -V` works after a reboot. You will need to create a Discord or Slack channel with a webhook to make this work. Telegram, PagerDudy, and Twilio are also supported. This example script checks every `` seconds and alerts to Discord and Slack if `` number of failures show in a row\...ie 900 seconds Multiple scripts can be running with different `--validator-identity` and pumped into the same alert channel and use the `--name-suffix` to uniquely identify which machine is failing. :::hint{type="warning"} NOTE: If our RPC node goes down or is unreachable from your location...you will get false positives that your machine is down...this can be added if desired: `--ignore-http-bad-gateway` `Ignore HTTP 502 Bad Gateway errors from the JSON RPC URL. This flag can help reduce false positives, at the expense of no alerting should a Bad Gateway error be a side effect of the real problem` ::: :::CodeblockTabs nano ```linux nano watchtower-alerts.sh ``` vim ```linux vim watchtower-alerts.sh ``` ::: Add text to file and modify for your needs: :::CodeblockTabs text ```linux export DISCORD_WEBHOOK=https://discord.com/api/webhooks/xxxxxxx/yyyyyyyyyy export SLACK_WEBHOOK=https://hooks.slack.com/services/xxxxxxxxx/yyyyyyyy/zzzzzz #note for google spaces output, use the same format as slack but add double quotes, see below. export SLACK_WEBHOOK="https://chat.googleapis.com/v1/spaces/xxxxxxxxx/messages?key=yyyyyyyyyyy-yyyyyyyytoken=zzzzzzzzzzzzzzz" #! /bin/sh exec agave-watchtower \ --url https://api.devnet.xandeum.com:8899/ \ --validator-identity \ --name-suffix :::: \ --interval 300 \ --unhealthy-threshold 3 \ --minimum-validator-identity-balance 3 \ ``` ::: :::CodeblockTabs CLI ```linux chmod a+x watchtower-alerts.sh ``` ::: Run the script! You may want this running in a tmux session so it stays active when you close your teminal. [Learn Tmux](docId:4ivv9szuCMvtZAXZxUxhj) :::CodeblockTabs CLI ```linux ./watchtower-alerts.sh ``` ::: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/PqxUCTwyd5VdRxwma1um__image.png) From the script, we will see that 3 ERRORS in a row checked at 300 second intervals will trigger the alert to be sent to our Discord webhook. Consider next [Zabbix Installation](docId\:MLb0ziv_jx0kZbybDclo2) [title] Validator Home [path] Operator Guides/vNode Guide/ ![Xandeum Exabytes for Solana Programs](https://app.archbee.com/api/optimize/ePevXmvzgG-7aqJ72Gpg_/VDQyu5F-6c32A1aVQ67d3_logo.png) # Instructions for the installation and configuration of a Xandeum validator. ## Xandeum DevNet ### Based on Agave codebase** v2.2.0** :::hint{type="danger"} NOTE: NEW VERSION OF THIS GUIDE WILL BE COMING SOON! SOME SECTIONS ARE OUTDATED AND NOT RELEVANT. ::: Complete in order: - [Old Server housekeeping](docId\:mtDBFB19PE6hBSmwcBQyX) - [Access your server](docId\:Zfe1yVUNsXwBAs-gS62nZ) - [Ports Setup](docId\:j0pESfiSYOf0pOjvko-Mp) - [Setup Your Disks](docId\:pdGnCjvolHQmV1wGVCQ53) - [Validator Installation](docId\:A0DBbe-YQ--wWLU4Ojjfn) - [Setup System Service](docId:_z4VVag78Oly1DTLPVmmb) - [Setup LogRotate](docId\:OLsHuypkjco2MYsxJL9P3) - [Starting your validator](docId\:QT-gKqLryy-cYMxMcoZYe) - [Monitoring your validator](docId\:H7WUjkBUV1l28im8DQxRD) - [Onboarding](docId:13z9rNSejJ8SU0NCV5u2Z) - [Validator Commands](docId\:IZ8K2IUlzWiP78mLxBgE1) - [Learn Tmux](docId:4ivv9szuCMvtZAXZxUxhj) [Troubleshooting](docId\:T7w-jycONeX1Pe8ePlFIC) Update a running Validator: [Validator UPDATE version](docId\:Sf_gT0LbYBo9LL93wc2l7) vNode Xandeum-RPC upgrade guide (Coming Soon) [Enable Xandeum RPC functions](docId\:EgqaPduFHCbNuxMDdezT-) Faucet Repayment / Funding your ID Account - [Faucet Repayment](docId:6ZnCulKrlV9HONhhniS-s) [title] Validator UPDATE version [path] Operator Guides/vNode Guide/ :::hint{type="warning"} Run as `sol` user Sudo password may be required ::: Update your system installation :::CodeblockTabs CLI ```linux sudo apt-get update -y && sudo apt-get upgrade -y ``` ::: Reboot if you need to load a newer kernel. ## Choose which release you want to install Go to the Xandeum Binaries repo and download the `tar.bz2` file to your server. This guide is using version v2.2.0-xandeum\_**ca4fded3** You can right-click on the file name to copy the download link and do the upgrade manually if you want.[ ](https://github.com/Xandeum/binaries/releases)[https://github.com/Xandeum/binaries/releases/latest](https://github.com/Xandeum/binaries/releases/latest) Otherwise, set some variables and upgrade using our process below. ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/hHxpVz5RtyCKeOHKCbsdq_image.png) Set the version and filename variables, some versions are listed here: :::CodeblockTabs CLI ```none #latest release 06-18-2025 ver="v2.2.0-xandeum_b5a94688" file="v2.2.0-xandeum_b5a94688.tar.gz" echo -e "\n" echo version=$ver; echo filename=$file echo -e "\n" ``` ::: :::CodeblockTabs CLI ```linux cd ~ wget https://github.com/Xandeum/binaries/releases/download/$ver/$file ``` ::: Create the needed `bin` folder :::CodeblockTabs CLI ```linux mkdir ~/.local/share/xandeum/install/releases/$ver -p ``` ::: Extract the file into the new `bin` dir :::CodeblockTabs CLI ```linux cd ~ tar -xf $file --directory ~/.local/share/xandeum/install/releases/$ver ``` ::: Add a directory for connection info, and empty it if there is old files. :::CodeblockTabs CLI ```linux sudo mkdir -p /var/run/xandeum && sudo chown sol:sol /var/run/xandeum && sudo chmod 755 /var/run/xandeum sudo rm /var/run/xandeum/* ``` ::: Test a binary by running it in the local folder :::CodeblockTabs CLI ```linux cd ~/.local/share/xandeum/install/releases/$ver/bin ``` ::: Test a binary by running it in the local folder :::CodeblockTabs CLI ```linux ./agave-validator -V ``` ::: Check the version and src match your chosen version from above: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/QQMnfYQQd99S_REAGlZZG_image.png) Remove downloaded file if binaries are working :::CodeblockTabs CLI ```linux rm ~/$file ``` ::: ### Set our symlink to the new version Set a symlink from our new release to the active\_release folder we will use in our `$PATH` later. (This command removes an old symlink to `active_release` if it exists) :::CodeblockTabs CLI ```linux rm /home/sol/.local/share/xandeum/install/releases/active_release ln -sf /home/sol/.local/share/xandeum/install/releases/$ver/bin /home/sol/.local/share/xandeum/install/releases/active_release ``` ::: ### Check your Install of the software from the home dirctory to prove the symlink worked: As `sol` user, time to test if everything worked. - Check Xandeum Software Version: - Results should appear simlar to the following (check for correct version and src) :::CodeblockTabs CLI ```linux cd ~ agave-validator -V ``` ::: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/hKtWmAUbX5g9cxBksdN0q_image.png) ### Restart your validator If everyting looks good, restart your validator while delinquincy is below 10% and monitor until it is caught back up to the chain. If you have the system service set to `restart=always` , then you can use the validator exit command. The validator will restart as soon as it creates a snapshot and stops. ```bash agave-validator --ledger ~/ledger exit --max-delinquent-stake 10 --min-idle-time 0 --monitor ``` *** If you have issues, try looking here: [Monitoring your validator](docId\:MYh9NcGnA169K2hipDjBA) [Validator Commands](docId\:IZ8K2IUlzWiP78mLxBgE1) [Troubleshooting](docId\:x8Yesauj1rjaEmmnrp3tB) [title] Validator UPDATE version (Feb 2026 restart) [path] Operator Guides/vNode Guide/ :::hint{type="warning"} Run as `sol` user Sudo password may be required ::: Update your system installation :::CodeblockTabs CLI ```linux sudo systemctl stop validator.service sudo apt-get update -y && sudo apt-get upgrade -y ``` ::: Reboot if you need to load a newer kernel. ## Choose which release you want to install If you dont already have the repo and this is a fresh install, Go to the Xandeum Agave repo, use the instructions to build the software [https://github.com/Xandeum/xandeum-agave/tree/v3.0.14-upgrade](https://github.com/Xandeum/xandeum-agave/tree/v3.0.14-upgrade) Use `git checkout` after cloning to get the right branch of the Xandeum Agave in your local repo. ```bash git clone https://github.com/Xandeum/xandeum-agave/ cd xandeum-agave git checkout v3.0.14-upgrade ``` There are many ways to build the Agave Software. Your specific setup will determine many things, such as the $PATH you keep your files, and how you transition from one version to anouther, and wheter you keep an old version around or not for rollback. Use the instructions published by Anza to "Install from Source" published various places: [https://github.com/Xandeum/xandeum-agave/blob/v3.0.14-upgrade/docs/src/cli/install.md#build-from-source](https://github.com/Xandeum/xandeum-agave/blob/v3.0.14-upgrade/docs/src/cli/install.md#build-from-source) ## Instructions if using Agave-Maint-Util: A tool such as agave-maint-util published by t3chie-404 (Brad @Xandeum) can be used to help handle some of these functions for you. [https://github.com/T3chie-404/agave-maint-util](https://github.com/T3chie-404/agave-maint-util) This guide assumes you already have a working validator running and you have already used this agave-maint-util before. If you haven't, use the readme to get familiar and start by going through the system-tuner to set some important parameters and paths. ```bash cd agave-maint-util/ cat start-upgrade.sh ``` :::hint{type="warning"} **note the paths in the configuration settings at the top of the file (copy paste to notepad). They will be set to default when git stash / git pull are performed and will need to be put back how they were. A future release of agave-maint-util will have a proper .env file but has not been implemented yet.** ::: ```bash git stash git pull ``` :::hint{type="warning"} Next fix your paths in the start-upgrade.sh config section to match what you had. ::: Remove old Ledger ```bash rm ~/ledger/* -Rf ``` Fix cluster genesis and shred version...add these arguments to the file. ```bash vim ~/validator-start.sh New Cluster Info: --expected-shred-version 37688 \ --expected-genesis-hash 4Ag7HtMBo7XpYj5YZcSP3PeCwjcrQJuQhaVVgz2BGHnb \ Remove if its in your file: --no-snapshot-fetch \ ``` Full validator-start.sh **example file** from one of the Xandeum Nodes using only Xandeum known-validators. ```bash #!/bin/bash exec agave-validator \ --known-validator G6x4w89TJA9oDBSRNcpeanaThqBUJbEv5DJRBZGrQHYV \ --known-validator 5PW1SsXftQqKLF9FU88898BMG1vv3tqYRrVkGkFRwobs \ --known-validator 96wn2RrHFxXNMNJCN64qZCpBPCkHVTuKfWoeRTGrCdDy \ --known-validator DiEyTNni4uPwXaj9AX4pvFWvYFY5FKLEo3RRgN6Q22Lc \ --known-validator G5QXt6hybXuiHjaNVZqA5ccX9ysfLkzj2uzaJnnE5J94 \ --entrypoint xand-5.devnet.xandeum.com:8000 \ --entrypoint xand-4.devnet.xandeum.com:8000 \ --entrypoint xand-3.devnet.xandeum.com:8000 \ --entrypoint xand-2.devnet.xandeum.com:8000 \ --entrypoint xand-1.devnet.xandeum.com:8000 \ --expected-shred-version 37688 \ --expected-genesis-hash 4Ag7HtMBo7XpYj5YZcSP3PeCwjcrQJuQhaVVgz2BGHnb \ --snapshot-interval-slots 500 \ --full-snapshot-interval-slots 10000 \ --identity ~/validator-keypair.json \ --vote-account ~/vote-keypair.json \ --ledger ~/ledger/ \ --dynamic-port-range 8000-10000 \ --rpc-port 8899 \ --log /home/sol/data/logs/solana-validator.log \ --no-poh-speed-test \ --limit-ledger-size 30000000 \ ``` Next, ADD a parameter to validator.service file. In the \[Service] section make sure youhave these two parameters ```bash sudo vim /etc/systemd/system/validator.service LimitNOFILE=2000000 LimitMEMLOCK=2000000000 ``` Reload daemon ```bash sudo systemctl daemon-reload ``` Get branches on Xandeum Agave Repo ```bash cd ~/agave-maint-util/ ./start-upgrade.sh --list-branches xandeum ``` :::CodeblockTabs output ```bash --- Showing Available branches for variant: xandeum --- Using source directory: /home/sol/data/xandeum-agave Repository URL: https://github.com/Xandeum/xandeum-agave.git Source directory /home/sol/data/xandeum-agave already exists. Ensuring correct ownership of existing /home/sol/data/xandeum-agave for user sol... Fetching updates from remote origin... Newest 20 (approx) available branches (local and remote-tracking, sorted by most recent commit first): 2026-02-09 23:53:08 +0530 origin/v2.3.13-upgrade 2026-02-04 16:32:18 +0530 origin/rpc-fix 2026-01-29 12:37:06 +0530 origin/v3.0.14-stoinc 2026-01-14 12:21:10 +0530 origin/v3.0.14-upgrade 2025-11-26 11:41:02 +0530 origin/reinheim 2025-11-06 16:58:40 +0530 origin/upgrade 2025-10-31 00:40:44 +0700 origin/v0.3.9-agave 2025-10-08 11:01:05 -0700 origin/agave-v3.0.6 2025-09-19 19:20:53 +0530 origin/ingolstadt 2025-09-19 19:20:53 +0530 origin/xandeum-v3.0.6-upgrade 2025-09-19 16:42:14 +0530 x2.2.0-herrenberg 2025-09-19 16:42:14 +0530 origin/x2.2.0-herrenberg 2025-09-19 16:41:50 +0530 origin/perf-fix 2025-09-06 09:32:47 -0700 origin/fix/perf 2025-08-27 17:42:43 -0700 origin/delay-fix 2025-05-27 23:20:44 +0530 x2.2.0-munich 2025-05-27 23:20:44 +0530 origin/x2.2.0-munich 2025-05-20 19:14:48 +0530 origin/show-atals-rpc-api 2025-04-23 18:10:23 +0530 origin/x2.2.0 2025-04-07 12:19:45 +0530 origin/zmq-sockets ``` ::: :::hint{type="info"} In start-upgrade script: -j (--jobs) can be used to determine number of worker threads to build with. (It can also be set in the CONFIG section of the start-upgrade.sh file.) ::: ```bash cd ~/agave-maint-util/ ./start-upgrade.sh origin/v3.0.14-upgrade --variant xandeum -j 12 ``` :::CodeblockTabs output ```bash Build successful for origin/v2.3.13-upgrade. Creating directory for compiled version: /home/sol/data/compiled/origin_v2.3.13-upgrade/bin Syncing compiled binaries... Using build output from custom CARGO_TARGET_DIR: /tmp/cargo-target-1770689871/release Note: cargo-install-all.sh doesn't respect CARGO_TARGET_DIR, using actual build location Build complete. Check artifacts in /home/sol/data/compiled/origin_v2.3.13-upgrade/bin. Press Enter to update active_release symlink... ``` ::: Proceeding with symlink update... Backing up current symlink from /home/sol/data/compiled/origin\_v2.3.13-upgrade/bin to: /home/sol/data/compiled/active\_release\_20260212055648\_before\_upgrade Removing old symlink (if any remaining after backup attempt): /home/sol/data/compiled/active\_release Creating new symlink /home/sol/data/compiled/active\_release -> /home/sol/data/compiled/origin\_v3.0.14-upgrade/bin Verifying new version using binary from symlink (direct path)... Running: /home/sol/data/compiled/active\_release/agave-validator -V agave-validator 3.0.14 (src:aefe7c56; feat:3604001754, client:Xandeum) Ref used for this upgrade = origin/v3.0.14-upgrade (compiled into directory: origin\_v3.0.14-upgrade) Performing secondary verification (from home directory using system PATH)... Temporarily changed to directory: /home/sol Attempting to run: agave-validator -V (using existing system PATH) agave-validator 3.0.14 (src:aefe7c56; feat:3604001754, client:Xandeum) Secondary verification successful: 'agave-validator' found in system PATH. Secondary verification attempt complete. Verification step complete. Pausing before restart prompt... **At this point you can use ctrl+c to cancel...there is no need to restart when the validator is already stopped.** We are ready to start the validator again: ```bash sudo systemctl enable --now validator.service ``` Create your vote account: ```bash solana airdrop 1 ~/validator-keypair.json solana create-vote-account ~/vote-keypair.json ~/validator-keypair.json ~/withdraw-keypair.json ``` Watch Logs to see if you connect to the new cluster (\~2-3 minutes) Your vote account will be staked sometime after your vote account is created. Ping Brad in Discord Operations (vNodes) channel to ensure it is caught. *** If you have issues, try looking here: [Monitoring your validator](docId\:MYh9NcGnA169K2hipDjBA) [Validator Commands](docId\:IZ8K2IUlzWiP78mLxBgE1) [Troubleshooting](docId\:x8Yesauj1rjaEmmnrp3tB) [title] Xandeum pNode Network Port Requirements [path] Operator Guides/pNode Guide/ ## What this guide covers This page lists the current network ports and firewall checks required or recommended for Xandeum pNode operation. These examples are based on Ubuntu 24.04 LTS with UFW on a VPS. If you use a different setup, adjust the commands while preserving the required ports, protocols, and traffic direction. Please note that this guide focuses specifically on Xandeum pNode network requirements, not full VPS administration. The examples below are intended to help operators confirm the required ports and firewall posture for pNode operation. Operators remain responsible for their own server configuration, security, maintenance, backups, recovery access, and any other services they choose to run on the same VPS. Xandeum defines these requirements because insecure, unreachable, or misconfigured pNodes can affect pNode reliability, network security, network integrity, and reward-related operation. ## Scope This guide covers: - current Xandeum pNode port requirements; - required traffic direction and protocol; - example UFW commands for Ubuntu 24.04 LTS; - verification commands for checking firewall state; - SSH access considerations when changing firewall rules; - a known local port conflict that may affect VPS setups using both `pod` and `pod-manager`. This guide does not cover: - full VPS administration; - changing the SSH port; - SSH key setup; - password-authentication settings; - hosting-provider recovery procedures; - automated firewall reset or replacement scripts. ## Supported operating system The examples in this guide are based on Ubuntu 24.04 LTS with UFW. Check the operating system before applying firewall changes: ```bash cat /etc/os-release ``` If the VPS is not running Ubuntu 24.04 LTS, review the relevant setup requirements for your operating system and firewall tool before continuing. ## Current Xandeum pNode port profile The current Xandeum pNode network profile is: | Port | Direction | Protocol | Purpose | | -------- | -------------------- | -------- | --------------------------------- | | `5000` | Inbound | UDP | Atlas | | `9001` | Inbound and outbound | UDP | Gossip | | `6000` | Inbound | TCP | pRPC | | `7000` | Inbound and outbound | TCP | Ingest/Tap | | `7001` | Outbound | UDP | outbound pod-to-pod fanout | | `7002` | Inbound | UDP | inbound pod-to-pod fanout | | SSH port | Inbound | TCP | SSH access with UFW rate limiting | The SSH port is usually `22`, unless the operator has intentionally configured a different SSH port. Purpose labels are descriptive operational labels. If more precise service names are confirmed later, this table should be updated. ## Before changing firewall rules Firewall changes can interrupt access to a VPS if SSH access is not preserved. Before making changes: 1. Keep the current SSH session open. 2. Open a second SSH session and confirm it works. 3. Confirm the active SSH port. 4. Check the current firewall state. 5. Confirm that you can log in to your hosting-provider dashboard and that account recovery details are current. 6. If your provider supports snapshots or backups, take a fresh snapshot or backup before making significant firewall changes. Check the current UFW state: ```bash sudo ufw status verbose ``` `sudo ufw status verbose` is preferred because it shows both active rules and default policies, such as `deny incoming` and `allow outgoing`. ## Example UFW commands These commands are examples. Operators should review their current firewall state before applying changes, especially if the VPS also runs monitoring, dashboards, backup agents, support tooling, or other non-Xandeum services. Show current UFW status first: ```bash sudo ufw status verbose ``` ### SSH access rule Add SSH rate limiting for the active SSH port before enabling or tightening firewall rules. For the default SSH port: ```bash sudo ufw limit 22/tcp comment 'SSH access with UFW rate limiting' ``` If SSH has intentionally been moved to another port, replace `22` with the active SSH port. For example: ```bash sudo ufw limit 2022/tcp comment 'SSH access with UFW rate limiting' ``` ### Xandeum pNode rules Allow the current Xandeum pNode ports: ```bash sudo ufw allow 5000/udp comment 'Atlas' sudo ufw allow 9001/udp comment 'Gossip inbound' sudo ufw allow out 9001/udp comment 'Gossip outbound' sudo ufw allow 6000/tcp comment 'pRPC' sudo ufw allow 7000/tcp comment 'Ingest/Tap inbound' sudo ufw allow out 7000/tcp comment 'Ingest/Tap outbound' sudo ufw allow out 7001/udp comment 'Outbound pod-to-pod fanout' sudo ufw allow 7002/udp comment 'Inbound pod-to-pod fanout' ``` `9001/udp` and `7000/tcp` are listed twice because they are inbound and outbound requirements. In UFW, inbound and outbound rules are separate. For example, `sudo ufw allow 7000/tcp` allows inbound traffic to local port `7000`; `sudo ufw allow out 7000/tcp` allows outbound traffic to destination port `7000`. `7001/udp` and `7002/udp` are different because they have different directions in the current profile: `7001/udp` is outbound pod-to-pod fanout, while `7002/udp` is inbound pod-to-pod fanout. If your firewall uses the common default policy of allowing outgoing traffic, explicit outbound rules may already be covered. They are still shown here to document the full Xandeum traffic profile, especially for operators using stricter outbound policies. ### Default UFW policies Many operators use a default-deny inbound firewall policy, then explicitly allow only the inbound services they need: ```bash sudo ufw default deny incoming sudo ufw default allow outgoing ``` These default-policy commands do **not** delete existing UFW allow rules. If the Xandeum allow rules already exist, running these default-policy commands afterwards should not remove or disable those specific rules. However, default policies affect traffic that does not match an explicit rule. Before setting or changing default policies, make sure SSH and any other required services have explicit allow or limit rules. For example, `default deny incoming` is safe for Xandeum port `7000/tcp` only if the inbound `7000/tcp` allow rule exists. Similarly, `default allow outgoing` allows outbound traffic generally; explicit outbound rules for `9001/udp`, `7000/tcp`, and `7001/udp` document the Xandeum profile and remain useful for stricter firewall setups. Enable UFW only after confirming SSH will remain accessible: ```bash sudo ufw enable sudo ufw status verbose ``` ## Known local port conflict: pod-manager and port 7000 Port `7000/tcp` is part of the current Xandeum pNode network profile for Ingest/Tap traffic. Some VPS setups may also have `pod-manager` installed. If both `pod` and `pod-manager` are configured to use port `7000` on the same VPS, one service may fail to start or may prevent the other service from binding to the port correctly. Before changing firewall rules, check what is listening on port `7000`: ```bash sudo ss -ltnp | grep ':7000' ``` If `pod-manager` is using port `7000`, move the `pod-manager` server port to another unused local port, such as `7100`, so that `pod` can use port `7000`. The `pod-manager` configuration is commonly located at: ```text /root/pod-man/config.json ``` Preserve the existing JSON structure and change only the configured server or listen port. The exact key name may vary by installed `pod-manager` version. After changing the configuration, restart `pod-manager` and confirm it is running: ```bash sudo systemctl restart pod-manager sudo systemctl status pod-manager --no-pager ``` Then check port `7000` again: ```bash sudo ss -ltnp | grep ':7000' ``` If `pod` does not automatically take port `7000`, restart the relevant pod service according to the pNode setup used for that installation. Do not add the replacement `pod-manager` port, such as `7100`, to the public firewall profile unless your setup specifically requires external access to it. In many cases, a management port should remain local or be accessed through a controlled method such as SSH. ## SSH port note Moving SSH away from port `22` is optional. It may reduce generic port-22 scan noise and log clutter, but it should not be presented as meaningful security hardening by itself. It does not replace maintaining reliable SSH access, using appropriate authentication settings, applying firewall rate limiting, or keeping recovery access available. ## UFW rate limiting note UFW rate limiting helps reduce repeated SSH connection attempts from the same IP address. It does not inspect SSH login failures, usernames, passwords, or keys. It limits repeated connection attempts at the firewall level. This can help reduce noisy brute-force and bot activity, but it is not a full SSH security solution by itself. ## Avoid reset-based firewall instructions Do not use `ufw --force reset` as a normal public operator instruction. A reset can remove rules that the operator relies on for SSH, monitoring, backups, dashboards, support access, or other services. Even with rollback instructions, a reset can still cause lockout or downtime if SSH access is interrupted before the operator can recover. The safer default is: 1. show the current UFW state; 2. add only missing Xandeum-required rules; 3. preserve unrelated rules unless the operator has reviewed them; 4. manually remove legacy or unnecessary ports only when the operator understands the impact. ## Verification After applying changes, review the active firewall state: ```bash sudo ufw status verbose ``` Expected Xandeum-related rules should include: ```text 5000/udp ALLOW IN Anywhere # Atlas 9001/udp ALLOW IN Anywhere # Gossip inbound 9001/udp ALLOW OUT Anywhere # Gossip outbound 6000/tcp ALLOW IN Anywhere # pRPC 7000/tcp ALLOW IN Anywhere # Ingest/Tap inbound 7000/tcp ALLOW OUT Anywhere # Ingest/Tap outbound 7001/udp ALLOW OUT Anywhere # Outbound pod-to-pod fanout 7002/udp ALLOW IN Anywhere # Inbound pod-to-pod fanout SSH/tcp LIMIT IN Anywhere # SSH access with UFW rate limiting ``` IPv6 entries may also appear if IPv6 is enabled in UFW. ## Operator responsibility These are the current network ports and baseline firewall checks required or recommended for Xandeum pNode operation. VPS administration remains the responsibility of the operator. Operators should ensure their firewall policy does not break SSH access, hosting-provider access, monitoring, backups, or any other services they intentionally run on the VPS. Before making firewall changes, confirm that you can access your hosting-provider dashboard and that your account recovery details are current. If your provider supports snapshots or backups, take a fresh snapshot or backup before making significant firewall changes. ## Internal tooling note Xandeum may use internal helper tools for development, support, or diagnostics. Those tools are not part of this public guide. Operators should follow the port matrix and example commands above, and should review any firewall change before applying it to their own VPS. [title] pNode RPC [path] Older Releases/v0.4 Herrenberg/ ## **Overview** Herrenberg introduces a **Remote Procedure Call (RPC) interface** for pNodes, enabling external applications and smart contracts to interact directly with the storage layer. Unlike Solana’s standard RPC, this interface is **pNode-specific**, allowing queries for shard status, performance metrics, and designated pRPC functions. The RPC interface is fully integrated with **Xandeum Web3.js**, an extension of Solana’s Web3.js library. Developers can now invoke storage primitives directly from smart contracts, streamlining workflows for uploading, retrieving, or querying data within decentralized applications (sedApps). This functionality builds on Munich’s Pod Monitor GUI, which provided only visual analytics, by enabling **programmatic access** and integration with third-party analytics tools. The addition of RPC opens new possibilities for high-performance storage applications, custom monitoring platforms, and dynamic staker analytics. ## **Description** The pNode RPC provides a standardized, programmatic interface for interacting with pNodes. Core capabilities include: - Retrieving **pNode status** (uptime, storage usage, shard availability). - Accessing **data shards** for recovery or verification purposes. - Invoking **pRPC-specific functions** for advanced queries. By separating this interface from Solana’s native RPC, Herrenberg ensures queries are **tailored to pNode operations** while maintaining compatibility with Web3 development workflows. ## **Technical Details** - **Integration with Web3.js:** The RPC interface extends **Xandeum Web3.js**, allowing smart contracts and client applications to directly call storage primitives. - **Request Handling:** RPC supports efficient processing of upload, retrieval, and query requests, minimizing latency and computational overhead. - **Extensibility:** Developers can build custom analytics dashboards, monitoring tools, and high-throughput sedApps that leverage real-time pNode performance metrics. - **Security & Access Control:** RPC endpoints include authentication and rate-limiting mechanisms to ensure safe and reliable operation across decentralized nodes. ## **Improvements Over Munich** - **Programmatic Access:** While Munich provided basic analytics via the Pod Monitor GUI, Herrenberg exposes pNode metrics via RPC, enabling automated queries and third-party integrations. - **Enhanced Developer Workflows:** Integration with Web3.js reduces friction for sedApp development, supporting direct interaction with storage primitives from smart contracts. - **Real-Time Monitoring:** Developers and stakers can now monitor pNode health and storage performance programmatically, supporting optimized XAND staking strategies. ## **Impact** The pNode RPC empowers developers to create **high-performance storage applications**, such as decentralized file-sharing systems, research hubs, and collaborative content platforms. Stakers gain programmatic access to **pNode metrics** (e.g., uptime, storage efficiency), enabling data-driven decisions for XAND staking rewards. Community participation is encouraged, with plans for a **collaborative analytics dashboard** on xandeum.network, providing shared visibility into network performance and fostering transparency across the ecosystem. [RPC API Reference](docId:1pIQKxDlIlNF5TIRyzKsD) [What's new in Herrenberg](docId\:XxVyhaY2PPaB5DpODSuPL) [title] What is a Xandeum Pod? [path] Older Releases/v0.5 Ingolstadt/ ### Overview A **Xandeum Pod** (often just called "pod") is the **core software that runs on each pNode (provider Node)** in the Xandeum distributed storage network. Think of it as the storage node daemon/service. It handles key functions like data sharding via erasure coding, peer-to-peer communication through gossip protocols, and integration with pRPC APIs for programmatic access, enabling efficient, fault-tolerant storage for sedApps. With a CLI (pod) for quick starts, configuration (e.g., custom IPs/ports), and monitoring via a stats dashboard. The software powers features like the XandMiner GUI for pNode management, supporting STOINC rewards and network health tracking. ## 1. Core Purpose Pod software acts as the runtime for pNodes, coordinating data distribution across pods to ensure tamper-proof, reconstructable storage without centralization. It offloads data from Solana validators, making it ideal for high-throughput Web3 apps like decentralized social platforms or AI tools. ### What Pod Does The main purpose of the pod is **Storage Management** where it stores and retrieves data in the distributed network. The pods participate in **Networking **by enabling communicates with other pNodes. Providing JSON-RPC **API** they allow monitoring and interaction with other pods. They synchronise with the central **Atlas** server for network state, and ensure the status of the network through **Performance Tracking** where they monitor CPU, RAM, storage, and network metrics. ## 2. Key Components - **CLI Interface**: Simple commands for; version checks, isolated testing, and flags for RPC/Atlas customization. - **Networking**: Uses gossip for peer discovery and heartbeats (every 30s) to maintain rewards eligibility. - **Integration**: Powers XandMiner for GUI monitoring, with JSON-RPC endpoints (e.g., /rpc on port 6000) for stats like CPU/RAM/uptime and peer lists. - **Security**: Emphasizes non-standard ports and firewall configs for resilient operations. ## 3. Installation and Usage - Install via apt from Xandeum's repo; run with defaults for local DevNet. - Advanced: Daemonize with systemd for 24/7 uptime, crucial for STOINC (e.g., amplified by NFTs up to 11x). - Testing: Includes curl examples for RPC health checks and troubleshooting for common errors like port conflicts. ## Conclusion As a foundational piece of Xandeum's ecosystem, Pod software empowers community operators to build and earn. [title] What's new in Ingolstadt [path] Older Releases/v0.5 Ingolstadt/ ## State of Development Post-Ingolstadt Ingolstadt (v0.5) marks a critical advancement in Xandeum's South Era, shifting focus to sophisticated reward tracking and performance-based incentives for DevNet pNodes, building on Herrenberg's connectivity foundations, it introduces credit systems for heartbeats (e.g., +1 per successful 30s signal, -100 on failures) and allocates 10,000 XAND monthly to top performers, this contributes to the STOINC calculations. This fosters fair, data-driven delegation via the Foundation Program, positioning Xandeum closer to mainnet by emphasizing reliability metrics like uptime and efficiency. ## Core Features - [Heartbeat Credit System](docId\:nFcCkdZ4JM_BeotCMK3jy): +1 credit per success, -100 on failures, with monthly rollovers for seasonal fairness. - **Monthly XAND Rewards**: 10,000 distributed to high-credit pNodes. - **Delegation Optimization**: Enables stakers to query metrics for informed XAND allocations. - **Integration with Analytics**: Ties into Pod Monitor for performance dashboards, supporting community-built tools. - [Xandeum Pod Software](docId\:PZBErs_yDv2XyevJY-7B7) This release continues Xandeum's development of a scalable, community-owned storage layer for Solana, driving toward intelligent, incentive-aligned operations. ## **SUMMARY** The Ingolstadt release (v0.5) in Xandeum's South Era advances toward mainnet by introducing reward tracking and performance incentives for DevNet pNodes. Heartbeat Credit System is the Key: +1 credit per successful 30-second check (up to \~2,880 daily at 100% uptime), -100 for failures, with monthly rollovers and 10,000 XAND distributed to top performers. It enables metric-based delegation via the Foundation Program, boosting STOINC via era multipliers (e.g., 16x Deep South) and NFTs (e.g., 11x Titans). Enhancements include Pod Monitor dashboards, community tools, and Xandeum Pod software. [title] Search Capabilities [path] Older Releases/v0.4 Herrenberg/ ## **Overview** Herrenberg introduces **basic search functionality** for Xandeum’s scalable storage units, enabling users and developers to query and retrieve data without scanning entire datasets. This initial implementation is designed for **efficiency and quick lookups**, integrated with the pNode RPC (pRPC) interface to support rapid data retrieval within sedApps. While Munich provided file hosting capabilities, it lacked any querying mechanism. Herrenberg’s search features make storage **dynamic and programmable**, enabling new use cases and enhancing the usability of stored data for decentralized applications. ## **Description** The Primitive Search Capabilities allow developers and sedApps to: - Perform **targeted queries** across stored datasets. - Retrieve relevant results without performing full dataset scans. - Access search functionality via the **pRPC interface**, enabling integration with smart contracts and client applications. This lays the groundwork for more sophisticated search and indexing mechanisms in future protocol updates. ## **Technical Details** - **Initial Implementation:** Focused on lightweight, high-efficiency queries suitable for low-latency applications. - **pRPC Integration:** Search queries are executed through the pNode RPC interface, allowing sedApps to perform programmatic lookups. - **Scope:** The current release supports basic keyword matching and dataset filtering; advanced features like full-text indexing, ranking, or semantic search are planned for future iterations. - **Performance Considerations:** Optimized for rapid retrieval on large datasets while minimizing computational and network overhead. ## **Improvements Over Munich** - **Dynamic Data Access:** Munich allowed storage and retrieval but did not support querying. Herrenberg introduces programmatic search for faster, targeted access. - **Integration with Developer Tools:** pRPC integration allows developers to access search functions directly from smart contracts or client applications. - **Foundation for Advanced Features:** This initial release sets the stage for future search capabilities, including indexed and semantic queries, without redesigning the storage layer. ## **Impact** The new search functionality enhances **sedApp development**, supporting applications like content platforms, decentralized databases, and research hubs that require targeted access to stored data. By enabling **low-latency, random-access queries**, this release aligns with Xandeum’s goal of providing efficient, scalable storage on Solana. It also opens opportunities for community-driven enhancements and advanced analytics in future protocol eras. [title] v0.4 Herrenberg [path] Older Releases/ ![Xandeum Exabytes for Solana Programs](https://app.archbee.com/api/optimize/ePevXmvzgG-7aqJ72Gpg_/VDQyu5F-6c32A1aVQ67d3_logo.png) # Overview This page provides an overview of the Herrenberg release in Xandeum's South Era, including pre and post development states, newly introduced and enhanced feature. Greater detailed is given in dedicated sections. ::::LinkArray{contentSource="CUSTOM"} :::LinkArrayItem [What's new in Herrenberg](docId\:XxVyhaY2PPaB5DpODSuPL) Key advancements introduced in Herrenberg, building on Munich's foundation. ::: :::LinkArrayItem [Foundation - pre Herrenberg](docId\:T9UE30yv_ym3fwbnXpeg_) Summary of the project's state leading up to Herrenberg. ::: :::: ## Enhanced functionality Herrenberg shifted focus to enhanced communication, reliability, and tools for sedApps. The Gossip Protocol uses Erasure coding it to distribute data shards among pods for resilient, global-scale storage. A core outcome of Erasure Coding is Xandeum's Full Data Reconstructability, enabling 100% data recovery from distributed shards, even in failures. ::::LinkArray{contentSource="CUSTOM"} :::LinkArrayItem [Gossip Protocol](docId\:oH38ZmOQcWGo3lOZN6ABo) Xandeum's Gossip Protocol enables decentralized pNode scalable file systems to dynamically discover peers and share real-time updates on data health, performance, and erasure-coded shards for resilient, tamper-proof storage on Solana. ::: :::LinkArrayItem [Reconstructability](docId\:V4wDz4ys17QJgXOxME-46) Full Data Reconstructability uses advanced erasure coding to enable complete recovery of stored data from distributed pod shards, even amid pNode failures, for resilient exabyte-scale storage on Solana. ::: :::LinkArrayItem [pNode RPC](docId\:Y33rJCkzM_RkbSw-ueaMn) Xandeum's pRPC is a tailored RPC interface for pNodes, enabling storage layer interactions like status and shard queries, distinct from Solana's RPC, to streamline sedApp building via Xandeum Web3.js. ::: :::LinkArrayItem [Search Capabilities](docId\:pbq8dxx9J8EUwPaEW8ISx) Herrenberg adds search capabilities which enable basic, efficient querying of scalable storage units via pRPC, allowing data retrieval without full dataset scans for sedApps on Solana. ::: :::: *** ## Herrenberg Summary Herrenberg represents a pivotal milestone in Xandeum's South Era, advancing pNode capabilities with enhanced communication, reliability, and developer tools. This release introduces interconnected, analyzable systems to support storage-enabled dApps (sedApps), while the concurrent Dutch Auction of 52 Deep South pNodes and NFT multipliers (up to 11x) for STOINC rewards drive operator incentives and fund progress toward Ingolstadt's reward tracking and Stuttgart's mainnet redundancy. ## Additional Enhancements and Community Focus Herrenberg also updates the web GUI, improving pNode oversight and providing real-time visibility into pNode performance.  Emphasis is placed on security best practices (non-standard ports, SSH key-only access). The groundwork is now done to enable data-driven delegation of XAND tokens through the Foundation Delegation Program. Overall, these features position Xandeum as a robust Minimum Viable Product (MVP) for testing.  This release not only boosts technical capabilities but also fosters ecosystem growth, with potential for future auctions and dApps like LLM integrations. This release continues addressing the blockchain storage trilemma and positions Xandeum for future milestones like Engold and Stodgard. [title] Original Xandeum Whitepaper [path] Core Concepts/ ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/VDQyu5F-6c32A1aVQ67d3_logo.png) Here you can find the original Xandeum Whitepaper. We have evolved some ideas and concepts and completly changed some others (such as originally being visioned as an L1 Blockchain). This represents our roots and our vision to transform how we can use Blockchain! [https://github.com/Xandeum/WhitePaper](https://github.com/Xandeum/WhitePaper) [title] pNode UPDATE version [path] Operator Guides/pNode Guide/Xandeum pNode Setup Guide/ Connect to your pNode via SSH, forwarding the proper ports into the localhost of the pNode. If you're using windows, you'll use `cmd.exe` or `power shell` , use this format: ****Be sure to verify the location of your SSH identity file and public IP address.**** :::CodeblockTabs CLI ```linux ssh -i "C:\path to ssh key\id_ed25519.pub" root@ -L 4000:localhost:4000 -L 3000:localhost:3000 -L 8000:localhost:8000 ``` ::: If using Mac terminal or Linux, use this format: ****Be sure to verify the location of your SSH identity file and public IP address.**** :::CodeblockTabs CLI ```linux ssh -i ~/.ssh/id_ed25519 root@ -L 4000:localhost:4000 -L 3000:localhost:3000 -L 8000:localhost:8000 ``` ::: Run the newest version of the `install.sh` script, and use Option 2 to Upgrade: :::hint{type="warning"} Run as `root` user use `sudo -i` to change to root user Sudo password may be required ::: :::CodeblockTabs CLI ```linux wget -O install.sh "https://raw.githubusercontent.com/Xandeum/xandminer-installer/refs/heads/master/install.sh" && chmod a+x install.sh && ./install.sh ``` ::: ::::hint{type="success"} :::BlockQuote After running Option 2, Wait for the completion messages. It may take several minutes and will look like this when done: Xandminerd Service Running On Port : 4000 To access your Xandminer, use address localhost:3000 in your web browser Setup completed successfully! Upgrade completed successfully! Restarting Xandeum service... Service restart completed. ::: :::: Go to your local web browser and check your xandminer status in the web GUI :::CodeblockTabs CLI ```linux http://localhost:3000/ ``` ::: A completed upgrade will show the correct versions, see screenshot: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/1gZJMHyvbN5TB2KUb3zDp_image.png) Congratulations, you completed the upgrade! :::hint{type="warning"} Check your pNode is accessible on the correct ports here: [https://pnodes.xandeum.network/#nYHpd](https://pnodes.xandeum.network/#nYHpd) ------------------------------------------------------------------------------------ ::: ***Don't forget to enable storage by using the "Dedicate and Earn" button!*** *** [title] Erasure Coding [path] Older Releases/v0.4 Herrenberg/ ### Where Erasure Coding Fits in Herrenberg Erasure coding in Xandeum's Herrenberg release (v0.4.0) enables redundant, fault-tolerant data storage by splitting data into shards with parity info, allowing full reconstruction even if some shards are lost. It integrates with the new gossip protocol to distribute these shards across pNode "pods," ensuring tamper-proof, scalable storage coordination. Erasure coding is directly involved with the Gossip Protocol, as the protocol uses it to distribute data shards among pods for resilient, global-scale storage. A core outcome of erasure coding is Full Data Reconstructability, enabling 100% data recovery from distributed shards, even in failures. ### What is Erasure Coding? Erasure coding is a data protection technique that adds redundancy to original data by splitting it into fragments (shards), encoding them with parity information, and distributing them across multiple locations. This allows reconstruction of the full data even if some shards are lost or corrupted, similar to RAID systems but more efficient for distributed networks like blockchains. It's based on error-correcting codes (e.g., Reed-Solomon) and provides fault tolerance without full duplication, balancing storage costs and reliability. ### Erasure Coding in Xandeum Xandeum uses erasure coding to enable scalable, redundant storage on Solana, splitting data into pages and distributing encoded shards across pNodes (provider nodes) for exabyte-level capacity with blockchain-grade integrity. Here's a breakdown: - **Data Splitting and Encoding**: Data is divided into fixed-size pages (e.g., optimized for Solana's transaction limits), then encoded using erasure codes like Reed-Solomon generalizations. This creates data shards plus parity shards, allowing reconstruction from a subset (e.g., tolerate up to a configurable number of failures). - **Configurable Redundancy**: Users set redundancy levels (e.g., 1.5x to 3x overhead), determining how many extra parity shards are generated. This stores data on a subset of pNodes rather than all validators, optimizing costs while ensuring availability—e.g., recover from 30-50% node failures without data loss. - **Distribution Across pNodes**: Encoded shards are spread across decentralized pNodes in "pods," using gossip protocols for coordination. This offloads storage from Solana validators (vNodes), which supervise via cryptographic proofs. - **Security and Integrity**: pNodes generate Merkle proofs for tamper-proofing; vNodes verify using Threshold Signature Schemes (TSS). Combined with Solana's PoH, this ensures data can't be altered undetected. - **Availability and Reconstruction**: Supports primitives like Poke (store), Peek (retrieve), and Prove (verify). Data is highly available without full replication; e.g., reconstruct from any sufficient shards, even in partial network failures. - **Integration with Solana**: Erasure coding ties into Solana transactions for on-chain access, with fees in SOL funding the ecosystem. It's designed for sedApps (storage-enabled dApps), enabling low-latency operations at scale. *** For implementation code or deeper math, refer to Xandeum's GitHub repos or whitepaper for Reed-Solomon specifics. [title] Xandeum's scalable storage solution [path] Getting Started/ Xandeum's scalable storage solution is a scaling innovation designed specifically for the Solana blockchain, enabling exabyte-scale data storage that supports high-performance, data-intensive decentralized applications (dApps) without compromising on decentralization or efficiency. It addresses the limitations of traditional blockchain storage, where data is often expensive, slow, or reliant on centralized providers, by creating a global network of community-operated nodes that integrate seamlessly with Solana's smart contracts. This allows developers to build "storage-enabled dApps" (sedApps) for use cases like decentralized social platforms, AI governance tools, research hubs, or file-sharing systems, all while maintaining low-latency access and security. ## Core Architecture and How It Works At its foundation, Xandeum uses a distributed network of **provider nodes (pNodes)**, which are hardware devices or servers run by community participants to store and serve data. Data uploaded to the network is processed through **erasure coding**, a technique that splits files into multiple shards (fragments) with built-in redundancy. This ensures that even if some pNodes go offline or fail, the data can be fully reconstructed from the remaining shards, providing tamper-proof reliability and minimizing storage overhead (e.g., achieving high efficiency without needing full duplication). These shards are distributed across **pods **(groups of pNodes that communicate via a **gossip protocol**) for dynamic status updates, data availability checks, and efficient distribution. **Validator nodes (vNodes)** monitor the network's integrity using cryptographic proofs, preventing downtime and enabling seamless recovery. Storage is organized into scalable, file-system-like containers for data. Users and sedApps interact with these through a **pNode-specific RPC interface** (distinct from Solana's standard RPC), allowing programmatic queries for uploads, retrievals, or status checks. This is facilitated by **Xandeum Web3.js**, an extension of Solana's Web3.js library, which lets developers call storage primitives directly from smart contracts. Fees for storage operations are paid in SOL, which feeds into Xandeum's liquid staking mechanism: staked SOL (converted to xandSOL) earns rewards, including Storage Income (STOINC) amplified by NFT multipliers, and XAND governance tokens. This incentivizes pNode operators and stakers, creating a self-sustaining ecosystem. ## Integration with Solana Xandeum is natively built on Solana, offloading data from validators to pNodes to reduce network congestion while keeping storage operations on-chain. sedApps can efficiently store and access large datasets (e.g., user profiles, media files, or AI models) without external oracles or off-chain hacks. For example, in recent demos, prototype sedApps like scalable file-sharing tools or AI governance apps showcased real-time operations across global pNodes (from the US to Nigeria and Japan). This integration ensures Solana's high throughput (thousands of TPS) extends to storage-heavy applications, making it viable for Web3 equivalents of centralized services like Dropbox or social media platforms. ## Resolution of the Blockchain Storage Trilemma Xandeum explicitly solves the "storage trilemma" which is the challenge of balancing scalability, smart contract-native integration, and random access: - **Scalability**: Supports exabytes+ of storage through distributed pNodes and erasure coding, far beyond typical blockchain limits. - **Smart Contract-Native Integration**: Storage is directly callable from Solana programs, avoiding silos and enabling efficient, on-chain data handling. - **Random Access**: Unlike file-level systems that require full downloads, Xandeum allows granular, low-latency queries (e.g., via crude search capabilities in buckets), ensuring quick retrieval of specific data segments. ## Development Status and Innovations As of October 27, 2025, Xandeum is in the South Era of its six-phase innovation roadmap, having completed the Deep South Era (with 300 incentivized devnet pNodes sold out) and advanced through releases like Munich (first operational pNode prototype with basic file hosting and analytics) and Herrenberg (September 2025: added gossip protocol, RPC interface, 100% reconstructability, crude search, and custom analytics). The Herrenberg release, described as a "new POV" for intelligent decentralized storage, coincided with a Dutch Auction raising funds for the Xandeum Foundation and introducing NFT-boosted rewards. Upcoming releases like Engold (reward tracking) and Stodgard (redundancy for mainnet) aim for full mainnet launch by late 2025. Unique innovations include the **XandMiner tool** for easy pNode management (e.g., key generation, registration, and monitoring via a web GUI with Pod Monitor analytics), security best practices (non-standard ports, SSH key-only access), and community-driven features like real-time heartbeats (every 30 seconds) for STOINC eligibility. Recent community discussions highlight clarifications on RPC types (one for storage primitives to pNodes, another for analytics) and excitement for sedApps that "think" via AI/ML integration. Overall, Xandeum transforms Solana into a complete platform for Web3, combining speed with unlimited, secure storage. For hands-on involvement, operators can set up pNodes via docs.xandeum.network, and stakers can participate through the Foundation Delegation Program. [title] Core Concepts [path] / ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/VDQyu5F-6c32A1aVQ67d3_logo.png) ### The Xandeum difference Xandeum is a decentralized storage layer built on Solana, designed to overcome the blockchain's storage limitations by enabling scalable, smart contract-native storage up to exabytes for data-intensive applications like DeFi, NFTs, AI, and big data. - **Scalable Storage Layer**: A blockchain-enabled file system that allows Solana programs to store and access massive amounts of data (e.g., terabytes or more) with seamless random access, unlike Solana's limited account-based storage. - **Proof of History Integration**: Leverages Solana's PoH for timestamping and ordering storage operations, ensuring efficient, verifiable data management without compromising the base layer's speed. - **Erasure Coding for Redundancy**: Data is split into pages, encoded with configurable redundancy (e.g., Reed-Solomon codes), and distributed across nodes to provide fault tolerance and data availability while minimizing storage overhead. - **Cryptographic Proofs (Poke, Peek, Prove)**: Core primitives for interacting with storage; Poke offloads data to pods, Peek retrieves it on-chain, and Prove verifies integrity using zero-knowledge-like proofs, all wrapped in Solana transactions. - **Decentralized Node Network**: Comprises pNodes (provider nodes for actual data storage) and vNodes (validator nodes for supervision), creating a supervised, incentivized ecosystem that scales storage without burdening Solana validators. - **Liquid Staking and DAO Governance**: Powered by XAND (governance token) and XandSOL (liquid staking token for SOL), enabling users to stake, earn rewards, and participate in community-driven decisions via the Xandeum DAO. - **Storage Fees in SOL**: Fees for storage operations are paid in SOL, distributed to validators, pNodes, and the DAO treasury, fostering economic alignment with the broader Solana ecosystem. *** ### Investor Perspective: Investing in XAND and XandSOL Xandeum offers investment opportunities through its tokens, XAND (governance and utility token) and XandSOL (liquid staking token), with a focus on rewards, governance, and network growth. The model emphasizes community incentives, airdrops, and treasury accrual from fees, positioning it for long-term value in Solana's expanding ecosystem. - **XAND Tokenomics**: Fixed supply of 4.015 billion tokens, with allocations for marketing (10%), ecosystem development (10%), community grants (2%), airdrops, and DAO treasury; circulating supply starts low (580 million on day 1) with vesting cliffs to manage inflation and reward long-term holders. - **Governance and Voting Power**: XAND holders lock tokens to vote in the DAO, influencing network upgrades, parameter changes (e.g., fees), and treasury spending, (staking commissions, storage transactions) flow to the treasury, creating value accrual for stakers. - **Airdrops**: Five planned airdrops (e.g., snapshot-based, with 50% immediate claim and 50% vesting); - **XandSOL Liquid Staking**: Stake SOL to receive XandSOL, which earns XAND rewards through seasonal programs (3-month cycles); multipliers like 10x in early phases (Hyperdrive for \<30k SOL staked) boost yields, with real-time accrual and end-of-season claims—staking volume has exceeded 30,000 SOL (over $8M TVL), offering industry-leading APY of around 15%, double that of competitors like Jito and Marinade. - **Raydium Liquidity Provision Opportunities**: Investors can provide liquidity to a XandSOL-related pool on Raydium (e.g., SOL-XAND) to earn trading fees and potential farming rewards with high APRs with liquidity amounts reaching $100,000. **Incentives**: Early investors (XANDC holders) upgrade 1:1 with partial unlocks, plus referral bonuses and liquidity incentives for DEX/CEX providers. **Reward Seasons and Boosts**: Structured phases (Hyperdrive, Launchpad, Liftoff, Cruising) based on total staked SOL, offering higher rewards for early adopters; DAO can adjust distributions, aligning incentives with network growth. **Economic Alignment with Solana**: Storage fees in SOL fund the ecosystem, while XAND staking provides yields; foundation reserves support partnerships and development, reducing risk through community control post-Season 4. **Risk and Potential**: Low initial liquidity for XandSOL requires caution, especially in early Raydium pools; however, deflationary mechanics (e.g., fee burns), treasury growth from adoption, and milestones like staking volume exceeding 30,000 SOL could drive appreciation as storage demand rises. *** ### Developer Perspective: Participating in pNodes, vNodes, RPC, pRPC Xandeum empowers developers to build and participate in its storage infrastructure, integrating seamlessly with Solana for creating data-heavy dApps. Focus is on running nodes, using protocols for storage access, and contributing to the network for rewards. - **pNodes (Provider Nodes)**: Decentralized storage nodes responsible for holding encrypted data pages; participate by running hardware/software setups (e.g., via devnet guides), earning SOL fees and XAND rewards for availability and integrity, when possible join wait lists for sales and incentives. - **vNodes (Validator Nodes)**: Supervisory nodes that cryptographically monitor pNodes using proofs to ensure data redundancy and prevent faults; developers can run vNodes on Solana's devnet/martinet, contributing to consensus and earning commissions from the DAO treasury. - **RPC (Remote Procedure Call)**: Refers to mechanisms for random access and integrity challenges in storage operations; developers implement RPC in dApps for querying/verifying pNode data off-chain, integrating with Solana RPC endpoints for seamless calls. - **pRPC (Provider RPC)**: Extension for provider-side handling, possibly physical node-specific protocols for data replication and challenges; participate by configuring pNodes to respond to pRPC requests, ensuring cryptographic supervision and earning rewards for compliance. - **Devnet Participation**: Start by running a devnet validator or pNode using official docs; test storage primitives (Poke/Peek/Prove) in Solana programs, with tools for erasure coding and redundancy configuration. - **Building dApps**: Use Xandeum-enabled RPC nodes to extend Solana accounts with Web3 storage; developers can create storage-intensive apps (e.g., AI models, big data) and propose grants via DAO for ecosystem funding. - **Rewards and Governance**: Earn from storage income (STOINC) programs, with sold-out pNode rounds indicating high demand, a focus on uptime and performance for merit-based incentives. [title] v0.8 Reinheim [path] Older Releases/ # State of Development Post-Reinheim Reinheim (v0.8) is a focused, small release in Xandeum's South Era, delivering directory tree name searching via glob patterns to make large file systems significantly more navigable for sedApps and operators. ## Core Features - **Directory Tree Name Searching**: Enables efficient, manageable file discovery in large file systems, making storage more practical for sedApps. - The new `find` operation searches for files and directories matching a glob pattern within a specified file system or subtree. - Supports Unix-like wildcard patterns: - `*` for any characters - `?` for a single character - Escaped literals (e.g., `\.` for a dot) - Fully recursive, traversing subdirectories automatically. - Ideal for queries like yearly reports (e.g., "financials200?.\*") or config files. ::::CodeDrawer{isResponseExpanded="true" title="Searching for Files with Glob Patterns" codeEditorData="[object Object]" responsesEditorData="[object Object]" autoGeneratedAnchorSlug="searching-for-files-with-glob-patterns" legacyHash="Ui2FIWTlJRyvQPrLsa2_k"} :::CodeblockTabsExamples ```javascript // Search the root of file system ID 1234 for all .txt files (recursive) const results = await xandeum.find("1234", "*.txt"); // Example: Search for config-related files and directories const configResults = await xandeum.find("1234", "config*"); ``` ::: :::CodeblockTabsResponses ```text // Example results for "*.txt" [ "/document.txt", "/notes.txt", "/readme.txt", "/data/file.txt" ] // Example results for "config*" [ "/config.json", "/config_prod.yaml", "/configuration.txt", "/configs/settings.ini" ] ``` ::: :::: ## Summary Reinheim (v0.8) delivers a valuable usability improvement in Xandeum's South Era by adding directory tree name searching with glob pattern support. This small but impactful release makes file discovery efficient in large-scale file systems, building on prior advancements in redundancy (Stuttgart) and analytics (Heidelberg). It enhances practical day-to-day operations for sedApp developers and pNode operators alike, while bringing the prototype storage layer one step closer to full mainnet readiness by late 2025. [title] Setup LogRotate [path] Operator Guides/vNode Guide/Validator Home/ # LogRotate LogRotate will break your log into a new file daily and keep 7 days of logs and discard old logs. :::hint{type="warning"} **Important:** Make sure your validator start script starts with `exec` or your validator will go offline for a time each time the logs rotate. ::: :::hint{type="info"} Run as `root` user, use `sudo -i` ::: Copy code block and paste into terminal. :::CodeblockTabs CLI ```linux cat > logrotate.agave <> /root/.ssh/authorized_keys ``` # Validator Keypairs Make sure you have copied your validator keypairs if they are needed for the new server. Otherwise they can be created new during install of the validator software. There is no reason to re-use the old one, only personal preferance. # Remove xand user account Once you have sucessfully logged into your server using either `root` or `sol` user, and copied/backed up any files you need, you may wish to remove everything from `xand` user and their files. ```bash sudo -s ``` ```bash userdel -rf xand ``` [title] v1.2 Bonn [path] / # Behind the Scenes From the outside it looks as if we have jumped from v0.8 Reinheim to v1.2 Bonn. In the background Xandeum has been developing the intervening releases. - **v0.9 Bamberg**: Improved redundancy statistics for apps and allows tracking of app-requested metrics. - **v1.0 Frankfurt**: Now shows redundancy stats and storage volume on a public page, which can be queried by community-developed support and management software. - Includes test crash tolerance. - An updated XandMiner. - An update to the pNode Portal. - [https://stats.xandeum.network/](https://stats.xandeum.network/) - **v1.1 Olef**: Introduces the ability to repair pages utilizing the power of the pNode network to reliably restore data. ## Mainnet Launch Update – January 2026 Xandeum mainnet launched on **December 31, 2025**, with the first pNodes coming online on **January 1, 2026**. As of January 2026, the network is live and stable, currently operating with community pNodes. ### Current Mainnet Access - **Official RPC**: Available at `api.mainnet.xandeum.network` (rate-limited). - **Community-operated RPCs**: Multiple independent, community-run endpoints are now live or coming online shortly, providing additional access options. ### Upcoming Mainnet Roadmap (Provisional) - **January 2026 (expected)**: Rollout of **STOINC** – storage income model where applications pay fees in SOL, distributed proportionally to pNodes. - **February 2026 (expected)**: Transition XAND staking from Realms DAO to direct on-pNode staking; introduction of **bonded pNodes** (slashable bond tier for higher rewards and accountability). - **Q3 2026 (expected, by end of September)**: Activation of **Byzantine Fault Tolerance (BFT)** for full unstoppable data guarantees, alongside supply/demand-based dynamic storage pricing. This phased approach ensures continued stability while progressively unlocking economic incentives and ultimate resilience for the scalable storage layer. # State of Development Post-Bonn Bonn (v1.2) marks a major milestone in operational maturity and production readiness for Xandeum's scalable storage layer. This release introduces Crash Fault Tolerance with automated eviction and data replacement for unresponsive pNodes, dedicated pod logging for improved diagnostics, and a full-featured pNode portal that enables secure owner-operator separation through Solana mainnet-signed transactions. Building on redundancy statistics, public metrics dashboards, and network-driven page repair from Bamberg, Frankfurt, and Olef, Bonn delivers significantly higher reliability, self-healing capabilities, and governance, enhancing mainnet operations in 2026. ## Core Features - **Crash Fault Tolerance (CFT)** Now includes an evict & replace protocol to manage low-performing or unresponsive pNodes and replace their data storage from other pNodes, allowing a pNode to automatically return to the network once it has recovered. - **Pod Dedicated Log Storage** Pod now has dedicated log storage. - **pNode Portal** A pNode portal has been introduced to support an owner-operator model and is supported through XandMiner. We have implemented a change from Solana devnet to mainnet so that wallets can sign transactions for: - register/update pNode - assign manager - create/update rewards account - register as pNode manager and update manager account details - update pNode manager account ## Summary Bonn (v1.2) significantly improves network reliability and operational control with automated Crash Fault Tolerance, dedicated logging, and a mainnet-enabled pNode portal supporting owner-operator governance. These advancements deliver self-healing storage, better diagnostics, and secure management, advancing Xandeum toward robust, production-ready mainnet operations in 2026. [title] Getting Started [path] / ![Xandeum Exabytes for Solana Programs](https://app.archbee.com/api/optimize/ePevXmvzgG-7aqJ72Gpg_/VDQyu5F-6c32A1aVQ67d3_logo.png) Welcome to Xandeum Network, the groundbreaking scalable storage platform transforming Solana with scalable, secure, and smart contract-native solutions for data-intensive Web3 applications. Built to tackle network congestion and reliability challenges, Xandeum empowers developers and users with exabyte-scale storage, innovative pNodes for distributed data management, and the XAND token for seamless governance and rewards. Join us in redefining blockchain efficiency and unlocking the future of decentralized innovation. ::::LinkArray{contentSource="CUSTOM"} :::LinkArrayItem 🚀 [Introduction](docId:9H8B1KzzqMzP8j8pp6Avi) Xandeum is a revolutionary scalable storage solution on Solana, enabling fast, data-intensive Web3 apps with exabyte-scale capacity, seamless smart contracts, and true decentralization. ::: :::LinkArrayItem [The blockchain storage trilemma](docId:1695ASjyFElrDBdcO4oCj) Xandeum solves the blockchain storage trilemma by delivering exabyte-scale scalability, seamless smart contract-native integration, and instant random access, empowering data-intensive Web3 apps on Solana without compromises. ::: :::LinkArrayItem [Xandeum's scalable storage solution](docId\:oc7rTZO4z3w0dTQPYT-9B) Xandeum operates as a complementary infrastructure to Solana, and it extends Solana's capabilities through seamless primitives that allow smart contracts to store, retrieve, and verify large datasets. ::: :::: [title] Xandeum pNode Setup Guide [path] Operator Guides/pNode Guide/ ![Xandeum Exabytes for Solana Programs](https://app.archbee.com/api/optimize/ePevXmvzgG-7aqJ72Gpg_/VDQyu5F-6c32A1aVQ67d3_logo.png) This document provides step-by-step instructions for setting up and managing a pNode for the Xandeum Network. Each section covers a specific part of the process, from prerequisites to troubleshooting. *** :::hint{type="info"} If you have already run through the prerequisites and security concerns, you can skip to the installation: [](https://app.archbee.com/docs/jJnL3gd8VnRbIK0kH13OK/dxThFWSwJQtbz2GYN2gPv#ibw0o) ::: # Prerequisites for Setting Up a pNode for Xandeum Before you begin setting up your pNode for the Xandeum Network, ensure you meet the following requirements. These steps will prepare your hardware, software, and environment to run xandminer and xandminerd effectively. ### Hardware Requirements - **Recommended VPS:** We recommend using a Virtual Private Server (VPS) from Contabo for $5.50/month. However, Contabo’s default 20 GB SSD storage is insufficient for Xandeum’s needs. Ensure your VPS or server has at least: - 4 CPU core - 4 GB RAM - 80 GB SSD storage (20 GB for system operations + an additional at least 60GiB free space to dedicate to the Xandeum Network) - 1 Gbps network - **Alternative Options:** You can use any Ubuntu-based machine, including home servers or other VPS providers, as long as they meet the minimum specs above and have a stable internet connection. - **Storage for Blockchain-Grade Data:** Ensure your pNode has sufficient storage (e.g., additional drives or partitions) to handle Xandeum’s blockchain-grade storage needs. xandminerd will interface with your hardware to query drives and partitions. ### Software Requirements - **Operating System on pNode:** - Ubuntu 24.04 LTS or later (recommended for stability and compatibility with Xandeum software). - Ensure the pNode has a clean, updated Ubuntu installation. - **Local Machine OS (for Managing pNode):** - Windows 10 or later, macOS, or any Linux distribution (e.g., Ubuntu, Fedora). - Windows users must have PowerShell or Command Prompt available (built into Windows 10/11). - **SSH Client:** - Windows: Built-in OpenSSH client (available since Windows 10). - macOS/Linux: Built-in `ssh` command (via OpenSSH). - **Web Browser:** Any modern browser (e.g., Chrome, Firefox, Edge) to access the xandminer GUI at `http://localhost:3000`. ### Network Requirements - **Stable Internet Connection:** Your pNode and local machine need a reliable internet connection for SSH access and software updates. - **Port Availability:** Ensure ports 3000 and 4000 are not blocked by firewalls or your ISP on your pNode, as it will be used for the xandminer GUI and xandminerd background service via an SSH tunnel. - **Static IP (Recommended):** A static IP address for your pNode is recommended for consistent access, though dynamic IPs can work with proper DNS configuration. ### Tools and Access - **Git:** Installed on your pNode to clone repositories from GitHub. - **SSH Keys:** You’ll need to generate an SSH key pair (Ed25519 recommended) on your local machine and add it to your pNode for secure access. Instructions for this are in the next section. - **Basic Command-Line Knowledge:** Familiarity with terminal commands (e.g., `ssh`, `curl`, `git`) on your local machine and pNode. ### Notes :::BlockQuote **Important:** These prerequisites ensure your pNode can run xandminer [https://github.com/Xandeum/xandminer](https://github.com/Xandeum/xandminer) and xandminerd [https://github.com/Xandeum/xandminerd](https://github.com/Xandeum/xandminerd) effectively. If you have questions or encounter issues, consult our Troubleshooting section or join our community on X/Discord for support. ::: :::BlockQuote **Future BFT Consensus:** As Xandeum evolves to include Byzantine Fault Tolerance (BFT) consensus, your pNode will need additional resources. We’ll provide updates in future sections. ::: :::BlockQuote **Xandeum Network Branding:** Note that “Xandeum Network” is our official branding, with both words capitalized. Visit our main website at [xandeum.network](https://xandeum.network) for more information. ::: *** # SSH Key Setup for pNode Access To securely access and manage your pNode, you'll need to generate an SSH key pair on your local machine and configure it on your pNode. We recommend using Ed25519 keys for their security and performance, but RSA 4096 is also supported as a fallback. ### Generating an SSH Key Pair Follow these steps based on your local machine's operating system. ### On Windows (Using OpenSSH) - **Requirements:** Ensure you're running Windows 10 or later with PowerShell or Command Prompt available. - **Generate an Ed25519 Key:** 1. Open PowerShell or Command Prompt. 2. Run the following command to generate an Ed25519 key pair: `ssh-keygen -t ed25519` 3. Press Enter to accept the default file location (`C:\Users\\.ssh\id_ed25519`) or specify a custom path. 4. Optionally, enter a passphrase for added security (recommended, but optional). 5. This will create two files: `id_ed25519` (private key) and `id_ed25519.pub` (public key) in your `.ssh` directory. - **Fallback to RSA 4096 (if Needed):** If Ed25519 isn't compatible with your pNode, generate an RSA 4096 key with: `ssh-keygen -t rsa -b 4096` - **Verify the Key:** Check that the keys were generated by listing the `.ssh` directory: `dir C:\Users\\.ssh` ### On Linux or macOS - **Generate an Ed25519 Key:** 1. Open a terminal. 2. Run the following command to generate an Ed25519 key pair: `ssh-keygen -t ed25519` 3. Press Enter to accept the default file location (`/home//.ssh/id_ed25519`) or specify a custom path. 4. Optionally, enter a passphrase for added security (recommended, but optional). 5. This will create `id_ed25519` (private key) and `id_ed25519.pub` (public key) in your `.ssh` directory. - **Fallback to RSA 4096 (if Needed):** If Ed25519 isn't compatible, generate an RSA 4096 key with: `ssh-keygen -t rsa -b 4096` - **Verify the Key:** Check the keys by listing the `.ssh` directory: `ls -l ~/.ssh` ### Adding the Public Key to Your pNode 1. Copy the public key (`id_ed25519.pub` or `id_rsa.pub`, depending on the key type you generated) to your clipboard: - On Windows (PowerShell): `type C:\Users\\.ssh\id_ed25519.pub | clip` - On Linux/macOS: `cat ~/.ssh/id_ed25519.pub | pbcopy # macOS` `cat ~/.ssh/id_ed25519.pub | xclip # Linux (if xclip is installed)` 2. SSH into your pNode using password authentication (you'll disable this later): `ssh root@` Replace `` with your pNode's IP address. 3. Create or edit the `~/.ssh/authorized_keys` file on your pNode: `mkdir -p ~/.ssh` `nano ~/.ssh/authorized_keys` Paste your public key into the file, save, and exit (Ctrl+O, Enter, Ctrl+X in `nano`). 4. Ensure the permissions are correct: `chmod 700 ~/.ssh` `chmod 600 ~/.ssh/authorized_keys` ### Testing SSH Access - Exit the pNode (`exit`) and test SSH access using your private key: - On Windows (PowerShell): `ssh -i C:\Users\\.ssh\id_ed25519 root@` - On Linux/macOS: `ssh -i ~/.ssh/id_ed25519 root@` - **If prompted, enter your SSH key passphrase (if you set one). You should now access your pNode without a password. If you are still prompted for a password, go back through the above steps or ask for assistance from the community.** ### Disabling Password Login for Enhanced Security To maximize the security of your pNode, you should disable password-based SSH login and rely solely on SSH keys. This prevents brute-force attacks and ensures only authorized users with SSH keys can access your pNode. However, this step is irreversible without access to your SSH private key, so proceed carefully. ### Important Precautions - Ensure you've successfully tested SSH key-based access (as described earlier in this guide) before proceeding. - Keep your SSH private key safe and backed up. If you lose it, you won't be able to access your pNode without assistance from your hosting provider. - Run this step from a secure connection, and keep your current SSH session open in case you need to revert changes. ### Using Our Script to Disable Password Login We've created a simple script to safely disable password login on your pNode, handling common configuration file variations (e.g., `/etc/ssh/sshd.d`). Follow these steps: Note: will only work if you are using file naming from above (ie `~/.ssh/id_ed25519`) :::hint{type="info"} Note: Option 4 In the Xandeum pNode Software Installer will handle SSH hardening also. You may use either method. ::: 1. Download our SSH hardening script by running the following command in your terminal: `wget https://gist.github.com/bernieblume/7c49b49e718f9e41d4802e94e7a9e103/raw/nopwlogin.sh` 2. Make the script executable: `chmod +x nopwlogin.sh` 3. Run the script with sudo: `sudo ./nopwlogin.sh` 4. Follow the on-screen instructions and verify that you can still access your pNode using your SSH key. ### Manual Instructions (Advanced Users) If you prefer to disable password login manually or the script doesn't work for your setup, follow these steps: 1. SSH from your local machine into your pNode using your SSH key: `ssh -i ~/.ssh/id_ed25519 root@` 2. Open the SSH configuration file in a text editor (e.g., `nano` or `vim`): `nano /etc/ssh/sshd_config` 3. Look for the following lines and set them to `no`. If the lines are commented (start with `#`), uncomment them by removing the `#`: `PasswordAuthentication no` `ChallengeResponseAuthentication no` 4. Check if `/etc/ssh/sshd_config.d/` exists. If it does, create or edit a file (e.g., `10-disable-password-auth.conf`) in that directory and add: `PasswordAuthentication no` `ChallengeResponseAuthentication no` 5. Save the file and exit the editor (in `nano`, press Ctrl+O, Enter, then Ctrl+X). 6. Restart the SSH service: `systemctl restart ssh` or, if that doesn't work: `service ssh restart` 7. Test SSH access with your key to ensure you're not locked out: `ssh -i ~/.ssh/id_ed25519 root@` ### Troubleshooting - If you're locked out, restore from the backups created by the script (located at `/etc/ssh/sshd_config.bak-*` and `/etc/ssh/sshd_config.d.bak-*`) or contact your hosting provider for console access. - If password login is still enabled, check for conflicting settings in `/etc/ssh/sshd_config.d/` files and ensure the SSH service restarted correctly. :::BlockQuote **Note:** Disabling password login is permanent unless you re-enable it manually or via console access. Always test key-based access before proceeding. ::: *** # Installing and Configuring xandminer on Your pNode Now that you've secured your pNode with SSH key-based authentication and disabled password login, it's time to install and configure the xandminer software to set up your pNode as a mining node. This chapter guides you through downloading and running the pNode installer script, which automates the setup of xandminer and xandminerd, including repository management, systemd service configuration, and verification steps. ### Prerequisites Before proceeding, ensure the following: - You have SSH access to your pNode using your SSH key (as configured in the previous chapter). - **Optionally, open an ssh session tunnel that forwards the ports that will be needed later as well:** - `ssh -i ~/.ssh/id_ed25519 root@ -L 4000:localhost:4000 -L 3000:localhost:3000 8000:localhost:8000` - This will allow port `http://localhost:3000` in your web browser to connect through the ssh tunnel to your xandminer - Port 4000 is used to connect the GUI to the xandminerd service - Port 8000 is used for the stats page - Your pNode is running a compatible Linux distribution (e.g., Ubuntu 20.04 or later, Debian 11 or later). - You have `root` privileges on your pNode. - Git, curl, and systemd are installed on your pNode. You can install them with: `apt update && apt install -y git curl systemd` - Restart if prompted to load newer kernel ### Downloading and Running the pNode Installer We've created a simple installer script to automate the setup of xandminer and xandminerd on your pNode. This script checks for critical security settings, clones or updates the repositories, configures systemd services, and provides instructions for the next steps. ### Steps to Run the Installer 1. SSH from your local machine into your pNode using your SSH key: `ssh -i ~/.ssh/id_ed25519 root@ -L 4000:localhost:4000 -L 3000:localhost:3000 8000:localhost:8000` Replace `` with your pNode's IP address. 2. Download the installer script by running the following command in your terminal: `wget -O install.sh "https://raw.githubusercontent.com/Xandeum/xandminer-installer/refs/heads/master/install.sh"` 3. Make `install.sh` executable `chmod a+x install.sh` 4. Run the script with sudo: `./install.sh` 5. Follow the on-screen instructions and verify the output to ensure the installation completed successfully. Choose option: `1. Install Xandeum pNode Software` ### What the Installer Script Does The installer script performs the following actions: - **Repository Management**: - Checks if the `xandminer` and `xandminerd` directories exist in `/root`. - If the directories don't exist, the script clones the respective Git repositories into `/root/xandminer` and `/root/xandminerd`. - If the directories exist, the script changes into each directory and runs `git pull` to update the repositories to the latest version. - **Systemd Service Configuration**: - Copies the `xandminer.service` and `xandminerd.service` files (located in the root directory of their respective repositories) to `/etc/systemd/system`. - Enablesand starts the services using `systemctl enable xandminer.service --now` and `systemctl enable xandminerd.service --now` - **Success Message**: Outputs a success message indicating that the services are enabled and running, along with a link to the documentation for further instructions (using a placeholder for now, e.g., ``). ### Troubleshooting - If Git cloning or pulling fails, ensure you have an active internet connection and the necessary permissions on your pNode. - If systemd service configuration fails, check the permissions of `/etc/systemd/system` and ensure systemd is properly installed and running. ### Next Steps Once the installer script has completed successfully, it is reccomeended to restart your pNode to load any new kernel drivers. Xandminer and xandminerd services will be running upon reboot. Refer to the documentation at `` for detailed instructions on starting, monitoring, and troubleshooting the services, as well as configuring xandminer for optimal mining performance. *** # Starting and Monitoring xandminer Services Now that you’ve installed and enabled the xandminer and xandminerd services on your pNode using the installer script, it’s time to start them and monitor their operation. This chapter walks you through manually starting the services, checking their status, reviewing logs, and troubleshooting common issues to ensure your pNode is mining effectively. ### Prerequisites Before proceeding, ensure the following: - You have SSH access to your pNode using your SSH key (as configured in the “SSH Key Setup” chapter). - The xandminer and xandminerd services are installed and enabled on your pNode (as described in the “Installing and Configuring xandminer on Your pNode” chapter). - You have `root` privileges on your pNode. ### Starting the xandminer and xandminerd Services The installer script enabled the services but did not start them. Follow these steps to manually start the services: 1. SSH into your pNode using your SSH key: `ssh -i ~/.ssh/id_ed25519 root@ -L 4000:localhost:4000 -L 3000:localhost:3000 8000:localhost:8000` Replace `` with your pNode’s IP address. 2. Start the xandminer service: `systemctl start xandminer` 3. Start the xandminerd service: `systemctl start xandminerd` ### Checking Service Status After starting the services, verify they are running correctly: 1. Check the status of the xandminer service: `systemctl status xandminer` Look for output indicating “active (running)” and no errors. If the service isn’t running, you’ll see “inactive” or “failed.” 2. Check the status of the xandminerd service: `systemctl status xandminerd` ### Sample Output for a Running Service Here’s an example of what a running service status might look like: ```text xandminer.service - xandminer Mining Service Loaded: loaded (/etc/systemd/system/xandminer.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2025-02-21 10:00:00 UTC; 5min ago Main PID: 12345 (xandminer) Tasks: 10 (limit: 4915) Memory: 50.0M CGroup: /system.slice/xandminer.service └─12345 /usr/bin/xandminer --config /root/xandminer/config.json ``` Or, if there’s an issue: ```text xandminer.service - xandminer Mining Service Loaded: loaded (/etc/systemd/system/xandminer.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2025-02-21 10:05:00 UTC; 1min ago Docs: Process: 12346 ExecStart=/usr/bin/xandminer --config /root/xandminer/config.json (code=exited, status=1/FAILURE) ### Monitoring Logs To troubleshoot or monitor the services, check their logs using `journalctl`: 1. View logs for xandminer: `journalctl -u xandminer` 2. View logs for xandminerd: `journalctl -u xandminerd` You can also tail the logs in real-time: `journalctl -u xandminer -f` `journalctl -u xandminerd -f` ``` Look for any error messages, warnings, or indications of successful mining activity (e.g., connection to the mining pool, hash rates, etc.). ### Troubleshooting Common Issues If the services fail to start or aren’t running as expected, try the following: - **Check Permissions**: Ensure the service files in `/etc/systemd/system` and the repository directories (`/root/xandminer`, `/root/xandminerd`) have the correct permissions: ```text chmod 644 /etc/systemd/system/xandminer.service chmod 644 /etc/systemd/system/xandminerd.service chmod -R 755 /root/xandminer chmod -R 755 /root/xandminerd ``` - **Restart Services**: If you make changes, restart the services: `systemctl restart xandminer` `systemctl restart xandminerd` - **Review Logs**: Use `journalctl` to identify specific errors (e.g., missing dependencies, configuration issues, or network problems). - **Verify Dependencies**: Ensure all required dependencies for xandminer and xandminerd are installed. - **Check Network**: Ensure your pNode has internet access and can connect to the mining pool (if applicable). ### Enabling Automatic Startup (Optional) If you want the services to start automatically on boot (in addition to manual starting), you can enable them (though this was already done by the installer): `systemctl enable xandminer` `systemctl enable xandminerd` ### Next Steps Once the services are running and monitored, you can configure xandminer for optimal mining performance. *** # Setting Up an SSH Tunnel and Accessing the xandminer Web GUI To manage your pNode remotely and access the xandminer web-based graphical user interface (GUI) securely, you can set up an SSH tunnel using OpenSSH on Windows. This chapter guides you through creating an SSH tunnel to forward traffic from your local machine to the xandminer web GUI running on your pNode, ensuring secure and encrypted access. ### Prerequisites Before proceeding, ensure the following: - You have SSH access to your pNode using your SSH key (as configured in the “SSH Key Setup” chapter). - The xandminer and xandminerd services are installed, enabled, and running (as described in the “Starting and Monitoring xandminer Services” chapter). - The xandminer web GUI is enabled and configured on your pNode. - You have `root` privileges on your pNode. - You have OpenSSH installed on your Windows machine. You can install it via Windows 10/11 Settings under “Optional Features” or through Windows Subsystem for Linux (WSL). ### Enabling the xandminer Web GUI Open an SSH tunnel that forwards the proper ports through the tunnel, ensure the xandminer service is enabled and running on your pNode: 1. SSH into your pNode using OpenSSH on Windows: `ssh -i %userprofile%\.ssh\id_ed25519 root@ -L 4000:localhost:4000 -L 3000:localhost:3000 8000:localhost:8000` Replace `` with your pNode’s IP address. 2. Check if the xandminer web GUI service is installed and enabled: `systemctl status xandminer` If the service isn’t running or installed, refer to the xandminer installation instructions. 3. Start and enable the xandminer web GUI service: `systemctl enable --now xandminer` 4. Verify the GUI is accessible locally on the pNode (if on the same network) by opening a web browser on the pNode and navigating to `http://localhost:3000` (or the port specified in the documentation). ### Setting Up an SSH Tunnel with OpenSSH on Windows The xandminer web GUI typically runs on a local port (e.g., 3000) on your pNode, but it may not be exposed publicly for security reasons. You can use an SSH tunnel with OpenSSH on Windows to forward traffic from your local machine to the pNode’s GUI port securely. 1. Open a Windows Command Prompt, PowerShell, or WSL terminal on your local machine and create an SSH tunnel to forward local ports 3000 and 4000 to the pNode’s ports 3000 and 4000: `ssh -i %userprofile%\.ssh\id_ed25519 -L 4000:localhost:4000 -L 3000:localhost:3000 8000:localhost:8000 root@` - `-L 3000:localhost:3000` forwards local port 3000 to port 3000 on the pNode. - `-L 4000:localhost:4000` forwards local port 4000 to port 4000 on the pNode. - `-L 8000:localhost:8000` forwards local port 8000 to port 8000 on the pNode. - Replace `` with your pNode’s IP address. 2. Keep the terminal window open to maintain the tunnel. The SSH connection will stay active until you close the terminal, the session times out, or the connection is interrupted. 3. Open a web browser on your local machine and navigate to `http://localhost:3000` to access the xandminer web GUI. ### Managing the SSH Tunnel When using an SSH tunnel, consider the following guidance to manage it effectively and securely: - **Leaving the Tunnel Open**: You can leave the SSH tunnel open while actively managing your pNode via the xandminer web GUI. This allows continuous access to the GUI without needing to recreate the tunnel frequently. However, be aware that the tunnel might close over time due to network interruptions, idle timeouts, or system sleep/hibernate modes on your local machine or pNode. - **Reopening the Tunnel**: If the tunnel closes (e.g., due to a network disconnection or timeout), you’ll need to reopen it by rerunning the SSH command: `ssh -i %userprofile%\.ssh\id_ed25519 -L 4000:localhost:4000 -L 3000:localhost:3000 root@` Check the terminal for error messages (e.g., “Connection closed” or “Connection timed out”) to diagnose why the tunnel closed. - **Avoid Leaving Unattended for Too Long**: Do not leave the SSH tunnel open for extended periods when you’re not actively using it, such as when you leave your PC unattended for hours or overnight. Leaving the tunnel open unnecessarily can expose your pNode to potential security risks if the connection is compromised or if your local machine is left unsecured. Close the terminal or disconnect the SSH session (`exit` or Ctrl+C) when you’re done using the GUI to minimize risks. ### Checking the pNode ports: Use this one-line command to check if the correct ports are accessible from the public interent. It tests public UDP 5000 and localhost TCP 3000 and TCP 4000 The tool uses nc (netcat) and ss (socket statistics) to test the pNode ports. :::CodeblockTabs CLI ```bash MY_IP=$(curl -s https://ipinfo.io/ip) && echo " UDP 5000 on $MY_IP" && if command -v nc >/dev/null 2>&1; then timeout 10 nc -zu $MY_IP 5000 && echo "✅ UDP 5000 PUBLIC" || echo "❌ UDP 5000 NOT PUBLIC"; else echo "⚠️ netcat (nc) not installed - cannot test UDP 5000"; fi && echo " Localhost TCP:" && for port in 3000 4000; do ss -tlnp 2>/dev/null | grep -q "127.0.0.1:$port " && echo "✅ $port" || echo "❌ $port"; done ``` ::: :::hint{type="info"} The output should look like this: If you have any red X marks next to a port you need to investigate the connection issues. ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/q9eePtm-hB2ORFmoBIA5C_image.png) ::: :::hint{type="success"} This section is now complete. See below for advanced and future features. Otherwise, continue on to [Register your pNode](docId:7V5bNlOBkun6-EPMcPJYf) on the Xandeum DevNet. ::: ### Troubleshooting SSH Tunnels and Web GUI Access If you encounter issues, try the following: - **Connection Refused**: Ensure the xandminer web GUI service is running on the pNode: `sudo systemctl status xandminer` Start it if necessary: `sudo systemctl enable --now xandminer`. - **Port Conflict**: Verify port 3000 (or the configured GUI port) isn’t in use by another service on your local machine or pNode: `sudo netstat -tuln | grep 3000` - **SSH Key Issues**: Confirm your SSH key is correctly configured and permissions are set (e.g., `chmod 600 %userprofile%\.ssh\id_ed25519` on WSL or via a Linux-like file manager on Windows). - **Firewall Rules**: Ensure port 3000 is open on the pNode for local access (if not using a tunnel, though tunnels bypass external firewalls): `ufw allow 3000/tcp` - **Browser Issues**: Clear your browser cache or try a different browser if the GUI doesn’t load. ### Automating SSH Tunnels (Optional) For frequent access, automate the SSH tunnel using a batch script or SSH configuration: - Create a batch script (e.g., `start_ssh_tunnel.bat`): @echo off start cmd /k "ssh -i %userprofile%.ssh\id\_ed25519 -L 3000\:localhost:3000 -L 4000\:localhost:4000 root@\" Save it, double-click to run, and it will open a new Command Prompt window with the tunnel. Close the window to terminate the tunnel. - Or, edit your SSH config (`%userprofile%\.ssh\config`) to include a tunnel: Host \ HostName \ User root IdentityFile %userprofile%.ssh\id\_ed25519 LocalForward 3000 localhost:3000 LocalForward 4000 localhost:4000 LocalForward 8000 localhost:8000 Then connect with: `ssh pnode` ### Next Steps With the SSH tunnel and xandminer web GUI set up, you can remotely manage your pNode’s mining operations securely. Use the GUI to complement the command-line tools and monitoring scripts from previous chapters. *** *** [title] Operator Guides [path] / ![Xandeum Exabytes for Solana Programs](https://app.archbee.com/api/optimize/ePevXmvzgG-7aqJ72Gpg_/VDQyu5F-6c32A1aVQ67d3_logo.png) # Overview Xandeum's Setup Guide is a streamlined resource for launching your participation in Solana's scalable storage revolution. Whether you're deploying a pNode to contribute storage capacity or a vNode to validate network integrity, this guide equips you with step-by-step instructions. Below, explore summaries of the pNode and vNode guides, with links to details for hands-on implementation. ## pNode Setup pNodes form the backbone of Xandeum's scalable storage, enabling data sharding via erasure coding and gossip protocols. The guide covers hardware requirements (e.g., minimum CPU/RAM/disk specs for DevNet), software installation (Ubuntu preferred), installation, and key steps: generating key pairs with XandMiner, registering via the daemon (XandMinerD). It highlights security best practices (non-standard ports, SSH keys) and troubleshooting for common issues like connectivity failures. For full instructions, see the [Xandeum pNode Setup Guide](docId\:d5u0eE4dArWEkaw11p9VQ) section. ## vNode Setup vNodes ensure network trust by monitoring pNode integrity through cryptographic proofs, offloading validation from Solana's core chain. This section outlines prerequisites (e.g., Solana CLI tools, sufficient SOL for staking), software installation of validator software, configuration for DevNet syncing, and activation via the Foundation Delegation Program. It includes tips for optimizing uptime, integrating with Pod Monitor analytics, and handling epoch-based rewards. Aligned with the Green Paper's vision for tamper-proof resilience, vNodes support the storage trilemma resolution by enabling seamless data reconstruction. Dive into the complete walkthrough in the [Validator Home](docId\:NZ-58KgjBp-toFSlvYgaw) section. ## Conclusion Xandeum's setup guide bridges theory to action, empowering you to join a community-operated ecosystem that's evolving rapidly through eras like South (foundational pNodes) and North (intelligent prototypes). Once configured, monitor performance via the web GUI and contribute to mainnet milestones. Start today to unlock rewards and shape Solana's scalable storage future. For deeper context, reference the Innovation Eras overview or Green Paper for technical foundations. [title] Register your pNode [path] Operator Guides/pNode Guide/Xandeum pNode Setup Guide/ # Setting Up an SSH Tunnel and Accessing the xandminer Web GUI To manage your pNode remotely and access the xandminer web-based graphical user interface (GUI) securely, you can set up an SSH tunnel using OpenSSH on Windows. This chapter guides you through creating an SSH tunnel to forward traffic from your local machine to the xandminer web GUI running on your pNode, ensuring secure and encrypted access. ### Prerequisites Before proceeding, ensure the following: - You have SSH access to your pNode using your SSH key (as configured in the “SSH Key Setup” chapter). - The xandminer and xandminerd services are installed, enabled, and running (as described in the “Starting and Monitoring xandminer Services” chapter). - The xandminer web GUI is enabled and configured on your pNode. - You have `root` privileges on your pNode. - You have OpenSSH installed on your Windows machine. You can install it via Windows 10/11 Settings under “Optional Features” or through Windows Subsystem for Linux (WSL). ### Enabling the xandminer Web GUI Open an SSH tunnel that forwards the proper ports through the tunnel, ensure the xandminer service is enabled and running on your pNode: 1. SSH into your pNode using OpenSSH on Windows: `ssh -i %userprofile%\.ssh\id_ed25519 root@ -L 4000:localhost:4000 -L 3000:localhost:3000` Replace `` with your pNode’s IP address. 1. port 3000 is for the GUI connection (http\://localhost:3000) 2. port 4000 is for the xandminerd connection 2. Check if the xandminer and xandminerd services are installed and enabled: `sudo systemctl status xandminer` `sudo systemctl status xandminerd` 3. If the service isn’t installed, refer to the xandminer installation instructions. 4. Start and enable the xandminer services: `sudo systemctl enable --now xandminer` `sudo systemctl enable --now xandminerd` 5. Verify the GUI is accessible locally on the opening a web browser on the remote Windows machine and navigating to `http://localhost:3000`. A sucessful connection will look like the screenshot below: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/FTnUwhjUPyAwSSRud1GS8_image.png) # Connect your wallet Using Phantom wallet or Solflare wallet, connect your Manager wallet using the "Select Wallet" button, and choose your wallet that has purchased at least one pNode license. - A manager can have up to 3 pNode licenses - Each pNode will need its own ip address After your wallet is connected, generate a keypair on your pNode using the "Generate Identity Key-pair" button. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/rTywDF8TK8yDvyRFY0fg3_image.png" size="24" width="282" height="447" position="center" showCaption="false"} - the keypair will be created on the pnode and the pubkey can be viewed in he Xandminer GUI - Press on the pNode Identity Keypair button again to copy the pubkey to your clipboard Next, press the "register pNode" button to register your pNode onto the Xandeum Network ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/gfRsKeyJT8srNzOFCImgE_image.png" size="24" width="282" height="421" position="center" showCaption="false"} [title] Register devnet pNodes [path] Operator Guides/pNode Portal/ # Update your pNode software Connect to your pNode via SSH, forwarding the required ports to the pNode localhost. If you are using Windows, use `cmd.exe` or `PowerShell` in this format: **Be sure to verify the location of your SSH private key file and your pNode public IP address.** :::CodeblockTabs CLI ```linux ssh -i "C:\path to ssh key\id_ed25519" root@ -L 4000:localhost:4000 -L 3000:localhost:3000 -L 8000:localhost:80 ``` ::: If you are using macOS or Linux, use this format: **Be sure to verify the location of your SSH private key file and your pNode public IP address.** :::CodeblockTabs CLI ```linux ssh -i ~/.ssh/id_ed25519 root@ -L 4000:localhost:4000 -L 3000:localhost:3000 -L 8000:localhost:80 ``` ::: :::Paragraph{listStyleType="decimal" indent="2"} Port 3000 is for the GUI connection (`http://localhost:3000`) ::: :::Paragraph{listStyleType="decimal" listStart="2" indent="2"} Port 4000 is for the `xandminerd` connection ::: :::Paragraph{listStyleType="decimal" listStart="3" indent="2"} Port 8000 is for running the Pod Monitor ::: Run the latest version of the `install.sh` script, then select **Option 2: Update Xandeum pNode Software**. :::hint{type="warning"} Run the installer as the `root` user. Use `sudo -i` to switch to `root` before running the command. Your sudo password may be required. ::: :::CodeblockTabs CLI ```linux wget -O install.sh "https://raw.githubusercontent.com/Xandeum/xandminer-installer/refs/heads/master/install.sh" && chmod a+x install.sh && ./install.sh ``` ::: ::::hint{type="success"} :::BlockQuote After selecting Option 2, choose the default options unless you know what you are doing and want to use different settings. - Keypair Configuration \- pRPC Configuration \- Atlas Cluster Configuration Select "DevNet" here \- Operator Revenue Configuration This will not do anything on devnet. We have chosen 1000 as the default value, but you must still type "1000" and press Enter. \- Pod Log ConfigurationWait for the completion messages. It may take several minutes. Your installed versions must be these versions or later\:Verifying services... ✓ xandminer.service is running ✓ xandminerd.service is running ✓ pod.service is running✓ All services started successfullyxandminer: v1.3.4 (Cologne) xandminerd: v1.3.1 pod: v1.3.2Xandminer web Service Running On Port : 3000 Xandminerd Service Running On Port : 4000 ::: :::: # Register as a pNode owner Keep the SSH tunnel open to one of the pNodes owned by the wallet you are registering. Then open `http://localhost:3000` in your browser. If you have upgraded correctly, you should see something like this: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/hZi1iLhZ4708qIDcv05eY_image.png) Note the **pNode Identity Pubkey** shown on the page. Click it to copy that pNode's public key to your clipboard. You will need it later. ## Connect your wallet Using Phantom or Solflare, connect your manager wallet using the **Select Wallet** button. Choose the wallet that has purchased at least one pNode license. - A wallet can have multiple pNode licenses - Each pNode will need its own IP address ## Select the "Register pNode" button This will take you to `http://localhost:3000/owner`. If this is the first time you have done this for the wallet, you will see a screen like this: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/OQTX9XkuNoAXP9Ki47Lqv_image.png) Press the **Register** button, then approve the transaction in your wallet. You will need a small amount of SOL in your wallet. After the transaction is confirmed, the page should refresh to something like this: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/vJGhHfH-8ecAM6XKWqfDq_image.png) You will see the Rewards Wallet, which you can redirect, and a table with a row for each of your pNodes. # Register each devnet pNode Each pNode must be added individually. Open an SSH tunnel to your first pNode and copy its public key. You can do this from the previous screen at `http://localhost:3000`. In the **Devnet pNode PubKey** column, click the empty `-` placeholder for that row. Paste in the public key, then click outside the field to apply the edit. A **Save** button will appear, as shown below: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/PWfCgU7_t7Yg7VzCWHHNh_image.png) Click the **Save** button, then approve the transaction in your wallet. You will need a small amount of SOL in your wallet. Register each pNode one at a time. Before saving a Devnet pNode public key, make sure your SSH tunnel is connected to that specific pNode. If the tunnel points to a different pNode, the transaction will fail with an expected signer mismatch error. ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/2gCp-gEpBoAXAL37YQOfw_image.png) Once you have registered all your pNodes, you will see a screen like this: ![](https://archbee-image-uploads.s3.amazonaws.com/ePevXmvzgG-7aqJ72Gpg_/DqKRifxkyRF7Kou9Gf8M1_image.png) Here you can see that each pNode is registered, along with its current credits, boost value, NFT assignment options, and Manager setting. [title] pNode Portal [path] Operator Guides/ [title] Developer Guides [path] / These will be coming soon, as a community let us know what would help you. [title] v0.6 Stuttgart [path] Older Releases/ # v0.6 Stuttgart ## State of Development Post-Stuttgart Stuttgart (v0.6) advances Xandeum's South Era by introducing **redundancy** mechanisms to the scalable storage layer for Solana, enhancing fault tolerance and data durability for smart contracts. Building on Ingolstadt's reward tracking and performance incentives, it shifts focus to replicated data distribution across pNodes, ensuring file systems remain accessible even during outages. This release refines the BigBang operation to incorporate user-defined replica counts, optimizes reconstruction processes, and separates environments for testing, positioning Xandeum toward mainnet with improved reliability and efficiency for storage-enabled dApps (sedApps). ## Core Features - **Redundancy Mechanisms**: User-configurable replication (1+ replicas) for each file system, with data distributed across semi-randomly selected pNodes to prevent single points of failure. - **BigBang Enhancements**: Now accepts a replica\_count parameter during file system creation, defining the number of pNode copies for every page; fails if requested replicas exceed available pNodes. - **Reconstruction Improvements**: Atlas reconstruction now requires only one healthy pNode per redundancy set to rebuild file systems, with caching to speed up lookups and reduce I/O. - **Pod Environment Separation**: Introduces devnet (default) and trynet modes; trynet uses an isolated gossip network and generates a new identity keypair on each start for convenient testing. - **Performance Optimizations**: Implements multithreading for simultaneous data transmission to multiple pNodes, accelerating replication processes. - **On-Chain Operations**: Commands like mkdir, copy, rename, and Armageddon are executed as instant on-chain transactions, propagating across the pod network for consistency without third-party dependencies. - **Integration with FSOnChain**: Supports fully on-chain file system management, where BigBang instantiates independent file systems with automatic data replication across pNodes for censorship-resistant control. ## Redundancy System ### Overview Redundancy in Stuttgart ensures every piece of data in a file system is replicated across multiple pNodes, configurable by users during BigBang. This provides resilience, allowing full accessibility and recovery as long as at least one replica per set remains online. It builds toward a scalable file system for smart contracts on Solana, with pNodes participating in multiple sets based on assignments. ### Key Concepts 1. **Replica Count** - Specified at BigBang (e.g., 1+); determines pNodes per page. - Semi-random selection of pNodes for each set. - Write operations replicate to all in the set. - Rejects if replica\_count > available pNodes. 2. **Redundancy Sets** - Groups of pNodes storing replicas for a file system. - A pNode can belong to multiple sets. - Enhances fault tolerance without central reliance. 3. **Updated Reconstruction (with Caching)** - Pre-Stuttgart: Required all pNodes online; risked data loss if any down. - Post-Stuttgart: Needs one healthy pNode per set; caches info for faster recovery. - Reduces dependency on full cluster scans. 4. **pNode Operations** - No hardware changes; stable internet and static IP required. - Open ports: UDP 9001 (gossip), TCP 5000 (Atlas), TCP 6000 (pRPC). - Multithreading improves data sending efficiency to replicas. ### Evolution - Starts centralized on Atlas but resilient via pNode data. - Prepares for decentralization in later eras (e.g., validators using Merkle proofs). - Ties into STOINC for proportional rewards based on contributions. ## pNode Rewards and Integration - Builds on Ingolstadt's credits: Redundancy participation factors into performance scores. - Monthly XAND allocations (10,000) to high-performers via Foundation Program. - Analytics via Pod Monitor for dashboards and community tools. ## Xandeum Pod Software This release updates the open-source Pod software, the runtime for pNodes in Xandeum's scalable storage layer for Solana. It coordinates data sharding, P2P communication, and RPC APIs for efficient file system operations in sedApps. ### What is a Xandeum Pod? A Xandeum Pod (pod) is the core software turning a VPS/server into a pNode. It manages storage, network participation, and monitoring. Technical Components: - pRPC API (Port 6000): JSON-RPC for stats and methods. - Gossip Protocol (Port 9001): P2P discovery and coordination. - Atlas Client (Port 5000): State sync. - Storage Engine: Handles file metadata in /xandeum-pages/pod.db. - Stats Dashboard (Port 80): Local web metrics. What Pod Does: 1. Storage Management: Stores/retrieves replicated data. 2. Network Participation: Gossip for peers; supports devnet/trynet. 3. API Service: Monitoring/interaction. 4. Atlas Coordination: Syncs state. 5. Performance Tracking: Metrics for credits. Installation: ```text # Add repo deb [trusted=yes] https://xandeum.github.io/pod-apt-package/ stable main sudo apt-get update sudo apt-get install pod ``` Running Pod: - Devnet (default): `pod --rpc-ip 0.0.0.0 --entrypoint :9001 --atlas-ip :5000` Terminology: - pNode: Hardware/VPS. - Pod: Software daemon. As of 2025 updates, Pod supports redundancy for fault-tolerant storage, essential for mainnet by late 2025. ## Stuttgart Summary Stuttgart marks a key milestone in Xandeum's South Era, adding redundancy to pNode operations for resilient file systems. It enhances BigBang for replica specification, optimizes reconstruction, and introduces trynet for testing. This fosters ecosystem growth with on-chain operations and FSOnChain integration, advancing toward Stuttgart's successors and full mainnet rollout.