Zoltar

Registers universe forks, charges the fork haircut, and mints branch-specific child REP. Zoltar source contract

Read surface

Use universes, forkThresholdDivisor, forkBurnDivisor, zoltarQuestionData, genesisReputationToken, childReputationTokenCount, getForkTime, getForkChoiceDeadline, getForkRecapitalizationDeadline, getEarliestForkTime, forkQuestionMatches, getRepToken, getForkThresholdAttoRep, getNonDecisionThresholdAttoRep, getUniverseTheoreticalSupplyAttoRep, getChildUniverseId, getDeployedChildUniverses, getMigrationRepBalanceAttoRep, and getChildMigrationRepAmountsAttoRep to reconstruct universe and migration state. The choice and recap deadlines are the native fork time plus eight and nine weeks. A child may next fork at its parent fork time plus ten weeks; origin universes have no parent cooldown. Late preparation never moves these timestamps. The child migration getter accepts an array of child universe IDs and returns cumulative amounts in the same order, with zero for unused IDs. The fork threshold is the live universe theoretical supply divided by forkThresholdDivisor, rounded up, so every nonzero-supply universe has a positive fork cost. Construction requires a deployed genesis REP token with the REPv2 getTotalTheoreticalSupply() selector, theoretical supply from one attoREP through 11 million REP, forkThresholdDivisor > 1, and forkBurnDivisor >= 5, which caps the uncredited fork haircut at 20% of the threshold. The constructor emits UniverseInitialized once, for genesis universe 0; deployChild does not emit it, so child universes are discovered through DeployChild and ChildReputationTokenInitialized. Genesis REP uses ordinary ERC-20 approvals because the configured mainnet REPv2 token does not implement ERC-2612 or ERC-3009.

Security assumptions

These calls depend on A15 intended question selection and A25 safe immutable parameters.

State-changing interactions

Each call lists its parameter names in ABI order. The contract index defines the columns.

Transaction Caller Main prerequisites State or asset effect Primary signals
forkUniverse(universeId, questionId) Any address able to fund the current fork threshold Initialized and unforked universe; existing ended question; sufficient caller REP; a child must have reached its parent fork timestamp plus ten weeks. Genesis REP requires allowance; child REP is burned directly without allowance. Records the fork, removes threshold REP from the parent universe, and credits the caller with the threshold minus the uncredited fork haircut. The REP burn events (genesis REP Transfer to the burn address, or child REP Transfer and Burn), then UniverseForked
burnRep(universeId, amountAttoRep) Any REP holder; the caller can burn only its own balance Initialized universe; positive amount; sufficient caller REP and theoretical supply. Genesis REP requires allowance. Permanently removes REP without creating migration credit; escalation settlement uses this to burn the escalation haircut when its own fork has not already paid it. The REP burn events (genesis REP Transfer to the burn address, or child REP Transfer and Burn), then RepBurned
deployChild(universeId, outcomeIndex) Anyone Parent forked; outcome is well formed; child is not already deployed. Deploys the deterministic child REP token and initializes the child universe. TheoreticalSupplySet, ReputationTokenInitialized, DeployChild, and ChildReputationTokenInitialized
addRepToMigrationBalance(universeId, amountAttoRep) Parent REP holder Universe forked; sufficient caller REP. Genesis REP requires allowance; child REP is burned directly without allowance. Burns or sinks additional parent REP and increases the caller's reusable migration balance. The REP burn events (genesis REP Transfer to the burn address, or child REP Transfer and Burn), then MigrationRepAdded
prepareAndSplitMigrationRep(universeId, amountAttoRep, outcomeIndexes, preparationAttoRep) Parent REP holder Forked universe; positive split amount; nonempty valid outcomes; sufficient parent REP for the exact preparationAttoRep supplied and sufficient migration credit for every split. Outcome order is unrestricted. Genesis REP requires allowance for preparation; child REP needs no allowance. Adds the supplied preparation amount to migration credit, then splits the requested REP into the supplied outcomes using the existing migration checks. Both steps revert together on failure. Callers compute any preparation shortfall from cumulative child migration amounts, rather than current child token holdings. The addRepToMigrationBalance signals when preparationAttoRep is positive; TheoreticalSupplySet, ReputationTokenInitialized, DeployChild, and ChildReputationTokenInitialized when children are deployed; child REP Transfer, Mint, and MigrationRepSplit for each destination
splitMigrationRep(universeId, amountAttoRep, outcomeIndexes) Migration-balance holder Universe forked; positive split amount; nonempty list of well-formed outcomes; the cumulative amount per child must not exceed the caller's migration balance. Mints amountAttoRep of child REP into every selected branch, deploying missing children lazily. TheoreticalSupplySet, ReputationTokenInitialized, DeployChild, and ChildReputationTokenInitialized when children are deployed; child REP Transfer and Mint, then MigrationRepSplit, per selected branch