Obsidian Rollup

A proxy keeps its state in its own storage and executes the implementation's code against it. Every implementation must therefore preserve the slot assignment of existing variables; new variables may only be appended or placed in dedicated namespaces.

The v1 OutputOracle declares, in order, startingBlockNumber, startingTimestamp, l2Outputs (a dynamic array) and finalizationPeriodSeconds set during initialisation. The v2 implementation adds uint256 public proposalBond as the first state variable, before startingBlockNumber. After the upgrade every existing variable is read one slot later: startingTimestamp reads the old startingBlockNumber, the array length of l2Outputs is read from the old startingTimestamp slot, and finalizationPeriodSeconds reads the slot that previously held the length of l2Outputs.

Because finalizationPeriodSeconds would equal the number of outputs proposed so far (a few thousand), the seven-day challenge window would shrink to roughly an hour. The upgrade script calls upgradeToAndCall with no layout validation, so the shift would have taken effect on execution.

Loss of bridged funds held by the Portal and invalid L2 state accepted on L1. The finding was caught before the upgrade was proposed; no deployed contract was affected.

Append new variables after existing ones or move state into an EIP-7201 namespaced struct. Add an automated storage-layout comparison between the deployed and new implementations to the upgrade pipeline and refuse to produce upgrade calldata when the check fails.

Fixed. New state lives in a namespaced struct, and the upgrade pipeline now diffs forge inspect storageLayout output against the deployed implementation and fails on any change to existing slots.

The ProxyAdmin that controls every L1 proxy is owned directly by a 2-of-3 operations multisig. An upgrade takes effect in the block it is executed. Users therefore have no window to withdraw if they disagree with an upgrade, and a compromise of two operations signers would give immediate control of all bridged funds.

Rollups at this stage commonly keep an emergency upgrade path, but separate it from routine upgrades, which pass through a public delay longer than the withdrawal period so that users can exit first.

Total loss of bridged assets in a key-compromise scenario. No defect in contract logic.

Route routine upgrades through a timelock longer than the withdrawal period (at least eight days) and reserve instant upgrades for the security council, with that power documented and monitored.

Partially resolved. Routine upgrades now pass through a 48-hour UpgradeTimelock, shorter than the eight days recommended, so users still cannot always exit before an upgrade takes effect; the 4-of-7 security council retains an instant path for emergencies, which Obsidian documents in its public risk disclosures.

When a withdrawal is proven, the Portal records the dispute game that backs the output root and the proof timestamp. _checkWithdrawal later verifies that PROOF_MATURITY_DELAY has passed since proving and that game.status() != GameStatus.CHALLENGER_WINS.

The check is phrased as "not lost" rather than "won". A game that is still IN_PROGRESS passes it. Dispute games can legitimately run longer than the proof-maturity delay when bisection is deep and both parties use their full clocks, so a withdrawal proven against an output that is under active dispute can be finalised before the game concludes. If the challenger later wins, the withdrawal has already been paid.

The OP Stack design that Obsidian follows requires the game to have resolved in favour of the defender and an additional "air-gap" delay after resolution, during which a guardian can blacklist a game resolved incorrectly.

Theft of Portal funds by a malicious proposer despite an honest challenger, defeating the purpose of fault proofs.

Require game.status() == GameStatus.DEFENDER_WINS and block.timestamp − game.resolvedAt() > DISPUTE_GAME_FINALITY_DELAY, and let the guardian blacklist games during that delay.

Fixed as recommended with a 3.5-day finality delay and a guardian blacklist. Differential tests against the specification behaviour pass.

Anyone may finalise any proven withdrawal. The Portal executes the withdrawal's target call with gasleft() and, if the call fails, leaves finalizedWithdrawals[hash] unset so that it can be retried.

Two problems follow. First, a griefer can finalise someone else's withdrawal with just enough gas for the Portal's own logic but too little for the target call; because of the 63/64 rule the call fails while the outer transaction succeeds. Second, the failed withdrawal remains open indefinitely and can be executed later by anyone, at a moment the original sender did not choose, for example after the target contract has changed state.

The specification addresses this by recording the withdrawal as finalised whether or not the call succeeds and by refusing to make the call unless enough gas remains to forward the withdrawal's declared gas limit.

Withdrawals fail or execute in unexpected states; funds can be stranded in contracts that no longer handle them.

Mark the withdrawal finalised before the call, and require SafeCall.hasMinGas(gasLimit, RESERVED_GAS) so that the declared gas limit is always forwarded.

Fixed. Withdrawals are final after one attempt and the declared gas is guaranteed to the target.

The batcher records a frame as confirmed when its transaction receipt is returned and then prunes the frame from memory. Confirmation is checked once, at the first receipt. If the L1 block containing the batch is reorganised out, the transaction may never be re-included (the batcher has already moved its nonce forward and later transactions fill the gap), and the frame is gone.

Derivation on L2 cannot advance the safe head past the missing frame until the channel times out, after which the corresponding L2 blocks are re-derived without those transactions. In practice this halts finality for the duration of the channel timeout and can reorder user transactions.

Liveness degradation of L2 finality; bridges and exchanges relying on the safe head stop crediting deposits.

Track confirmations by block hash, keep frames until they are buried under a configurable confirmation depth, and requeue frames whose inclusion block is no longer canonical.

Fixed. Frames are retained until ten confirmations and requeued when their block leaves the canonical chain; a devnet reorg test reproduces the original stall and passes after the fix.

Deposits submitted to the Portal must be included at the start of L2 blocks. The Portal checks only that the requested L2 gas limit is above a minimum derived from calldata size; nothing charges the depositor for the L2 gas they reserve.

An attacker can submit many deposits with large gas limits from L1, paying only L1 gas. Each deposit reserves L2 block gas, crowding out sequenced transactions and raising L2 fees for everyone. Designs derived from the OP Stack meter deposit gas with an EIP-1559-style market on L1, burning L1 gas proportional to the L2 gas purchased.

Degraded L2 throughput and elevated fees; sequenced transactions may be delayed.

Introduce resource metering for deposits: track L2 gas purchased per L1 block, adjust a base fee toward a target, and burn the corresponding L1 gas from the depositor.

Fixed with a ResourceMetering base contract and parameters stored in SystemConfig.

deleteL2Outputs(index) lets the CHALLENGER role remove outputs from index onward. It checks that the index exists but not that the outputs are still within the finalisation period. A mistaken or compromised challenger could delete finalised outputs, invalidating proofs for withdrawals that users have already proven and forcing them to re-prove against new outputs.

Delayed withdrawals and operational disruption; no direct loss.

Revert if the first deleted output is already finalised.

Fixed as recommended.

On start-up the batcher prints its full configuration struct with log.Debug("config", "cfg", cfg). The struct contains the L1 RPC URL with an embedded API token and, when a local key is used instead of a remote signer, the private key in hex. Debug logging is enabled in the staging environment and logs are shipped to a shared aggregation service.

Compromise of the batcher key allows posting arbitrary batch data, disrupting derivation until the key is rotated in SystemConfig.

Implement redaction for secret fields and use a remote signer in every environment.

Fixed. Secrets are redacted and staging now uses the remote signer.

Configuration changes emit a generic ConfigUpdate(version, type, data) event with ABI-encoded data. Monitoring has to decode the payload to distinguish a gas-limit change from a batcher rotation, which slows alerting on the most sensitive change (batcher key rotation).

Slower detection of configuration changes.

Keep the generic event for compatibility and add typed events for batcher and resource-configuration changes.

Acknowledged. Obsidian keeps the generic event for tooling compatibility and has added decoding rules to its monitoring.