Address input
Address fields help you identify a transfer recipient, multisig member, delegate, contract to call, or body. Wherever the app asks for an account or contract address, the field uses the same validation and ENS resolution. The surrounding form determines whether a value is required and what the address will be used for.
Validation and ENS resolution
Checksum enforcement is on by default. The field accepts an all-lowercase, all-uppercase, or correctly checksummed address and normalizes it to its EIP-55 checksum form. An address whose mixed-case checksum is wrong is marked critical and is not accepted, because a failed checksum is how a mistyped address is detected. Surrounding whitespace is trimmed when the field loses focus, and the field reports a value only when the input is a valid address or a resolvable ENS name.
A .eth name resolves through Ethereum mainnet's ENS Universal Resolver, and an entered address receives the corresponding reverse lookup; when both are known, the field can switch between showing the ENS name and the address. Resolution uses mainnet even when the transaction being composed belongs to another chain, consistent with ENS as the profile layer.
Controls
The controls sit beside the value: paste when the field is empty, clear while editing a non-empty value, switch between the ENS name and the address when both have resolved, open the address in the block explorer of the chain the flow acts on, and copy the current field text. To copy the address behind a resolved ENS name, switch to the address view first. The explorer control is disabled when that chain has no configured explorer. It targets a resolved address or text that loosely parses as one, so an address with a wrong checksum can still expose the explorer and copy controls even though the field marks it critical and does not accept it.
Copying never reinterprets or authorizes the value. Address display applies the same exact-copy rule outside forms.
Last updated on