Detailed Instructions

Begin by reviewing the upgrade proposal and its associated technical specifications. Determine if the changes are to the core sequencer, state transition function, data availability layer, or bridge contracts. A change to the bridge's proving mechanism, for example, introduces a different risk profile than a tweak to gas parameters. Map the new and modified components against a threat model.

• Sub-step 1: Identify all smart contract addresses being upgraded (e.g., 0x1234... for the L1 Escrow, 0xabcd... for the L2 rollup contract).
• Sub-step 2: Review the diff of the proposed code against the current deployment to pinpoint logic changes.
• Sub-step 3: Evaluate the trust assumptions for any new external dependencies or oracles introduced.

solidityCopy
// Example: Checking if a critical state variable is now mutable
contract BridgeV1 {
    address public immutable guardian; // Immutable in V1
}
contract BridgeV2 {
    address public guardian; // Now upgradeable in V2 - Increased risk!
}

Tip: Use a tool like git diff or a dedicated audit platform to visualize code changes systematically.

Detailed Instructions

Scrutinize the governance mechanism that will authorize the upgrade. For decentralized autonomous organizations (DAOs), check the proposal's voting period, quorum requirements, and the multisig signer set if applicable. Determine if there is a timelock period between proposal approval and execution; a standard security practice is a delay of at least 48-72 hours. Verify the upgrade executor contract (e.g., a ProxyAdmin or TimelockController) and confirm its current admins.

• Sub-step 1: Locate the governance contract address (e.g., a Governor contract at 0xgov...) and verify the proposal ID.
• Sub-step 2: Confirm the timelock duration by calling getMinDelay() on the timelock contract.
• Sub-step 3: Check the upgrade paths are correctly configured and cannot bypass governance, such as ensuring a TransparentUpgradeableProxy points to the correct admin.

Tip: A missing or short timelock is a critical red flag, as it prevents community reaction to a malicious proposal.

Detailed Instructions

Focus on the safety of user funds held in bridges and the consistency of the L2 state root. An upgrade must guarantee that all pre-upgrade assets remain accessible and that the state transition is cryptographically verifiable. For optimistic rollups, ensure the upgrade does not alter the rules for fraud proof submission or finalization. For ZK-rollups, verify the new verifier contract is sound and the upgrade does not introduce a vulnerability that could allow invalid state roots to be confirmed.

• Sub-step 1: Audit the migration script for any logic that could incorrectly map user balances or leave funds stranded.
• Sub-step 2: Verify that the upgrade mechanism does not have the ability to arbitrarily mint or freeze tokens in the bridge.
• Sub-step 3: Confirm that the data availability commitment for pre-upgrade transactions remains accessible and valid.

javascriptCopy
// Example: Simulating a balance check post-upgrade
const preUpgradeBalance = await bridgeContract.balanceOf(userAddress, blockNumberBeforeUpgrade);
const postUpgradeBalance = await bridgeContractV2.balanceOf(userAddress);
// These values must be equal

Tip: Pay special attention to edge cases like pending withdrawals or unresolved fraud challenges during the upgrade window.

Detailed Instructions

A secure upgrade process includes post-upgrade monitoring and a clear rollback plan. Determine if the team has prepared monitoring dashboards for key health metrics like sequencer liveness, transaction success rates, and bridge activity. Investigate the technical feasibility of a rollback. For some L2 architectures, a rollback may be impossible; in such cases, a graceful shutdown and user migration plan is essential. Check if emergency multisig keys are held by diverse, reputable entities and if their use requires a cool-down period.

• Sub-step 1: Request and review the incident response runbook for the specific upgrade.
• Sub-step 2: Identify the circuit breaker functions in the new contracts (e.g., pause(), emergencyStop()).
• Sub-step 3: Verify the process and required signatures for invoking emergency measures.

Tip: The absence of a documented and tested rollback or emergency plan significantly increases the systemic risk of the upgrade.