Deployment Status Oracle
Security assumptions: A23 verified canonical deployments and A24 client and RPC integrity.
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.
The canonical mainnet and Sepolia manifests list this contract directly, so operators and frontends need a precise explanation of the returned bitmask and the built-in 256-step ceiling.
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 args, ownership wiring, or post-deployment setup.
Deployment Status MaskEach configured deployment step owns one bit position in the returned word. The oracle sets that bit only if the step's address currently contains code.
Deployment BitmaskEach 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. Offchain 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 onchain 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 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 and
Sepolia deployment manifests,
excluding deploymentStatusOracle. Each manifest's ordered
deploymentSteps array is the canonical mapping for that network.
| Bit | Mainnet step id | Label | Status in entered mask |
|---|---|---|---|
| Loading the canonical manifest… | |||
Decode a mainnet deployment mask
Paste the decimal or hexadecimal uint256 returned by the mainnet
getDeploymentMask(). The status column above updates against the
mainnet constructor order. Sepolia has a different order; use the Sepolia table
below instead of this decoder when interpreting its mask.
Decoded status:
Bits above the tracked manifest range are reported separately.
| Bit | Sepolia step id | Label |
|---|---|---|
| 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 is separate. Those addresses are
not part of the deployment-status mask unless they also appear in the constructor
array.
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...255 are supported. A deployment process with more than
256 tracked addresses must split status across multiple masks or use a
different representation.
Sources
DeploymentStatusOracle.solui/ts/protocol/deployment.tsbuilds the constructor address list and decodes the returned mask for the UI.mainnet-deployment-addresses.jsonsepolia-deployment-addresses.json