List of System Contracts
Explore all of the system contracts that Abstract implements.
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.
Was this page helpful?