This documentation is for Ethers v5.
For Ethers v6, see the v6 documentation.
The ethers.js library aims to be a complete and compact library for interacting with the Ethereum Blockchain and its ecosystem. It was originally designed for use with ethers.io and has since expanded into a more general-purpose library.
- Keep your private keys in your client, safe and sound
- Import and export JSON wallets (Geth, Parity and crowdsale)
- Import and export BIP 39 mnemonic phrases (12 word backup phrases) and HD Wallets (English, Italian, Japanese, Korean, Simplified Chinese, Traditional Chinese; more coming soon)
- Meta-classes create JavaScript objects from any contract ABI, including ABIv2 and Human-Readable ABI
- Connect to Ethereum nodes over JSON-RPC, INFURA, Etherscan, Alchemy, Cloudflare or MetaMask.
- ENS names are first-class citizens; they can be used anywhere an Ethereum addresses can be used
- Tiny (~88kb compressed; 284kb uncompressed)
- Complete functionality for all your Ethereum needs
- Extensive documentation
- Large collection of test cases which are maintained and added to
- Fully TypeScript ready, with definition files and full TypeScript source
- MIT License (including ALL dependencies); completely open source to do with as you please
This section will be kept up to date, linking to documentation of older versions of the library.
Ethers' various Classes and Functions are available to import manually from sub-packages under the @ethersproject organization but for most projects, the umbrella package is the easiest way to get started.
It is generally better practice (for security reasons) to copy the ethers library to your own webserver and serve it yourself.
For quick demos or prototyping though, you can load it in your Web Applications from our CDN.
This section needs work...
| Provider | A Provider (in ethers) is a class which provides an abstraction for a connection to the Ethereum Network. It provides read-only access to the Blockchain and its status. | |
| Signer | A Signer is a class which (usually) in some way directly or indirectly has access to a private key, which can sign messages and transactions to authorize the network to charge your account ether to perform operations. | |
| Contract | A Contract is an abstraction which represents a connection to a specific contract on the Ethereum Network, so that applications can use it like a normal JavaScript object. | |
| Common Terms | ||
The quickest and easiest way to experiment and begin developing on Ethereum is to use MetaMask, which is a browser extension that provides:
- A connection to the Ethereum network (a Provider)
- Holds your private key and can sign things (a Signer)
The JSON-RPC API is another popular method for interacting with Ethereum and is available in all major Ethereum node implementations (e.g. Geth and Parity) as well as many third-party web services (e.g. INFURA). It typically provides:
- A connection to the Ethereum network (a Provider)
- Holds your private key and can sign things (a Signer)
Once you have a Provider, you have a read-only connection to the blockchain, which you can use to query the current state, fetch historic logs, look up deployed code and so on.
A Contract is an abstraction of program code which lives on the Ethereum blockchain.
The Contract object makes it easier to use an on-chain Contract as a normal JavaScript object, with the methods mapped to encoding and decoding data for you.
If you are familiar with Databases, this is similar to an Object Relational Mapper (ORM).
In order to communicate with the Contract on-chain, this class needs to know what methods are available and how to encode and decode the data, which is what the Application Binary Interface (ABI) provides.
This class is a meta-class, which means its methods are constructed at runtime, and when you pass in the ABI to the constructor it uses it to determine which methods to add.
While an on-chain Contract may have many methods available, you can safely ignore any methods you don't need or use, providing a smaller subset of the ABI to the contract.
An ABI often comes from the Solidity or Vyper compiler, but you can use the Human-Readable ABI in code, which the following examples use.
This is a brief overview of some aspects of Ethereum and blockchains which developers can make use of or should be aware of.
This section is sparse at the moment, but will be expanded as time goes on.
Logs and filtering are used quite often in blockchain applications, since they allow for efficient queries of indexed data and provide lower-cost data storage when the data is not required to be accessed on-chain.
These can be used in conjunction with the Provider Events API and with the Contract Events API.
The Contract Events API also provides higher-level methods to compute and query this data, which should be preferred over the lower-level filter.
When a Contract creates a log, it can include up to 4 pieces of data to be indexed by. The indexed data is hashed and included in a Bloom Filter, which is a data structure that allows for efficient filtering.
So, a filter may correspondingly have up to 4 topic-sets, where each topic-set refers to a condition that must match the indexed log topic in that position (i.e. each condition is AND-ed together).
If a topic-set is null, a log topic in that position is not filtered at all and any value matches.
If a topic-set is a single topic, a log topic in that position must match that topic.
If a topic-set is an array of topics, a log topic in that position must match any one of the topics (i.e. the topic in this position are OR-ed).
This may sound complicated at first, but is more easily understood with some examples.
| Topic-Sets | Matching Logs | |||
| [ A ] | topic[0] = A | |||
| [ A, null ] | ||||
| [ null, B ] | topic[1] = B | |||
| [ null, [ B ] ] | ||||
| [ null, [ B ], null ] | ||||
| [ A, B ] | (topic[0] = A) AND (topic[1] = B) | |||
| [ A, [ B ] ] | ||||
| [ A, [ B ], null ] | ||||
| [ [ A, B ] ] | (topic[0] = A) OR (topic[0] = B) | |||
| [ [ A, B ], null ] | ||||
| [ [ A, B ], [ C, D ] ] | [ (topic[0] = A) OR (topic[0] = B) ] AND [ (topic[1] = C) OR (topic[1] = D) ] | |||
| Example Log Matching | ||||
To simplify life, ..., explain here, the contract API
This is a quick (and non-comprehensive) overview of how events are computed in Solidity.
This is likely out of the scope for most developers, but may be interesting to those who want to learn a bit more about the underlying technology.
Solidity provides two types of events, anonymous and non-anonymous. The default is non-anonymous, and most developers will not need to worry about anonymous events.
For non-anonymous events, up to 3 topics may be indexed (instead of 4), since the first topic is reserved to specify the event signature. This allows non-anonymous events to always be filtered by their event signature.
This topic hash is always in the first slot of the indexed data, and is computed by normalizing the Event signature and taking the keccak256 hash of it.
For anonymous events, up to 4 topics may be indexed, and there is no signature topic hash, so the events cannot be filtered by the event signature.
Each additional indexed property is processed depending on whether its length is fixed or dynamic.
For fixed length types (e.g. uint, bytes5), all of which are internally exactly 32 bytes (shorter types are padded with zeros; numeric values are padded on the left, data values padded on the right), these are included directly by their actual value, 32 bytes of data.
For dynamic types (e.g. string, uint256[]) , the value is hashed using keccak256 and this hash is used.
Because dynamic types are hashed, there are important consequences in parsing events that should be kept in mind. Mainly that the original value is lost in the event. So, it is possible to tell is a topic is equal to a given string, but if they do not match, there is no way to determine what the value was.
If a developer requires that a string value is required to be both able to be filtered and also able to be read, the value must be included in the signature twice, once indexed and once non-indexed (e.g. someEvent(string indexed searchBy, string clearText)).
For a more detailed description, please refer to the Solidity Event Documentation.
Explain what happens to strings and bytes, how to filter and retain the value
Explain attack vectors
The gas price is used somewhat like a bid, indicating an amount you are willing to pay (per unit of execution) to have your transaction processed.
While security should be a concern for all developers, in the blockchain space developers must be additionally conscious of many areas which can be exploited.
Once a problem has an economic incentives to exploit it, there is a much larger risk and with blockchain apps it can become quite valuable to attack.
In addition to many of the other security issues app developers may have to worry about, there are a few additional vectors that JavaScript developers should be aware of.
A Side-Channel Attack occurs when something orthogonal to the implementation of the algorithm used can be exploited to learn more about secure or private information.
In JavaScript, memory may not be securely allocated, or more importantly securely released.
Historically, new Buffer(16) would re-use old memory that had been released. This would mean that code running later, may have access to data that was discarded.
As an example of the dangers, imagine if you had used a Buffer to store a private key, signed data and then returned from the function, allowing the Buffer to be de-allocated. A future function may be able to request a new Buffer, which would still have that left-over private key, which it could then use to steal the funds from that account.
There are also many debugging tools and systems designed to assist developers inspect the memory contents of JavaScript programs. In these cases, any private key or mnemonic sitting in memory may be visible to other users on the system, or malicious scripts.
Timing attacks allow a malicious user or script to determine private data through analysing how long an operation requires to execute.
In JavaScript, Garbage Collection occurs periodically when the system determines it is required. Each JavaScript implementation is different, with a variety of strategies and and abilities.
Most Garbage Collection requires "stopping the world", or pausing all code being executed while it runs. This adds a large delay to any code that was currently running.
This can be exploited by attackers to "condition cause a delay". They will set up a scenario where the system is on the edge of needing to garbage collect, and call your code with two paths, a simple path and complex path. The simple path won't stir things up enough to cause a garbage collection, while the complex one will. By timing how long the code took to execute, they now know whether garbage collection occured and therefore whether the simple or complex path was taken.
Advanced timing attacks are very difficult to mitigate in any garbage-collection-based language. Most libraries where this matters will hopefully mitigate this for you as much as possible, but it is still good to be aware of.
This is not specific to Ethereum, but is a useful technique to understand and has some implications on User Experience.
Many people are concerned that encrypting and decrypting an Ethereum wallet is quite slow and can take quite some time. It is important to understand this is intentional and provides much stronger security.
The algorithm usually used for this process is scrypt, which is a memory and CPU intensive algorithm which computes a key (fixed-length pseudo-random series of bytes) for a given password.
The goal is to use as much CPU and memory as possible during this algorithm, so that a single computer can only compute a very small number of results for some fixed amount of time. To scale up an attack, the attacker requires additional computers, increasing the cost to brute-force attack to guess the password.
For example, if a user knows their correct password, this process may take 10 seconds for them to unlock their own wallet and proceed.
But since an attacker does not know the password, they must guess; and each guess also requires 10 seconds. So, if they wish to try guessing 1 million passwords, their computer would be completely tied up for 10 million seconds, or around 115 days.
Without using an algorithm like this, a user would be able to log in instantly, however, 1 million passwords would only take a few seconds to attempt. Even secure passwords would likely be broken within a short period of time. There is no way the algorithm can be faster for a legitimate user without also being faster for an attacker.
Rather than reducing the security (see below), a better practice is to make the user feel better about waiting. The Ethers encryption and decryption API allows the developer to incorporate a progress bar, by passing in a progress callback which will be periodically called with a number between 0 and 1 indication percent completion.
In general a progress bar makes the experience feel faster, as well as more comfortable since there is a clear indication how much (relative) time is remaining. Additionally, using language like "decrypting..." in a progress bar makes a user feel like their time is not being needlessly wasted.
There are ways to reduce the time required to decrypt an Ethereum JSON Wallet, but please keep in mind that doing so discards nearly all security on that wallet.
The scrypt algorithm is designed to be tuned. The main purpose of this is to increase the difficulty as time goes on and computers get faster, but it can also be tuned down in situations where the security is less important.
Handling a change in the network (e.g. Görli vs Mainnet) is incredibly complex and a slight failure can at best make your application seem confusing and at worst cause the loss of funds, leak private data or misrepresent what an action performed.
Luckily, standard users should likely never change their networks unless tricked to do so or they make a mistake.
This is a problem you mainly need to worry about for developers, and most developers should understand the vast array of issues surrounding a network change during application operation and will understand the page reloading (which is already the default behaviour in many clients).
So, the best practice when a network change occurs is to simply refresh the page. This should cause all your UI components to reset to a known-safe state, including any banners and warnings to your users if they are on an unsupported network.
This can be accomplished by using the following function:
( TL; DR – sign up for your own API keys with the links below to improve your application performance )
When using a Provider backed by an API service (such as Alchemy, Etherscan or INFURA), the service requires an API key, which allows each service to track individual projects and their usage and permissions.
The ethers library offers default API keys for each service, so that each Provider works out-of-the-box.
These API keys are provided as a community resource by the backend services for low-traffic projects and for early prototyping.
Since these API keys are shared by all users (that have not acquired their own API key), they are aggressively throttled which means retries occur more frequently and the responses are slower.
It is highly recommended that you sign up for a free API key from each service for their free tier, which (depending on the service) includes many advantages:
- a much higher request rate and concurrent request limit
- faster responses with fewer retries and timeouts
- useful metric tracking for performance tuning and to analyze your customer behaviour
- more advanced APIs, such as archive data or advanced log queries
Etherscan(see the EtherscanProvider)
Etherscan is an Ethereum block explorer, which is possibly the most useful developer tool for building and debugging Ethereum applications.
They offer an extensive collection of API endpoints which provide all the operations required to interact with the Ethereum Blockchain.
Sign up for a free API key on Etherscan
Benefits:
- higher rate limit (since you are not using the shared rate limit)
- customer usage metrics
homestead, goerli, sepolia, matic. maticmum, arbitrum, arbitrum-goerli, optimism and optimism-goerli.
INFURA(see the InfuraProvider)
The INFURA service has been around for quite some time and is very robust and reliable and highly recommended.
They offer a standard JSON-RPC interface and a WebSocket interface, which makes interaction with standard tools versatile, simple and straightforward.
Sign up for a free Project ID on INFURA
Benefits:
- higher rate limit
- customer usage metrics
- access to archive data (requires paid upgrade)
homestead, goerli, sepolia, matic. maticmum, arbitrum, arbitrum-goerli, optimism and optimism-goerli.
Alchemy(see the AlchemyProvider)
The Alchemy service has been around a few years and is also very robust and reliable.
They offer a standard JSON-RPC interface and a WebSocket interface, as well as a collection of advanced APIs for interacting with tokens and to assist with debugging.
Sign up for a free API key on Alchemy
Benefits:
- higher rate limit
- customer usage metrics
- access to advanced token balance and metadata APIs
- access to advanced debugging trace and revert reason APIs
homestead, goerli, matic. maticmum, arbitrum, arbitrum-goerli, optimism and optimism-goerli.
Pocket Gateway(see the PocketProvider)
They offer a standard JSON-RPC interface using either a load-balanced network or non-load-balanced fleet.
Sign up for a free API key on Pocket
Benefits:
- customer usage metrics
- decentralized Access to Blockchain Infrastructure
- Stake as opposed to paying a monthly fee
- Highly redundant global set of nodes incentivized by cryptoeconomic incentives
homestead
Ankr(see the AnkrProvider)
They offer a standard JSON-RPC interface and have fairly high capacity without the need for an API key early on in the development cycle.
See their free tier features on Ankr
Benefits:
- higher rate limit
- customer usage metrics
- access to archive data (requires paid upgrade)
homestead, matic and arbitrum
The default provider connects to multiple backends and verifies their results internally, making it simple to have a high level of trust in third-party services.
A second optional parameter allows API keys to be specified to each Provider created internally and any API key omitted will fallback onto using the default API key for that service.
It is highly recommended that you provide an API for each service, to maximize your applications performance.
If the API key "-" is used, the corresponding Provider will be omitted.
An Application Programming Interface (API) is the formal specification of the library.
A Provider is an abstraction of a connection to the Ethereum network, providing a concise, consistent interface to standard Ethereum node functionality.
The ethers.js library provides several options which should cover the vast majority of use-cases, but also includes the necessary functions and classes for sub-classing if a more custom configuration is necessary.
Most users should use the Default Provider.
The default provider is the safest, easiest way to begin developing on Ethereum, and it is also robust enough for use in production.
It creates a FallbackProvider connected to as many backend services as possible. When a request is made, it is sent to multiple backends simultaneously. As responses from each backend are returned, they are checked that they agree. Once a quorum has been reached (i.e. enough of the backends agree), the response is provided to your application.
This ensures that if a backend has become out-of-sync, or if it has been compromised that its responses are dropped in favor of responses that match the majority.
Returns a new Provider, backed by multiple services, connected to network. If no network is provided, homestead (i.e. mainnet) is used.
The network may also be a URL to connect to, such as http://localhost:8545 or wss://example.com.
The options is an object, with the following properties:
| Property | Description | |
| alchemy | Alchemy API Token | |
| etherscan | Etherscan API Token | |
| infura | INFURA Project ID or { projectId, projectSecret } | |
Pocket Network Application ID or { applicationId, applicationSecretKey } | ||
| quorum | The number of backends that must agree (default: 2 for mainnet, 1 for testnets) | |
| Option Properties | ||
It is highly recommended for production services to acquire and specify an API Key for each service.
The default API Keys used by ethers are shared across all users, so services may throttle all services that are using the default API Keys during periods of load without realizing it.
Many services also have monitoring and usage metrics, which are only available if an API Key is specified. This allows tracking how many requests are being sent and which methods are being used the most.
Some services also provide additional paid features, which are only available when specifying an API Key.
There are several official common Ethereum networks as well as custom networks and other compatible projects.
Any API that accept a Networkish can be passed a common name (such as "mainnet" or "goerli") or chain ID to use that network definition or may specify custom parameters.
Returns the full Network for the given standard aNetworkish Networkish.
This is useful for functions and classes which wish to accept Networkish as an input parameter.
One common reason to specify custom properties for a Network is to override the address of the root ENS registry, either on a common network to intercept the ENS Methods or to specify the ENS registry on a dev network (on most dev networks you must deploy the ENS contracts manually).
A Provider in ethers is a read-only abstraction to access the blockchain data.
If you are coming from Web3.js, this is one of the biggest differences you will encounter using ethers.
The ethers library creates a strong division between the operation a Provider can perform and those of a Signer, which Web3.js lumps together.
This separation of concerns and a stricted subset of Provider operations allows for a larger variety of backends, a more consistent API and ensures other libraries to operate without being able to rely on any underlying assumption.
Returns the balance of address as of the blockTag block height.
Returns the contract code of address as of the blockTag block height. If there is no contract currently deployed, the result is 0x.
Returns the Bytes32 value of the position pos at address addr, as of the blockTag.
Returns the number of transactions address has ever sent, as of blockTag. This value is required to be the nonce for the next transaction from address sent to the network.
Get the block from the network, where the result.transactions is a list of transaction hashes.
Get the block from the network, where the result.transactions is an Array of TransactionResponse objects.
The Ethereum Naming Service (ENS) allows a short and easy-to-remember ENS Name to be attached to any set of keys and values.
One of the most common uses for this is to use a simple name to refer to an Ethereum Address.
In the ethers API, nearly anywhere that accepts an address, an ENS name may be used instead, which can simplify code and make reading and debugging much simpler.
The provider offers some basic operations to help resolve and work with ENS names.
Returns the URL for the avatar associated to the ENS name, or null if no avatar was configured.
Returns an EnsResolver instance which can be used to further inquire about specific entries for an ENS name.
Performs a reverse lookup of the address in ENS using the Reverse Registrar. If the name does not exist, or the forward lookup does not match, null is returned.
An ENS name requries additional configuration to setup a reverse record, they are not automatically set up.
Looks up the address of name. If the name is not owned, or does not have a Resolver configured, or the Resolver does not have an address configured, null is returned.
The name of this resolver.
The address of the Resolver.
Returns an object the provides the URL of the avatar and the linkage representing each stage in the avatar resolution.
If there is no avatar found (or the owner of any NFT does not match the name owner), null is returned.
The AvatarInfo has the properties:
info.linkage- An array of info on each step resolving the avatarinfo.url- The URL of the avatar
Returns a Promise which resolves to any stored EIP-1577 content hash.
Returns a Promise which resolves to any stored EIP-634 text entry for key.
Returns the Array of Log matching the filter.
Keep in mind that many backends will discard old events, and that requests which are too broad may get dropped as they require too many resources to execute the query.
Returns the block number (or height) of the most recently mined block.
Returns a best guess of the Gas Price to use in a transaction.
Returns the current recommended FeeData to use in a transaction.
For an EIP-1559 transaction, the maxFeePerGas and maxPriorityFeePerGas should be used.
For legacy transactions and networks which do not support EIP-1559, the gasPrice should be used.
Returns a Promise which will stall until the network has heen established, ignoring errors due to the target node not being active yet.
This can be used for testing or attaching scripts to wait until the node is up and running smoothly.
Returns the result of executing the transaction, using call. A call does not require any ether, but cannot change any state. This is useful for calling getters on Contracts.
Returns an estimate of the amount of gas that would be required to submit transaction to the network.
An estimate may not be accurate since there could be another transaction on the network that was not accounted for, but after being mined affected relevant state.
Returns the transaction with hash or null if the transaction is unknown.
If a transaction has not been mined, this method will search the transaction pool. Various backends may have more restrictive transaction pool access (e.g. if the gas price is too low or the transaction was only recently sent and not yet indexed) in which case this method may also return null.
Returns the transaction receipt for hash or null if the transaction has not been mined.
To stall until the transaction has been mined, consider the waitForTransaction method below.
Submits transaction to the network to be mined. The transaction must be signed, and be valid (i.e. the nonce is correct and the account has sufficient balance to pay for the transaction).
Returns a Promise which will not resolve until transactionHash is mined.
If confirms is 0, this method is non-blocking and if the transaction has not been mined returns null. Otherwise, this method will block until the transaction has confirms blocks mined on top of the block in which is was mined.
The EventEmitter API allows applications to use an Observer Pattern to register callbacks for when various events occur.
This closely follows the Event Emitter provided by other JavaScript libraries with the exception that event names support some more complex objects, not only strings. The objects are normalized internally.
Add a listener to be triggered for each eventName event.
Add a listener to be triggered for only the next eventName event, at which time it will be removed.
Notify all listeners of the eventName event, passing args to each listener. This is generally only used internally.
Remove a listener for the eventName event. If no listener is provided, all listeners for eventName are removed.
Remove all the listeners for the eventName events. If no eventName is provided, all events are removed.
Returns the number of listeners for the eventName events. If no eventName is provided, the total number of listeners is returned.
Returns the list of Listeners for the eventName events.
Any of the following may be used as the eventName in the above methods.
A filter is an object, representing a contract log Filter, which has the optional properties address (the source contract) and topics (a topic-set to match).
If address is unspecified, the filter matches any contract address.
See EventFilters for more information on filtering events.
The value of a Topic-Set Filter is a array of Topic-Sets.
This event is identical to a Log Filter with the address omitted (i.e. from any contract).
See EventFilters for more information on filtering events.
In addition to transaction and filter events, there are several named events.
| Event Name | Arguments | Description | |||||
"block" | blockNumber | emitted when a new block is mined | |||||
"error" | error | emitted on any error | |||||
"pending" | pendingTransaction | emitted when a new transaction enters the memory pool; only certain providers offer this event and may require running your own node for reliable results | |||||
"willPoll" | pollId | emitted prior to a polling loop is about to begin; (very rarely used by most developers) | |||||
"poll" | pollId, blockNumber | emitted during each poll cycle after `blockNumber` is updated (if changed) and before any other events (if any) are emitted during the poll loop; (very rarely used by most developers) | |||||
"didPoll" | pollId | emitted after all events from a polling loop are emitted; (very rarely used by most developers) | |||||
"debug" | provider dependent | each Provider may use this to emit useful debugging information and the format is up to the developer; (very rarely used by most developers) | |||||
| Named Provider Events | |||||||
Returns true if and only if object is a Provider.
Most Providers available in ethers are sub-classes of BaseProvider, which simplifies sub-classes, as it handles much of the event operations, such as polling and formatting.
Indicates if the Provider is currently polling. If there are no events to poll for or polling has been explicitly disabled, this will be false.
The frequency at which the provider polls.
JsonRpcProvider inherits BaseProvider
The JSON-RPC API is a popular method for interacting with Ethereum and is available in all major Ethereum node implementations (e.g. Geth and Parity) as well as many third-party web services (e.g. INFURA)
Connect to a JSON-RPC HTTP API using the URL or ConnectionInfo urlOrConnectionInfo connected to the networkish network.
If urlOrConnectionInfo is not specified, the default (i.e. http://localhost:8545) is used and if no network is specified, it will be determined automatically by querying the node using eth_chainId and falling back on eth_networkId.
Each node implementation is slightly different and may require specific command-line flags, configuration or settings in their UI to enable JSON-RPC, unlock accounts or expose specific APIs. Please consult their documentation.
The fully formed ConnectionInfo the Provider is connected to.
Returns a JsonRpcSigner which is managed by this Ethereum node, at addressOrIndex. If no addressOrIndex is provided, the first account (account #0) is used.
Returns a list of all account addresses managed by this provider.
Allows sending raw messages to the provider.
This can be used for backend-specific calls, such as for debugging or specific account management.
A JsonRpcSigner is a simple Signer which is backed by a connected JsonRpcProvider.
The provider this signer was established from.
Returns a new Signer object which does not perform additional checks when sending a transaction. See getUncheckedSigner for more details.
Sends the transaction and returns a Promise which resolves to the opaque transaction hash.
Request the node unlock the account (if locked) using password.
The JSON-RPC API only provides a transaction hash as the response when a transaction is sent, but the ethers Provider requires populating all details of a transaction before returning it. For example, the gas price and gas limit may be adjusted by the node or the nonce automatically included, in which case the opaque transaction hash has discarded this.
To remedy this, the JsonRpcSigner immediately queries the provider for the details using the returned transaction hash to populate the TransactionResponse object.
Some backends do not respond immediately and instead defer releasing the details of a transaction it was responsible for signing until it is mined.
The UncheckedSigner does not populate any additional information and will immediately return the result as a mock TransactionResponse-like object, with most of the properties set to null, but allows access to the transaction hash quickly, if that is all that is required.
StaticJsonRpcProvider inherits JsonRpcProvider
An ethers Provider will execute frequent getNetwork calls to ensure the network calls and network being communicated with are consistent.
In the case of a client like MetaMask, this is desired as the network may be changed by the user at any time, in such cases the cost of checking the chainId is local and therefore cheap.
However, there are also many times where it is known the network cannot change, such as when connecting to an INFURA endpoint, in which case, the StaticJsonRpcProvider can be used which will indefinitely cache the chain ID, which can reduce network traffic and reduce round-trip queries for the chain ID.
This Provider should only be used when it is known the network cannot change.
Many methods are less common or specific to certain Ethereum Node implementations (e.g. Parity vs Geth. These include account and admin management, debugging, deeper block and transaction exploration and other services (such as Swarm and Whisper).
The jsonRpcProvider.send method can be used to access these.
- All JSON-RPC methods (including the less common methods) which most Ethereum Nodes support.
- Parity's Trace Module can be used to trace and debug EVM execution of a transaction (requires custom configuration)
- Geth's Debug Module can be used to debug transactions and internal cache state, etc.
- Additional Geth Methods
- Additional Parity Methods
There are many services which offer a web API for accessing the Ethereum Blockchain. These Providers allow connecting to them, which simplifies development, since you do not need to run your own instance or cluster of Ethereum nodes.
However, this reliance on third-party services can reduce resilience, security and increase the amount of required trust. To mitigate these issues, it is recommended you use a Default Provider.
EtherscanProvider inherits BaseProvider
The EtherscanProvider is backed by a combination of the various Etherscan APIs.
Create a new EtherscanProvider connected to network with the optional apiKey.
The network may be specified as a string for a common network name, a number for a common chain ID or a [Network Object]provider-(network).
If no apiKey is provided, a shared API key will be used, which may result in reduced performance and throttled requests. It is highly recommended for production, you register with Etherscan for your own API key.
If no apiKey is provided, a shared API key will be used, which may result in reduced performance and throttled requests.
It is highly recommended for production, you register with Etherscan for your own API key.
homestead- Homestead (Mainnet)goerli- Görli (clique testnet)sepolia- Sepolia (proof-of-authority testnet)arbitrum- Arbitrum Optimistic L2arbitrum-goerli- Arbitrum Optimistic L2 testnetmatic- Polgon mainnetmaticmum- Polgon testnetoptimism- Optimism Optimistic L2optimism-goerli- Optimism Optimistic L2 testnet
@TODO... Explain
InfuraProvider inherits UrlJsonRpcProvider
The InfuraProvider is backed by the popular INFURA Ethereum service.
Create a new InfuraProvider connected to network with the optional apiKey.
The network may be specified as a string for a common network name, a number for a common chain ID or a [Network Object]provider-(network).
The apiKey can be a string Project ID or an object with the properties projectId and projectSecret to specify a Project Secret which can be used on non-public sources (like on a server) to further secure your API access and quotas.
Create a new WebSocketProvider using the INFURA web-socket endpoint to connect to network with the optional apiKey.
The network and apiKey are specified the same as the constructor.
If no apiKey is provided, a shared API key will be used, which may result in reduced performance and throttled requests.
It is highly recommended for production, you register with INFURA for your own API key.
homestead- Homestead (Mainnet)goerli- Görli (clique testnet)sepolia- Sepolia (proof-of-authority testnet)arbitrum- Arbitrum Optimistic L2arbitrum-goerli- Arbitrum Optimistic L2 testnetmatic- Polgon mainnetmaticmum- Polgon testnetoptimism- Optimism Optimistic L2optimism-goerli- Optimism Optimistic L2 testnet
AlchemyProvider inherits UrlJsonRpcProvider
The AlchemyProvider is backed by Alchemy.
Create a new AlchemyProvider connected to network with the optional apiKey.
The network may be specified as a string for a common network name, a number for a common chain ID or a Network Object.
If no apiKey is provided, a shared API key will be used, which may result in reduced performance and throttled requests.
It is highly recommended for production, you register with Alchemy for your own API key.
homestead- Homestead (Mainnet)goerli- Görli (clique testnet)arbitrum- Arbitrum Optimistic L2arbitrum-goerli- Arbitrum Optimistic L2 testnetmatic- Polgon mainnetmaticmum- Polgon testnetoptimism- Optimism Optimistic L2optimism-goerli- Optimism Optimistic L2 testnet
CloudflareProvider inherits UrlJsonRpcProvider
The CloudflareProvider is backed by the Cloudflare Ethereum Gateway.
Create a new CloudflareProvider connected to mainnet (i.e. "homestead").
homestead- Homestead (Mainnet)
PocketProvider inherits UrlJsonRpcProvider
The PocketProvider is backed by Pocket.
Create a new PocketProvider connected to network with the optional apiKey.
The network may be specified as a string for a common network name, a number for a common chain ID or a Network Object.
If no apiKey is provided, a shared API key will be used, which may result in reduced performance and throttled requests.
It is highly recommended for production, you register with Pocket for your own API key.
homestead- Homestead (Mainnet)goerli- Görli (clique testnet)matic- Polgon mainnetmaticmum- Polgon testnet
AnkrProvider inherits UrlJsonRpcProvider
The AnkrProvider is backed by Ankr.
Create a new AnkrProvider connected to network with the optional apiKey.
The network may be specified as a string for a common network name, a number for a common chain ID or a Network Object.
If no apiKey is provided, a shared API key will be used, which may result in reduced performance and throttled requests.
It is highly recommended for production, you register with Ankr for your own API key.
homestead- Homestead (Mainnet)matic- Polygonarbitrum- Arbitrum (L2; optimistic roll-up)
FallbackProvider inherits BaseProvider
The FallbackProvider is the most advanced Provider available in ethers.
It uses a quorum and connects to multiple Providers as backends, each configured with a priority and a weight .
When a request is made, the request is dispatched to multiple backends, randomly chosen (lower-value priority backends are always selected first) and the results from each are compared against the others. Only once the quorum has been reached will that result be accepted and returned to the caller.
By default the quorum requires 50% (rounded up) of the backends to agree. The weight can be used to give a backend Provider more influence.
Creates a new instance of a FallbackProvider connected to providers. If quorum is not specified, half of the total sum of the provider weights is used.
The providers can be either an array of Provider or FallbackProviderConfig. If a Provider is provided, the defaults are a priority of 1 and a weight of 1.
The list of Provider Configurations that describe the backends.
The quorum the backend responses must agree upon before a result will be resolved. By default this is half the sum of the weights.
The provider for this configuration.
The priority used for the provider. Lower-value priorities are favoured over higher-value priorities. If multiple providers share the same priority, they are chosen at random.
The timeout (in ms) after which another Provider will be attempted. This does not affect the current Provider; if it returns a result it is counted as part of the quorum.
Lower values will result in more network traffic, but may reduce the response time of requests.
The weight a response from this provider provides. This can be used if a given Provider is more trusted, for example.
IpcProvider inherits JsonRpcProvider
The IpcProvider allows the JSON-RPC API to be used over a local filename on the file system, exposed by Geth, Parity and other nodes.
This is only available in node.js (as it requires file system access, and may have additional complications due to file permissions. See any related notes on the documentation for the actual node implementation websites.
The path this Provider is connected to.
JsonRpcBatchProvider inherits JsonRpcProvider
The JsonRpcBatchProvider operated identically to any other Provider, except the calls are implicly batched during an event-loop and sent using the JSON-RPC batch protocol to the backend.
This results in fewer connections and fewer requests, which may result in lower costs or faster responses, depending on your use case.
Keep in mind some backends may not support batched requests.
UrlJsonRpcProvider inherits JsonRpcProvider
This class is intended to be sub-classed and not used directly. It simplifies creating a Provider where a normal JsonRpcProvider would suffice, with a little extra effort needed to generate the JSON-RPC URL.
Sub-classes do not need to override this. Instead they should override the static method getUrl and optionally getApiKey.
The value of the apiKey that was returned from InheritedClass.getApiKey.
This function should examine the apiKey to ensure it is valid and return a (possible modified) value to use in getUrl.
The URL to use for the JsonRpcProvider instance.
Web3Provider inherits JsonRpcProvider
The Web3Provider is meant to ease moving from a web3.js based application to ethers by wrapping an existing Web3-compatible (such as a Web3HttpProvider, Web3IpcProvider or Web3WsProvider) and exposing it as an ethers.js Provider which can then be used with the rest of the library.
This may also be used to wrap a standard EIP-1193 Provider.
Create a new Web3Provider, which wraps an EIP-1193 Provider or Web3Provider-compatible Provider.
The provider used to create this instance.
An ExternalProvider can be either one for the above mentioned Web3 Providers (or otherwise compatible) or an EIP-1193 provider.
An ExternalProvider must offer one of the following signatures, and the first matching is used:
This follows the EIP-1193 API signature.
The request should be a standard JSON-RPC payload, which should at a minimum specify the method and params.
The result should be the actual result, which differs from the Web3.js response, which is a wrapped JSON-RPC response.
This follows the Web3.js Provider Signature.
The request should be a standard JSON-RPC payload, which should at a minimum specify the method and params.
The callback should use the error-first calling semantics, so (error, result) where the result is a JSON-RPC wrapped result.
This is identical to sendAsync. Historically, this used a synchronous web request, but no current browsers support this, so its use this way was deprecated quite a long time ago
WebSocketProvider inherits JsonRpcProvider
The WebSocketProvider connects to a JSON-RPC WebSocket-compatible backend which allows for a persistent connection, multiplexing requests and pub-sub events for a more immediate event dispatching.
The WebSocket API is newer, and if running your own infrastructure, note that WebSockets are much more intensive on your server resources, as they must manage and maintain the state for each client. For this reason, many services may also charge additional fees for using their WebSocket endpoints.
Returns a new WebSocketProvider connected to url as the network.
If url is unspecified, the default "ws://localhost:8546" will be used. If network is unspecified, it will be queried from the network.
A BlockTag specifies a specific block location in the Blockchain.
"latest"- The most recently mined block"earliest"- Block #0"pending"- The block currently being prepared for mining; not all operations and backends support this BlockTag- number - The block at this height
- a negative number - The block this many blocks ago
- hex string - The block at this height (as a hexidecimal value)
A Networkish may be any of the following:
- a Network object
- the name of a common network as a string (e.g.
"homestead") - the chain ID a network as a number; if the chain ID is that of a common network, the
nameandensAddresswill be populated, otherwise, the default name"unknown"and noensAddressis used
A Network represents an Ethereum network.
The human-readable name of the network, such as homestead. If the network name is unknown, this will be "unknown".
The Chain ID of the network.
The address at which the ENS registry is deployed on this network.
A FeeData object encapsulates the necessary fee data required to send a transaction, based on the best available recommendations.
The gasPrice to use for legacy transactions or networks which do not support EIP-1559.
The maxFeePerGas to use for a transaction. This is based on the most recent block's baseFee.
The maxPriorityFeePerGas to use for a transaction. This accounts for the uncle risk and for the majority of current MEV risk.
The hash of this block.
The hash of the previous block.
The height (number) of this block.
The timestamp of this block.
The nonce used as part of the proof-of-work to mine this block.
This property is generally of little interest to developers.
The difficulty target required to be met by the miner of the block.
Recently the difficulty frequently exceeds the size that a JavaScript number can safely store (53-bits), so in that case this property may be null. It is recommended to use the `_difficulty` property below, which will always return a value, but as a BigNumber.
This property is generally of little interest to developers.
The difficulty target required to be met by the miner of the block, as a BigNumber.
Recently the difficulty frequently exceeds the size that a JavaScript number can safely store (53-bits), so this property was added to safely encode the value for applications that require it.
This property is generally of little interest to developers.
The maximum amount of gas that this block was permitted to use. This is a value that can be voted up or voted down by miners and is used to automatically adjust the bandwidth requirements of the network.
This property is generally of little interest to developers.
The total amount of gas used by all transactions in this block.
The coinbase address of this block, which indicates the address the miner that mined this block would like the subsidy reward to go to.
This is extra data a miner may choose to include when mining a block.
This property is generally of little interest to developers.
Often only the hashes of the transactions included in a block are needed, so by default a block only contains this information, as it is substantially less data.
A list of the transactions hashes for each transaction this block includes.
BlockWithTransactions inherits Block
If all transactions for a block are needed, this object instead includes the full details on each transaction.
A list of the transactions this block includes.
The address to filter by, or null to match any address.
The topics to filter by or null to match any topics.
Each entry represents an AND condition that must match, or may be null to match anything. If a given entry is an Array, then that entry is treated as an OR for any value in the entry.
See Filters for more details and examples on specifying complex filters.
Filter inherits EventFilter
The starting block (inclusive) to search for logs matching the filter criteria.
The end block (inclusive) to search for logs matching the filter criteria.
FilterByBlockHash inherits EventFilter
The specific block (by its block hash) to search for logs matching the filter criteria.
The block height (number) of the block including the transaction of this log.
The block hash of the block including the transaction of this log.
During a re-org, if a transaction is orphaned, this will be set to true to indicate the Log entry has been removed; it will likely be emitted again in the near future when another block is mined with the transaction that triggered this log, but keep in mind the values may change.
The address of the contract that generated this log.
The data included in this log.
The list of topics (indexed properties) for this log.
The transaction hash of the transaction of this log.
The index of the transaction in the block of the transaction of this log.
The index of this log across all logs in the entire block.
A transaction request describes a transaction that is to be sent to the network or otherwise processed.
All fields are optional and may be a promise which resolves to the required type.
The address (or ENS name) this transaction it to.
The address this transaction is from.
The nonce for this transaction. This should be set to the number of transactions ever sent from this address.
The transaction data.
The amount (in wei) this transaction is sending.
The maximum amount of gas this transaction is permitted to use.
If left unspecified, ethers will use estimateGas to determine the value to use. For transactions with unpredicatable gas estimates, this may be required to specify explicitly.
The price (in wei) per unit of gas this transaction will pay.
This may not be specified for transactions with type set to 1 or 2, or if maxFeePerGas or maxPriorityFeePerGas is given.
The maximum price (in wei) per unit of gas this transaction will pay for the combined EIP-1559 block's base fee and this transaction's priority fee.
Most developers should leave this unspecified and use the default value that ethers determines from the network.
This may not be specified for transactions with type set to 0 or if gasPrice is specified..
The price (in wei) per unit of gas this transaction will allow in addition to the EIP-1559 block's base fee to bribe miners into giving this transaction priority. This is included in the maxFeePerGas, so this will not affect the total maximum cost set with maxFeePerGas.
Most developers should leave this unspecified and use the default value that ethers determines from the network.
This may not be specified for transactions with type set to 0 or if gasPrice is specified.
The chain ID this transaction is authorized on, as specified by EIP-155.
If the chain ID is 0 will disable EIP-155 and the transaction will be valid on any network. This can be dangerous and care should be taken, since it allows transactions to be replayed on networks that were possibly not intended. Intentionally-replayable transactions are also disabled by default on recent versions of Geth and require configuration to enable.
The EIP-2718 type of this transaction envelope, or null for to use the network default. To force using a lagacy transaction without an envelope, use type 0.
The AccessList to include; only available for EIP-2930 and EIP-1559 transactions.
TransactionResponse inherits Transaction
A TransactionResponse includes all properties of a Transaction as well as several properties that are useful once it has been mined.
The number ("height") of the block this transaction was mined in. If the block has not been mined, this is null.
The hash of the block this transaction was mined in. If the block has not been mined, this is null.
The timestamp of the block this transaction was mined in. If the block has not been mined, this is null.
The number of blocks that have been mined (including the initial block) since this transaction was mined.
The serialized transaction. This may be null as some backends do not populate it. If this is required, it can be computed from a TransactionResponse object using this cookbook recipe.
Resolves to the TransactionReceipt once the transaction has been included in the chain for confirms blocks. If confirms is 0, and the transaction has not been mined, null is returned.
If the transaction execution failed (i.e. the receipt status is 0), a CALL_EXCEPTION error will be rejected with the following properties:
error.transaction- the original transactionerror.transactionHash- the hash of the transactionerror.receipt- the actual receipt, with the status of0
If the transaction is replaced by another transaction, a TRANSACTION_REPLACED error will be rejected with the following properties:
error.hash- the hash of the original transaction which was replacederror.reason- a string reason; one of"repriced","cancelled"or"replaced"error.cancelled- a boolean; a"repriced"transaction is not considered cancelled, but"cancelled"and"replaced"areerror.replacement- the replacement transaction (a TransactionResponse)error.receipt- the receipt of the replacement transaction (a TransactionReceipt)
Transactions are replaced when the user uses an option in their client to send a new transaction from the same account with the original nonce. This is usually to speed up a transaction or to cancel one, by bribing miners with additional fees to prefer the new transaction over the original one.
The EIP-2718 type of this transaction. If the transaction is a legacy transaction without an envelope, it will have the type 0.
The AccessList included, or null for transaction types which do not support access lists.
The address this transaction is to. This is null if the transaction was an init transaction, used to deploy a contract.
The address this transaction is from.
If this transaction has a null to address, it is an init transaction used to deploy a contract, in which case this is the address created by that contract.
To compute a contract address, the getContractAddress utility function can also be used with a TransactionResponse object, which requires the transaction nonce and the address of the sender.
The index of this transaction in the list of transactions included in the block this transaction was mined in.
The EIP-2718 type of this transaction. If the transaction is a legacy transaction without an envelope, it will have the type 0.
The intermediate state root of a receipt.
Only transactions included in blocks before the Byzantium Hard Fork have this property, as it was replaced by the status property.
The property is generally of little use to developers. At the time it could be used to verify a state transition with a fraud-proof only considering the single transaction; without it the full block must be considered.
The amount of gas actually used by this transaction.
The effective gas price the transaction was charged at.
Prior to EIP-1559 or on chains that do not support it, this value will simply be equal to the transaction gasPrice.
On EIP-1559 chains, this is equal to the block baseFee for the block that the transaction was included in, plus the transaction maxPriorityFeePerGas clamped to the transaction maxFeePerGas.
A bloom-filter, which includes all the addresses and topics included in any log in this transaction.
The block hash of the block that this transaction was included in.
The transaction hash of this transaction.
All the logs emitted by this transaction.
The block height (number) of the block that this transaction was included in.
The number of blocks that have been mined since this transaction, including the actual block it was mined in.
For the block this transaction was included in, this is the sum of the gas used by each transaction in the ordered list of transactions up to (and including) this transaction.
This is generally of little interest to developers.
This is true if the block is in a post-Byzantium Hard Fork block.
The status of a transaction is 1 is successful or 0 if it was reverted. Only transactions included in blocks post-Byzantium Hard Fork have this property.
An Access List is optional an includes a list of addresses and storage slots for that address which should be warmed or pre-fetched for use within the execution of this transaction. A warmed value has an additional upfront cost to access, but is discounted throughout the code execution for reading and writing.
A looser description of an AccessList, which will be converted internally using accessListify.
It may be any of:
- any AccessList
- an Array of 2-element Arrays, where the first element is the address and second array is an array of storage keys
- an object, whose keys represent the addresses and each value is an array of storage keys
When using the object form (the last option), the addresses and storage slots will be sorted. If an explicit order for the access list is required, one of the other forms must be used. Most developers do not require explicit order.
An EIP-2930 transaction allows an optional AccessList which causes a transaction to warm (i.e. pre-cache) another addresses state and the specified storage keys.
This incurs an increased intrinsic cost for the transaction, but provides discounts for storage and state access throughout the execution of the transaction.
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.
A Contract object is an abstraction of a contract (EVM bytecode) deployed on the Ethereum network. It allows for a simple way to serialize calls and transactions to an on-chain contract and deserialize their results and emitted logs.
A ContractFactory is an abstraction of a contract's bytecode and facilitates deploying a contract.
Contract
A Contract is an abstraction of code that has been deployed to the blockchain.
A Contract may be sent transactions, which will trigger its code to be run with the input of the transaction data.
Returns a new instance of the Contract attached to a new address. This is useful if there are multiple similar or identical copies of a Contract on the network and you wish to interact with each of them.
This is the address (or ENS name) the contract was constructed with.
This is a promise that will resolve to the address the Contract object is attached to. If an Address was provided to the constructor, it will be equal to this; if an ENS name was provided, this will be the resolved address.
If the Contract object is the result of a ContractFactory deployment, this is the transaction which was used to deploy the contract.
If a provider was provided to the constructor, this is that provider. If a signer was provided that had a Provider, this is that provider.
If a signer was provided to the constructor, this is that signer.
Return Events that match the event.
Return the number of listeners that are subscribed to event. If no event is provided, returns the total count of all events.
Return a list of listeners that are subscribed to event.
Unsubscribe listener to event.
Subscribe to event calling listener when the event occurs.
Subscribe once to event calling listener when the event occurs.
Unsubscribe all listeners for event. If no event is provided, all events are unsubscribed.
A Meta-Class is a Class which has any of its properties determined at run-time. The Contract object uses a Contract's ABI to determine what methods are available, so the following sections describe the generic ways to interact with the properties added at run-time during the Contract constructor.
A constant method (denoted by pure or view in Solidity) is read-only and evaluates a small amount of EVM code against the current blockchain state and can be computed by asking a single node, which can return a result. It is therefore free and does not require any ether, but cannot make changes to the blockchain state..
The type of the result depends on the ABI. If the method returns a single value, it will be returned directly, otherwise a Result object will be returned with each parameter available positionally and if the parameter is named, it will also be available by its name.
For values that have a simple meaning in JavaScript, the types are fairly straightforward; strings and booleans are returned as JavaScript strings and booleans.
For numbers, if the type is in the JavaScript safe range (i.e. less than 53 bits, such as an int24 or uint48) a normal JavaScript number is used. Otherwise a BigNumber is returned.
For bytes (both fixed length and dynamic), a DataHexString is returned.
If the call reverts (or runs out of gas), a CALL_EXCEPTION will be thrown which will include:
error.address- the contract addresserror.args- the arguments passed into the methoderror.transaction- the transaction
The overrides object for a read-only method may include any of:
overrides.from- themsg.sender(orCALLER) to use during the execution of the codeoverrides.value- themsg.value(orCALLVALUE) to use during the execution of the codeoverrides.gasPrice- the price to pay per gas (theoretically); since there is no transaction, there is not going to be any fee charged, but the EVM still requires a value to report totx.gasprice(orGASPRICE); most developers will not require thisoverrides.gasLimit- the amount of gas (theoretically) to allow a node to use during the execution of the code; since there is no transaction, there is not going to be any fee charged, but the EVM still processes gas metering so calls likegasleft(orGAS) report meaningful valuesoverrides.blockTag- a block tag to simulate the execution at, which can be used for hypothetical historic analysis; note that many backends do not support this, or may require paid plans to access as the node database storage and processing requirements are much higher
The result will always be a Result, even if there is only a single return value type.
This simplifies frameworks which wish to use the Contract object, since they do not need to inspect the return types to unwrap simplified functions.
Another use for this method is for error recovery. For example, if a function result is an invalid UTF-8 string, the normal call using the above meta-class function will throw an exception. This allows using the Result access error to access the low-level bytes and reason for the error allowing an alternate UTF-8 error strategy to be used.
Most developers should not require this.
The overrides are identical to the read-only operations above.
A non-constant method requires a transaction to be signed and requires payment in the form of a fee to be paid to a miner. This transaction will be verified by every node on the entire network as well by the miner who will compute the new state of the blockchain after executing it against the current state.
It cannot return a result. If a result is required, it should be logged using a Solidity event (or EVM log), which can then be queried from the transaction receipt.
Returns a TransactionResponse for the transaction after it is sent to the network. This requires the Contract has a signer.
The overrides object for write methods may include any of:
overrides.gasPrice- the price to pay per gasoverrides.gasLimit- the limit on the amount of gas to allow the transaction to consume; any unused gas is returned at the gasPriceoverrides.value- the amount of ether (in wei) to forward with the calloverrides.nonce- the nonce to use for the Signer
If the wait() method on the returned TransactionResponse is called, there will be additional properties on the receipt:
receipt.events- an array of the logs, with additional properties (if the ABI included a description for the events)receipt.events[n].args- the parsed argumentsreceipt.events[n].decode- a method that can be used to parse the log topics and data (this was used to computeargs)receipt.events[n].event- the name of the eventreceipt.events[n].eventSignature- the full signature of the eventreceipt.removeListener()- a method to remove the listener that trigger this eventreceipt.getBlock()- a method to return the Block this event occurred inreceipt.getTransaction()- a method to return the Transaction this event occurred inreceipt.getTransactionReceipt()- a method to return the Transaction Receipt this event occurred in
There are several options to analyze properties and results of a write method without actually executing it.
Returns the estimate units of gas that would be required to execute the METHOD_NAME with args and overrides.
The overrides are identical to the overrides above for read-only or write methods, depending on the type of call of METHOD_NAME.
Returns an UnsignedTransaction which represents the transaction that would need to be signed and submitted to the network to execute METHOD_NAME with args and overrides.
The overrides are identical to the overrides above for read-only or write methods, depending on the type of call of METHOD_NAME.
Rather than executing the state-change of a transaction, it is possible to ask a node to pretend that a call is not state-changing and return the result.
This does not actually change any state, but is free. This in some cases can be used to determine if a transaction will fail or succeed.
This otherwise functions the same as a Read-Only Method.
The overrides are identical to the read-only operations above.
An event filter is made up of topics, which are values logged in a Bloom Filter, allowing efficient searching for entries which match a filter.
Return a filter for EVENT_NAME, optionally filtering by additional constraints.
Only indexed event parameters may be filtered. If a parameter is null (or not provided) then any value in that field matches.
ContractFactory
To deploy a Contract, additional information is needed that is not available on a Contract object itself.
Mainly, the bytecode (more specifically the initcode) of a contract is required.
The Contract Factory sends a special type of transaction, an initcode transaction (i.e. the to field is null, and the data field is the initcode) where the initcode will be evaluated and the result becomes the new code to be deployed as a new contract.
Creates a new instance of a ContractFactory for the contract described by the interface and bytecode initcode.
Consumes the output of the Solidity compiler, extracting the ABI and bytecode from it, allowing for the various formats the solc compiler has emitted over its life.
Returns a new instance of the ContractFactory with the same interface and bytecode, but with a different signer.
The bytecode (i.e. initcode) that this ContractFactory will use to deploy the Contract.
The Signer (if any) this ContractFactory will use to deploy instances of the Contract to the Blockchain.
Return an instance of a Contract attached to address. This is the same as using the Contract constructor with address and this the interface and signerOrProvider passed in when creating the ContractFactory.
Returns the unsigned transaction which would deploy this Contract with args passed to the Contract's constructor.
If the optional overrides is specified, they can be used to override the endowment value, transaction nonce, gasLimit or gasPrice.
Uses the signer to deploy the Contract with args passed into the constructor and returns a Contract which is attached to the address where this contract will be deployed once the transaction is mined.
The transaction can be found at contract.deployTransaction, and no interactions should be made until the transaction is mined.
If the optional overrides is specified, they can be used to override the endowment value, transaction nonce, gasLimit or gasPrice.
The concept of Meta-Classes is somewhat confusing, so we will go over a short example.
A meta-class is a class which is defined at run-time. A Contract is specified by an Application Binary Interface (ABI), which describes the methods and events it has. This description is passed to the Contract object at run-time, and it creates a new Class, adding all the methods defined in the ABI at run-time.
Most often, any contract you will need to interact with will already be deployed to the blockchain, but for this example will will first deploy the contract.
Create a new ContractFactory which can deploy a contract to the blockchain.
ERC20Contract inherits Contract
Creating a new instance of a Contract connects to an existing contract by specifying its address on the blockchain, its abi (used to populate the class' methods) a providerOrSigner.
If a Provider is given, the contract has only read-only access, while a Signer offers access to state manipulating methods.
Properties(inheritted from Contract)
This is the address (or ENS name) the contract was constructed with.
This is a promise that will resolve to the address the Contract object is attached to. If an Address was provided to the constructor, it will be equal to this; if an ENS name was provided, this will be the resolved address.
If the Contract object is the result of a ContractFactory deployment, this is the transaction which was used to deploy the contract.
If a provider was provided to the constructor, this is that provider. If a signer was provided that had a Provider, this is that provider.
If a signer was provided to the constructor, this is that signer.
Methods(inheritted from Contract)
Returns a new instance of the Contract attached to a new address. This is useful if there are multiple similar or identical copies of a Contract on the network and you wish to interact with each of them.
Events(inheritted from Contract)
See Meta-Class Filters for examples using events.
Return Events that match the event.
Return the number of listeners that are subscribed to event. If no event is provided, returns the total count of all events.
Return a list of listeners that are subscribed to event.
Unsubscribe listener to event.
Subscribe to event calling listener when the event occurs.
Subscribe once to event calling listener when the event occurs.
Unsubscribe all listeners for event. If no event is provided, all events are unsubscribed.
Since the Contract is a Meta-Class, the methods available here depend on the ABI which was passed into the Contract.
Returns the number of decimal places used by this ERC-20 token. This can be used with parseUnits when taking input from the user or [formatUnits](utils-formatunits] when displaying the token amounts in the UI.
Returns the balance of owner for this ERC-20 token.
Returns the symbol of the token.
Transfers amount tokens to target from the current signer. The return value (a boolean) is inaccessible during a write operation using a transaction. Other techniques (such as events) are required if this value is required. On-chain contracts calling the transfer function have access to this result, which is why it is possible.
Performs a dry-run of transferring amount tokens to target from the current signer, without actually signing or sending a transaction.
This can be used to preflight check that a transaction will be successful.
Returns an estimate for how many units of gas would be required to transfer amount tokens to target.
Returns an UnsignedTransaction which could be signed and submitted to the network to transaction amount tokens to target.
When you perform a static call, the current state is taken into account as best as Ethereum can determine. There are many cases where this can provide false positives and false negatives. The eventually consistent model of the blockchain also means there are certain consistency modes that cannot be known until an actual transaction is attempted.
Since the Contract is a Meta-Class, the methods available here depend on the ABI which was passed into the Contract.
Returns a new Filter which can be used to query or to subscribe/unsubscribe to events.
If fromAddress is null or not provided, then any from address matches. If toAddress is null or not provided, then any to address matches.
These utilities are used extensively within the library, but are also quite useful for application developers.
An Application Binary Interface (ABI) is a collection of Fragments which specify how to interact with various components of a Contract.
An Interface helps organize Fragments by type as well as provides the functionality required to encode, decode and work with each component.
Most developers will not require this low-level access to encoding and decoding the binary data on the network and will most likely use a Contract which provides a more convenient interface. Some framework, tool developers or developers using advanced techniques may find these classes and utilities useful.
AbiCoder
The AbiCoder is a collection of Coders which can be used to encode and decode the binary data formats used to interoperate between the EVM and higher level libraries.
Most developers will never need to use this class directly, since the Interface class greatly simplifies these operations.
For the most part, there should never be a need to manually create an instance of an AbiCoder, since one is created with the default coercion function when the library is loaded which can be used universally.
This is likely only needed by those with specific needs to override how values are coerced after they are decoded from their binary format.
Create a new AbiCoder instance, which will call the coerceFunc on every decode, where the result of the call will be used in the Result.
The function signature is `(type, value)`, where the type is the string describing the type and the value is the processed value from the underlying Coder.
If the callback throws, the Result will contain a property that when accessed will throw, allowing for higher level libraries to recover from data errors.
Encode the array values according to the array of types, each of which may be a string or a ParamType.
Decode the data according to the array of types, each of which may be a string or ParamType.
There are several formats available to specify an ABI for a Smart Contract, which specifies to the under-lying library what methods, events and errors exist so that encoding and decoding the data from and to the network can be handled by the library.
The supports ABI types are:
The Human-Readable ABI was introduced early by ethers, which allows for a Solidity signatures to be used to describe each method, event and error.
It is important to note that a Solidity signature fully describes all the properties the ABI requires:
- name
- type (constructor, event, function)
- inputs (types, nested structures and optionally names)
- outputs (types nested structures and optionally names)
- state mutability (for constructors and methods)
- payability (for constructors and methods)
- whether inputs are indexed (for events)
This allows for a simple format which is both machine-readable (since the parser is a machine) and human-readable (at least developer-readable), as well as simple for humans to type and inline into code, which improves code readability. The Human-Readable ABI is also considerably smaller, which helps reduce code size.
A Human-Readable ABI is simple an array of strings, where each string is the Solidity signature.
Signatures may be minimally specified (i.e. names of inputs and outputs may be omitted) or fully specified (i.e. with all property names) and whitespace is ignored.
Several modifiers available in Solidity are dropped internally, as they are not required for the ABI and used old by Solidity's semantic checking system, such as input parameter data location like "calldata" and "memory". As such, they can be safely dropped in the ABI as well.
The Solidity JSON ABI is a standard format that many tools export, including the Solidity compiler. For the full specification, see the Solidity compiler documentation.
Various versions include slightly different keys and values. For example, early compilers included only a boolean "constant" to indicate mutability, while newer versions include a string "mutabilityState", which encompasses several older properties.
When creating an instance of a Fragment using a JSON ABI, it will automatically infer all legacy properties for new-age ABIs and for legacy ABIs will infer the new-age properties. All properties will be populated, so it will match the equivalent created using a Human-Readable ABI fragment.
The output from parsing (using JSON.parse) a Solidity JSON ABI is also fully compatible with the Interface class and each method, event and error from that object are compatible with the Fragment class.
Some developers may prefer this as it allows access to the ABI properties as normal JavaScript objects, and closely matches the JSON ABI that those familiar with the Solidity ABI will recognize.
The Fragment object makes it simple to reformat a single method, event or error, however most developers will be interested in converting an entire ABI.
For production code it is recommended to inline the Human-Readable ABI as it makes it easy to see at a glance which methods, events and errors are available. It is also highly recommend to strip out unused parts of the ABI (such as admin methods) to further reduce code size.
Explain an ABI.
The JSON ABI Format is the format that is output from the Solidity compiler.
A JSON serialized object is always a string, which represents an Array of Objects, where each Object has various properties describing the Fragment of the ABI.
The deserialized JSON string (which is a normal JavaScript Object) may also be passed into any function which accepts a JSON String ABI.
The Human-Readable ABI was introduced by ethers in this article and has since gained wider adoption.
The ABI is described by using an array of strings, where each string is the Solidity signature of the constructor, function, event or error.
When parsing a fragment, all inferred properties will be injected (e.g. a payable method will have its constant proeprty set to false).
Tuples can be specified by using the tuple(...) syntax or with bare (additional) parenthesis, (...).
Output Formats
Each Fragment and ParamType may be output using its format method.
This is a full human-readable string, including all parameter names, any optional modifiers (e.g. indexed, public, etc) and white-space to aid in human readability.
This is similar to full, except with no unnecessary whitespace or parameter names. This is useful for storing a minimal string which can still fully reconstruct the original Fragment using Fragment . from.
This returns a JavaScript Object which is safe to call JSON.stringify on to create a JSON string.
This is a minimal output format, which is used by Solidity when computing a signature hash or an event topic hash.
The sighash format is insufficient to re-create the original Fragment, since it discards modifiers such as indexed, anonymous, stateMutability, etc.
It is only useful for computing the selector for a Fragment, and cannot be used to format an Interface.
Fragment
An ABI is a collection of Fragments, where each fragment specifies:
- An Error
- An Event
- A Function
- A Constructor
This is the name of the Event or Function. This will be null for a ConstructorFragment.
This is a string which indicates the type of the Fragment. This will be one of:
constructoreventfunction
This is an array of each ParamType for the input parameters to the Constructor, Event of Function.
Creates a string representation of the Fragment using the available output formats.
Creates a new Fragment sub-class from any compatible objectOrString.
Returns true if object is a Fragment.
This is the gas limit that should be used during deployment. It may be null.
This is whether the constructor may receive ether during deployment as an endowment (i.e. msg.value != 0).
This is the state mutability of the constructor. It can be any of:
nonpayablepayable
Creates a new ConstructorFragment from any compatible objectOrString.
Returns true if object is a ConstructorFragment.
Creates a new ErrorFragment from any compatible objectOrString.
Returns true if object is an ErrorFragment.
This is whether the event is anonymous. An anonymous Event does not inject its topic hash as topic0 when creating a log.
Creates a new EventFragment from any compatible objectOrString.
Returns true if object is an EventFragment.
FunctionFragment inherits ConstructorFragment
This is whether the function is constant (i.e. does not change state). This is true if the state mutability is pure or view.
This is the state mutability of the constructor. It can be any of:
nonpayablepayablepureview
A list of the Function output parameters.
Creates a new FunctionFragment from any compatible objectOrString.
Returns true if object is a FunctionFragment.
ParamType
The following examples will represent the Solidity parameter:
string foobar
The local parameter name. This may be null for unnamed parameters. For example, the parameter definition string foobar would be foobar.
The full type of the parameter, including tuple and array symbols. This may be null for unnamed parameters. For the above example, this would be foobar.
The base type of the parameter. For primitive types (e.g. address, uint256, etc) this is equal to type. For arrays, it will be the string array and for a tuple, it will be the string tuple.
Whether the parameter has been marked as indexed. This only applies to parameters which are part of an EventFragment.
The type of children of the array. This is null for any parameter which is not an array.
The length of the array, or -1 for dynamic-length arrays. This is null for parameters which are not arrays.
The components of a tuple. This is null for non-tuple parameters.
Creates a string representation of the Fragment using the available output formats.
Creates a new ParamType from any compatible objectOrString.
Returns true if object is a ParamType.
Interface
The Interface Class abstracts the encoding and decoding required to interact with contracts on the Ethereum network.
Many of the standards organically evolved along side the Solidity language, which other languages have adopted to remain compatible with existing deployed contracts.
The EVM itself does not understand what the ABI is. It is simply an agreed upon set of formats to encode various types of data which each contract can expect so they can interoperate with each other.
Create a new Interface from a JSON string or object representing abi.
The abi may be a JSON string or the parsed Object (using JSON.parse) which is emitted by the Solidity compiler (or compatible languages).
The abi may also be a Human-Readable Abi, which is a format the Ethers created to simplify manually typing the ABI into the source and so that a Contract ABI can also be referenced easily within the same source file.
All the Error Fragments in the interface.
All the Event Fragments in the interface.
All the Function Fragments in the interface.
The Constructor Fragments for the interface.
Return the formatted Interface. If the format type is json a single string is returned, otherwise an Array of the human-readable strings is returned.
Returns the FunctionFragment for fragment (see Specifying Fragments).
Returns the ErrorFragment for fragment (see Specifying Fragments).
Returns the EventFragment for fragment (see Specifying Fragments).
Return the sighash (or Function Selector) for fragment (see Specifying Fragments).
Return the topic hash for fragment (see Specifying Fragments).
Return the encoded deployment data, which can be concatenated to the deployment bytecode of a contract to pass values into the contract constructor.
Returns the encoded error result, which would normally be the response from a reverted call for fragment (see Specifying Fragments) for the given values.
Most developers will not need this method, but may be useful for authors of a mock blockchain.
Returns the encoded topic filter, which can be passed to getLogs for fragment (see Specifying Fragments) for the given values.
Each topic is a 32 byte (64 nibble) DataHexString.
Returns the encoded data, which can be used as the data for a transaction for fragment (see Specifying Fragments) for the given values.
Returns the encoded result, which would normally be the response from a call for fragment (see Specifying Fragments) for the given values.
Most developers will not need this method, but may be useful for authors of a mock blockchain.
Returns the decoded values from the result of a call during a revert for fragment (see Specifying Fragments) for the given data.
Most developers won't need this, as the decodeFunctionResult will automatically decode errors if the data represents a revert.
Returns the decoded event values from an event log for fragment (see Specifying Fragments) for the given data with the optional topics.
If topics is not specified, placeholders will be inserted into the result.
Most developers will find the parsing methods more convenient for decoding event data, as they will automatically detect the matching event.
Returns the decoded values from transaction data for fragment (see Specifying Fragments) for the given data.
Most developers will not need this method, but may be useful for debugging or inspecting transactions.
Most developers will also find the parsing methods more convenient for decoding transation data, as they will automatically detect the matching function.
Returns the decoded values from the result of a call for fragment (see Specifying Fragments) for the given data.
The functions are generally the most useful for most developers. They will automatically search the ABI for a matching Event or Function and decode the components as a fully specified description.
Search for the error that matches the error selector in data and parse out the details.
Search the event that matches the log topic hash and parse the values the log represents.
Search for the function that matches the transaction data sighash and parse the transaction properties.
A Result is an array, so each value can be accessed as a positional argument.
Additionally, if values are named, the identical object as its positional value can be accessed by its name.
The name length is however reserved as it is part of the Array, so any named value for this key is renamed to _length. If there is a name collision, only the first is available by its key.
The values of the input parameters of the error.
The ErrorFragment which matches the selector in the data.
The error name. (e.g. AccountLocked)
The error signature. (e.g. AccountLocked(address,uint256))
The selector of the error.
The values of the input parameters of the event.
The EventFragment which matches the topic in the Log.
The event name. (e.g. Transfer)
The event signature. (e.g. Transfer(address,address,uint256))
The topic hash.
The decoded values from the transaction data which were passed as the input parameters.
The FunctionFragment which matches the sighash in the transaction data.
The name of the function. (e.g. transfer)
The sighash (or function selector) that matched the transaction data.
The signature of the function. (e.g. transfer(address,uint256))
The value from the transaction.
When specifying a fragment to any of the functions in an Interface, any of the following may be used:
- The name of the event or function, if it is unique and non-ambiguous within the ABI (e.g.
transfer) - The signature of the event or function. The signature is normalized, so, for example,
uintanduint256are equivalent (e.g.transfer(address, uint)) - The sighash or topichash of the function. The sighash is often referred to the function selector in Solidity (e.g.
0xa9059cbb) - A Fragment
Explain addresses,formats and checksumming here.
Also see: constants.AddressZero
An Address is a DataHexString of 20 bytes (40 nibbles), with optional mixed case.
If the case is mixed, it is a Checksum Address, which uses a specific pattern of uppercase and lowercase letters within a given address to reduce the risk of errors introduced from typing an address or cut and paste issues.
All functions that return an Address will return a Checksum Address.
The ICAP Address Format was an early attempt to introduce a checksum into Ethereum addresses using the popular banking industry's IBAN format with the country code specified as XE.
Due to the way IBAN encodes address, only addresses that fit into 30 base-36 characters are actually compatible, so the format was adapted to support 31 base-36 characters which is large enough for a full Ethereum address, however the preferred method was to select a private key whose address has a 0 as the first byte, which allows the address to be formatted as a fully compatibly standard IBAN address with 30 base-36 characters.
In general this format is no longer widely supported anymore, however any function that accepts an address can receive an ICAP address, and it will be converted internally.
To convert an address into the ICAP format, see getIcapAddress.
Returns address as a Checksum Address.
If address is an invalid 40-nibble HexString or if it contains mixed case and the checksum is invalid, an INVALID_ARGUMENT Error is thrown.
The value of address may be any supported address format.
Returns address as an ICAP address. Supports the same restrictions as getAddress.
Returns true if address is valid (in any supported format).
Returns the address for publicOrPrivateKey. A public key may be compressed or uncompressed, and a private key will be converted automatically to a public key for the derivation.
Use ECDSA Public Key Recovery to determine the address that signed digest to which generated signature.
Returns the contract address that would result if transaction was used to deploy a contract.
Returns the contract address that would result from the given CREATE2 call.
Many operations in Ethereum operate on numbers which are outside the range of safe values to use in JavaScript.
A BigNumber is an object which safely allows mathematical operations on numbers of any magnitude.
Most operations which need to return a value will return a BigNumber and parameters which accept values will generally accept them.
Many functions and methods in this library take in values which can be non-ambiguously and safely converted to a BigNumber. These values can be specified as:
A HexString or a decimal string, either of which may be negative.
A BytesLike Object, such as an Array or Uint8Array.
An existing BigNumber instance.
A number that is within the safe range for JavaScript numbers.
A JavaScript BigInt object, on environments that support BigInt.
The constructor of BigNumber cannot be called directly. Instead, Use the static BigNumber.from.
Returns an instance of a BigNumber for aBigNumberish.
Examples:
The BigNumber class is immutable, so no operations can change the value it represents.
Returns a BigNumber with the value of BigNumber + otherValue.
Returns a BigNumber with the value of BigNumber - otherValue.
Returns a BigNumber with the value of BigNumber × otherValue.
Returns a BigNumber with the value of BigNumber ÷ divisor.
Returns a BigNumber with the value of the remainder of BigNumber ÷ divisor.
Returns a BigNumber with the value of BigNumber to the power of exponent.
Returns a BigNumber with the value of BigNumber with bits beyond the bitcount least significant bits set to zero.
Two's Complement is an elegant method used to encode and decode fixed-width signed values while efficiently preserving mathematical operations. Most users will not need to interact with these.
Returns a BigNumber with the value of BigNumber converted from twos-complement with bitwidth.
Returns a BigNumber with the value of BigNumber converted to twos-complement with bitwidth.
Returns true if and only if the value of BigNumber is equal to otherValue.
Returns true if and only if the value of BigNumber < otherValue.
Returns true if and only if the value of BigNumber ≤ otherValue.
Returns true if and only if the value of BigNumber > otherValue.
Returns true if and only if the value of BigNumber ≥ otherValue.
Returns true if and only if the value of BigNumber is zero.
Returns the value of BigNumber as a JavaScript BigInt value, on platforms which support them.
Returns the value of BigNumber as a JavaScript value.
This will throw an error if the value is greater than or equal to Number.MAX_SAFE_INTEGER or less than or equal to Number.MIN_SAFE_INTEGER.
Returns the value of BigNumber as a base-10 string.
Returns the value of BigNumber as a base-16, 0x-prefixed DataHexString.
Returns true if and only if the object is a BigNumber object.
This section is a for a couple of questions that come up frequently.
The first problem many encounter when dealing with Ethereum is the concept of numbers. Most common currencies are broken down with very little granularity. For example, there are only 100 cents in a single dollar. However, there are 1018 wei in a single ether.
JavaScript uses IEEE 754 double-precision binary floating point numbers to represent numeric values. As a result, there are holes in the integer set after 9,007,199,254,740,991; which is problematic for Ethereum because that is only around 0.009 ether (in wei), which means any value over that will begin to experience rounding errors.
To demonstrate how this may be an issue in your code, consider:
To remedy this, all numbers (which can be large) are stored and manipulated as Big Numbers.
The functions parseEther( etherString ) and formatEther( wei ) can be used to convert between string representations, which are displayed to or entered by the user and Big Number representations which can have mathematical operations handled safely.
Everyone has their own favourite Big Number library, and once someone has chosen one, it becomes part of their identity, like their editor, vi vs emacs. There are over 100 Big Number libraries on npm.
One of the biggest differences between the Ethers BigNumber object and other libraries is that it is immutable, which is very important when dealing with the asynchronous nature of the blockchain.
Capturing the value is not safe in async functions, so immutability protects us from easy to make mistakes, which is not possible on the low-level library's objects which supports myriad in-place operations.
Second, the Ethers BigNumber provides all the functionality required internally and should generally be sufficient for most developers while not exposing some of the more advanced and rare functionality. So it will be easier to swap out the underlying library without impacting consumers.
For example, if BN.js was exposed, someone may use the greatest-common-denominator functions, which would then be functionality the replacing library should also provide to ensure anyone depending on that functionality is not broken.
The reason why BN.js is used internally as the big number is because that is the library used by elliptic.
Therefore it must be included regardless, so we leverage that library rather than adding another Big Number library, which would mean two different libraries offering the same functionality.
This has saved about 85kb (80% of this library size) of library size over other libraries which include separate Big Number libraries for various purposes.
Another comment that comes up frequently is the desire to specify a global user-defined Big Number library, which all functions would return.
This becomes problematic since your code may live along side other libraries or code that use Ethers. In fact, even Ethers uses a lot of the public functions internally.
If you, for example, used a library that used a.plus(b) instead of a.add(b), this would break Ethers when it tries to compute fees internally, and other libraries likely have similar logic.
But, the BigNumber prototype is exposed, so you can always add a toMyCustomBigNumber() method to all BigNumber's globally which is safe.
While there are many high-level APIs for interacting with Ethereum, such as Contracts and Providers, a lot of the low level access requires byte manipulation operations.
Many of these operations are used internally, but can also be used to help normalize binary data representations from the output of various functions and methods.
A Bytes is any object which is an Array or TypedArray with each value in the valid byte range (i.e. between 0 and 255 inclusive), or is an Object with a length property where each indexed property is in the valid byte range.
A BytesLike can be either a Bytes or a DataHexString.
A DataHexstring is identical to a HexString except that it has an even number of nibbles, and therefore is a valid representation of binary data as a string.
A Hexstring is a string which has a 0x prefix followed by any number of nibbles (i.e. case-insensitive hexadecimal characters, 0-9 and a-f).
- r and s --- The x co-ordinate of r and the s value of the signature
- v --- The parity of the y co-ordinate of r
- yParityAndS --- The compact representation of the s and v
- _vs --- Deprecated property; renamed to yParityAndS
- recoveryParam --- The normalized (i.e. 0 or 1) value of v
- compact - The full siggnature using compact representation
Raw Signature inherits string<DataHexString<65>>
A Raw Signature is a common Signature format where the r, s and v are concatenated into a 65 byte (130 nibble) DataHexString.
A SignatureLike is similar to a Signature, except redundant properties may be omitted or it may be a Raw Signature.
For example, if _vs is specified, s and v may be omitted. Likewise, if recoveryParam is provided, v may be omitted (as in these cases the missing values can be computed).
Returns true if and only if object is a Bytes or DataHexString.
Returns true if and only if object is a valid hex string. If length is specified and object is not a valid DataHexString of length bytes, an InvalidArgument error is thrown.
Converts DataHexStringOrArrayish to a Uint8Array.
Converts hexstringOrArrayish to a DataHexString.
Converts aBigNumberish to a HexString, with no unnecessary leading zeros.
Concatenates all the BytesLike in arrayOfBytesLike into a single Uint8Array.
Returns a Uint8Array with all leading 0 bytes of aBtyesLike removed.
Returns a Uint8Array of the data in aBytesLike with 0 bytes prepended to length bytes long.
If aBytesLike is already longer than length bytes long, an InvalidArgument error will be thrown.
Concatenates all the BytesLike in arrayOfBytesLike into a single DataHexString
Returns the length (in bytes) of aBytesLike.
Returns a DataHexString representation of a slice of aBytesLike, from offset (in bytes) to endOffset (in bytes). If endOffset is omitted, the length of aBytesLike is used.
Returns a HexString representation of aBytesLike with all leading zeros removed.
Returns a DataHexString representation of aBytesLike padded to length bytes.
If aBytesLike is already longer than length bytes long, an InvalidArgument error will be thrown.
Return the raw-format of aSignaturelike, which is 65 bytes (130 nibbles) long, concatenating the r, s and (normalized) v of a Signature.
Return the full expanded-format of aSignaturelike or a raw-format DataHexString. Any missing properties will be computed.
Return a new Uint8Array of length random bytes.
Return a copy of array shuffled using Fisher-Yates Shuffle.
The ethers.constants Object contains commonly used values.
The Address Zero, which is 20 bytes (40 nibbles) of zero.
The Hash Zero, which is 32 bytes (64 nibbles) of zero.
The Ether symbol, Ξ.
The BigNumber value representing "1000000000000000000", which is the number of Wei per Ether.
The BigNumber value representing the maximum uint256 value.
When creating an Application, it is useful to convert between user-friendly strings (usually displaying ether) and the machine-readable values that contracts and maths depend on (usually in wei).
For example, a Wallet may specify the balance in ether, and gas prices in gwei for the User Interface, but when sending a transaction, both must be specified in wei.
The parseUnits will parse a string representing ether, such as 1.1 into a BigNumber in wei, and is useful when a user types in a value, such as sending 1.1 ether.
The formatUnits will format a BigNumberish into a string, which is useful when displaying a balance.
A Unit can be specified as a number, which indicates the number of decimal places that should be used.
Examples:
- 1 ether in wei, has 18 decimal places (i.e. 1 ether represents 1018 wei)
- 1 bitcoin in Satoshi, has 8 decimal places (i.e. 1 bitcoin represents 108 satoshi)
There are also several common Named Units, in which case their name (as a string) may be used.
| Name | Decimals | |
| wei | 0 | |
| kwei | 3 | |
| mwei | 6 | |
| gwei | 9 | |
| szabo | 12 | |
| finney | 15 | |
| ether | 18 |
Returns a string with value grouped by 3 digits, separated by ,.
Returns a string representation of value formatted with unit digits (if it is a number) or to the unit specified (if a string).
The equivalent to calling formatUnits(value, "ether").
Returns a BigNumber representation of value, parsed with unit digits (if it is a number) or from the unit specified (if a string).
The equivalent to calling parseUnits(value, "ether").
Base58
Return a typed Uint8Array representation of textData decoded using base-58 encoding.
Return aBytesLike encoded as a string using the base-58 encoding.
Return a typed Uint8Array representation of textData decoded using base-64 encoding.
Return aBytesLike encoded as a string using the base-64 encoding.
The Recursive Length Prefix encoding is used throughout Ethereum to serialize nested structures of Arrays and data.
Encode a structured Data Object into its RLP-encoded representation.
Decode an RLP-encoded aBytesLike into its structured Data Object.
All Data components will be returned as a DataHexString.
A Data Object is a recursive structure which is used to serialize many internal structures in Ethereum. Each Data Object can either be:
- Binary Data
- An Array of Data Objects (i.e. this recursively includes Nesting)
"0x1234"[ "0x1234", [ "0xdead", "0xbeef" ], [ ] ]
A FixedNumber is a fixed-width (in bits) number with an internal base-10 divisor, which allows it to represent a decimal fractional component.
The FixedNumber constructor cannot be called directly. There are several static methods for creating a FixedNumber.
Returns an instance of a FixedNumber for value as a format.
Returns an instance of a FixedNumber for value as a format.
Returns an instance of a FixedNumber for value as a format. The value must not contain more decimals than the format permits.
Returns an instance of a FixedNumber for value with decimals as a format.
The FixedFormat of fixednumber.
Returns a new FixedNumber with the value of fixedvalue + otherValue.
Returns a new FixedNumber with the value of fixedvalue - otherValue.
Returns a new FixedNumber with the value of fixedvalue × otherValue.
Returns a new FixedNumber with the value of fixedvalue ÷ otherValue.
Returns a new FixedNumber with the value of fixedvalue rounded to decimals.
Returns true if and only if the value of FixedNumber is zero.
Returns a new FixedNumber with the value of fixedvalue with format.
Returns a string representation of fixednumber.
Returns a floating-point JavaScript number value of fixednumber. Due to rounding in JavaScript numbers, the value is only approximate.
Returns true if and only if value is a FixedNumber.
A FixedFormat is a simple object which represents a decimal (base-10) Fixed-Point data representation. Usually using this class directly is unnecessary, as passing in a Format Strings directly into the FixedNumber will automatically create this.
A format string is composed of three components, including signed-ness, bit-width and number of decimals.
A signed format string begins with fixed, which an unsigned format string begins with ufixed, followed by the width (in bits) and the number of decimals.
The width must be congruent to 0 mod 8 (i.e. (width % 8) == 0) and no larger than 256 bits and the number of decimals must be no larger than 80.
For example:
- fixed128x18 is signed, 128 bits wide and has 18 decimals; this is useful for most purposes
- fixed32x0 is signed, 32 bits wide and has 0 decimals; this would be the same as a
int32_tin C - ufixed32x0 is unsigned, 32 bits wide and has 0 decimals; this would be the same as a
uint32_tin C - fixed is shorthand for
fixed128x18 - ufixed is shorthand for
ufixed128x18
Returns a new instance of a FixedFormat defined by value. Any valid Format Strings may be passed in as well as any object which has any of signed, width and decimals defined, including a FixedFormat object.
The signed-ness of fixedFormat, true if negative values are supported.
The width (in bits) of fixedFormat.
The number of decimal points of fixedFormat.
The name of the fixedFormat, which can be used to recreate the format and is the string that the Solidity language uses to represent this format.
A shorthand for fixed128x18.
There are many hashing algorithms used throughout the blockchain space as well as some more complex usages which require utilities to facilitate these common operations.
The Cryptographic Hash Functions are a specific family of hash functions.
The Ethereum Identity function computes the KECCAK256 hash of the text bytes.
Returns the KECCAK256 digest aBytesLike.
Returns the RIPEMD-160 digest of aBytesLike.
Returns the SHA2-256 digest of aBytesLike.
Returns the SHA2-512 digest of aBytesLike.
HMAC Supported Algorithms
Use the SHA2-256 hash algorithm.
Use the SHA2-512 hash algorithm.
Computes the EIP-191 personal message digest of message. Personal messages are converted to UTF-8 bytes and prefixed with \x19Ethereum Signed Message: and the length of message.
Returns the ENS Namehash of name.
Typed Data Encoder
The TypedDataEncoder is used to compute the various encoded data required for EIP-712 signed data.
Signed data requires a domain, list of structures and their members and the data itself.
The domain is an object with values for any of the standard domain properties.
The types is an object with each property being the name of a structure, mapping to an array of field descriptions. It should not include the EIP712Domain property unless it is required as a child structure of another.
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 exported class name will be renamed from _TypedDataEncoder to TypedDataEncoder once it has been used in the field a bit.
Creates a new TypedDataEncoder for types. This object is a fairly low-level object that most developers should not require using instances directly.
Most developers will find the static class methods below the most useful.
Encodes the Returns the hashed EIP-712 domain.
Returns the standard payload used by various JSON-RPC eth_signTypedData* calls.
All domain values and entries in value are normalized and the types are verified.
Constructs a directed acyclic graph of the types and returns the root type, which can be used as the primaryType for EIP-712 payloads.
Returns the computed EIP-712 hash.
Returns the hashed EIP-712 domain.
Returns a copy of value, where any leaf value with a type of address will have been recursively replacedwith the value of calling resolveName with that value.
When using the Solidity abi.encodePacked(...) function, a non-standard tightly packed version of encoding is used. These functions implement the tightly packing algorithm.
Returns the non-standard encoded values packed according to their respective type in types.
Returns the KECCAK256 of the non-standard encoded values packed according to their respective type in types.
Returns the SHA2-256 of the non-standard encoded values packed according to their respective type in types.
The Hierarchal Deterministic (HD) Wallet was a standard created for Bitcoin, but lends itself well to a wide variety of Blockchains which rely on secp256k1 private keys.
For a more detailed technical understanding:
- BIP-32 - the hierarchal deterministic description
- BIP-39 - the method used to derive the BIP-32 seed from human-readable sequences of words (i.e. a mnemonic)
- BIP-44 - a standard defined to make BIP-32 easy to adapt to any future compatible blockchain
Constants
The default path for Ethereum in an HD Wallet
The mnemonic phrase for this mnemonic. It is 12, 15, 18, 21 or 24 words long and separated by the whitespace specified by the locale.
The HD path for this mnemonic.
The language of the wordlist this mnemonic is using.
HDNode
Return the HDNode for phrase with the optional password and wordlist.
Return the HDNode for the extendedKey. If extendedKey was neutered, the HDNode will only be able to compute addresses and not private keys.
The private key for this HDNode.
The (compresses) public key for this HDNode.
The fingerprint is meant as an index to quickly match parent and children nodes together, however collisions may occur and software should verify matching nodes.
Most developers will not need to use this.
The fingerprint of the parent node. See fingerprint for more details.
Most developers will not need to use this.
The address of this HDNode.
The mnemonic of this HDNode, if known.
The path of this HDNode, if known. If the mnemonic is also known, this will match mnemonic.path.
The chain code is used as a non-secret private key which is then used with EC-multiply to provide the ability to derive addresses without the private key of child non-hardened nodes.
Most developers will not need to use this.
The index of this HDNode. This will match the last component of the path.
Most developers will not need to use this.
The depth of this HDNode. This will match the number of components (less one, the m/) of the path.
Most developers will not need to use this.
A serialized string representation of this HDNode. Not all properties are included in the serialization, such as the mnemonic and path, so serializing and deserializing (using the fromExtendedKey class method) will result in reduced information.
Return a new instance of hdNode with its private key removed but all other properties preserved. This ensures that the key can not leak the private key of itself or any derived children, but may still be used to compute the addresses of itself and any non-hardened children.
Return a new HDNode which is the child of hdNode found by deriving path.
Convert a mnemonic phrase to a seed, according to BIP-39.
Convert a mnemonic phrase to its entropy, according to BIP-39.
Returns true if phrase is a valid mnemonic phrase, by testing the checksum.
These are just a few simple logging utilities provided to simplify and standardize the error facilities across the Ethers library.
The Logger library has zero dependencies and is intentionally very light so it can be easily included in each library.
The Censorship functionality relies on one instance of the Ethers library being included. In large bundled packages or when npm link is used, this may not be the case. If you require this functionality, ensure that your bundling is configured properly.
Logger
Create a new logger which will include version in all errors thrown.
Log debugging information.
Log generic information.
Log warnings.
These functions honor the current Censorship and help create a standard error model for detecting and processing errors within Ethers.
Create an Error object with message and an optional code and additional params set. This is useful when an error is needed to be rejected instead of thrown.
Throw an Error with message and an optional code and additional params set.
Throw an INVALID_ARGUMENT Error with name and value.
There can be used to ensure various properties and actions are safe.
If target is kind, throws a UNSUPPORTED_OPERATION error otherwise performs the same operations as checkNew.
This is useful for ensuring abstract classes are not being instantiated.
If count is not equal to expectedCount, throws a MISSING_ARGUMENT or UNEXPECTED_ARGUMENT error.
If target is not a valid this or target value, throw a MISSING_NEW error. This is useful to ensure callers of a Class are using new.
Check that the environment has a correctly functioning String.normalize. If not, a UNSUPPORTED_OPERATION error is thrown.
If value is not safe as a JavaScript number, throws a NUMERIC_FAULT error.
Set error censorship, optionally preventing errors from being uncensored.
In production applications, this prevents any error from leaking information by masking the message and values of errors.
This can impact debugging, making it substantially more difficult.
Set the log level, to suppress logging output below a particular log level.
Every error in Ethers has a code value, which is a string that will match one of the following error codes.
The operation is not implemented. This may occur when calling a method on a sub-class that has not fully implemented its abstract superclass.
There was an error communicating with a server.
This may occur for a number of reasons, for example:
- a CORS issue; this is quite often the problem and also the hardest to diagnose and fix, so it is very beneficial to familiarize yourself with CORS; some backends allow you configure your CORS, such as the geth command-line or conifguration files or the INFURA and Alchemy dashboards by specifing allowed Origins, methods, etc.
- an SSL issue; for example, if you are trying to connect to a local node via HTTP but are serving the content from a secure HTTPS website
- a link issue; a firewall is preventing the traffic from reaching the server
- a server issue; the server is down, or is returning 500 error codes
- a backend DDoS mitigation proxy; for example, Etherscan operates behind a Cloudflare proxy, which will block traffic if the request is sent via specific User Agents or the client fingerprint is detected as a bot in some cases
The operation is not supported.
This can happen for a variety reasons, for example:
- Some backends do not support certain operations; such as passing a blockTag to an EtherscanProvider for call
- A Contract object connected to Provider (instead of a Signer) cannot sign or send transactions
- a Contract connected to a Signer without a Provider is write-only and cannot estimate gas or execute static calls
The amount of data needed is more than the amount of data required, which would cause the data buffer to read past its end.
This can occur if a contract erroneously returns invalid ABI-encoded data or RLP data is malformed.
There was an invalid operation done on numeric values.
Common cases of this occur when there is overflow, arithmetic underflow in fixed numeric types or division by zero.
The type or value of an argument is invalid. This will generally also include the name and value of the argument. Any function which accepts sensitive data (such as a private key) will include the string "[[REDACTED]]" instead of the value passed in.
An attempt to call a blockchain contract (getter) resulted in a revert or other error, such as insufficient gas (out-of-gas) or an invalid opcode. This can also occur during gas estimation or if waiting for a TransactionReceipt which failed during execution.
Consult the contract to determine the cause, such as a failed condition in a require statement. The reason property may provide more context for the cause of this error.
The account is attempting to make a transaction which costs more than is available.
A sending account must have enough ether to pay for the value, the gas limit (at the gas price) as well as the intrinsic cost of data. The intrinsic cost of data is 4 gas for each zero byte and 68 gas for each non-zero byte, as well as 35000 gas if a transaction contains no to property and is therefore expected to create a new account.
When replacing a transaction, by using a nonce which has already been sent to the network, but which has not been mined yet the new transaction must specify a higher gas price.
This error occurs when the gas price is insufficient to bribe the transaction pool to prefer the new transaction over the old one. Generally, the new gas price should be about 50% + 1 wei more, so if a gas price of 10 gwei was used, the replacement should be 15.000000001 gwei. This is not enforced by the protocol, as it deals with unmined transactions, and can be configured by each node, however to ensure a transaction is propagated to a miner it is best practice to follow the defaults most nodes have enabled.
When a transaction has been replaced by the user, by broadcasting a new transaction with the same nonce as an existing in-flight (unmined) transaction in the mempool, this error will occur while waiting if the transaction being waited for has become invalidated by that other transaction.
This can happen for several reasons, but most commonly because the user has increased the gas price (which changes the transaction hash) to "speed up" a transaction or if a user has "cancelled" the transaction in their client. In either case this is usually accomplished by bribing the miners with a higher gas priced transaction.
This error will have the additional properties, cancelled, hash, reason, receipt and replacement.
See the TransactionResponse for the wait method for more details.
When estimating the required amount of gas for a transaction, a node is queried for its best guess.
If a node is unable (or unwilling) to predict the cost, this error occurs.
The best remedy for this situation is to specify a gas limit in the transaction manually.
This error can also indicate that the transaction is expected to fail regardless, if for example an account with no tokens is attempting to send a token.
Log all output, including debugging information.
Only log output for informational, warnings and errors.
Only log output for warnings and errors.
Only log output for errors.
Do not output any logs.
This is a collection of utility functions used for handling properties in a platform-safe way.
The next major version of ethers will no longer be compatible with ES3, so many of these will be removed in favor of the built-in options available in ES2015 and above.
Checks that object only contains properties included in check, and throws INVALID_ARGUMENT if not.
Creates a recursive copy of anObject. Frozen (i.e. and other known immutable) objects are copied by reference.
Uses the Object.defineProperty method to set a read-only property on an object.
Recursively check for a static method key on an inheritance chain from aConstructor to all ancestors.
This is used to mimic behaviour in other languages where this in a static method will also search ancestors.
Retruns a Promise which resolves all child values on anObject.
Returns a shallow copy of anObject. This is the same as using Object.assign({ }, anObject).
Create a new SigningKey for privateKey.
The private key for this Signing Key.
The uncompressed public key for this Signing Key. It will always be 65 bytes (130 nibbles) and begins with 0x04.
The compressed public key for this Signing Key. It will always be 33 bytes (66 nibbles) and begins with either 0x02 or 0x03.
Sign the digest and return the signature.
Compute the ECDH shared secret with otherKey. The otherKey may be either a public key or a private key, but generally will be a public key from another party.
It is best practice that each party computes the hash of this before using it as a symmetric key.
Returns true if anObject is a SigningKey.
Returns the address that signed message producing signature. The signature may have a non-canonical v (i.e. does not need to be 27 or 28), in which case it will be normalized to compute the `recoveryParam` which will then be used to compute the address; this allows systems which use the v to encode additional data (such as EIP-155) to be used since the v parameter is still completely non-ambiguous.
Returns the address that signed the EIP-712 value for the domain and types to produce the signature.
Returns the uncompressed public key (i.e. the first byte will be 0x04) of the private key that was used to sign digest which gave the signature.
Computes the public key of key, optionally compressing it. The key can be any form of public key (compressed or uncompressed) or a private key.
A String is a representation of a human-readable input of output, which are often taken for granted.
When dealing with blockchains, properly handling human-readable and human-provided data is important to prevent loss of funds, assets, incorrect permissions, etc.
A string in Solidity is length prefixed with its 256-bit (32 byte) length, which means that even short strings require 2 words (64 bytes) of storage.
In many cases, we deal with short strings, so instead of prefixing the string with its length, we can null-terminate it and fit it in a single word (32 bytes). Since we need only a single byte for the null termination, we can store strings up to 31 bytes long in a word.
Strings that are 31 bytes long may contain fewer than 31 characters, since UTF-8 requires multiple bytes to encode international characters.
Returns the decoded string represented by the Bytes32 encoded data.
Returns a bytes32 string representation of text. If the length of text exceeds 31 bytes, it will throw an error.
Returns the UTF-8 bytes of text, optionally normalizing it using the UnicodeNormalizationForm form.
Returns the Array of codepoints of text, optionally normalized using the UnicodeNormalizationForm form.
This function correctly splits each user-perceived character into its codepoint, accounting for surrogate pairs. This should not be confused with string.split(""), which destroys surrogate pairs, splitting between each UTF-16 codeunit instead.
Returns the string represented by the UTF-8 bytes of aBytesLike.
The onError is a Custom UTF-8 Error function and if not specified it defaults to the error function, which throws an error on any UTF-8 error.
UnicodeNormalizationForm
There are several commonly used forms when normalizing UTF-8 data, which allow strings to be compared or hashed in a stable way.
Maintain the current normalization form.
The Composed Normalization Form. This form uses single codepoints which represent the fully composed character.
For example, the é is a single codepoint, 0x00e9.
The Decomposed Normalization Form. This form uses multiple codepoints (when necessary) to compose a character.
For example, the é is made up of two codepoints, "0x0065" (which is the letter "e") and "0x0301" which is a special diacritic UTF-8 codepoint which indicates the previous character should have an acute accent.
The Composed Normalization Form with Canonical Equivalence. The Canonical representation folds characters which have the same syntactic representation but different semantic meaning.
For example, the Roman Numeral I, which has a UTF-8 codepoint "0x2160", is folded into the capital letter I, "0x0049".
The Decomposed Normalization Form with Canonical Equivalence. See NFKC for more an example.
Only certain specified characters are folded in Canonical Equivalence, and thus it should not be considered a method to achieve any level of security from homoglyph attacks.
When converting a string to its codepoints, there is the possibility of invalid byte sequences. Since certain situations may need specific ways to handle UTF-8 errors, a custom error handling function can be used, which has the signature:
The reason is one of the UTF-8 Error Reasons, offset is the index into bytes where the error was first encountered, output is the list of codepoints already processed (and may be modified) and in certain Error Reasons, the badCodepoint indicates the currently computed codepoint, but which would be rejected because its value is invalid.
This function should return the number of bytes to skip past keeping in mind the value at offset will already be consumed.
UTF-8 Error Reasons
A byte was encountered which is invalid to begin a UTF-8 byte sequence with.
A UTF-8 sequence was begun, but did not have enough continuation bytes for the sequence. For this error the ofset is the index at which a continuation byte was expected.
The computed codepoint is outside the range for valid UTF-8 codepoints (i.e. the codepoint is greater than 0x10ffff). This reason will pass the computed badCountpoint into the custom error function.
Due to the way UTF-8 allows variable length byte sequences to be used, it is possible to have multiple representations of the same character, which means overlong sequences allow for a non-distinguished string to be formed, which can impact security as multiple strings that are otherwise equal can have different hashes.
Generally, overlong sequences are an attempt to circumvent some part of security, but in rare cases may be produced by lazy libraries or used to encode the null terminating character in a way that is safe to include in a char*.
This reason will pass the computed badCountpoint into the custom error function, which is actually a valid codepoint, just one that was arrived at through unsafe methods.
The string does not have enough characters remaining for the length of this sequence.
This error is similar to BAD_PREFIX, since a continuation byte cannot begin a valid sequence, but many may wish to process this differently. However, most developers would want to trap this and perform the same operation as a BAD_PREFIX.
The computed codepoint represents a value reserved for UTF-16 surrogate pairs. This reason will pass the computed surrogate half badCountpoint into the custom error function.
There are already several functions available for the most common situations.
The will throw an error on any error with a UTF-8 sequence, including invalid prefix bytes, overlong sequences, UTF-16 surrogate pairs.
This will drop all invalid sequences (by consuming invalid prefix bytes and any following continuation bytes) from the final string as well as permit overlong sequences to be converted to their equivalent string.
This will replace all invalid sequences (by consuming invalid prefix bytes and any following continuation bytes) with the UTF-8 Replacement Character, (i.e. U+FFFD).
An unsigned transaction represents a transaction that has not been signed and its values are flexible as long as they are not ambiguous.
The address this transaction is to.
The nonce of this transaction.
The gas limit for this transaction.
The gas price for this transaction.
The maximum fee per unit of gas for this transaction.
The maximum priority fee per unit of gas for this transaction.
The data for this transaction.
The value (in wei) for this transaction.
The chain ID for this transaction. If the chain ID is 0 or null, then EIP-155 is disabled and legacy signing is used, unless overridden in a signature.
A generic object to represent a transaction.
The transaction hash, which can be used as an identifier for transaction. This is the keccak256 of the serialized RLP encoded representation of transaction.
The address transaction is to.
The address transaction is from.
The nonce for transaction. Each transaction sent to the network from an account includes this, which ensures the order and non-replayability of a transaction. This must be equal to the current number of transactions ever sent to the network by the from address.
The gas limit for transaction. An account must have enough ether to cover the gas (at the specified gasPrice). Any unused gas is refunded at the end of the transaction, and if there is insufficient gas to complete execution, the effects of the transaction are reverted, but the gas is fully consumed and an out-of-gas error occurs.
The price (in wei) per unit of gas for transaction.
For EIP-1559 transactions, this will be null.
The maximum price (in wei) per unit of gas for transaction.
For transactions that are not EIP-1559 transactions, this will be null.
The priority fee price (in wei) per unit of gas for transaction.
For transactions that are not EIP-1559 transactions, this will be null.
The data for transaction. In a contract this is the call data.
The value (in wei) for transaction.
The chain ID for transaction. This is used as part of EIP-155 to prevent replay attacks on different networks.
For example, if a transaction was made on goerli with an account also used on homestead, it would be possible for a transaction signed on goerli to be executed on homestead, which is likely unintended.
There are situations where replay may be desired, however these are very rare and it is almost always recommended to specify the chain ID.
The r portion of the elliptic curve signatures for transaction. This is more accurately, the x coordinate of the point r (from which the y can be computed, along with v).
The s portion of the elliptic curve signatures for transaction.
The v portion of the elliptic curve signatures for transaction. This is used to refine which of the two possible points a given x-coordinate can have, and in EIP-155 is additionally used to encode the chain ID into the serialized transaction.
Normalizes the AccessListish anAccessListish into an AccessList.
This is useful for other utility functions which wish to remain flexible as to the input parameter for access lists, such as when creating a Signer which needs to manipulate a possibly typed transaction envelope.
Parses the transaction properties from a serialized transaction.
Computes the serialized transaction, optionally serialized with the a signature. If signature is not present, the unsigned serialized transaction is returned, which can be used to compute the hash necessary to sign.
This function uses EIP-155 if a chainId is provided, otherwise legacy serialization is used. It is highly recommended to always specify a chainId.
If signature includes a chain ID (explicitly or implicitly by using an EIP-155 v or _vs) it will be used to compute the chain ID.
If there is a mismatch between the chain ID of transaction and signature an error is thrown.
Fetch and parse the JSON content from urlOrConnectionInfo, with the optional body json and optionally processing the result with processFun before returning it.
Repeatedly call pollFunc using the PollOptions until it returns a value other than undefined.
The URL to connect to.
The username to use for Basic Authentication. The default is null (i.e. do not use basic authentication)
The password to use for Basic Authentication. The default is null (i.e. do not use basic authentication)
Allow Basic Authentication over non-secure HTTP. The default is false.
How long to wait (in ms) before rejecting with a timeout error. (default: 120000).
Additional headers to include in the connection.
Normally a connection will specify the default values for a connection such as CORS-behavior and caching policy, to ensure compatibility across platforms. On some services, such as Cloudflare Workers, specifying any value (inclluding the default values) will cause failure. Setting this to true will prevent any values being passed to the underlying API.
If false, any server error is thrown as a SERVER_ERROR, otherwise a the processFunc is called with response including the error status intact. (default: false)
Allow Gzip responses. (default: false)
How many times to retry in the event of a 429 status code.
The exponential back-off slot delay (i.e. omega), creating a staggered, increasing random delay on retries.
Callback that allows application level hints to retry (within the throttleLimit) or quick fail.
The amount of time (in ms) allowed to elapse before triggering a timeout error.
The minimum time limit to allow for Exponential Backoff.
The default is 0s.
The maximum time limit to allow for Exponential Backoff.
The default is 10s.
The interval used during Exponential Backoff calculation.
The default is 250ms.
The number of times to retry in the event of an error or undefined is returned.
If this is specified, the polling will wait on new blocks from provider before attempting the pollFunc again.
If this is specified, the polling will occur on each poll cycle of provider before attempting the pollFunc again.
The locale for this wordlist.
Returns the word at index.
Returns the index of word within the wordlist.
Returns the mnemonic split into each individual word, according to a locale's valid whitespace character set.
Returns the mnemonic by joining words together using the whitespace that is standard for the locale.
Checks that all words map both directions correctly and return the hash of the lists. Sub-classes should use this to validate the wordlist is correct against the official wordlist hash.
Register a wordlist with the list of wordlists, optionally overriding the registered name.
The official wordlists available at `ethers.wordlists`. In the browser, only the english language is available by default; to include the others (which increases the size of the library), see the dist files in the `ethers` package.
The Czech Wordlist.
The English Wordlist.
The Spanish Wordlist.
The French Wordlist.
The Italian Wordlist.
The Japanese Wordlist.
The Korean Wordlist.
The Simplified Chinese Wordlist.
The Traditional Chinese Wordlist.
Now that ethers is more modular, it is possible to have additional ancillary packages, which are not part of the core but optionally add functionality only needed in certain situations.
This module should still be considered fairly experimental.
This provides a quick, high-level overview of the Ethers ASM Dialect for EVM, which is defined by the Ethers ASM Dialect Grammar
Once a program is compiled by a higher level language into ASM (assembly), or hand-coded directly in ASM, it needs to be assembled into bytecode.
The assembly process performs a very small set of operations and is intentionally simple and closely related to the underlying EVM bytecode.
Operations include embedding programs within programs (for example the deployment bootstrap has the runtime embedded in it) and computing the necessary offsets for jump operations.
The Command-Line Assembler can be used to assemble an Ethers ASM Dialect file or to disassemble bytecode into its human-readable (ish) opcodes and literals.
An Opcode may be provided in either a functional or instructional syntax. For Opcodes that require parameters, the functional syntax is recommended and the instructional syntax will raise a warning.
@TODO: Examples
A Label is a position in the program which can be jumped to. A JUMPDEST is automatically added to this point in the assembled output.
@TODO: Examples
A Literal puts data on the stack when executed using a PUSH operation.
A Literal can be provided using a DataHexString or a decimal byte value.
@TODO: examples
To enter a comment in the Ethers ASM Dialect, any text following a semi-colon (i.e. ;) is ignored by the assembler.
A common case in Ethereum is to have one program embedded in another.
The most common use of this is embedding a Contract runtime bytecode within a deployment bytecode, which can be used as init code.
When deploying a program to Ethereum, an init transaction is used. An init transaction has a null to address and contains bytecode in the data. This data bytecode is a program, that when executed returns some other bytecode as a result, this result is the bytecode to be installed.
Therefore it is important that embedded code uses jumps relative to itself, not the entire program it is embedded in, which also means that a jump can only target its own scope, no parent or child scopes. This is enforced by the assembler.
A scope may access the offset of any child Data Segment or child Scopes (with respect to itself) and may access the length of any Data Segment or Scopes anywhere in the program.
Every program in the Ethers ASM Dialect has a top-level scope named _.
A Data Segment allows arbitrary data to be embedded into a program, which can be useful for lookup tables or deploy-time constants.
An empty Data Segment can also be used when a labelled location is required, but without the JUMPDEST which a Labels adds.
@TODO: Example
A Link allows access to a Scopes, Data Segment or Labels.
To access the byte offset of a labelled item, use $foobar.
For a Labels, the target must be directly reachable within this scope. For a Data Segment or a Scopes, it can be inside the same scope or any child scope.
For a Data Segment or a Labels, there is an additional type of Link, which provides the length of the data or bytecode respectively. A Length Link is accessed by #foobar and is pushed on the stack as a literal.
@TODO: exampl
The assembler utilities allow parsing and assembling an Ethers ASM Dialect source file.
Parse an ethers-format assembly file and return the Abstract Syntax Tree.
Performs assembly of the Abstract Syntax Tree node and return the resulting bytecode representation.
The Disassembler utilities make it easy to convert bytecode into an object which can easily be examined for program structure.
Bytecode inherits Array<Operation>
Each array index represents an operation, collapsing multi-byte operations (i.e. PUSH) into a single operation.
Get the operation at a given offset into the bytecode. This ensures that the byte at offset is an operation and not data contained within a PUSH, in which case null it returned.
An Operation is a single command from a disassembled bytecode stream.
The opcode for this Operation.
The offset into the bytecode for this Operation.
If the opcode is a PUSH, this is the value of that push
Opcode
Create a new instance of an Opcode for a given numeric value (e.g. 0x60 is PUSH1) or mnemonic string (e.g. "PUSH1").
The value (bytecode as a number) of this opcode.
The mnemonic string of this opcode.
The number of items this opcode will consume from the stack.
The number of items this opcode will push onto the stack.
A short description of what this opcode does.
Returns true if the opcode accesses memory.
Returns true if the opcode cannot change state.
Returns true if the opcode is a jumper operation.
Returns 0 if the opcode is not a PUSH*, or the number of bytes this opcode will push if it is.
Parsing a file using the Ethers ASM Dialect will generate an Abstract Syntax Tree. The root node will always be a ScopeNode whose name is _.
To parse a file into an Abstract Syntax tree, use the parse function.
The offset into the source code to the start of this node.
The length of characters in the source code to the end of this node.
The source code of this node.
@TODO: Place a diagram here showing the hierarchy
Node
A unique tag for this node for the lifetime of the process.
The source code and location within the source code that this node represents.
A ValueNode is a node which may manipulate the stack.
The literal value of this node, which may be a DataHexString or string of a decimal number.
This is true in a DataNode context, since in that case the value should be taken verbatim and no PUSH operation should be added, otherwise false.
A PopNode is used to store a place-holder for an implicit pop from the stack. It represents the code for an implicit place-holder (i.e. $$) or an explicit place-holder (e.g. $1), which indicates the expected stack position to consume.
The index this PopNode is representing. For an implicit place-holder this is 0.
A LinkNode represents a link to another Node's data, for example $foo or #bar.
The name of the target node.
Whether this node is for an offset or a length value of the target node.
The opcode for this Node.
A list of all operands passed into this Node.
An EvaluationNode is used to execute code and insert the results but does not generate any output assembly, using the {{! code here }} syntax.
This is true in a DataNode context, since in that case the value should be taken verbatim and no PUSH operation should be added, otherwise false.
The code to evaluate and produce the result to use as a literal.
An ExecutionNode is used to execute code but does not generate any output assembly, using the {{! code here }} syntax.
The code to execute. Any result is ignored.
A LabelledNode is used for any Node that has a name, and can therefore be targeted by a LinkNode.
The name of this node.
LabelNode inherits LabelledNode
A LabelNode is used as a place to JUMP to by referencing it name, using @myLabel:. A JUMPDEST is automatically inserted at the bytecode offset.
DataNode inherits LabelledNode
A DataNode allows for data to be inserted directly into the output assembly, using @myData[ ... ]. The data is padded if needed to ensure values that would otherwise be regarded as a PUSH value does not impact anything past the data.
The child nodes, which each represent a verbatim piece of data in insert.
ScopeNode inherits LabelledNode
A ScopeNode allows a new frame of reference that all LinkNode's will use when resolving offset locations, using @myScope{ ... }.
The list of child nodes for this scope.
The Ledger Hardware Wallets are a fairly popular brand.
Connects to a Ledger Hardware Wallet. The type if left unspecified is determined by the environment; in node the default is "hid" and in the browser "u2f" is the default. The default Ethereum path is used if path is left unspecified.
The Experimental package is used for features that are not ready to be included in the base library. The API should not be considered stable and does not follow semver versioning, so applications requiring it should specify the exact version needed.
These features are not available in the core ethers package, so to use them you must install the @ethersproject/experimental package and import them from that.
BrainWallet inherits Wallet
Ethers removed support for BrainWallets in v4, since they are unsafe and many can be easily guessed, allowing attackers to steal the funds. This class is offered to ensure older systems which used brain wallets can still recover their funds and assets.
Generates a brain wallet, with a slightly improved experience, in which the generated wallet has a mnemonic.
Generate a brain wallet which is compatible with the ethers v3 and earlier.
EIP1193Bridge inherits EventEmitter
The EIP1193Bridge allows a normal Ethers Signer and Provider to be exposed in as a standard EIP-1193 Provider, which may be useful when interacting with other libraries.
NonceManager inherits Signer
The NonceManager is designed to manage the nonce for a Signer, automatically increasing it as it sends transactions.
Currently the NonceManager does not handle re-broadcast. If you attempt to send a lot of transactions to the network on a node that does not control that account, the transaction pool may drop your transactions.
In the future, it'd be nice if the NonceManager remembered transactions and watched for them on the network, rebroadcasting transactions that appear to have been dropped.
Another future feature will be some sort of failure mode. For example, often a transaction is dependent on another transaction being mined first.
Create a new NonceManager.
The signer whose nonce is being managed.
The provider associated with the signer.
Set the current transaction count (nonce) for the signer.
This may be useful in interacting with the signer outside of using this class.
Bump the current transaction count (nonce) by count.
This may be useful in interacting with the signer outside of using this class.
The sandbox utility provides a simple way to use the most common ethers utilities required during learning, debugging and managing interactions with the Ethereum network.
If no command is given, it will enter a REPL interface with many of the ethers utilities already exposed.
The eval command can be used to execute simple one-line scripts from the command line to be passed into other commands or stored in script environment variables.
All mnemonic phrases have a password, but the default is to use the empty string (i.e. "") as the password. If you have a password on your mnemonic, the --mnemonic-password will prompt for the password to use to decrypt the account.
The --xxx-mnemonic-password is similar to the --mnemonic-password options, which uses a password to decrypt the account for a mnemonic, however it passes the password through the scrypt password-based key derivation function first, which is intentionally slow and makes a brute-force attack far more difficult.
This is still an experimental feature (hence the xxx).
The assembler Command-Line utility allows you to assemble the Ethers ASM Dialect into deployable EVM bytecode and disassemble EVM bytecode into human-readable mnemonics.
A bin file may be made up of multiple blocks of bytecode, each may optionally begin with a 0x prefix, all of which must be of even length (since bytes are required, with 2 nibbles per byte)
All whitespace is ignored.
The assembler converts an Ethers ASM Dialect into bytecode by running multiple passes of an assemble stage, each pass more closely approximating the final result.
This allows small portions of the bytecode to be massaged and tweaked until the bytecode stabilizes. This allows for more compact jump destinations and for code to include more advanced meta-programming techniques.
This allows key/value pairs (where the value is a string) and flags (which the value is true) to be passed along to the assembler, which can be accessed in Scripting Blocks, such as {{= defined.someKey }}.
By default any warning will be treated like an error. This enabled by-passing warnings.
When a program is assembled, the labels are usually given as an absolute byte position, which can be jumped to for loops and control flow. This means that a program must be installed at a specific location.
Byt specifying the Position Independent Code flag, code will be generated in a way such that all offsets are relative, allowing the program to be moved without any impact to its logic.
This does incur an additional gas cost of 8 gas per offset access though.
All programs have a root scope named _ which is by default assembled. This option allows another labelled target (either a Scopes or a Data Segment to be assembled instead. The entire program is still assembled per usual, so this only impacts which part of the program is output.
A disassembled program shows offsets and mnemonics for the given bytecode. This format may change in the future to be more human-readable.
TODO examples
TODO
The cli library is meant to make it easy to create command line utilities of your own.
CLI
A CLI handles parsing all the command-line flags, options and arguments and instantiates a Plugin to process the command.
A CLI may support multiple Plugin's in which case the first argument is used to determine which to run (or if no arguments, the default plugin will be selected) or may be designed to be standalone, in which case exactly one Plugin will be used and no command argument is allowed.
Add a plugin class for the command. After all options and flags have been consumed, the first argument will be consumed and the associated plugin class will be instantiated and run.
Set a dedicated Plugin class which will handle all input. This may not be used in conjunction with addPlugin and will not automatically accept a command from the arguments.
Shows the usage help screen for the CLI and terminates.
Usually the value of args passed in will be process.argv.slice(2).
Plugin
Each Plugin manages each command of a CLI and is executed in phases.
If the usage (i.e. help) of a CLI is requested, the static methods getHelp and getOptionHelp are used to generate the help screen.
Otherwise, a plugin is instantiated and the prepareOptions is called. Each plugin must call super.prepareOptions, otherwise the basic options are not yet processed. During this time a Plugin should consume all the flags and options it understands, since any left over flags or options will cause the CLI to bail and issue an unknown option error. This should throw if a value for a given option is invalid or some combination of options and flags is not allowed.
Once the prepareOptions is complete (the returned promise is resolved), the prepareArguments is called. This should validate the number of arguments expected and throw an error if there are too many or too few arguments or if any arguments do not make sense.
Once the prepareArguments is complete (the returned promise is resolved), the run is called.
The network this plugin is running for.
The provider for this plugin is running for.
The accounts passed into the plugin using --account, --account-rpc and --account-void which this plugin can use.
The gas limit this plugin should use. This is null if unspecified.
The gas price this plugin should use. This is null if unspecified.
The initial nonce for the account this plugin should use.
A plugin should use this method to resolve an address. If the resolved address is the zero address and allowZero is not true, an error is raised.
Dumps the contents of info to the console with a header in a nicely formatted style. In the future, plugins may support a JSON output format which will automatically work with this method.
Stops execution of the plugin and shows the help screen of the plugin with the optional message.
Stops execution of the plugin and shows message.
Each subclass should implement this static method which is used to generate the help screen.
Each subclass should implement this static method if it supports additional options which is used to generate the help screen.
ArgParser
The ArgParser is used to parse a command line into flags, options and arguments.
Flags are simple binary options (such as the --yes), which are true if present otherwise false.
Options require a single parameter follow them on the command line (such as --account wallet.json, which has the name account and the value wallet.json)
Arguments are all other values on the command line, and are not accessed through the ArgParser directly.
When a CLI is run, an ArgParser is used to validate the command line by using prepareOptions, which consumes all flags and options leaving only the arguments behind, which are then passed into prepareArgs.
Remove the flag name and return true if it is present.
Remove all options which match any name in the Array of names with their values returning the list (in order) of values.
Remove the option with its value for name and return the value. This will throw a UsageError if the option is included multiple times.
Remove all options with their values for name and return the list (in order) of values.
A collection (that will grow over time) of common, simple snippets of code that are in general useful.
The React Native framework has become quite popular and has many popular forks, such as Expo.
React Native is based on JavaScriptCore (part of WebKit) and does not use Node.js or the common Web and DOM APIs. As such, there are many operations missing that a normal web environment or Node.js instance would provide.
For this reason, there is a Shims module provided to fill in the holes.
To use ethers in React Native, you must either provide shims for the needed missing functionality, or use the ethers.js shim.
It is HIGHLY RECOMMENDED you check out the security section below for instructions on installing packages which can affect the security of your application.
After installing packages, you may need to restart your packager and company.
The React Native environment does not contain a secure random source, which is used when computing random private keys. This could result in private keys that others could possibly guess, allowing funds to be stolen and assets manipulated.
For this reason, it is HIGHLY RECOMMENDED to also install the React Native get-random-values, which must be included before the shims. If it worked correctly you should not receive any warning in the console regarding missing secure random sources.
Here are some migration guides when upgrading from older versions of Ethers or other libraries.
This migration guide focuses on migrating web3.js version 1.2.9 to ethers.js v5.
In ethers, a provider provides an abstraction for a connection to the Ethereum Network. It can be used to issue read only queries and send signed state changing transactions to the Ethereum Network.
In ethers, a signer is an abstraction of an Ethereum Account. It can be used to sign messages and transactions and send signed transactions to the Ethereum Network.
In web3, an account can be used to sign messages and transactions.
A contract object is an abstraction of a smart contract on the Ethereum Network. It allows for easy interaction with the smart contract.
Overloaded functions are functions that have the same name but different parameter types.
In ethers, the syntax to call an overloaded contract function is different from the non-overloaded function. This section shows the differences between web3 and ethers when calling overloaded functions.
See issue #407 for more details.
Convert to BigNumber:
Computing Keccak256 hash of a UTF-8 string in web3 and ethers:
This document only covers the features present in v4 which have changed in some important way in v5.
It does not cover all the new additional features that have been added and mainly aims to help those updating their older scripts and applications to retain functional parity.
If you encounter any missing changes, please let me know and I'll update this guide.
Since BigNumber is used quite frequently, it has been moved to the top level of the umbrella package.
The bigNumberify method was always preferred over the constructor since it could short-circuit an object instantiation for [[BigNumber] objects (since they are immutable). This has been moved to a static from class method.
The name of the resolved address has changed. If the address passed into the constructor was an ENS name, the address will be resolved before any calls are made to the contract.
The name of the property where the resolved address has changed from addressPromise to resolvedAddress.
The only difference in gas estimation is that the bucket has changed its name from estimate to estimateGas.
In a contract in ethers, there is a functions bucket, which exposes all the methods of a contract.
All these functions are available on the root contract itself as well and historically there was no difference between contact.foo and contract.functions.foo. The original reason for the functions bucket was to help when there were method names that collided with other buckets, which is rare.
In v5, the functions bucket is now intended to help with frameworks and for the new error recovery API, so most users should use the methods on the root contract.
The main difference will occur when a contract method only returns a single item. The root method will dereference this automatically while the functions bucket will preserve it as an Result.
If a method returns multiple items, there is no difference.
This helps when creating a framework, since the result will always be known to have the same number of components as the Fragment outputs, without having to handle the special case of a single return value.
All errors now belong to the Logger class and the related functions have been moved to Logger instances, which can include a per-package version string.
Global error functions have been moved to Logger class methods.
The Interface object has undergone the most dramatic changes.
It is no longer a meta-class and now has methods that simplify handling contract interface operations without the need for object inspection and special edge cases.
Interrogating properties about a function or event can now (mostly) be done directly on the Fragment object.
The mnemonic phrase and related properties have been merged into a single mnemonic object, which also now includes the locale.
Testing is a critical part of any library which wishes to remain secure, safe and reliable.
Ethers currently has over 23k tests among its test suites, which are all made available for other projects to use as simple exported GZIP-JSON files.
The tests are run on every check-in and the results can been seen on the GitHub CI Action.
We also strive to constantly add new test cases, especially when issues arise to ensure the issue is present prior to the fix, corrected after the fix and included to prevent future changes from causing a regression.
A large number of the test cases were created procedurally by using known correct implementations from various sources (such as Geth) and written in different languages and verified with multiple libraries.
For example, the ABI test suites were generated by procedurally generating a list of types, for each type choosing a random (valid) value, which then was converted into a Solidity source file, compiled using solc and deployed to a running Parity node and executed, with its outputs being captured. Similar to the how many of the hashing, event and selector test cases were created.
While web technologies move quite fast, especially in the Web3 universe, we try to keep ethers as accessible as possible.
Currently ethers should work on almost any ES3 or better environment and tests are run against:
- node.js 8.x
- node.js 10.x
- node.js 12.x
- node.js 13.x
- Web Browsers (using UMD)
- Web Browsers (using ES modules)
If there is an environment you feel has been overlooked or have suggestions, please feel free to reach out by opening an issue on Github.
We would like to add a test build for Expo and React as those developers often seem to encounter pain points when using ethers, so if you have experience or ideas on this, bug us.
The next Major version (probably summer 2021) will likely drop support for node 8.x and will require ES2015 for Proxy.
Certain features in JavaScript are also avoided, such as look-behind tokens in regular expressions, since these have caused conflicts (at import time) with certain JavaScript environments such as Otto.
Basically, the moral of the story is "be inclusive and don't drop people needlessly".
The test suites are available as gzipped JSON files in the @ethersproject/testcases, which makes it easy to install and import (both GZIP and JSON are quite easy to consume from most languages). Each test suite also has its schema available in this package.
| Filename | Test Cases | ||
| accounts.json.gz | Private Keys and addresses in checksum and ICAP formats | ||
| contract-events.json.gz | Compiled Solidity, ABI interfaces, input types/values with the output types/values for emitted events; all tests were executed against real Ethereum nodes | ||
| contract-interface.json.gz | Compiled Solidity, ABI interfaces, input types/values with the output types/values, encoded and decoded binary data and normalized values for function calls executed against real Ethereum nodes. | ||
| contract-interface-abi2.json.gz | Identical to contract-interface, except with emphasis on the ABIv2 coder which supports nested dynami types and structured data | ||
| contract-signatures.json.gz | Contract signatures and matching selectors | ||
| hashes.json.gz | Data and respective hashes against a variety of hash functions | ||
| hdnode.json.gz | HDNodes (BIP-32) with mnemonics, entropy, seed and computed nodes with pathes and addresses | ||
| namehash.json.gz | ENS names along with computed [namehashes](link-namehash | ||
| nameprep.json.gz | IDNA and Nameprep representations including official vectors | ||
| rlp-coder.json.gz | Recursive-Length Prefix (RLP) data and encodings | ||
| solidity-hashes.json.gz | Hashes based on the Solidity non-standard packed form | ||
| transactions.json.gz | Signed and unsigned transactions with their serialized formats including both with and without EIP-155 replay protection | ||
| units.json.gz | Values converted between various units | ||
| wallets.json.gz | Keystore JSON format wallets, passwords and decrypted values | ||
| wordlists.json.gz | Fully decompressed BIP-39 official wordlists | ||
| Test Suites | |||
There are also convenience functions for those developing directly in TypeScript.
Load all the given testcases for the tag.
A tag is the string in the above list of test case names not including any extension (e.g. "solidity-hashes")
Most testcases have its schema available as a TypeScript type to make testing each property easier.
When creating test cases, often we want want random data from the perspective we do not case what values are used, however we want the values to be consistent across runs. Otherwise it becomes difficult to reproduce an issue.
In each of the following the seed is used to control the random value returned. Be sure to tweak the seed properly, for example on each iteration change the value and in recursive functions, concatenate to the seed.
Return at least lower random bytes, up to upper (exclusive) if specified, given seed. If upper is omitted, exactly /lower bytes are returned.
Identical to randomBytes, except returns the value as a DataHexString instead of a Uint8Array.
Returns a random number of at least lower and less than upper given seed.
This section is still a work in progress, but will outline some of the more nuanced aspects of the test cases and their values.
There will likely be an overhaul of the test cases in the next major version, to make code coverage testing more straightforward and to collapse some of the redundancy.
For example, there is no longer a need to separate the ABI and ABIv2 test case and the accounts and transactions suites can be merged into one large collection.
Basic account information using a private key and computing various address forms.
Tests were verified against [EthereumJS](https://github.com/ethereumjs) and custom scripts created to directly interact with Geth and cpp implementations.
See: accounts.json.gz
| Property | Meaning | |
| name | The testcase name | |
| privateKey | The private key | |
| address | The address (lowercase) | |
| checksumAddress | The address with checksum-adjusted case | |
| icapAddress | The ICAP address | |
| Properties | ||
Procedurally generated test cases to test ABI coding.
Computed ABI signatures and the selector hash.
Tests for BIP-32 HD Wallets.
Test cases for the ENS Namehash Algorithm.
Tests for the non-standard packed form of the Solidity hash functions.
These tests were created by procedurally generating random signatures and values that match those signatures, constructing the equivalent Soldity, compiling it and deploying it to a Parity node then evaluating the response.
Serialized signed and unsigned transactions with both EIP-155 enabled and disabled.
Unit conversion.
Tests for the JSON keystore format.
The ethers.js library is something that I've written out of necessity, and has grown somewhat organically over time.
Many things are the way they are for good (at the time, at least) reasons, but I always welcome criticism, and am completely willing to have my mind changed on things.
Pull requests are always welcome, but please keep a few points in mind:
- Backwards-compatibility-breaking changes will not be accepted; they may be considered for the next major version
- Security is important; adding dependencies require fairly convincing arguments as to why
- The library aims to be lean, so keep an eye on the dist/ethers.min.js file size before and after your changes
- Keep the PR simple and readable; only modify files in the
docs.wrm/andpackages/*/src.ts/folders, as this allows the changes to be easily verified - Add test cases for both expected and unexpected input
- Any new features need to be supported by me (future issues, documentation, testing, migration), so anything that is overly complicated or specific may not be accepted
In general, please start an issue before beginning a pull request, so we can have a public discussion and figure out the best way to address the problem/feature. :)
The build process for ethers is unfortunatly not super trivial, but I have attempted to make it as straightforward as possible.
It is a mono-repo which attempts to be compatibile with a large number of environments, build tools and platforms, which is why there are a some weird things it must do.
There are several custom scripts in the misc/admin folder to help manage the monorepo. Developers working on contributing to ethers should not generally need to worry about those, since they are wrapped up behind npm run SCRIPT operations.
Once your environment is set up, you should be able to simply start the auto-build feature, and make changes to the TypeScript source.
To create files for use directly in a browser, the distribution files (located in packages/ethers/dist) need to be built which requires several intermediate builds, scripts and for various rollup scripts to execute.
Most developers should not ever require this step, but for people forking ethers and creating alternates (for example if you have a non-EVM compatible chain but are trying to reuse this package).
This script will rebuild the entire ethers project, compare it against npm, re-write package versions, update internal hashes, re-write various TypeScript files (to get around some ES+TS limitations for Tree Shaking and linking), re-write map files, bundle stripped versions of dependencies and basically just a whole bunch of stuff.
If you use this and get stuck, message me.
For Pull Requests, please ONLY commit files in the docs.wrm/ and packages/*/src.ts/ folders. I will prepare the distribution builds myself and keeping the PR relevant makes it easier to verify the changes.
Again, this should not be necessary for most developers. This step requires using the misc/admin/cmds/config-set script for a number of values, including private keys, NPM session keys, AWS access keys, GitHub API tokens, etc.
The config file is encrypted with about 30 seconds of scrypt password-based key derivation function, so brute-forcing the file is quite expensive.
The config file also contains a plain-text mnemonic. This is a money-pot. Place a tempting amount of ether or Bitcoin on this account and set up an e-mail alert for this account.
If any attacker happens across your encrypted config, they will have instant access to the plain-text mnemonic, so they have the option to immediately steal the ether (i.e. the responsible-disclosure bond).
If you ever see this ether taken, your encrypted file is compromised! Rotate all your AWS keys, NPM session keys, etc. immedately.
@TODO: document all the keys that need to be set for each step
The documents are generated using Flatworm documentation generation tool, which was written for the purpose of writing the documentation for ethers.
Style Guide (this section will have much more coming):
- Try to keep lines no longer than around 80 characters
- Avoid inline links in the source; use the
externalLinksfield in the config.js - Prefix external links with
link- - Changing an anchor name must be well justified, as it will break all existing links to that section; flatworm will support symlinks in the future
- In general, I aim for consistency; look to similar situations throughout the documentation
To build the documentation, you should first follow the above steps to build the ethers library.
Building the docs will generate several types of output:
- A full set of HTML pages, linking across each other
- A single one-page HTML page with all pages linking to local anchors
- A full set of README.md pages organized to be browsable and linkable in GitHub
- A metadata dump for tool ingestion (still needs more work)
- (@TODO; only half done) The documentation as a LaTeX and generated PDF
When building the documentation, all code samples are run through a JavaScript VM to ensure there are no typos in the example code, as well the exact output of results are injected into the output, so there is no need to keep the results and code in-sync.
However, this can be a bit of a headache when making many small changes, so to build the documentation faster, you can skip the evaluation step, which will inject the code directly.
To preview the changes locally, you can use any standard web server and run from the /docs/ folder, or use the built-in web server.
The same caveats as normal web development apply, such flushing browser caches after changing (and re-building) the docs.
There is a lot of documentation on the internet to help you get started, learn more or cover advanced topics. Here are a few resources to check out.
- Official Ethereum Developer Documentations
- The Solidity Documentation, the defactor language for smart contracts as well as a resource for some of the core concepts of Ethereum
I do not manage or maintain these tutorials, but have happened across them. If a link is dead or outdated, please let me know and I'll update it.
The Flatworm Docs rendering engine is designed to be very simple, but provide enough formatting necessary for documenting JavaScript libraries.
A lot of its inspiration came from Read the Docs and the Sphinx project.
Each page is made up of fragments. A fragment is a directive, with an value and optional link, extensions and a body.
Many directives support markdown in their value and body.
A fragment's body continues until another fragment is encountered.
A definition has its TERM in normal text and the body is indented.
The title and body support markdown.
A property has its JavaScript SIGNATURE formatted.
The body supports markdown and the return portion of the signature support markdown links.
Extensions: @src
A note is placed in a blue bordered-box to draw attention to it.
The body supports markdown.
A warning is placed in an orange bordered-box to draw attention to it.
The body supports markdown.
Creates a Code block.
The body does not support markdown, and will be output exactly as is, with the exception of Code Evaluation.
If a line begins with a "_", it should be escaped with a "\".
Extensions: @lang
A toc injects a Table of Contents, loading each line of the body as a filename and recursively loads the toc if present, otherwise all the sections and subsections.
The body does not support markdown, as it is interpreted as a list of files and directories to process.
A null is used to terminated a directive. For example, after a definition, the bodies are indented, so a null can be used to reset the indentation.
The body supports markdown.
The markdown is simple and does not have the flexibility of other dialects, but allows for bold, italic, underlined, monospaced, superscript and strike text, supporting links and lists.
Lists are rendered as blocks of a body, so cannot be used within a title or within another list.
The code directive creates a monospace, contained block useful for displaying code samples.
For JavaScript files, the file is transpiled and executed in a VM, allowiung output (or exceptions) of blocks to be included in the fragment output.
The entire code fragment source is included in an async IIFE, whick means await is allowed, and several special comment directives are allowed.
A //_hide: will include any following code directly into the output, but will not include it in the generated output for the fragment.
A //_log: will include the value of any following expression in the output, prefixed with a // . Renderers will mark output in different style if possible.
A //_result: will begin a block, assigning the contents to _. The block can be ended with a //_log: or //_null:, if no value is given to log, then _ is assumed. If an error occurs, generation fails.
A //_throws: will begin a block, which is expected to throw assigning the error to _. The block can be ended with a //_log: or //_null:, if no value is given to log, then _ is assumed. If an error do not occur, generation fails.
The language can be specified using the @lang extension.
| Language | Notes | |
| javascript | Syntax highlights and evaluates the JavaScript | |
| script | Same as javascript, but does not evaluate the results | |
| shell | Shell scripts or command-line | |
| text | Plain text with no syntax highlighting |
The table directive consumes the entire body up until the next directive. To terminate a table early to begin a text block, use a _null: directive.
Each line of the body should be Row Data or a Variable Declaration (or continuation of a Variable Declaration). Blank lines are ignored.
Each Row Data line must begin and end with a "|", with each gap representing the cell data, alignment with optional column and row spanning.
The alignment for a cell is determined by the whitespace surrounding the cell data.
| Alignment | Whitespace | |
| Left | 1 or fewer spaces before the content | |
| Right | 1 or fewer spaces after the content | |
| Center | 2 or more space both before and after the content | |
| Alignment Conditions (higher precedence listed first) | ||
| center | |
| left | |
| left | |
| right | |
| right | |
| Result of Alignment Example |
A column may end its content with any number of "<" which indicates how many additional columns to extend into.
If the cell content contains only a "^", then the row above is extended into this cell (into the same number of columns).
| (1x1) | (1x2) | (2x1) | ||
| (2x2) | (2x1) | |||
| (1x1) | ||||
| Result of Cell Spanning Example | ||||
The @style extension for a table can be used to control its appearance.
| Name | Width | Columns | |
| minimal | minimum size | best fit | |
| compact | 40% | evenly spaced | |
| wide | 67% | evenly spaced | |
| full | 100% | evenly spaced |
Often the layout of a table is easier to express and maintain without uneven or changing content within it. So the content can be defined separately within a table directive using variables. A variable name must begin with a letter and must only contain letters and numbers.
Variables are also useful when content is repeated throughout a table.
A variable is declared by starting a line with "$NAME:", which consumes all lines until the next variable declaration or until the next table row line.
A variable name must start with a letter and may consist of letters and numbers. (i.e. /[a-z][a-z0-9]*/i)
| Feature | Supported | |
| Dancing Monkey | This option is supported. | |
| Singing Turtle | This option is not supported. | |
| Newt Hair | This option is supported. | |
| This just represents an example of what is possible. Notice that variable content can span multiple lines. | ||
| Result of Variables Example | ||
Configuration is optional (but highly recommended) and may be either a simple JSON file (config.json) or a JS file (config.js) placed in the top of the source folder.
TODO: example JSON and example JS
Adds an inherits description to a directive. The markdown may contain links.
Set the language a code directive should be syntax-highlighted for. If "javascript", the code will be evaluated.
Sets the name in the breadcrumbs when not the current node.
Adds a note to a directive. The markdown may contain links. If the directive already has an @INHERIT extension, that will be used instead and the @NOTE will be ignored.
Calls the configuration getSourceUrl(key, VALUE) to get a URL which will be linked to by a link next to the directive.
This extended directive function requires an advanced config.js Configuration file since it requires a JavaScript function.
The Table Style to use for a table directive.
The ethers library (including all dependencies) are available under the MIT License, which permits a wide variety of uses.
Copyright © 2019-2021 Richard Moore.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.