Testnet Participation & Data Persistence Policy

Version 1.0

Effective Date: June 1st 2026

1. Purpose This Testnet exists to validate, test, and improve the protocol, infrastructure, applications, and user experience prior to production deployment.

The current network should be considered an Early Access Testnet, positioned between a closed testing environment and a fully public long-term testnet. While public participation is permitted, the network remains under active development and significant protocol, infrastructure, and operational changes may occur. Participation in the Testnet constitutes acceptance of this policy.

2. Current Testnet Phase The network is currently operating in an Early Access Testnet phase. During this phase:

• Core protocol components may still evolve.
• Infrastructure architecture may be modified.
• Network parameters may change.
• Smart contract and application deployments may be upgraded or replaced.
• State migrations may be required.
• Full backward compatibility is not guaranteed. The objective of this phase is to accelerate protocol maturity and operational readiness while collecting feedback from real-world usage.

3. Data Persistence Objectives The project recognizes that continuity of user identity and activity improves testing quality and user experience. Accordingly, the team intends, whenever reasonably possible, to preserve the following categories of data across upgrades, resets, and network migrations:

Intended Preservation Categories

• Usernames
• Account profiles
• Domain registrations
• Account balances
• Reputation or participation metrics
• Other user-facing records specifically designated by the project Where technically feasible, these records may be reconstructed, migrated, restored, or re-imported following Testnet upgrades or resets.

4. Engineering Trade-Offs Participants should understand that preserving Testnet state is not without cost. Maintaining continuity of usernames, registrations, balances, and related records requires:

• Additional engineering effort
• Migration tooling
• Data validation processes
• Infrastructure resources
• Operational maintenance

As a result, state preservation activities may occasionally compete with protocol development priorities. The project will make reasonable efforts to preserve designated data categories; however, such preservation should be viewed as a best-effort objective rather than a guaranteed service.

5. Network Resets and Restarts During this phase, network resets, chain restarts, state migrations, and protocol upgrades may be necessary. Examples include:

• Consensus upgrades
• Security improvements
• Performance optimizations
• Infrastructure changes
• Storage redesigns
• Data integrity corrections
• Protocol evolution The project reserves the right to perform such operations whenever deemed necessary for the long-term health and development of the ecosystem.

6. Restart Communication Policy Whenever reasonably possible, planned resets or disruptive upgrades will be announced in advance through official communication channels.

Announcements will generally include:

• Reason for the Change
• A summary of the technical or operational motivation.
• Expected Impact

Information regarding:

• Downtime
• State persistence
• Balance preservation
• Domain preservation
• Required user actions
• Timeline

Including:

• Announcement date
• Maintenance window
• Expected restoration timeline
• Migration Information Where applicable, guidance on any migration, verification, or recovery processes.

7. Emergency Actions Certain circumstances may require immediate intervention without advance notice.

• Examples include:
• Security vulnerabilities
• Critical infrastructure failures
• Data corruption events
• Consensus failures
• Service availability incidents

In such cases, the team may take immediate action to protect the network, users, and ecosystem. Post-incident communication will be provided as soon as reasonably possible.

8. No Guarantee of Persistence Although the project intends to preserve designated categories of user data whenever practical, participants acknowledge that:

• Testnet environments are experimental by nature.
• Data loss may occur.
• Migrations may fail.
• Restorations may be incomplete.
• Certain records may become unrecoverable. No representation, warranty, or guarantee is made regarding the permanent preservation of any Testnet data. Users should not rely on Testnet assets, balances, registrations, domains, identities, or records as permanent or production-grade resources.

9. Protocol Evolution Priority The primary purpose of this Testnet is to support protocol development and ecosystem maturation. Accordingly, during the current phase, the project will prioritize:

• Security
• Stability
• Protocol correctness
• Network evolution
• Long-term architectural integrity over
• Historical state preservation
• Testnet continuity
• Legacy compatibility
• Non-essential user data retention While every reasonable effort will be made to preserve important user-facing records, there may be situations where protocol evolution requires actions that impact persistence. Participants acknowledge and accept that, during this phase of development, the long-term success and integrity of the protocol may require decisions that supersede Testnet data continuity objectives.

10. Future Phases As the network matures, the project may introduce more stringent guarantees regarding:

• State persistence
• Upgrade compatibility
• Migration procedures
• Operational stability Any such commitments will be communicated through updated policy versions and official announcements.

11. Acceptance By creating an account, registering a domain, interacting with the network, or otherwise participating in the Testnet, users acknowledge that they have read, understood, and accepted this Testnet Participation & Data Persistence Policy.