Skip to content

Observations and tips checklist for auditing protocols on multiple chains 🧐

License

Notifications You must be signed in to change notification settings

0xJuancito/multichain-auditor

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Multichain Auditor

Observations and tips for auditing protocols on multiple chains 🧐

✍️ Open to Contributions

If you see some error, or want to add an observation, please create an issue or a PR. References are greatly appreciated. You can also contact me on Twitter at @0xJuancito.

πŸ“œ Disclaimer

Take the observations in this repository as a guideline and kickstarter to your findings. Judge the actual impact independently, and please do not use them as a tool to spam audit contests. Do your own research.

Index

General Observations

Block time is not the same on different chains

Block time refers to the time separating blocks. The average block time in Ethereum is 12s, but this value is different on different chains.

Example:

// 1 block every 12 sec -> 5 blocks / min
uint256 auctionDuration = 7200; // Auction duration lasts for one day (5 * 60 * 24 = 7200)

Example: OZ Wizard

πŸ’‘ Look for hardcoded time values dependent on the block.number that may only be valid on Mainnet.

Block production may not be constant

block.number is NOT a reliable source of timing information for short terms.

On Arbitrum it reflects the L1 block number, which is updated once per minute

πŸ’‘ Look for the use of block.number as a time reference, especially on L2. πŸ’‘ Block time may change on the same chain over time.

πŸ“ 1 2

L2 Sequencer Uptime Feeds in Chainlink

From Chainlink documentation:

Optimistic rollup protocols have a sequencer that executes and rolls up the L2 transactions by batching multiple transactions into a single transaction.

If a sequencer becomes unavailable, it is impossible to access read/write APIs that consumers are using and applications on the L2 network will be down for most users.

This means that if the project does not check if the sequencer is down, it can return stale results.

Optimism Goerli Uptime Feed

Mitigations can be found on Handling Arbitrum outages and Handling outages on Optimism and Metis.

Example:

function getPrice(address token) external view override returns (uint) {
    if (!isSequencerActive()) revert Errors.L2SequencerUnavailable();
    ...
}

function isSequencerActive() internal view returns (bool) {
    (, int256 answer, uint256 startedAt,,) = sequencer.latestRoundData();
    if (block.timestamp - startedAt <= GRACE_PERIOD_TIME || answer == 1)
        return false;
    return true;
}

πŸ’‘ Check if the projects handles the scenarios where a sequencer is down on optimistic rollup protocols.

πŸ“ 1 2 3 4 5

Chainlink Price Feeds

Chainlink Data Feeds provide data that is aggregated from many data sources by a decentralized set of independent node operators.

Chainlink provides more price feeds for some chains like Ethereum than others like Base for example. On other chains, no feed may be supported. Also, the same feed like AAVE/USD may have one address on a chain like Ethereum, and another one on Moonriver.

πŸ’‘ Check that the price feed for the desired pair is supported on all of the deployed chains.

πŸ’‘ Check that the correct addresses are set correctly for each chain if they are hardcoded.

AMM pools token0 and token1 order

In Uniswap and derived AMMs: token0 is the token with the lower sort order, while token1 is the token with the higher sort order, as described on Uniswap documentation. This is valid for both v2 and v3 pools.

The order is important because that determines which one is the base token, and which one is the quote token. In other words, if the price is WETH/USDC or USDC/WETH.

As contracts may have different addresses on different chains, the token order can change. That is the case for example on Arbitrum, where the pair is WETH/USDC while on Polygon it is USDC/WETH.

πŸ’‘ Verify that the token orders are taken into account, and it is not assumed to be the same on all chains.

Modified Opcodes

Some chains implement opcodes with some modification compared to Ethereum, or are not supported.

Optimism for example, has a different implementation of opcodes like block.coinbase, block.difficulty, block.basefee. tx.origin may also behave different if the it is an L1 => L2 transaction. It also implements some new opcode [L1BLOCKNUMBER](Chains may also implement new opcodes).

Arbitrum also has some differences in some operations/opcodes like: blockhash(x), block.coinbase, block.difficulty, block.number. msg.sender may also behave different for L1 => L2 "retryable ticket" transactions.

πŸ’‘ Verify that the EVM opcodes and operations used by the protocol are compatible on all chains

Support for the push0 opcode

push0 is an instruction which pushes the constant value 0 onto the stack. This opcode is still not supported by many chains and might be problematic for projects compiled with a version of Solidity >= 0.8.20 (when it was introduced).

πŸ’‘ Pay attention to projects using a Solidity version >= 0.8.20 and check if it is supported on the deployed chains.

ℹ️ Arbitrum added support in ArbOS 11 and Optimism introduced support for it on the Canyon Upgrade .

Address Aliasing - tx.origin / msg.sender

On some chains like Optimism, because of the behaviour of the CREATE opcode, it is possible for a user to create a contract on L1 and on L2 that share the same address but have different bytecode.

This can break trust assumptions, because one contract may be trusted and another be untrusted. To prevent this problem the behaviour of the ORIGIN and CALLER opcodes (tx.origin and msg.sender) differs slightly between L1 and L2.

πŸ’‘ Verify that the expected behaviour of tx.origin and msg.sender holds on all deployed chains

tx.origin == msg.sender

From Optimism documentation:

On L1 Ethereum tx.origin is equal to msg.sender only when the smart contract was called directly from an externally owned account (EOA). However, on Optimism tx.origin is the origin on Optimism. It could be an EOA. However, in the case of messages from L1, it is possible for a message from a smart contract on L1 to appear on L2 with tx.origin == msg.sender. This is unlikely to make a significant difference, because an L1 smart contract cannot directly manipulate the L2 state. However, there could be edge cases we did not think about where this matters.

πŸ’‘ Verify that the expected behavior of tx.origin and msg.sender holds on all deployed chains

Cross-chain message vulnerabilities

Some protocols work by sending cross-chain messages to their counterpart contracts on the other chains. This can lead to vulnerabilities like authorization issues, or issues with relayers.

πŸ’‘ Look for cross-chain messages implementations and verify the correct permissions and functionality considering all the actors involved

πŸ“ 1 2 3

transfer, send and fixed gas operations

transfer and send forward a hardcoded amount of gas and are discouraged as gas costs can change. On certain chains that cost can be higher than in Mainnet, and can result in issues, like in zkSync Era.

πŸ’‘ Look for fixed gas operations like transfer or send.

Gas fees

Transactions on Ethereum mainnet are much more expensive than on other chains. Chains with very low fees may open the possibility to implement attacks that require a large amount of transactions, or where the cost-benefit of the attack would now be profitable.

Examples:

  • DOS on unbound arrays
  • DOS by filling bound arrays
  • Spamming that can incur in extra processing costs for the protocol
  • An attack that only drains smaller amounts of wei that wouldn't be profitable with high gas fees
  • Frontrunning operations to prevent txns to be executed during a time frame (liquidations, complete auctions, etc.)
  • Griefing attacks against the protocol

Although cheaper, each case should be analyzed to check if it is economically viable to actually be considered an attack.

πŸ’‘ Analyze attack vectors that require low gas fees or where a considerable numbers of transactions have to be executed

πŸ“ 1

Frontrunning

Frontrunning is possible on chains that have a mempool or a way to read proposed transactions before they are executed.

It is possible on some chains like Ethereum, although expensive because of gas costs. It is possible at a cheaper cost on other chains like Polygon.

But it may be very difficult on chains like Optimism with a private mempool

πŸ’‘ Verify if a frontrunning attack is possible due to chain constraints or economic viability

Signature replay across chains

If a contract is deployed on multiple chains and uses signatures, it may be possible to reuse a signature used on one chain and execute the same transaction on another chain.

To prevent that, it is important that the signed data contains the chain id where it should be executed.

Example from UniswapV2:

constructor() public {
    uint chainId;
    assembly {
        chainId := chainid
    }
    DOMAIN_SEPARATOR = keccak256(
        abi.encode(
            keccak256('EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)'),
            keccak256(bytes(name)),
            keccak256(bytes('1')),
@>          chainId,                   // @audit
            address(this)
        )
    );
}

function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external {
    require(deadline >= block.timestamp, 'UniswapV2: EXPIRED');
    bytes32 digest = keccak256(
        abi.encodePacked(
            '\x19\x01',
@>          DOMAIN_SEPARATOR, // @audit
            keccak256(abi.encode(PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline))
        )
    );
    address recoveredAddress = ecrecover(digest, v, r, s);
    require(recoveredAddress != address(0) && recoveredAddress == owner, 'UniswapV2: INVALID_SIGNATURE');
    _approve(owner, spender, value);
}

πŸ’‘ Check that the data from the signed hash contains the chain id

πŸ“ 1 2 3

Hardcoded Contract Addresses

Projects sometimes deploy their contracts on the same addresses over different chains but that is not always the case.

Take WETH as an example. Its address on Ethereum is 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2, but 0x7ceb23fd6bc0add59e62ac25578270cff1b9f619 on Polygon.

πŸ’‘ Verify external contract addresses for the chains where the contracts are deployed

πŸ“ 1

ERC20 decimals

Some ERC20 tokens have different decimals on different chains. Even some popular ones like USDT and USDC have 6 decimals on Ethereum, and 18 decimals on BSC for example:

A more exhaustive list can be found in the tokens-decimals repository by @magnetto90.

πŸ’‘ Check that the correct decimals are set for the deployed chains if the token values are hardcoded.

Contracts Interface

Some contracts have a slightly different interface on different chains, which may break compatibility.

USDT for example is missing its return value on Ethereum as the ERC20 specification suggests, but it is compliant on that aspect on Polygon. This may lead to some vulnerabilities on some chains, while not on others.

USDT on Ethereum:

  function transfer(address _to, uint _value) public whenNotPaused {

USDT Implementation | USDT Proxy on Polygon:

  function transfer(address recipient, uint256 amount) public virtual override returns (bool) {

ERC20 transfer specification:

  function transfer(address _to, uint256 _value) public returns (bool success)

πŸ’‘ Verify that the contracts respect the same interface on different chains, or that sufficient mitigations are taken.

Contracts Upgradability

Some contracts are immutable on a chain but upgradeable on others, like USDT in Ethereum vs USDT in Polygon.

πŸ’‘ Double-check the upgradability of contracts on different chains and evaluate their implications.

Contracts may behave differently

Contracts deployed on different chains may behave differently.

On the XDai chain, USDC, WBTC, and WETH contained post-transfer callback procedures, as opposed to their traditional ERC20 implementations on other chains with no callback.

That enabled the possibility of a re-entrancy attack that was exploited and ultimately derived on the fork of the chain.

πŸ’‘ Check that implementations of contracts match on different chains, or that their differences won't incur on any new vulnerability.

Precompiles

Chains have precompiled contracts on different addresses like Arbitrum or Optimism. Care has to be taken if some is used that is not available, works differently or is on a different address.

πŸ’‘ Double-check the use of precompiled contracts, their addresses, and their compatibility

zkSync Era

zkSync Era has many differences from Ethereum on EVM instructions like CREATE, CREATE2, CALL, STATICCALL, DELEGATECALL, MSTORE, MLOAD, CALLDATALOAD, CALLDATACOPY, etc.

πŸ’‘ Double-check the compatibility of the contracts when being deployed to zkSync Era


Differences from Ethereum

Some blockchains have articles explaining their differences with Ethereum or other EVM chains. Here's a list of official docs:

EVM Compatible Chains Diff

Check evm-diff repository and the website evmdiff.com to diff EVM-compatible chains in a friendly format. It's an amazing tool created by @mds1

About

Observations and tips checklist for auditing protocols on multiple chains 🧐

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published