Deployment status oracle
DeploymentStatusOracle is a deployment-progress helper. It does not measure protocol readiness or initialization success. It only reports which configured deployment-step addresses currently contain runtime bytecode.
What getDeploymentMask() returns
The constructor stores one ordered address[] deploymentAddresses. getDeploymentMask() loops over that array and checks deploymentAddresses[index].code.length. When code exists, the oracle sets bit index in the returned uint256.
This is a code-presence bitmap. A set bit means code exists at the configured address. A clear bit means the address currently has no code. The oracle does not verify constructor arguments, ownership wiring, or post-deployment setup.
Deployment status maskEach configured deployment step uses one bit position in the returned word. The oracle sets that bit only if the step's address currently contains code.
Each configured deployment step contributes one bit position to the returned word.
How bits map to deployment steps
Bit positions are array positions. Bit 0 maps to the first constructor address, bit 1 to the second, and so on. Off-chain decoding must use the same ordered list that seeded the oracle.
The constructor emits DeploymentAddressesSet(address[] deploymentAddresses) with that exact ordered list. It is the on-chain source for recovering a particular oracle instance's bit mapping. The manifest below describes the current planned deployment and must match the constructor event for that instance.
The current user interface (UI) and deployment helpers derive the constructor list from deploymentSteps with one exception: the oracle does not include its own address in its constructor array. The manifest still lists deploymentStatusOracle as a deployment step, but the UI tracks that step out of band and starts consuming mask bits from the remaining addresses.
The tables below render the complete bit mappings directly from the canonical mainnet deployment manifest and Sepolia deployment manifest, excluding deploymentStatusOracle. These tables use the Yes manifests. The mainnet No manifest and Sepolia No manifest use the same bit order with their own deployment addresses. Each manifest's ordered deploymentSteps array is the canonical mapping for its network and genesis outcome. The orders differ: Sepolia inserts the genesis REP token at bit 1, so the same mask names different steps on each network. Select the network before decoding.
A second, Zoltar-only oracle is deployed by the Zoltar app's deployment flow and by the testnet deployer for each genesis outcome. The four manifests omit these oracles and the Trading factory and router. The testnet plan identifies the oracles as yes:zoltarDeploymentStatusOracle and no:zoltarDeploymentStatusOracle, and applies the same outcome prefixes to tradingFactory and tradingRouter. Each oracle's constructor list is a prefix of its manifest mapping: the proxy deployer, genesis REP on Sepolia, Multicall3, ZoltarQuestionData, and Zoltar. Decode its mask with the same table; only those leading bits exist.
| Bit | Mainnet step id | Label | Status in entered mask |
|---|---|---|---|
| Loading the canonical manifest… | |||
| Bit | Sepolia step id | Label | Status in entered mask |
|---|---|---|---|
| Loading the canonical manifest… | |||
If the manifest's constructor order changes, the rendered bit meanings change with it; this page does not maintain a second list.
The manifest's derivedContracts list adds no mask bits. Five of its six entries (securityPoolForker, escalationGameClaimDelegate, escalationGameFactory, securityPoolFactory, and securityPoolOperationsDelegate) repeat a deploymentSteps address under a different label, so each already has a bit. Only escalationGameProofVerifier, which EscalationGameFactory deploys in its constructor, has no bit. The tables use the deploymentSteps labels.
In the Sepolia manifest the genesis REP step has the id reputationToken and the label GenesisReputationToken. It is the token at network.genesisRepTokenAddress, not a child ReputationToken.
Decode a deployment mask
The decoder maps each set bit to the selected network's constructor address at the same index.
Why the cap is 256 steps
The constructor requires deploymentAddresses.length <= uint256(type(uint8).max) + 1, which is 256. The limit exists because the result is a single uint256, and each tracked step consumes one bit.
Indices 0 through 255 are supported. A deployment process with more than 256 tracked addresses must split status across multiple masks or use a different representation.
Interpretation and verification boundaries
| Evidence | What it proves | What it does not prove |
|---|---|---|
| Bit set | Runtime bytecode exists at the configured address. | Correct bytecode, constructor values, wiring, permissions, or operational readiness. |
| Bit clear | No runtime bytecode was observed at that address by this call. | Whether the address is intentionally empty or the manifest is wrong. |
| Manifest match | The decoder used the intended ordered address list for the network. | That deployed code matches the release or that remote procedure call (RPC) responses are honest. |
| Full deployment verification | Code hashes, required wiring, permissions, and manifest provenance can be checked together. | Economic safety or future operational liveness. |
Static decoder test vectors
| Mask | Meaning |
|---|---|
0x0 |
No tracked constructor address contains runtime code. |
0x1 |
Only constructor address index 0 is present. |
0x5 |
Constructor address indices 0 and 2 are present. |
2^255 |
Only the highest supported bit, index 255, is present. |