• This contract currently is a stub of the real BondManager that does nothing but allow the OVM Proposer to submit state root batches.

function isCollateralized(address _who) public view returns (bool) {
  // Only authenticate sequencer to submit state root batches.
	

• The CTC contract is an append-only log of transactions which must be applied to the rollup state.

• It defines the ordering of rollup transactions by writing them to the ‘CTC:batches’ instance of the Chain Storage Container.

• The CTC also allows any account to enqueue an L2 transaction, which will require that the Sequencer will eventually append it to the rollup state.

• The Chain Storage Container provides its owner contract with read, write and delete functionality. This provides gas efficiency gains by enabling it to overwrite storage slots which can no longer be used in a fraud proof due to the fraud window having passed, and the associated chain state or transactions being finalised

• 3 distinct Chain Storage Containers will be deployed on Layer 1:
1. Stores transaction batches for the Canonical Transaction Chain.
2. Stores queued transactions for the Canonical Transaction Chain.
3. Stores chain state batches for the State Commitment Chain.

• Retrieve or change the address associated with a particular name

• The L1 Cross Domain Messenger contract sends messages from L1 to L2 and relays messages from L2 onto L1.

• In the event that a message sent from L1 to L2 is rejected for exceeding the L2 epoch gas limit, it can be resubmitted via this contract’s replay function.

• The L1 ETH and ERC20 Bridge is a contract which stores deposited L1 funds and standard tokens that are in use on L2.

• It synchronises a corresponding L2 bridge, informing it of deposits and listening to it for newly finalised deposits.

• The SCC contract contains a list of proposed state roots which Proposers assert to be a result of each transaction in the CTC.

• Elements here have a 1:1 correspondence with transactions in the CTC, and should be the unique state root calculated off-chain by applying the canonical transactions one by one.

• Accepts deposits that will be disbursed to the sender’s address on L2.

• Sends messages from L2 to L1, and is an entry point for L2 messages sent via the L1 Cross Domain Manager.

• This contract works together with the L1 Standard Bridge to enable ETH and ERC20 transfers between L1 and L2.

• This contract acts as a minter for new tokens when it hears about deposits into the L1 Standard Bridge.

• This contract acts as a burner of tokens intended for withdrawal, informing the L1 bridge to release L1 funds.

• This is a simple holding contract for fees paid to the permissioned Sequencer operated by Optimism.

• It will be replaced in the future (but since we are operating with a single centralised sequencer, it is okay for now)

• This is a factory contract for creating standard L2 token representations of L1 ERC20s compatible with and working on the standard bridge.

• The ETH predeploy provides an ERC20 interface for ETH deposited to L2. Note that unlike on L1, L2 accounts do not have a balance field.

• Looks like a custom wrapped Ether contract for L2. Not sure why the standard token factory could not be used for it?

• A temporary pre-deploy used to provide additional safety during the initial phases of Optimism mainnet rollout.

• The last transaction sent to it was to enable arbitrary contract deployment on Optimism mainnet thus making this whitelist contract obsolete.

• The contract code is simply a fallback method that reverts.

• Must have been just for testing deployment. Not used for anything and source code not available for it.