A Signer in ethers is an abstraction of an Ethereum Account, which can be used to sign messages and transactions and send signed transactions to the Ethereum Network to execute state changing operations.
The available operations depend largely on the sub-class used.
For example, a Signer from MetaMask can send transactions and sign messages but cannot sign a transaction (without broadcasting it).
The most common Signers you will encounter are:
- Wallet, which is a class which knows its private key and can execute any operations with it
- JsonRpcSigner, which is connected to a JsonRpcProvider (or sub-class) and is acquired using getSigner
Signer
The Signer class is abstract and cannot be directly instantiated.
Instead use one of the concrete sub-classes, such as the Wallet, VoidSigner or JsonRpcSigner.
Sub-classes must implement this, however they may simply throw an error if changing providers is not supported.
Returns a Promise that resolves to the account address.
This is a Promise so that a Signer can be designed around an asynchronous source, such as hardware wallets.
Sub-classes must implement this.
Returns true if and only if object is a Signer.
Returns the balance of this wallet at blockTag.
Returns the chain ID this wallet is connected to.
Returns the number of transactions this account has ever sent. This is the value required to be included in transactions as the nonce.
Returns the result of calling using the transactionRequest, with this account address being used as the from field.
Returns the result of estimating the cost to send the transactionRequest, with this account address being used as the from field.
Returns the address associated with the ensName.
This returns a Promise which resolves to the Raw Signature of message.
A signed message is prefixd with "\x19Ethereum Signed Message:\n" and the length of the message, using the hashMessage method, so that it is EIP-191 compliant. If recovering the address in Solidity, this prefix will be required to create a matching hash.
Sub-classes must implement this, however they may throw if signing a message is not supported, such as in a Contract-based Wallet or Meta-Transaction-based Wallet.
If message is a string, it is treated as a string and converted to its representation in UTF8 bytes.
If and only if a message is a Bytes will it be treated as binary data.
For example, the string "0x1234" is 6 characters long (and in this case 6 bytes long). This is not equivalent to the array [ 0x12, 0x34 ], which is 2 bytes long.
A common case is to sign a hash. In this case, if the hash is a string, it must be converted to an array first, using the arrayify utility function.
Returns a Promise which resolves to the signed transaction of the transactionRequest. This method does not populate any missing fields.
Sub-classes must implement this, however they may throw if signing a transaction is not supported, which is common for security reasons in many clients.
This method populates the transactionRequest with missing fields, using populateTransaction and returns a Promise which resolves to the transaction.
Sub-classes must implement this, however they may throw if sending a transaction is not supported, such as the VoidSigner or if the Wallet is offline and not connected to a Provider.
Signs the typed data value with types data structure for domain using the EIP-712 specification.
This is still an experimental feature. If using it, please specify the exact version of ethers you are using (e.g. spcify "5.0.18", not "^5.0.18") as the method name will be renamed from _signTypedData to signTypedData once it has been used in the field a bit.
It is very important that all important properties of a Signer are immutable. Since Ethereum is very asynchronous and deals with critical data (such as ether and other potentially valuable crypto assets), keeping properties such as the provider and address static throughout the life-cycle of the Signer helps prevent serious issues and many other classes and libraries make this assumption.
A sub-class must extend Signer and must call super().
This is generally not required to be overridden, but may be needed to provide custom behaviour in sub-classes.
This should return a copy of the transactionRequest, with any properties needed by call, estimateGas and populateTransaction (which is used by sendTransaction). It should also throw an error if any unknown key is specified.
The default implementation checks only if valid TransactionRequest properties exist and adds from to the transaction if it does not exist.
If there is a from field it must be verified to be equal to the Signer's address.
This is generally not required to be overridden, but may be needed to provide custom behaviour in sub-classes.
This should return a copy of transactionRequest, follow the same procedure as checkTransaction and fill in any properties required for sending a transaction. The result should have all promises resolved; if needed the resolveProperties utility function can be used for this.
The default implementation calls checkTransaction and resolves to if it is an ENS name, adds gasPrice, nonce, gasLimit and chainId based on the related operations on Signer.
Wallet inherits ExternallyOwnedAccount and Signer
The Wallet class inherits Signer and can sign transactions and messages using a private key as a standard Externally Owned Account (EOA).
Create a new Wallet instance for privateKey and optionally connected to the provider.
Returns a new Wallet with a random private key, generated from cryptographically secure entropy sources. If the current environment does not have a secure entropy source, an error is thrown.
Wallets created using this method will have a mnemonic.
Create an instance by decrypting an encrypted JSON wallet.
If progress is provided it will be called during decryption with a value between 0 and 1 indicating the progress towards completion.
Create an instance from an encrypted JSON wallet.
This operation will operate synchronously which will lock up the user interface, possibly for a non-trivial duration. Most applications should use the asynchronous fromEncryptedJson instead.
Create an instance from a mnemonic phrase.
If path is not specified, the Ethereum default path is used (i.e. m/44'/60'/0'/0/0).
If wordlist is not specified, the English Wordlist is used.
The address for the account this Wallet represents.
The provider this wallet is connected to, which will be used for any Blockchain Methods methods. This can be null.
A Wallet instance is immutable, so if you wish to change the Provider, you may use the connect method to create a new instance connected to the desired provider.
The uncompressed public key for this Wallet represents.
Encrypt the wallet using password returning a Promise which resolves to a JSON wallet.
If progress is provided it will be called during decryption with a value between 0 and 1 indicating the progress towards completion.
A VoidSigner is a simple Signer which cannot sign.
It is useful as a read-only signer, when an API requires a Signer as a parameter, but it is known only read-only operations will be carried.
For example, the call operation will automatically have the provided address passed along during the execution.
Create a new instance of a VoidSigner for address.
The address of this VoidSigner.
This is an interface which contains a minimal set of properties required for Externally Owned Accounts which can have certain operations performed, such as encoding as a JSON wallet.
The privateKey of this EOA
Optional. The account HD mnemonic, if it has one and can be determined. Some sources do not encode the mnemonic, such as HD extended keys.