The Moon Fork

The Moon Fork was Augur’s first completed algorithmic fork. Augur community member Micah Zoltu raised funds to drive a dispute over the market “Will the Artemis II Mission successfully liftoff in the first week of April?” through the protocol’s escalation path. The event ended with outcome index 1, Yes, as the contract-reported winner.

This page is a historical case study, not a migration guide. The migration deadline was 2026-08-03T01:00:59Z; it cannot be reopened, and no action is available here.

Event timeline

The dates below separate the public event timeline from the final contract observation.

The dated announcements remain useful artifacts: The Augur Fork Is Here, Phase 1: The Escalation Game, and Phase 2: The Fork Migration. They record what the project communicated at the time; this case study is the canonical durable account.

What the protocol was expected to do

Augur v2 uses a fork only after ordinary reporting and escalating dispute bonds fail to settle a market. Once the fork threshold is reached:

1. The disputed market becomes the forking market for its parent universe.
2. REP holders can make a one-way migration toward a possible market outcome.
3. A child universe and its REP token are created only when migration first targets that outcome; unused outcomes do not require an eagerly created child.
4. The parent universe’s fork end time bounds migration at the contract level.
5. The child selected by getWinningChildUniverse() becomes the winning universe, and its outcome finalizes the forking market.

The evergreen lessons explain these rules in more depth: What Is a Fork?, How Disputes & Bonds Work, and How Fork Migration Works.

What the final record showed

All values in this section were read from Ethereum mainnet at block 25,677,103. The block hash was 0xab19846fa87d598ab7cf801092d94533b1fd4f3a0ebe2dc442c49f188f3af5b7.

Outcome-specific migration

The totals below use each child REP token’s getTotalMigrated() counter. They are not ERC-20 totalSupply() values.

The existence of Yes and No children, while Invalid had no child, is direct evidence of lazy child-universe creation during migration. The Yes child held the largest recorded migrated amount and is the exact child returned by getWinningChildUniverse().

Expected behavior compared with observation

Participation and interface record

The on-chain totals show how much REP migrated to each created child. They do not establish how many distinct people participated, how much activity was self-custodied, or how much was handled by exchanges. Those questions require holder-level and custodial evidence that is outside this record.

Several practical boundaries were visible during and after the event:

• Wallet discovery: new child REP tokens were not always detected automatically. Users sometimes needed the exact Ethereum mainnet contract address to add the token to a wallet.
• Exchange handling: support varied by exchange. Kraken migrated supported balances and lists the current token under the ticker AUGUR, while its on-chain symbol remains REPv2_Yes_1.
• Tool lifecycle: ForkWatch, reporting, and migration interfaces were useful during the event but needed explicit historical labeling after the deadline. The Moon Fork Migration Record preserves those interfaces and screenshots without presenting them as current tools.
• Token naming: REPv1, pre-fork REPv2, REPv2_Yes_1, and Kraken’s AUGUR ticker refer to different lifecycle roles or labels. Documentation must always pair a token name with its chain, contract address, and current or legacy status.

Interpretation and lessons

The observations above support several project lessons. These are interpretations, not additional protocol facts.

1. Contract state should outrank schedule prose. Human-readable dates help participants, but the on-chain fork end time is the authoritative deadline.
2. Domain counters should outrank convenient proxies. The first post-close snapshot treated child-token totalSupply() as migrated REP. Comparing it with getTotalMigrated() exposed a difference of 147,679.019985211005520574 REP; the public generator was corrected to use the dedicated migration counter.
3. Lifecycle labels need contract-aware semantics. A persistent isForking() value after closure could be misread as an open event. Public interfaces should derive “migration open” from the deadline and verified result rather than from that flag alone.
4. Outcome interfaces should account for lazy creation. A possible outcome can remain valid even when no child contract exists because no REP migrated to it.
5. Token identity needs one durable source of truth. Wallet names and exchange tickers can differ. The winning universe’s getReputationToken() result, token symbol, chain, and contract address together identify current REP.
6. Custodial support must be communicated explicitly. Exchange migration can reduce action for custodial users, but support cannot be assumed across venues.
7. Historical tools should remain inspectable without remaining actionable. Preserving the procedure and screenshots helps research and troubleshooting; closed-state warnings prevent that evidence from becoming unsafe guidance.

Implications for future Augur and Lituus work

The Moon Fork demonstrates that Augur v2’s deployed fork path reached a contract-selected result under real transaction and interface conditions. It does not, by itself, prove the security or economics of a future oracle architecture, and it should not be used as evidence that Lituus mechanisms have already been validated.

It does provide concrete requirements for future work: publish machine-readable evidence alongside reader-facing explanations, expose authoritative deadlines and domain counters, plan wallet and exchange naming before a token transition, test closed-state presentation, and preserve event artifacts after their operational period ends. Those requirements can inform Augur and Lituus implementation and communication without predetermining their protocol design.

Sources and provenance

Continue

• Review the reusable mechanics in How Fork Migration Works →.
• Inspect the preserved procedure and screenshots in the Moon Fork Migration Record →.
• Return to the Fork learning path → or the full Learn catalog →.