Moon Fork migration is closed Historical procedure and evidence only

Final result

The final record was an Ethereum mainnet observation pinned to finalized block 25,677,103, with block hash 0xab19846fa87d598ab7cf801092d94533b1fd4f3a0ebe2dc442c49f188f3af5b7 and block time 2026-08-03T21:36:23Z.

The canonical universe is the child returned by getWinningChildUniverse(). The current REP identity is the token returned by that universe’s getReputationToken() and identified on-chain by the symbol REPv2_Yes_1. It is not inferred from a migration percentage.

Final migrated amounts

These final values were each read from the child token’s getTotalMigrated() counter at block 25,677,103. They are not ERC-20 totalSupply() values.

The parent universe’s migration deadline was 1785718859 (2026-08-03T01:00:59Z). It had passed before the evidence block was observed, so the migration window and its tools are closed.

Token identities preserved in this record

These labels refer to different roles. All addresses below are Ethereum mainnet addresses.

Evidence boundary

The final record used contract reads and block state pinned to 25,677,103. The migration totals above came from getTotalMigrated(), while totalSupply() was treated as a separate supply observation. The authoritative record also preserved the distinction between the legacy REPv1 input, pre-fork REPv2 input, and current REPv2_Yes_1 output.

Related material

• The Moon Fork is the canonical account of the trigger, timeline, final result, observed behavior, and lessons.
• How Fork Migration Works explains the reusable protocol mechanics without event-specific instructions.
• The Fork topic and How Disputes & Bonds Work provide the broader learning path.
• The Augur Fork Is Here remains a dated historical announcement rather than the canonical record.

Why?

The protocol design required REP holders to declare what they believed to be true when Augur forked. This increased the cost of attacking Augur. The historical announcement gave three reasons for this fork:

1. To learn from and improve the forking experience.
2. To verify that the incentive mechanisms worked as theorized.
3. To increase security by removing the portion of REP holders that would fail to respond if an attack happened.

When?

The contemporaneous procedure described the following historical phases. These dates were not a current schedule; the contract deadline recorded above was authoritative and has passed.

Moon Fork migration procedure (historical)

The sections below preserve the procedure that participants used during the completed Moon Fork. The wording is intentionally historical. Screenshots and links are retained for evidence, troubleshooting, and research; the linked tools are archived interfaces.

0. Consolidated REP on Ethereum mainnet

The procedure told participants whose REP was held on exchanges or Layer 2s to consolidate it to an Ethereum mainnet address they controlled. It also documented the following token identities for wallet recognition:

• Pre-fork REPv2 — 0x221657776846890989a759BA2973e427DfF5C9bB
• Legacy REPv1 — 0x1985365e9f78359a9B6AD760e32412f4a445E862

The procedure identified REPv2_Yes_1 at 0xCf6A0A7826fa124B7705d6f3c675eAD76f1e540D as the surviving fork token and noted that Kraken used AUGUR as its ticker for that same token. It also noted that wallets might not detect the tokens automatically, so participants manually added the token addresses. The procedure told participants who held REP in multiple places, including Layer 2s, Coinbase, or other exchanges, to consolidate it to one Ethereum mainnet address they controlled. Exchange support information and the historical exchange-support page are retained as archived references, not recommendations.

1. Opened the historical migration site

Participants opened the archived Augur Fork migration site. The link is retained to identify the interface shown in the screenshot; the migration tool is closed.

2. Connected an Ethereum wallet

Participants connected an Ethereum wallet they controlled to the historical interface. No wallet connection or transaction is available through this archived page.

3. Converted remaining REPv1 to pre-fork REPv2

The historical interface showed whether an account still held REPv1. Participants who did were directed to convert it to pre-fork REPv2 before continuing. The screenshot preserves the “You have 0 REPv1” state.

4. Early migration (optional historical phase)

The archived procedure described early migration as follows:

• Early migration was available from April 8ᵗʰ to early June.
• The system paid a 40% return for early migration to the selected outcome.
• That return came from the penalty paid by reporters who migrated to a different outcome, and the 40% return was funded by crowdsourced donations.
• Early migration carried the risk that, if less than 3.33% of REP supply migrated to the same outcome, a different outcome would win and the early participant would lose the migrated REP.
• Early migration was limited to the first 367,000 REP.
• Participants sometimes checked on different days because the migration limit grew exponentially and the procedure said that roughly 75% of early migration happened during the last several days.
• Participants who wanted to use this phase checked the archived reporting interface until it allowed migration to an outcome. The interface’s wait message described when another round might be available.

5. Waited for the fork and contract deadline

The procedure told participants to wait until June 11ᵗʰ, when the fork was expected to have enabled unlimited migration. The deployed contract later recorded the final deadline as 1785718859 (2026-08-03T01:00:59Z). That deadline has passed, and the migration window is closed.

6. Opened the historical migration page

Participants opened the archived migration page. This link is preserved as a record of the procedure’s interface, not as a current tool.

7. Migrated pre-fork REPv2 to an outcome

The historical procedure directed participants to migrate their pre-fork REPv2 to the outcome they believed was correct for the Augur market “Will the Artemis II Mission successfully liftoff in the first week of April?” It described the expected correct answer as the one likely to result in a more valuable token and usually the truthful answer; that was procedure-era guidance, not a current recommendation. The final record identified outcome index 1, Yes, as the winning outcome and REPv2_Yes_1 as the current REP token.

The procedure sent participants who were unsure to the historical Augur Discord. That community link is retained as a historical artifact. Selecting another outcome produced a different child REP token; the final record identifies REPv2_No_1 as the losing child token and does not present it as current REP.

8. Verified the resulting token

After migration, participants verified that their wallet showed REPv2_Yes_1 at 0xCf6A0A7826fa124B7705d6f3c675eAD76f1e540D when they had migrated to the winning/canonical universe. Kraken’s AUGUR ticker referred to this same current token contract.

9. Completed the late-migration path

Participants who had only used late migration had no further procedure steps after receiving the token for the selected universe. The historical procedure stated that the correct-universe token would be used for both Augur Lituus and Augur Zoltar; this page preserves that period statement rather than making a current product recommendation.

10. Claimed the early-migration bonus

Participants who had used early migration returned to the archived migration page to check for the historical bonus. The interface is closed and no claim is available through this record.

11. Redeemed fork disputes

The historical procedure told early participants to refresh possible claims, select the available claims, and redeem fork disputes. It described this as giving 140% of the early-migrated REP, with the process complete when no claim boxes remained and the additional REP appeared in the wallet. The screenshot preserves the redemption screen and the procedure’s completion state.

For additional historical context, see The Augur Fork Is Here. The screenshots, token addresses, contract deadline, and block-pinned final values above are retained for research; this page contains no active migration call to action.