StandardArbERC20
Arbitrum One ERC-20 Token0x3f770ac673856f105b586bb393d122721265ad46
Solidity v0.6.11+commit.5ef660b1
Fungible token following the ERC-20 standard.
🤖
Query this contract from your AI
Reference:
0x3f770ac673856f105b586bb393d122721265ad46
Sample prompt:
"Tell me the current state of arbitrum/0x3f770ac673856f105b586bb393d122721265ad46"
No AI wired up yet? →
mcp.smarts.md
Admin & Risk
Who can change the rules?
No admin risk controls detected from the verified ABI.
Overview
Read Functions
11
Write Functions
10
Events
3
Read Functions
Block #25,176,894 · just now
DOMAIN_SEPARATOR()
view
→ 0x60a7ceacab02397e9248573e99be565f18250840b49a2ad0b3475658573dbceb
Returns
| Name | Type | Description |
|---|---|---|
| — | bytes32 |
allowance(owner: address, spender: address)
view
dev: See {IERC20-allowance}.
Parameters
| Name | Type | Description |
|---|---|---|
| owner | address | |
| spender | address |
Returns
| Name | Type | Description |
|---|---|---|
| — | uint256 |
balanceOf(account: address)
view
dev: See {IERC20-balanceOf}.
Parameters
| Name | Type | Description |
|---|---|---|
| account | address |
Returns
| Name | Type | Description |
|---|---|---|
| — | uint256 |
decimals()
view
→ 0
dev: 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 {_setupDecimals} is called. 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}.
Returns
| Name | Type | Description |
|---|---|---|
| — | uint8 |
isMaster()
view
→ true
Returns
| Name | Type | Description |
|---|---|---|
| — | bool |
l1Address()
view
→ 0x0000000000000000000000000000000000000000
Returns
| Name | Type | Description |
|---|---|---|
| — | address | address of layer 1 token |
l2Gateway()
view
→ 0x0000000000000000000000000000000000000000
Returns
| Name | Type | Description |
|---|---|---|
| — | address |
name()
view
→
dev: Returns the name of the token.
Returns
| Name | Type | Description |
|---|---|---|
| — | string |
nonces(owner: address)
view
dev: See {IERC20Permit-nonces}.
Parameters
| Name | Type | Description |
|---|---|---|
| owner | address |
Returns
| Name | Type | Description |
|---|---|---|
| — | uint256 |
symbol()
view
→
dev: Returns the symbol of the token, usually a shorter version of the name.
Returns
| Name | Type | Description |
|---|---|---|
| — | string |
totalSupply()
view
→ 0
dev: See {IERC20-totalSupply}.
Returns
| Name | Type | Description |
|---|---|---|
| — | uint256 |
Write Functions
approve(spender: address, amount: uint256)
nonpayable
dev: See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
Parameters
| Name | Type | Description |
|---|---|---|
| spender | address | |
| amount | uint256 |
Returns
| Name | Type | Description |
|---|---|---|
| — | bool |
bridgeBurn(account: address, amount: uint256)
nonpayable
Burn tokens on L2.
dev: only the token bridge can call this
Parameters
| Name | Type | Description |
|---|---|---|
| account | address | owner of tokens |
| amount | uint256 | amount of tokens burnt |
bridgeInit(_l1Address: address, _data: bytes)
nonpayable
initialize the token
dev: the L2 bridge assumes this does not fail or revert
Parameters
| Name | Type | Description |
|---|---|---|
| _l1Address | address | L1 address of ERC20 |
| _data | bytes | encoded symbol/name/decimal data for initial deploy |
bridgeMint(account: address, amount: uint256)
nonpayable
Mint tokens on L2. Callable path is L1Gateway depositToken (which handles L1 escrow), which triggers L2Gateway, which calls this
Parameters
| Name | Type | Description |
|---|---|---|
| account | address | recipient of tokens |
| amount | uint256 | amount of tokens minted |
decreaseAllowance(spender: address, subtractedValue: uint256)
nonpayable
dev: 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`.
Parameters
| Name | Type | Description |
|---|---|---|
| spender | address | |
| subtractedValue | uint256 |
Returns
| Name | Type | Description |
|---|---|---|
| — | bool |
increaseAllowance(spender: address, addedValue: uint256)
nonpayable
dev: 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.
Parameters
| Name | Type | Description |
|---|---|---|
| spender | address | |
| addedValue | uint256 |
Returns
| Name | Type | Description |
|---|---|---|
| — | bool |
permit(owner: address, spender: address, value: uint256, deadline: uint256, v: uint8, r: bytes32, s: bytes32)
nonpayable
dev: See {IERC20Permit-permit}.
Parameters
| Name | Type | Description |
|---|---|---|
| owner | address | |
| spender | address | |
| value | uint256 | |
| deadline | uint256 | |
| v | uint8 | |
| r | bytes32 | |
| s | bytes32 |
transfer(recipient: address, amount: uint256)
nonpayable
dev: See {IERC20-transfer}. Requirements: - `recipient` cannot be the zero address. - the caller must have a balance of at least `amount`.
Parameters
| Name | Type | Description |
|---|---|---|
| recipient | address | |
| amount | uint256 |
Returns
| Name | Type | Description |
|---|---|---|
| — | bool |
transferAndCall(_to: address, _value: uint256, _data: bytes)
nonpayable
dev: transfer token to a contract address with additional data if the recipient is a contact.
Parameters
| Name | Type | Description |
|---|---|---|
| _to | address | The address to transfer to. |
| _value | uint256 | The amount to be transferred. |
| _data | bytes | The extra data to be passed to the receiving contract. |
Returns
| Name | Type | Description |
|---|---|---|
| success | bool |
transferFrom(sender: address, recipient: address, amount: uint256)
nonpayable
dev: 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`.
Parameters
| Name | Type | Description |
|---|---|---|
| sender | address | |
| recipient | address | |
| amount | uint256 |
Returns
| Name | Type | Description |
|---|---|---|
| — | bool |
Events
Approval(owner: address, spender: address, value: uint256)
| Name | Type | Indexed | Description |
|---|---|---|---|
| owner | address | ✓ | |
| spender | address | ✓ | |
| value | uint256 |
Transfer(from: address, to: address, value: uint256, data: bytes)
| Name | Type | Indexed | Description |
|---|---|---|---|
| from | address | ✓ | |
| to | address | ✓ | |
| value | uint256 | ||
| data | bytes |
Transfer(from: address, to: address, value: uint256)
| Name | Type | Indexed | Description |
|---|---|---|---|
| from | address | ✓ | |
| to | address | ✓ | |
| value | uint256 |