AccountCodeStorage

The AccountCodeStorage contract is responsible for storing the code hashes of accounts for retrieval whenever the VM accesses an address.

The address is looked up in the AccountCodeStorage contract, if the associated value is non-zero (i.e. the address has code stored), this code hash is used by the VM for the account.

View the source code for AccountCodeStorage

View the AccountCodeStorage source code on Github.

BootloaderUtilities

Learn more about the bootloader and this system contract in the bootloader section.

View the source code for BootloaderUtilities

View the BootloaderUtilities source code on Github.

ComplexUpgrader

This contract is used to perform complex multi-step upgrades on the L2. It contains a single function, upgrade, which executes an upgrade of the L2 by delegating calls to another contract.

View the source code for ComplexUpgrader

View the ComplexUpgrader source code on Github.

Compressor

This contract is used to compress the data that is published to the L1, specifically, it:

  • Compresses the deployed smart contract bytecodes.
  • Compresses the state diffs (and validates state diff compression).

View the source code for Compressor

View the Compressor source code on Github.

Constants

This contract contains helpful constant values that are used throughout the system and can be used in your own smart contracts. It includes:

  • Addresses for all system contracts.
  • Values for other system constants such as MAX_NUMBER_OF_BLOBS, CREATE2_PREFIX, etc.

View the source code for Constants

View the Constants source code on Github.

ContractDeployer

This contract is responsible for deploying smart contracts on Abstract as well as generating the address of the deployed contract. Before deployment, it ensures the code hash of the smart contract is known using the KnownCodesStorage system contract.

See the contract deployment section for more details.

View the source code for ContractDeployer

View the ContractDeployer source code on Github.

Create2Factory

This contract can be used for deterministic contract deployment, i.e. deploying a smart contract with the ability to predict the address of the deployed contract.

It contains two functions, create2 and create2Account, which both call a third function, _relayCall that relays the calldata to the ContractDeployer contract.

You do not need to use this system contract directly, instead use ContractDeployer.

View the source code for Create2Factory

View the Create2Factory source code on Github.

DefaultAccount

This contract is built to simulate the behaviour of an EOA (Externally Owned Account) on the L2. It is intended to act the same as an EOA would on Ethereum, enabling Abstract to support EOA wallets, despite all accounts on Abstract being smart contracts.

As outlined in the transaction flow section, the DefaultAccount contract is used when the sender of a transaction is looked up and no code is found for the address; indicating that the address of the sender is an EOA as opposed to a smart contract wallet.

View the source code for DefaultAccount

View the DefaultAccount source code on Github.

EmptyContract

Some contracts need no other code other than to return a success value. An example of such address is the 0 address. In addition, the bootloader also needs to be callable so that users can transfer ETH to it.

For these contracts, the EmptyContract code is inserted upon . It is essentially a noop code, which does nothing and returns success=1.

View the source code for EmptyContract

View the EmptyContract source code on Github.

EventWriter

This contract is responsible for emitting events. It is not required to interact with this smart contract, the standard Solidity emit keyword can be used.

View the source code for EventWriter

View the EventWriter source code on Github.

ImmutableSimulator

This contract simulates the behavior of immutable variables in Solidity. It exists so that smart contracts with the same Solidity code but different constructor parameters have the same bytecode.

It is not required to interact with this smart contract directly, as it is used via the compiler.

View the source code for ImmutableSimulator

View the ImmutableSimulator source code on Github.

KnownCodesStorage

Since Abstract stores the code hashes of smart contracts and not the code itself (see contract deployment), the system must ensure that it knows and stores the code hash of all smart contracts that are deployed.

The ContractDeployer checks this KnownCodesStorage contract to see if the code hash of a smart contract is known before deploying it. If it is not known, the contract will not be deployed and revert with an error The code hash is not known.

View the source code for KnownCodesStorage

View the KnownCodesStorage source code on Github.

L1Messenger

This contract is used for sending messages from Abstract to Ethereum. It is used by the KnownCodesStorage contract to publish the code hash of smart contracts to Ethereum.

Learn more about what data is sent in the contract deployment section section.

View the source code for L1Messenger

View the L1Messenger source code on Github.

L2BaseToken

This contract holds the balances of ETH for all accounts on the L2 and updates them whenever other system contracts such as the Bootloader, ContractDeployer, or MsgValueSimulator perform balance changes while simulating the msg.value behaviour of Ethereum.

This is because the L2 does not have a set “native” token unlike Ethereum, so functions such as transferFromTo, balanceOf, mint, withdraw, etc. are implemented in this contract as if it were an ERC-20.

View the source code for L2BaseToken

View the L2BaseToken source code on Github.

MsgValueSimulator

This contract calls the L2BaseToken contract’s transferFromTo function to simulate the msg.value behaviour of Ethereum.

View the source code for MsgValueSimulator

View the MsgValueSimulator source code on Github.

NonceHolder

This contract stores the nonce for each account on the L2. More specifically, it stores both the deployment nonce for each account and the transaction nonce for each account.

Before each transaction starts, the bootloader uses the NonceHolder to ensure that the provided nonce for the transaction has not already been used by the sender.

During the transaction validation, it also enforces that the nonce is set as used before the transaction execution begins.

See more details in the nonces section.

View the source code for NonceHolder

View the NonceHolder source code on Github.

PubdataChunkPublisher

This contract is responsible for creating EIP-4844 blobs and publishing them to Ethereum. Learn more in the transaction lifecycle section.

View the source code for PubdataChunkPublisher

View the PubdataChunkPublisher source code on Github.

SystemContext

This contract is used to store and provide various system parameters not included in the VM by default, such as block-scoped, transaction-scoped, or system-wide parameters.

For example, variables such as chainId, gasPrice, baseFee, as well as system functions such as setL2Block and setNewBatch are stored in this contract.

View the source code for SystemContext

View the SystemContext source code on Github.