"notice":"Transfers ownership of this contract to the finalOwner. Only callable by the Final Owner, which is intended to be our multisig. This function shouldn't be necessary, but it gives a sense of reassurance that we can recover if something really surprising goes wrong."
"notice":"Called to finalize the transfer, this function is callable by anyone, but will only result in an upgrade if this contract is the owner Address Manager."
}
},
"events":{},
"errors":{},
"title":"AddressDictator",
"details":"The AddressDictator (glory to Arstotzka) is a contract that allows us to safely manipulate many different addresses in the AddressManager without transferring ownership of the AddressManager to a hot wallet or hardware wallet.",
"description":"Address associated with the given name."
}
},
"notice":"Resolves the address associated with a given name."
}
},
"events":{},
"errors":{},
"title":"BondManager",
"details":"This contract is, for now, a stub of the \"real\" BondManager that does nothing but allow the \"OVM_Proposer\" to submit state root batches.",
"notice":"Allows the sequencer to append a batch of transactions.",
"details":"This function uses a custom encoding scheme for efficiency reasons. .param _shouldStartAtElement Specific batch we expect to start appending to. .param _totalElementsToAppend Total number of batch elements we expect to append. .param _contexts Array of batch contexts. .param _transactionDataFields Array of raw transaction data."
"notice":"Allows the Burn Admin to update the parameters which determine the amount of gas to burn. The value of enqueueL2GasPrepaid is immediately updated as well."
"details":"The Canonical Transaction Chain (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.",
"description":"A 32 byte value to insert into the container."
}
},
"outputs":{},
"notice":"Pushes an object into the container. Function allows setting the global metadata since we'll need to touch the \"length\" storage slot anyway, which also contains the global metadata (it's an optimization)."
"notice":"Sets the container's global metadata field. We're using `bytes27` here because we use five bytes to maintain the length of the underlying data structure, meaning we have an extra 27 bytes to store arbitrary data."
}
},
"events":{},
"errors":{},
"title":"ChainStorageContainer",
"details":"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 finalized. Three 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",
"notice":"Transfers ownership of this contract to the finalOwner. Only callable by the finalOwner, which is intended to be our multisig. This function shouldn't be necessary, but it gives a sense of reassurance that we can recover if something really surprising goes wrong."
"details":"Like the AddressDictator, but specifically for the Proxy__OVM_L1StandardBridge. We're working on a generalized version of this but this is good enough for the moment.",
"details":"Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.",
"details":"Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.",
"details":"Library used to query support of an interface declared via {IERC165}. Note that these functions return the actual result of the query: they do not `revert` if an interface is not supported. It is up to the caller to decide what to do in these cases.",
"details":"Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless this function is overridden; NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}."
"details":"Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`."
"details":"Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address."
"details":"See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`."
"code":"event Transfer(address indexed from, address indexed to, uint256 value)",
"inputs":{
"from":{
"type":"address",
"indexed":true
},
"to":{
"type":"address",
"indexed":true
},
"value":{
"type":"uint256",
"indexed":false
}
}
}
},
"errors":{},
"details":"Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.",
"notice":"Allows the sequencer to append a batch of transactions.",
"details":"This function uses a custom encoding scheme for efficiency reasons. .param _shouldStartAtElement Specific batch we expect to start appending to. .param _totalElementsToAppend Total number of batch elements we expect to append. .param _contexts Array of batch contexts. .param _transactionDataFields Array of raw transaction data."
"notice":"Allows the Burn Admin to update the parameters which determine the amount of gas to burn. The value of enqueueL2GasPrepaid is immediately updated as well."
"description":"A 32 byte value to insert into the container."
}
},
"outputs":{},
"notice":"Pushes an object into the container. Function allows setting the global metadata since we'll need to touch the \"length\" storage slot anyway, which also contains the global metadata (it's an optimization)."
"notice":"Sets the container's global metadata field. We're using `bytes27` here because we use five bytes to maintain the length of the underlying data structure, meaning we have an extra 27 bytes to store arbitrary data."
"details":"Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas."
}
},
"events":{},
"errors":{},
"details":"Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.",
"details":"Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called."
"details":"Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event."
"details":"Moves `amount` tokens from the caller's account to `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"details":"Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"details":"Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called."
"details":"Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event."
"details":"Moves `amount` tokens from the caller's account to `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"details":"Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"description":"Address of the L1 ERC20 we are depositing"
},
"_l2Token":{
"type":"address",
"description":"Address of the L1 respective L2 ERC20"
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit"
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"deposit an amount of the ERC20 to the caller's balance on L2."
"description":"Address of the L1 ERC20 we are depositing"
},
"_l2Token":{
"type":"address",
"description":"Address of the L1 respective L2 ERC20"
},
"_to":{
"type":"address",
"description":"L2 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"deposit an amount of ERC20 to a recipient's balance on L2."
"description":"Address of L1 token to finalizeWithdrawal for."
},
"_l2Token":{
"type":"address",
"description":"Address of L2 token where withdrawal was initiated."
},
"_from":{
"type":"address",
"description":"L2 address initiating the transfer."
},
"_to":{
"type":"address",
"description":"L1 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_data":{
"type":"bytes",
"description":"Data provided by the sender on L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the L1 ERC20 token. This call will fail if the initialized withdrawal from L2 has not been finalized."
"description":"Address of the L1 ERC20 we are depositing"
},
"_l2Token":{
"type":"address",
"description":"Address of the L1 respective L2 ERC20"
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit"
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"deposit an amount of the ERC20 to the caller's balance on L2."
"description":"Address of the L1 ERC20 we are depositing"
},
"_l2Token":{
"type":"address",
"description":"Address of the L1 respective L2 ERC20"
},
"_to":{
"type":"address",
"description":"L2 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"deposit an amount of ERC20 to a recipient's balance on L2."
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Deposit an amount of the ETH to the caller's balance on L2."
"description":"L2 address to credit the withdrawal to."
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Deposit an amount of ETH to a recipient's balance on L2."
"description":"Address of L1 token to finalizeWithdrawal for."
},
"_l2Token":{
"type":"address",
"description":"Address of L2 token where withdrawal was initiated."
},
"_from":{
"type":"address",
"description":"L2 address initiating the transfer."
},
"_to":{
"type":"address",
"description":"L1 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_data":{
"type":"bytes",
"description":"Data provided by the sender on L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the L1 ERC20 token. This call will fail if the initialized withdrawal from L2 has not been finalized."
"description":"L2 address initiating the transfer."
},
"_to":{
"type":"address",
"description":"L1 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the L1 ETH token. Since only the xDomainMessenger can call this function, it will never be called before the withdrawal is finalized."
"description":"Address for the l1 token this is called with"
},
"_l2Token":{
"type":"address",
"description":"Address for the l2 token this is called with"
},
"_from":{
"type":"address",
"description":"Account to pull the deposit from on L2."
},
"_to":{
"type":"address",
"description":"Address to receive the withdrawal at"
},
"_amount":{
"type":"uint256",
"description":"Amount of the token to withdraw"
},
"_data":{
"type":"bytes",
"description":"Data provider by the sender on L1. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Complete a deposit from L1 to L2, and credits funds to the recipient's balance of this L2 token. This call will fail if it did not originate from a corresponding deposit in L1StandardTokenBridge."
"description":"Address of L2 token where withdrawal was initiated."
},
"_amount":{
"type":"uint256",
"description":"Amount of the token to withdraw. param _l1Gas Unused, but included for potential forward compatibility considerations."
},
"_l1Gas":{
"type":"uint32"
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L1. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"initiate a withdraw of some tokens to the caller's account on L1"
"description":"Address of L2 token where withdrawal is initiated."
},
"_to":{
"type":"address",
"description":"L1 adress to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the token to withdraw. param _l1Gas Unused, but included for potential forward compatibility considerations."
},
"_l1Gas":{
"type":"uint32"
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L1. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"initiate a withdraw of some token to a recipient's account on L1."
"details":"Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called."
"details":"Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event."
"details":"Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas."
"details":"Moves `amount` tokens from the caller's account to `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"details":"Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"details":"This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since a proxied contract can't have a constructor, it's common to move constructor logic to an external initializer function, usually called `initialize`. It then becomes necessary to protect this initializer function so it can only be called once. The {initializer} modifier provided by this contract will have this effect. TIP: To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the `_data` argument to {ERC1967Proxy-constructor}. CAUTION: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity.",
*This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since a proxied contract can't have a constructor, it's common to move constructor logic to an external initializer function, usually called `initialize`. It then becomes necessary to protect this initializer function so it can only be called once. The {initializer} modifier provided by this contract will have this effect. TIP: To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the `_data` argument to {ERC1967Proxy-constructor}. CAUTION: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity.*
*This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since a proxied contract can't have a constructor, it's common to move constructor logic to an external initializer function, usually called `initialize`. It then becomes necessary to protect this initializer function so it can only be called once. The {initializer} modifier provided by this contract will have this effect. TIP: To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the `_data` argument to {ERC1967Proxy-constructor}. CAUTION: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity. [CAUTION] ==== Avoid leaving a contract uninitialized. An uninitialized contract can be taken over by an attacker. This applies to both a proxy and its implementation contract, which may impact the proxy. To initialize the implementation contract, you can either invoke the initializer manually, or you can include a constructor to automatically mark it as initialized when it is deployed: [.hljs-theme-light.nopadding] ```*
"notice":"Queries the implementation address. Can only be called by the owner OR by making an eth_call and setting the \"from\" address to address(0)."
"notice":"Queries the owner of the proxy contract. Can only be called by the owner OR by making an eth_call and setting the \"from\" address to address(0)."
"description":"New contract code to run inside this contract."
}
},
"outputs":{},
"notice":"Sets the code that should be running behind this proxy. Note that this scheme is a bit different from the standard proxy scheme where one would typically deploy the code separately and then set the implementation address. We're doing it this way because it gives us a lot more freedom on the client side. Can only be triggered by the contract owner."
"notice":"Modifies some storage slot within the proxy contract. Gives us a lot of power to perform upgrades in a more transparent way. Only callable by the owner."
}
},
"events":{},
"errors":{},
"title":"L1ChugSplashProxy",
"details":"Basic ChugSplash proxy contract for L1. Very close to being a normal proxy but has added functions `setCode` and `setStorage` for changing the code or storage of the contract. Nifty! Note for future developers: do NOT make anything in this contract 'public' unless you know what you're doing. Anything public can potentially have a function signature that conflicts with a signature attached to the implementation contract. Public functions SHOULD always have the 'proxyCallIfNotOwner' modifier unless there's some *really* good reason not to have that modifier. And there almost certainly is not a good reason to not have that modifier. Beware!",
"details":"Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner."
"details":"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.",
"description":"Address of the L1 ERC20 we are depositing"
},
"_l2Token":{
"type":"address",
"description":"Address of the L1 respective L2 ERC20"
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit"
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"deposit an amount of the ERC20 to the caller's balance on L2."
"description":"Address of the L1 ERC20 we are depositing"
},
"_l2Token":{
"type":"address",
"description":"Address of the L1 respective L2 ERC20"
},
"_to":{
"type":"address",
"description":"L2 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"deposit an amount of ERC20 to a recipient's balance on L2."
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Deposit an amount of the ETH to the caller's balance on L2."
"description":"L2 address to credit the withdrawal to."
},
"_l2Gas":{
"type":"uint32",
"description":"Gas limit required to complete the deposit on L2."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Deposit an amount of ETH to a recipient's balance on L2."
"details":"Adds ETH balance to the account. This is meant to allow for ETH to be migrated from an old gateway to a new gateway. NOTE: This is left for one upgrade only so we are able to receive the migrated ETH from the old contract"
"description":"Address of L1 token to finalizeWithdrawal for."
},
"_l2Token":{
"type":"address",
"description":"Address of L2 token where withdrawal was initiated."
},
"_from":{
"type":"address",
"description":"L2 address initiating the transfer."
},
"_to":{
"type":"address",
"description":"L1 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_data":{
"type":"bytes",
"description":"Data provided by the sender on L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the L1 ERC20 token. This call will fail if the initialized withdrawal from L2 has not been finalized."
"description":"L2 address initiating the transfer."
},
"_to":{
"type":"address",
"description":"L1 address to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the ERC20 to deposit."
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L2. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the L1 ETH token. Since only the xDomainMessenger can call this function, it will never be called before the withdrawal is finalized."
"details":"The L1 ETH and ERC20 Bridge is a contract which stores deposited L1 funds and standard tokens that are in use on L2. It synchronizes a corresponding L2 Bridge, informing it of deposits and listening to it for newly finalized withdrawals.",
"details":"The L2 Cross Domain Messenger contract sends messages from L2 to L1, and is the entry point for L2 messages sent via the L1 Cross Domain Messenger.",
"description":"Address for the l1 token this is called with"
},
"_l2Token":{
"type":"address",
"description":"Address for the l2 token this is called with"
},
"_from":{
"type":"address",
"description":"Account to pull the deposit from on L2."
},
"_to":{
"type":"address",
"description":"Address to receive the withdrawal at"
},
"_amount":{
"type":"uint256",
"description":"Amount of the token to withdraw"
},
"_data":{
"type":"bytes",
"description":"Data provider by the sender on L1. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"Complete a deposit from L1 to L2, and credits funds to the recipient's balance of this L2 token. This call will fail if it did not originate from a corresponding deposit in L1StandardTokenBridge."
"description":"Address of L2 token where withdrawal was initiated."
},
"_amount":{
"type":"uint256",
"description":"Amount of the token to withdraw. param _l1Gas Unused, but included for potential forward compatibility considerations."
},
"_l1Gas":{
"type":"uint32"
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L1. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"initiate a withdraw of some tokens to the caller's account on L1"
"description":"Address of L2 token where withdrawal is initiated."
},
"_to":{
"type":"address",
"description":"L1 adress to credit the withdrawal to."
},
"_amount":{
"type":"uint256",
"description":"Amount of the token to withdraw. param _l1Gas Unused, but included for potential forward compatibility considerations."
},
"_l1Gas":{
"type":"uint32"
},
"_data":{
"type":"bytes",
"description":"Optional data to forward to L1. This data is provided solely as a convenience for external contracts. Aside from enforcing a maximum length, these contracts provide no guarantees about its content."
}
},
"outputs":{},
"details":"initiate a withdraw of some token to a recipient's account on L1."
"details":"The L2 Standard bridge is a contract which works together with the L1 Standard bridge to enable ETH and ERC20 transitions 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 also acts as a burner of the tokens intended for withdrawal, informing the L1 bridge to release L1 funds.",
"details":"Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless this function is overridden; NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}."
"details":"Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`."
"details":"Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address."
"details":"See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`."
"details":"Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner."
"details":"This library implements a bytes32 storage array with some additional gas-optimized functionality. In particular, it encodes its length as a uint40, and tightly packs this with an overwritable \"extra data\" field so we can store more information with a single SSTORE.",
"details":"The Deployer Whitelist is a temporary predeploy used to provide additional safety during the initial phases of our mainnet roll out. It is owned by the Optimism team, and defines accounts which are allowed to deploy contracts on Layer2. The Execution Manager will only allow an ovmCREATE or ovmCREATE2 operation to proceed if the deployer's address whitelisted.",
"details":"Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event."
"details":"Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless this function is overridden; NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}."
"details":"Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`."
"details":"Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address."
"details":"Moves `amount` tokens from the caller's account to `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"details":"Moves `amount` tokens from `sender` to `recipient` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event."
"code":"event Transfer(address indexed from, address indexed to, uint256 value)",
"inputs":{
"from":{
"type":"address",
"indexed":true
},
"to":{
"type":"address",
"indexed":true
},
"value":{
"type":"uint256",
"indexed":false
}
}
}
},
"errors":{},
"title":"OVM_ETH",
"details":"The ETH predeploy provides an ERC20 interface for ETH deposited to Layer 2. Note that unlike on Layer 1, Layer 2 accounts do not have a balance field.",
"description":"Amount of L1 gas used for a transaction"
}
},
"notice":"Computes the amount of L1 gas used for a transaction The overhead represents the per batch gas overhead of posting both transaction and state roots to L1 given larger batch sizes. 4 gas for 0 byte https://github.com/ethereum/go-ethereum/blob/9ada4a2e2c415e6b0b51c50e901336872e028872/params/protocol_params.go#L33 16 gas for non zero byte https://github.com/ethereum/go-ethereum/blob/9ada4a2e2c415e6b0b51c50e901336872e028872/params/protocol_params.go#L87 This will need to be updated if calldata gas prices change Account for the transaction being unsigned Padding is added to account for lack of signature on transaction 1 byte for RLP V prefix 1 byte for V 1 byte for RLP R prefix 32 bytes for R 1 byte for RLP S prefix 32 bytes for S Total: 68 bytes of padding"
"details":"Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner."
"details":"This contract exposes the current l2 gas price, a measure of how congested the network currently is. This measure is used by the Sequencer to determine what fee to charge for transactions. When the system is more congested, the l2 gas price will increase and fees will also increase as a result. All public variables are set while generating the initial L2 state. The constructor doesn't run in practice as the L2 state generation script uses the deployed bytecode instead of running the initcode.",
"details":"The L2 to L1 Message Passer is a utility contract which facilitate an L1 proof of the of a message on L2. The L1 Cross Domain Messenger performs this proof in its _verifyStorageProof function, which verifies the existence of the transaction hash in this contract's `sentMessages` mapping.",
"details":"Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner."
"details":"Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.",
"details":"Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner."
"details":"Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.",
"details":"Returns true if the contract is paused, and false otherwise."
}
},
"events":{
"Paused":{
"code":"event Paused(address account)",
"inputs":{
"account":{
"type":"address",
"indexed":false
}
},
"details":"Emitted when the pause is triggered by `account`."
},
"Unpaused":{
"code":"event Unpaused(address account)",
"inputs":{
"account":{
"type":"address",
"indexed":false
}
},
"details":"Emitted when the pause is lifted by `account`."
}
},
"errors":{},
"details":"Contract module which allows children to implement an emergency stop mechanism that can be triggered by an authorized account. This module is used through inheritance. It will make available the modifiers `whenNotPaused` and `whenPaused`, which can be applied to the functions of your contract. Note that they will not be pausable by simply including this module, only once the modifiers are put in place.",
"details":"Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].",
"details":"Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.",
"details":"The State Commitment Chain (SCC) contract contains a list of proposed state roots which Proposers assert to be a result of each transaction in the Canonical Transaction Chain (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.",
