Network Transition & Upgrade Policy
There is no deployed public ASHA token, live provider economy, or production SENEX network to migrate. ASHA is simulated and test-only. V1-testnet is a future production-candidate test environment; V1 would be a separate, fresh-genesis production network if approved.
This page replaces the former token-bridge narrative with the actual transition policy: test environments are for validation, not for creating permanent balances, state, rights, or financial expectations.
Status
| Status label | Scope |
|---|---|
| Working foundation | Local-first software and development data evolve through controlled releases. No public network migration is active. |
| V1-testnet target | Validate upgrades, compatibility, export, recovery, and participant communication with test-only value. |
| Research direction | Safe long-term interoperability and transition policy for independently operated systems. |
| External validation required | Security, privacy, data protection, operational resilience, and any future economic or legal implications. |
Environment boundaries
Development environments
Development builds may change frequently. Test records can be reset or invalidated as designs evolve. They are not durable claims against a future release.
V1-testnet
V1-testnet is intended to evaluate a production-candidate design under controlled participation. It may use test credentials, test-only accounting, and simulated ASHA records.
Testnet participants should expect:
- software and policy changes during evaluation;
- planned or emergency resets when required for safe testing;
- correction or removal of invalid test records;
- access changes as the threat model and operating policy evolve; and
- no monetary value, redemption, yield, or guaranteed continuation.
V1 production
V1 would be a separate production decision with fresh operating terms, security review, privacy assessment, governance authorization, and release evidence. It would begin from a fresh genesis.
No V1-testnet balance, simulated ASHA amount, transaction history, governance position, reputation, provider record, or application state will migrate into V1. Participation in testing creates no allocation or preferred status.
What may be portable
Fresh genesis does not require users to lose ownership of ordinary local material. Where safe and supported, a release may offer explicit export and import for user-controlled content or configuration.
Portability should be:
- initiated or approved by the owner;
- limited to documented data categories;
- validated before import;
- version-aware and reversible where practical;
- clear about information that cannot be transferred safely; and
- separate from network balances, authority, recognition, or economic state.
This is a product-policy target, not a claim that every format or release is already supported.
Software upgrade principles
- Identify the boundary. State whether a change affects only local software, interoperability, policy, stored data, or a shared environment.
- Assess compatibility. Document supported versions and known breaking behavior.
- Protect owner control. Avoid silently expanding permissions or external sharing.
- Provide notice. Explain material changes, required actions, and the consequences of declining.
- Stage the release. Validate on non-production environments before broader use.
- Preserve recovery. Define backup, rollback, or safe-forward behavior appropriate to the change.
- Verify the outcome. Monitor errors and policy violations after release.
- Retire safely. End unsupported versions without leaving users uncertain about data or access.
Testnet resets and incidents
A testnet may need a reset after a design change, integrity failure, or security incident. The operating policy should explain the reason, affected scope, evidence retained, and steps required from participants. Resets should not be framed as compensation events because test-only records have no financial status.
Emergency actions may prioritize containment, but they still require documentation and later review through the Governance Model.
No bridge or conversion promise
SENEX does not promise a token bridge, balance snapshot, conversion ratio, claim window, burn-and-mint process, or backward-compatible economic state. Any future production economy would be a separate decision documented only after the necessary validation and legal review.
See the Contribution Economy Research for the current economic boundary and the Roadmap for outcome-based release stages.