What To Do Around Fork Risk
This is a preparedness guide, not a live migration checklist. No current fork or migration deadline is implied here. The goal is to help you understand what to verify if a future fork condition is reported, while keeping historical Moon Fork instructions in their archived context.
Use the monitor as a signal
The monitor describes observed dispute escalation. Its round-progress percentage is not a probability, a prediction, or a statement about which outcome is true.
| Display | What it describes | Prepared response |
|---|---|---|
| None / 0% | No funded dispute progress is being reported for the tracked market. | Learn the market’s resolution source and check the monitor periodically. |
| Low | Early observed escalation. | Identify the disputed market and read the underlying outcome evidence. |
| Moderate | Escalation has progressed, but a fork is not established by this label. | Review your exposure and the protocol mechanics; do not infer a deadline from the gauge. |
| High | Late observed escalation. | Verify the market and bond data from maintained sources and understand the possible fork states. |
| Critical | The observed projection is near its configured fork threshold. | Treat this as a reason to verify protocol state, not as an instruction to migrate or trade. |
| Unknown | A defensible round projection is unavailable. | Avoid guessing; use the underlying data and maintained project guidance. |
Always be prepared
- Know the market’s resolution source and what evidence would distinguish its possible outcomes.
- Keep track of which network, wallet, exchange, and REP version a record refers to. Historical token addresses are not automatically current recommendations.
- Treat external links, screenshots, and old announcements as dated evidence. Confirm consequential information against the deployed contracts and maintained project records.
- Do not treat a monitoring label as financial advice or as a guarantee that a fork will occur.
- Read the general dispute and bond mechanics before interpreting escalation.
If a future fork is confirmed
These are verification questions for a future event, not actions to take now:
- Is the fork state real? Confirm the forking market, parent universe, and fork state from the deployed protocol rather than from a screenshot or social post.
- What are the child universes? Match each child to the forking market’s possible outcome, including Invalid where present.
- What is the contract deadline? Use the deployed universe’s fork-end value. Do not copy a date from an old guide.
- What does migration commit? Migration is one-way, and sibling universes cannot be used to reverse the choice. Understand the consequence before any transaction.
- Which result is authoritative? A child receiving the most migrated REP becomes the winning universe under the reference mechanics. Confirm the contract-reported result after the relevant deadline before treating it as final history.
The general migration mechanics lesson explains these rules without attaching them to a named event.
After a fork becomes history
A completed event should be read as a case study: separate observed facts, protocol behavior, and interpretation. The existing Moon Fork Migration Record remains available at its public URL because it preserves useful historical steps and evidence. Its old tools, dates, addresses, and instructions are not a current action path.
A future Moon Fork case study belongs beside this guide, not inside it. It should carry its own dates and provenance rather than turning event facts into evergreen protocol claims.
Continue the path
- Return to What Is a Fork? for the full sequence.
- Review How Fork Migration Works for general protocol mechanics.
- Use the historical migration record only as dated reference material.