Migratable objects in Augur
This page covers the details of what objects in the Augur system of contracts are migratable between parent and child universes. However all objects are not covered on this page, but only those that are likely to directly affect end users.
Hierarchical Relationships between Objects
The objects in the universe form a hierarchical relationship with the universe as a top.
The universe has REP, Market, and Dispute Window attached. And Market and Dispute Window have some attached objects, while REP doesn’t have any attached object. The point is that when forks occur, the lower objects migrate where their upper object migrates, and if the upper object may not migrate then their lower objects may not migrate. Of course, there are some exceptions, but this principle might help you understand the migration of the objects.
Overview
The following figure shows where the objects in the parent universe are migrated after a fork. (Click to enlarge)
The red objects can only be migrated to the winning universe, the blues can only be migrated to the losing universe, the purples can be migrated to one of the child universes, and the greens cannot be migrated to any child universe.
Before a fork, all objects are in the parent universe. After a fork, in the parent universe, there are the finalized markets, dispute windows, and the objects which are attached to them. The winning universe and the losing universe are created, and the forking market, non-finalized markets, and REP are migrated to them.
This can be summarized as follows:
- The migratable objects are:
- Forking market
- Non-Finalized Markets
- REP
- The un-migratable objects are:
- Finalized Markets
- Dispute Windows
- The winning universe receives:
- Forking market and its attached objects
- Non-Finalized markets
- REP
- The losing universe receives:
- Forking market
- REP
Child universe is created by REP holders
A child universe is created when the REP holder who first migrates their REP to it. Even if the forking market has finalized or the forking period ends, the child universe is not created without migrating REP. And the REP holder who first migrates their REP has to pay not only the transaction fee of migrating their REP, but also the transaction fee of creating the child universe.
Migration of Forking Market
Market Itself
The forking market is duplicated in each child universe. In a child universe, the forking market is finalized as the outcome that aligns with that particular child universe. (See basic knowledge for details on how child universes are created.)
This duplication occurs when the child universe is created. This happens when the first REP holder migrates their REP to that child universe.
Staked REP
The staked REP on any outcome of the forking market is migrated to the child universe corresponding to the staked outcome.
That REP will be unstaked and refunded to their owners in a child universe when the migration has done. They will also receive a 40% ROI in additional REP minted in the universe they staked on prior to the fork.
Attached Objects
The objects which are attached to the forking market are:
When the for is finalized, those objects are migrated to the winning universe by the Augur contracts automatically.
Regarding validity bond, which is paid by the market creator when creating the market, if the corresponding outcome of the winning universe is Invalid, this bond is paid out to participation token holders in proportion to the amount of participation token in the winning universe. If not Invalid, this bond is returned to the market creator in the winning universe.
As to creation bond, which is also paid by the market creator, no longer exists at the time of forking. Since this bond is already used by the designated reporter or the first public reporter as the initial reporter’s stake after the market’s event end time.
Migration of Non-Forking Markets (not finalized)
Market Itself
The non-forking markets which are not finalized can be migrated only to the winning universe. To migrate those markets, you need to make a transaction for that explicitly. It can be done by anyone, not just the market creator, and anytime after finalizing the forking market. It is one-way and cannot be reversed.
When you migrate a market, you need to supply creation bond (which is normally paid by the market creator when creating the market) and you become the initial reporter of the market in the winning universe. And if the market is past its event end time in the parent universe, the market is reset back to needing an initial reporting, and you need to submit the initial report for the market. At this time, the creation bond that you supplied when you migrate a market is used as the initial reporter’s stake.
The reason for this is that all of the REP locked in the non-forking markets in the parent universe is refunded to its respective owners when a fork starts (so that they migrate their REP to a child universe during the forking period), the first reporter must cover the first report REP costs themselves.
The migration of the non-forking markets is not mandatory. Even if a fork ends, you can still trade and settle your shares on the markets in the parent universe (See restrictons on use for details). However, after a fork starts, markets in the parent universe cannot be finalized. For the market to be finalized, you need to migrate it to the winning universe.
The migration of the non-forking markets can be done by anyone who wants to, but especially the market creator and the traders who have shares in the market may want to do. Since for the market creator to receive the creator fees and for the traders to claim a payout of their shares, the market needs to be finalized (However creator fees are forfeit in invalid markets). It might give them an incentive to migrate markets.
Staked REP
When a fork starts, all staked REP on the non-forking markets are un-staked and refunded to REP holders who staked it so that they migrate their REP during the forking period.
Attached Objects
The objects which are attached to the non-forking market are:
Those objects go where the market goes, they cannot be migrated separately.
Creation bond, which is paid by the market creator when creating the market in the parent universe, is refunded to either the market creator or the initial reporter. At the time of starting a fork, if the market has not received an initial reporting, this bond is refunded to the market creator. If it already has received the initial report, then it refunds the initial reporter. Because “received the initial reporting” means that the creation bond is already used by the initial reporter as the initial reporter’s stake.
Migration of REP in Wallet
All REP in the parent universe that are not staked on any outcome of the forking market can be migrated to one of the child universes by their owner. The migration of REP must be done during the forking period which lasts 60 days after the fork starts. After the forking period, the REP in the parent universe can never be migrated to any child universe (See to-do’s for details).
If you are the first person to migrate REP to a child universe, child universe creation is triggered and the forking market is also copied into it. In this case, you have to pay the transaction fee not only for migrating your REP but also for creating the child universe and copying the forking market.
Un-migratable objects
Finalized Markets
Finalized markets and their attached objects (shares, unfilled orders, and creator fee) can not be migrated. However, you can still trade and settle your shares on the markets during/after a fork.
Dispute Windows
Dispute Windows and their attached objects (reporting fee pool, reporting fees, validity bonds, creator fees, and participation tokens) can not be migrated.
Before and after a fork, there is no change in the features of a dispute window. This means Augur collects reporting fees, validity bonds, and creator fees, and adds those to reporting fee pool during a dispute window. At the end of the dispute window, the pool is paid out to participation token owners in proportion to the amount of participation token.
In the parent universe, anytime you can purchase participation tokens, and redeem them. By redeeming them, the REP that you paid to get the token return to you. Therefore, participation token owners who want to migrate their REP MUST redeem their tokens and migrate their REP within 60 days after a fork starts.