How-to guide
Handle a universe fork
A fork closes the parent pair for swaps and additions and leaves every migration decision to you. This guide walks through moving a position into the child universe or universes you choose.
Migrate a position
- Remove parent LP into parent YES and NO shares (Remove liquidity).
- Decide the destination branch or branches for each of your INVALID, YES, and NO balances. Nothing in Trading chooses a branch or migrates LP for you.
- For every nonzero parent balance you intend to migrate, submit one
ShareToken.migrate(fromId, targetOutcomeIndexes)call with that token ID and the explicitly chosen, strictly increasing target outcome indexes. Each call mints the matching child-universe share balance. The parent balance stays visible, but that source token ID is locked for the wallet and can no longer be transferred. - After each call, verify the expected child token ID and balance, then refresh or discover the canonical child SecurityPool.
- Wait until migration and truth-auction processing return the child to
Operational, then create a new pair for that exact child pool. Parent and child token IDs and reserves remain isolated.
Choose fork targets
Source and destination are independent: a parent INVALID, YES, or NO share can migrate into any valid branch of the fork question, and the child receives the same share outcome as the source. Migrating parent YES into three scalar branches, for example, produces child YES shares in all three children.
- For a categorical fork, select Invalid or one or more labeled answers.
- For a scalar fork, select Invalid or add one or more exact scalar ticks. The UI displays the human value and derives the packed onchain outcome index.
A single-target call may create a missing child SecurityPool. A multi-target call must reference children whose canonical pools already exist. To migrate one source share to several new scalar outcomes, submit each missing outcome by itself; locking prevents transfers but not later migration of the same source into a new child. Once those children exist, another source share can target all of them in one call. Every call must add at least one source-and-child entitlement the wallet has not migrated before.
In the live UI
The Fork migration action loads the actual fork question, keeps the INVALID/YES/NO source selector separate from its categorical or scalar target picker, and accepts many target branches. It simulates the exact ShareToken.migrate call before submission and states that the entire selected source balance is copied and locked. Repeat the workflow for each source share you intentionally choose. Forks and resolution explains why the pair behaves this way.