Base Security: OP Stack Assumptions and What Auditors Check

Base is an Ethereum L2 built on the OP Stack, the modular rollup framework developed by Optimism. Deploying on Base means inheriting a specific security model — one that diverges from Ethereum mainnet in meaningful, sometimes counterintuitive ways. Contracts that behave correctly on L1 may break, become exploitable, or silently introduce trust assumptions when ported to Base without adjustment.

This article walks through every layer of the OP Stack that a security-conscious developer or auditor must understand: the architecture and its components, the sequencer’s centralization trade-offs, the withdrawal lifecycle, cross-domain messaging, timestamp behavior, predeploy contracts, and the complete set of differences from Ethereum that affect contract security. It closes with a deployment checklist covering every item auditors specifically flag for OP Stack targets.

OP Stack Architecture

The OP Stack separates concerns across three logical domains: the L2 execution environment, the derivation pipeline, and the L1 settlement layer.

┌─────────────────────────────────────────────────────┐
│                   Ethereum L1                        │
│  ┌──────────────────┐   ┌────────────────────────┐  │
│  │  OptimismPortal  │   │  L2OutputOracle /      │  │
│  │  (deposits &     │   │  DisputeGameFactory    │  │
│  │   withdrawals)   │   │  (output proposals)    │  │
│  └──────────────────┘   └────────────────────────┘  │
└──────────────────────────────┬──────────────────────┘
                               │ state roots / calldata / blobs
┌──────────────────────────────▼──────────────────────┐
│                   OP Stack Node                      │
│  ┌──────────────┐  ┌──────────────┐  ┌───────────┐  │
│  │  op-node     │  │  op-geth     │  │ Sequencer │  │
│  │ (rollup node)│◄─│ (exec engine)│◄─│ (batcher) │  │
│  └──────────────┘  └──────────────┘  └───────────┘  │
└─────────────────────────────────────────────────────┘

Key Components

Component	Role
`op-node`	Derives the canonical L2 chain from L1 data
`op-geth`	Modified go-ethereum that executes L2 blocks
Sequencer / Batcher	Orders and submits L2 transactions to L1
`OptimismPortal`	L1 contract accepting deposits and finalizing withdrawals
`L2OutputOracle` / `DisputeGameFactory`	Stores proposed L2 state roots for verification
`CrossDomainMessenger`	High-level bridge for cross-chain message passing
`StandardBridge`	Token bridge built on top of the messenger

The derivation pipeline guarantees that any L2 state can be reconstructed purely from L1 data. This is the bedrock of the rollup’s security model — L1 is the source of truth, not the sequencer.

The Sequencer and Its Centralization Assumptions

What the Sequencer Does

The sequencer is the entity that:

Receives user transactions via the standard RPC endpoint
Orders those transactions into L2 blocks
Executes blocks via op-geth
Batches and compresses L2 transaction data, posting it to L1 as calldata or EIP-4844 blobs
Proposes L2 output roots to the L2OutputOracle or DisputeGameFactory

Centralization Risk

Base, like all current OP Stack deployments, runs a single, permissioned sequencer operated by Coinbase. This creates a set of explicit trust assumptions that every deployed contract must be designed around:

Liveness assumption. If the sequencer goes offline, users cannot have their transactions included via the normal path. However, they retain the ability to submit transactions directly to L1 via the OptimismPortal’s depositTransaction function — a censorship-resistance escape hatch that the sequencer cannot block.

Ordering assumption. The sequencer can reorder transactions within a batch. It cannot, however, insert transactions that users did not sign (excluding system transactions), and it cannot reorder transactions that have already been finalized on L1. This is a weaker guarantee than L1 Ethereum’s mempool model but stronger than a fully trusted third-party.

MEV exposure. Because the sequencer controls ordering, it can extract MEV. Protocols relying on fair ordering, commit-reveal schemes, or auction mechanics should be designed assuming an adversarial sequencer with respect to ordering — not message content.

What Contracts Should Assume

// UNSAFE: relying on tx.origin for sequencer-level protections
// The sequencer could front-run or sandwich any transaction.
// SAFE: treat the sequencer as a rational but potentially adversarial
// ordering authority. Use commit-reveal to prevent front-running.

contract AuctionWithCommitReveal {
    struct Commitment {
        bytes32 hash;
        uint256 revealDeadline;
    }

    mapping(address => Commitment) public commitments;
    mapping(address => uint256) public bids;

    function commit(bytes32 _hash, uint256 _revealDeadline) external {
        commitments[msg.sender] = Commitment(_hash, _revealDeadline);
    }

    function reveal(uint256 _bid, bytes32 _salt) external {
        Commitment memory c = commitments[msg.sender];
        require(block.timestamp <= c.revealDeadline, "Reveal window closed");
        require(
            keccak256(abi.encodePacked(_bid, _salt)) == c.hash,
            "Hash mismatch"
        );
        bids[msg.sender] = _bid;
        delete commitments[msg.sender];
    }
}

Key auditor check: Does any contract assume fair ordering, FIFO execution, or protection from sequencer-level MEV without an explicit mechanism (commit-reveal, TWAP, time-weighted averaging)?

The Two-Step Withdrawal Process and Finality Implications

Withdrawals from Base to Ethereum follow a two-step process enforced by the OptimismPortal. This is architecturally different from L1-to-L1 transfers and introduces time-locked finality that contracts on both sides must handle explicitly.

Step 1 — Initiate Withdrawal on L2

A user or contract calls L2ToL1MessagePasser.initiateWithdrawal (or indirectly via L2CrossDomainMessenger). This emits a MessagePassed event and records a withdrawal hash in the contract’s storage. No L1 transaction happens yet.

// Simplified view of what L2ToL1MessagePasser records
struct WithdrawalTransaction {
    uint256 nonce;
    address sender;
    address target;
    uint256 value;
    uint256 gasLimit;
    bytes   data;
}

Step 2 — Prove and Finalize on L1

After the L2 state root containing the withdrawal is proposed on L1 (via L2OutputOracle or a dispute game), the user must:

Prove the withdrawal by submitting a Merkle proof against the proposed output root. This is recorded in OptimismPortal.provenWithdrawals.
Wait for the challenge window (currently 7 days for the standard optimistic verification path) to elapse without a successful fault proof invalidating the root.
Finalize the withdrawal by calling OptimismPortal.finalizeWithdrawalTransaction. Only then are funds released on L1.

L2 tx ──► initiateWithdrawal ──► [wait for output proposal] ──►
proveWithdrawal ──► [7-day challenge window] ──► finalizeWithdrawal ──► L1 funds released

Security Implications

Reentrancy across the bridge. The finalizeWithdrawalTransaction function calls an arbitrary target on L1 with arbitrary data. L1 contracts that act as withdrawal targets must be reentrancy-safe. The OptimismPortal itself marks a withdrawal as finalized before making the external call, but the receiving contract has no such guarantee.

// L1 contract acting as a withdrawal target MUST be reentrancy-safe
contract L1WithdrawalReceiver is ReentrancyGuard {
    event Received(address sender, uint256 amount, bytes data);

    // Called by OptimismPortal during finalizeWithdrawalTransaction
    function receiveMessage(bytes calldata data) external nonReentrant {
        // Process the bridged message
        emit Received(msg.sender, msg.value, data);
    }

    receive() external payable nonReentrant {
        emit Received(msg.sender, msg.value, "");
    }
}

Double-finalization. The OptimismPortal tracks finalized withdrawals in a finalizedWithdrawals mapping. Contracts that maintain their own state about bridge messages must implement equivalent replay protection — they cannot rely solely on the bridge.

Output root replacement. In fault-proof-enabled deployments, a proven withdrawal can be invalidated if the dispute game it was proven against is resolved as invalid. Contracts must not treat a proven withdrawal as equivalent to a finalized withdrawal.

Key auditor checks:

Does any L1 contract callable by the portal implement reentrancy guards?
Does any protocol treat a proven-but-not-finalized withdrawal as “received”?
Does any off-chain indexer emit events or trigger state changes based on proveWithdrawal rather than finalizeWithdrawal?

Cross-Domain Messenger Security

The Messenger Stack

User/Contract (L2)
    │
    ▼
L2CrossDomainMessenger
    │  calls
    ▼
L2ToL1MessagePasser.initiateWithdrawal(...)
    │
    [L1 settlement + 7-day window]
    │
    ▼
OptimismPortal.finalizeWithdrawalTransaction(...)
    │  calls
    ▼
L1CrossDomainMessenger.relayMessage(...)
    │  calls
    ▼
Target L1 Contract

The CrossDomainMessenger contracts add replay protection, versioned message encoding, and a xDomainMessageSender context on top of the raw portal.

`xDomainMessageSender` — The Central Auth Primitive

On the receiving side, a contract must verify that the caller is the CrossDomainMessenger and that messenger.xDomainMessageSender() is the expected counterpart on the other domain.

// CORRECT cross-domain auth pattern
contract L1Receiver {
    address public immutable L1_MESSENGER;
    address public immutable L2_COUNTERPART;

    constructor(address _messenger, address _l2Counterpart) {
        L1_MESSENGER = _messenger;
        L2_COUNTERPART = _l2Counterpart;
    }

    modifier onlyFromL2Counterpart() {
        require(
            msg.sender == L1_MESSENGER,
            "Caller is not the L1 CrossDomainMessenger"
        );
        require(
            IL1CrossDomainMessenger(L1_MESSENGER).xDomainMessageSender()
                == L2_COUNTERPART,
            "xDomainMessageSender is not the expected L2 contract"
        );
        _;
    }

    function executeAction(bytes calldata payload) external onlyFromL2Counterpart {
        // safe to process cross-domain message
        _processPayload(payload);
    }

    function _processPayload(bytes calldata payload) internal { /* ... */ }
}

Common Messenger Vulnerabilities

Insufficient sender validation. A contract that checks only msg.sender == L1_MESSENGER but not xDomainMessageSender can be called by anyone who can trigger a message through the messenger from any L2 address — not just the intended counterpart.

Gas griefing. The messenger passes a minGasLimit parameter. If the target function consumes more gas than specified and the transaction reverts, the message is not automatically retried on the L2 side. Protocols must account for failed deliveries and implement replay or recovery mechanisms.

Message version mismatch. OP Stack uses versioned message encoding. Contracts parsing raw data fields from messenger calls must handle version prefixes correctly.

// Checking message version in a low-level receiver
function _decodeMessage(bytes calldata data)
    internal
    pure
    returns (uint16 version, bytes memory payload)
{
    // First 2 bytes encode the message version
    version = uint16(bytes2(data[0:2]));
    payload = data[2:];
}

Key auditor checks:

Is both msg.sender and xDomainMessageSender validated in every cross-domain receiver?
Are failed message deliveries handled, or do they silently brick funds?
Are gas limits estimated conservatively to prevent out-of-gas failures during relay?

`block.timestamp` Behavior on Base

How Timestamps Are Set

On OP Stack chains, block.timestamp is set by the sequencer. Each L2 block receives a timestamp, but the relationship between L2 timestamps and real-world time differs from Ethereum mainnet in two ways:

Block time is not fixed. OP Stack targets a 2-second block time, but blocks can be produced faster or slower depending on sequencer behavior. Multiple transactions can share the same block (and thus the same block.timestamp).
Sequencer discretion. The sequencer may assign timestamps that are ahead of real time by a bounded amount (the max_sequencer_drift parameter). Timestamps are required to be monotonically non-decreasing, but they can leap forward.

Practical Implications

Time-locked contracts. Any contract using block.timestamp for time locks — vesting schedules, auction deadlines, loan expirations — can be affected by sequencer timestamp manipulation within the allowed drift.

// VULNERABLE: Using block.timestamp for a precise 1-hour lock
// The sequencer can advance timestamp up to max_sequencer_drift seconds
contract TimeLock {
    uint256 public unlockTime;

    constructor() {
        unlockTime = block.timestamp + 1 hours;
    }

    // If max_sequencer_drift > 3600, sequencer could set timestamp
    // such that this passes immediately after construction
    function withdraw() external {
        require(block.timestamp >= unlockTime, "Still locked");
        payable(msg.sender).transfer(address(this).balance);
    }
}

// SAFER: Use L1 block number as an approximation for long durations,
// or use block.number with conservative assumptions about block time
contract TimeLockSafer {
    uint256 public unlockBlock;
    // Assume ~2s per block; 1800 blocks ≈ 1 hour (conservative)
    uint256 public constant LOCK_BLOCKS = 1800;

    constructor() {
        unlockBlock = block.number + LOCK_BLOCKS;
    }

    function withdraw() external {
        require(block.number >= unlockBlock, "Still locked");
        payable(msg.sender).transfer(address(this).balance);
    }
}

block.number on L2. On OP Stack, block.number reflects the L2 block count, not the L1 block number. This is a critical difference from some older L2 designs. If you need the L1 block number, use the L1Block predeploy.

Key auditor checks:

Are any deadlines or locks sensitive to timestamp manipulation within the sequencer’s drift window?
Does the protocol distinguish between L2 block.number and L1 block number?
Are TWAPs or price oracles using block.timestamp in a way that assumes Ethereum mainnet timing?

Predeploy Contracts and Their Trust Model

OP Stack ships with a set of predeploy contracts — system contracts at fixed addresses on every OP Stack chain. They are not deployed by users and are managed by the chain operator.

Key Predeploys

Address	Contract	Purpose
`0x4200...0006`	`L2CrossDomainMessenger`	Cross-domain message relay
`0x4200...0007`	`L2StandardBridge`	Standard token bridge
`0x4200...0010`	`L2ToL1MessagePasser`	Raw withdrawal initiation
`0x4200...0015`	`L1Block`	L1 block context on L2
`0x4200...0011`	`BaseFeeVault`	Collects L2 base fees
`0x4200...0019`	`GasPriceOracle`	Exposes L1/L2 gas prices

Trust Implications

Predeploys are upgradeable. The implementation behind each predeploy proxy can be upgraded by the chain operator (Coinbase for Base, Optimism Foundation for OP Mainnet) via the ProxyAdmin and governance multisig. Protocols that hard-code predeploy addresses must account for the possibility that the interface or behavior at that address changes.

L1Block is populated by the sequencer. The L1Block predeploy exposes number, timestamp, basefee, hash, and other L1 context. This data is injected by the sequencer via a setL1BlockValues system transaction at the top of each epoch. The sequencer is trusted to set this data correctly. A malicious or compromised sequencer could provide stale or manipulated L1 block data.

// Reading L1 context via the L1Block predeploy
interface IL1Block {
    function number() external view returns (uint64);
    function timestamp() external view returns (uint64);
    function basefee() external view returns (uint256);
    function hash() external view returns (bytes32);
    function sequenceNumber() external view returns (uint64);
}

contract L1AwareContract {
    IL1Block public constant L1_BLOCK =
        IL1Block(0x4200000000000000000000000000000000000015);

    function getL1BlockNumber() external view returns (uint64) {
        return L1_BLOCK.number();
    }

    // WARNING: This value is sequencer-supplied. Do not use for
    // high-stakes timing without understanding the trust model.
    function getL1Timestamp() external view returns (uint64) {
        return L1_BLOCK.timestamp();
    }
}

GasPriceOracle for L1 fee estimation. Contracts computing L1 data fees for users should use GasPriceOracle rather than hard-coded assumptions. Post-Ecotone, the fee model uses a blob-based scalar rather than a simple base fee multiplier.

Key auditor checks:

Does any contract assume predeploy implementations are immutable?
Does any protocol use L1Block.hash or L1Block.timestamp as a randomness source or high-trust signal?
Is gas fee estimation using the current fee model, not a pre-Ecotone formula?

Differences from Ethereum Mainnet That Affect Contract Security

1. No `SELFDESTRUCT`

OP Stack does not fully support SELFDESTRUCT. The opcode does not delete code or storage in the same way as on Ethereum mainnet. Contracts relying on selfdestruct for cleanup, fund recovery, or destroy patterns will behave incorrectly.

// This pattern is unreliable on OP Stack
contract Ephemeral {
    function destroy() external {
        selfdestruct(payable(msg.sender)); // Does NOT delete contract on L2
    }
}

2. `PUSH0` and EVM Version Parity

Base follows Ethereum EVM upgrades, but with a slight lag. Auditors must confirm which EVM version is active at the time of deployment and ensure compiler targets match.

3. ETH Deposits Are `msg.value`, Not Token Transfers

When ETH is deposited from L1 to L2 via OptimismPortal.depositTransaction, it arrives on L2 as a native ETH balance. The receiving address on L2 does not receive an ERC-20; it receives real ETH. Contracts expecting a wrapped ETH token from the bridge will not behave as intended.

4. `tx.origin` Differences During Deposits

When a deposit transaction is executed on L2, tx.origin is set to the L1 sender’s address aliased with a fixed offset (0x1111000000000000000000000000000000001111). This aliasing prevents L1 contracts from impersonating EOAs on L2.

// Alias constant used by OP Stack for contract senders crossing domains
uint160 constant ALIASING_OFFSET = 0x1111000000000000000000000000000000001111;

function applyAlias(address _l1Address) internal pure returns (address) {
    return address(uint160(_l1Address) + ALIASING_OFFSET);
}

function undoAlias(address _l2Address) internal pure returns (address) {
    return address(uint160(_l2Address) - ALIASING_OFFSET);
}

Key implication: An L1 contract that deposits and also wants to be recognized on L2 must use its aliased address for access control on L2, not its raw L1 address.

5. `blockhash` Availability

On OP Stack, blockhash(n) returns zero for blocks that are not recent, and the available range is different from Ethereum. Any randomness or anti-manipulation mechanism relying on blockhash should treat the return value as potentially zero or manipulable.

6. `ecrecover` and Precompiles

All standard Ethereum precompiles are available, including ecrecover, sha256, ripemd160, and the pairing precompiles. However, precompile gas costs may differ between L2 and L1, which can affect contracts with tight gas budgets.

7. Upgradeable System Contracts

Unlike Ethereum mainnet where core opcodes and precompiles are effectively immutable (barring hard forks), OP Stack system contracts are proxies upgradeable by the operator. A contract that integrates deeply with system contracts must be prepared for interface changes.

What Auditors Check Specifically for OP Stack Deployments

Auditors reviewing contracts for Base or OP Stack deployments run a specialized checklist in addition to standard Solidity and DeFi security checks.

Cross-Domain Messaging

Both msg.sender and xDomainMessageSender() validated in every receiver
No contract treats a message as “received” before finalizeWithdrawalTransaction on L1
Gas limits for cross-domain messages are sufficient for worst-case target execution
Failed message delivery has a defined recovery path

Sequencer Assumptions

No protocol relies on fair or FIFO transaction ordering
Commit-reveal or TWAP used wherever front-running is a concern
No assumption that sequencer downtime is impossible
Deposit escape hatch (via OptimismPortal) tested for censorship scenarios

Withdrawal Finality

L1 receivers implement reentrancy protection
No off-chain component triggers value-bearing state changes on proveWithdrawal events
Withdrawal replay protection does not rely solely on the portal; contract-level nonces used where necessary
Proven-but-not-finalized withdrawals treated as pending, not settled

Timestamps and Block Numbers

block.timestamp not used for precision locks shorter than max_sequencer_drift
block.number understood to be L2 block number, not L1
L1Block.number used where L1 block number is required, with understanding it is sequencer-supplied
No randomness derived from block.timestamp, block.number, or blockhash

Predeploy Integration

Predeploy addresses hard-coded only for stable, interface-stable contracts
No assumption of predeploy immutability in governance or emergency logic
GasPriceOracle used for L1 fee estimation with the correct post-Ecotone scalar model
L1Block.hash not used as a trusted randomness or security input

EVM Compatibility Gaps

No use of selfdestruct for functional logic
tx.origin checks account for the aliasing offset when the sender is an L1 contract
blockhash return value assumed to be zero for non-recent blocks
Compiler EVM version target matches the active fork on Base

Access Control and Trust Model

Admin keys / multisig signers reviewed for operational security
Contracts that could be called by the sequencer system account have appropriate guards
Upgradeable contracts use timelocks; no single-key upgrade authority for high-value contracts
Emergency pause mechanisms cannot be triggered by the sequencer unilaterally

Base and OP Stack Deployment Checklist

Use this checklist before deploying any contract to Base mainnet.

Architecture Review

[ ] Identified all cross-domain message flows (L1→L2 and L2→L1)
[ ] Mapped every predeploy the contract interacts with
[ ] Confirmed EVM version compatibility with current Base fork
[ ] Verified no reliance on selfdestruct for any functional path
[ ] Confirmed blockhash usage accounts for OP Stack return value behavior

Sequencer Risk

[ ] Protocol functions correctly if sequencer is offline for up to 24 hours
[ ] No protocol invariant breaks if the sequencer reorders transactions
    within a block
[ ] Deposit via OptimismPortal tested as a fallback path
[ ] MEV-sensitive logic uses commit-reveal, TWAP, or auction with
    sequencer-adversarial assumptions

Withdrawal and Bridge Security

[ ] L1 receiver contracts are reentrancy-safe (ReentrancyGuard or
    checks-effects-interactions strictly applied)
[ ] Withdrawal replay protection implemented at the contract level
    where funds are at stake
[ ] 7-day challenge window factored into any protocol relying on
    cross-chain value settlement
[ ] Off-chain bots and indexers do not act on proveWithdrawal as final
[ ] Dispute game invalidation scenario reviewed: what happens if a
    proven withdrawal root is overturned?

Cross-Domain Messenger

[ ] Every cross-domain receiver validates both msg.sender (messenger)
    and xDomainMessageSender (counterpart contract)
[ ] Gas limits specified with a margin above worst-case execution
[ ] Failed deliveries have a documented recovery flow
[ ] Message version handling tested for current OP Stack messenger version

Time and Block Context

[ ] All block.timestamp locks carry a margin greater than
    max_sequencer_drift (currently 600 seconds on Base)
[ ] block.number usage explicitly documented as L2 block number
[ ] L1 block context accessed via L1Block predeploy, not assumed
    from L2 block data
[ ] No oracle or price feed relies on block.timestamp with
    sub-minute precision

Predeploys

[ ] L2CrossDomainMessenger address confirmed correct for target network
[ ] L2StandardBridge integration tested with both ETH and ERC-20 paths
[ ] GasPriceOracle integration uses post-Ecotone fee model
[ ] No contract logic breaks if a predeploy implementation is upgraded

L1 Address Aliasing

[ ] Any L1 contract that also acts as an L2 actor uses its aliased
    address in L2 access control
[ ] applyAlias / undoAlias utilities tested with known vectors
[ ] No contract uses raw tx.origin comparison for security-critical
    paths involving cross-domain senders

Operational Security

[ ] Upgrade authority uses a multisig with ≥ 3/N signers
[ ] Timelocks of ≥ 48 hours on all upgrades affecting user funds
[ ] Emergency pause cannot be triggered without multisig quorum
[ ] Contract verified on Basescan with exact compiler settings
[ ] Constructor arguments logged and reproducible
[ ] Deployment scripts idempotent and tested on Base Sepolia

Closing Notes

Security on Base is not a subset of Ethereum security — it is a superset with additional dimensions. The sequencer, the withdrawal pipeline, the cross-domain messenger, and the predeploy trust model each introduce assumptions that do not exist on L1. Contracts that ignore these layers are not “L1 contracts running faster and cheaper”; they are contracts with unreviewed trust surface.

The OP Stack’s transparency — its open-source codebase, on-chain output proposals, and derivation pipeline — provides strong foundations. But foundations are not guarantees. Every protocol layered on top of Base must explicitly reason about sequencer centralization, withdrawal finality windows, cross-domain message authentication, and the EVM-compatibility gaps documented here.

Auditors approaching OP Stack targets should treat this checklist not as a supplement to their standard review but as an equal component of it. The attack surface that is unique to rollup architecture is often the surface that remains unreviewed.

Base Security: OP Stack Assumptions and What Auditors Check

OP Stack Architecture

Key Components

The Sequencer and Its Centralization Assumptions

What the Sequencer Does

Centralization Risk

What Contracts Should Assume

The Two-Step Withdrawal Process and Finality Implications

Step 1 — Initiate Withdrawal on L2

Step 2 — Prove and Finalize on L1

Security Implications

Cross-Domain Messenger Security

The Messenger Stack

xDomainMessageSender — The Central Auth Primitive

Common Messenger Vulnerabilities

block.timestamp Behavior on Base

How Timestamps Are Set

Practical Implications

Predeploy Contracts and Their Trust Model

Key Predeploys

Trust Implications

Differences from Ethereum Mainnet That Affect Contract Security

1. No SELFDESTRUCT

2. PUSH0 and EVM Version Parity

3. ETH Deposits Are msg.value, Not Token Transfers

4. tx.origin Differences During Deposits

5. blockhash Availability

6. ecrecover and Precompiles

7. Upgradeable System Contracts

What Auditors Check Specifically for OP Stack Deployments

Cross-Domain Messaging

Sequencer Assumptions

Withdrawal Finality

Timestamps and Block Numbers

Predeploy Integration

EVM Compatibility Gaps

Access Control and Trust Model

Base and OP Stack Deployment Checklist

Architecture Review

Sequencer Risk

Withdrawal and Bridge Security

Cross-Domain Messenger

Time and Block Context

Predeploys

L1 Address Aliasing

Operational Security

Closing Notes

`xDomainMessageSender` — The Central Auth Primitive

`block.timestamp` Behavior on Base

1. No `SELFDESTRUCT`

2. `PUSH0` and EVM Version Parity

3. ETH Deposits Are `msg.value`, Not Token Transfers

4. `tx.origin` Differences During Deposits

5. `blockhash` Availability

6. `ecrecover` and Precompiles