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 much 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.
The various Classes and Functions are available to be imported 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, it can be loaded 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 it can be used like a normal JavaScipt 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)
Once you have a Provider, you have a read-only connection to the blockchain, which can be used 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 method all mapped to encoding and decoding data for you.
If you are familiar with Databases, this is similar to 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 (API) provides.
This class is a meta-class, which means its methods are constructed at runtime, when you pass in the ABI to the constructor it uses that to determine which methods to add.
While a 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 may also be placed in the code easily using the Human-Readable ABI, which the following examples use.
This is a very breif overview of some aspects of Ethereum and blockchains which developers can make use of or should be aware of.
This section is fairly sparse at the moment, but will be expanded as time goes on.
Explain how topics and such work
How to compute the topic...
Example hog logs are used.
Link to provider.getLogs and contract.on
Filter are used as a way to query ... efficient, explain bloom filters lightly
A filter may have up to 4 topic-sets, where each topic-set refers to a condition that must match the 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).
| 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
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.
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 compuers, 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 there 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.
An Application Programming Interface (API) is the formal specification of the library.
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
Explain contract here...
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 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.
For values that have a simple meaning in JavaScript, the types are fairly straight forward; 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.
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.
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.
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.
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.
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.
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
@TODO: Fill this in, including @SRC links
Return an instance of a Contract attched to address. This is the same as using the Contract constructor with address and this the 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.
Uses the signer to deploy the Contract with args passed into the constructor and retruns 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.
ERC20Contract inherits Contract
See the above code example for creating an Instance which will (in addition to the Contact methods and properties) automatically add the additional properties defined in abi to a Contract connected to address using the providerOrSigner.
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)
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.
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 depends 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 instaniated.
Instead use one of the concreate 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 an 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.
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.
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 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 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 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 from 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 ge 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 an HD extended keys.
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 be able to simply 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 simulatenously. 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. Is no network is provided, homestead (i.e. mainnet) is used.
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 and Project Secret | |
| quorum | The number of backends that must agree (default: 2 for mainnet, 1 for testnets) | |
| Option Properties | ||
It is highly recommended for production services that to acquire and specify an API Key for each sercice.
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.
Explain what a provider is...
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.
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.
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.
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 result of executing the transaction, using call. A call does not require any ether, but cannot change any state. This is useful for calling gettings 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.
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.
Explain events here...
Add a listener to be triggered for each eventName.
Add a listener to be triggered for only the next eventName, at which time it be removed.
Notify all listeners of eventName, passing args to each listener. This is generally only used internally.
Remove a listener for eventName. If no listener is provided, all listeners for eventName are removed.
Remove all the listeners for eventName. If no eventName is provided, all events are removed.
Returns the number of listeners for eventName. If no eventName is provided, the total number of listeners is returned.
Returns the list of Listeners for eventName.
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 events for more information on how to specify topic-sets.
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).
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.
The JSON-RPC API is a very 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 API located at url using the aNetworkish network. If url 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.
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.
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.
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 resiliance, security and increase the amount of required trust. To mitigate these issues, it is recommended you use a Default Provider.
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 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 (Mainnet)
- Ropsten (proof-of-work testnet)
- Rinkeby (proof-of-authority testnet)
- Görli (clique testnet)
- Kovan (proof-of-authority 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 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 (Mainnet)
- Ropsten (proof-of-work testnet)
- Rinkeby (proof-of-authority testnet)
- Görli (clique testnet)
- Kovan (proof-of-authority 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 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 (Mainnet)
- Ropsten (proof-of-work testnet)
- Rinkeby (proof-of-authority testnet)
- Görli (clique testnet)
- Kovan (proof-of-authority testnet)
CloudflareProvider inherits UrlJsonRpcProvider
The CloudflareProvider is backed by the Cloudflare Ethereum Gateway.
Create a new CloudflareProvider connected to mainnet (i.e. "homestead").
- Homestead (Mainnet)
Others...
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 choosen (higher prioirty 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. Higher priorities are favoured over lower priorities. If multiple providers share the same prioirty, they are choosen 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.
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 wraping 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](link-eip-1193].
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 resourses, 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 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
And EventType can be any of the following.
- string -- TODO...
- Array<string<DataHexString<32>> | Array<string<DataHexString<32>>>> -- TODO...
- EventFilter -- TODO...
A Network represents an Etherem 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.
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 developers.
The difficulty target required to be met by the miner of the block.
This property is generally of little interest 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 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 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.
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 index of this log in the transaction.
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 maximum amount of gas this transaction is permitted to use.
The price (in wei) per unit of gas this transaction will pay.
The transaction data.
The amount (in wei) this transaction is sending.
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.
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.
Wait for confirmations. If 0, and the transaction has not been mined, null is returned.
The address this transaction is to. This is null if the 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 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.
A bloom-filter, which incldues 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 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.
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 coersion 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 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.
@TODO: Expand this section
See Human-Readable Abi.
See Solidity compiler.
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 @TODO
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 readabiliy.
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.
Fragment
An ABI is a collection of Fragments, where each fragment specifies:
- 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 of each ParamType for the input parameters to the Constructor, Event of Function.
Tra lal al
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
Tra la la...
Tra lal al
This is whether the event is anonymous. An anonymous Event does not inject its topic hash as topic0 when creating a log.
Tra la la...
Tra lal al
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.
Tra la la...
Tra lal al
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 for any parameter wjhich is not an array.
The length of the array, or -1 for dynamic-length arrays. This is null for parameters which is not arrays.
The components of a tuple. This is null for non-tuple parameters.
Tra la la...
Tra la la...
Tra la la...
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 compatibile 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 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 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 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 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.
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.
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 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 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 InvalidArgument Error is thrown.
The value of address may be any supported address format.
Returns address as an ICAP address. Supports the same restrictions as utils.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 operation on numbers which are outside the range of safe values to use in JavaScript.
A BigNumber is an object which safely allows mathematic 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 sepcified 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 Complicment is an elegant method used to encode and decode fixed-width signed values while efficiently preserving mathematic operations. Most users will not need to interact with these.
Returns a BigNumber with the value of BigNumber converted from twos-compliment with bitwidth.
Returns a BigNumber with the value of BigNumber converted to twos-compliment 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 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 choosen 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 eaiser 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 tha 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.
Tra la la...
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 hexidecumal 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
- _vs --- The compact representation of the s and v
- recoveryParam --- The normalized (i.e. 0 or 1) value of v
Raw Signature inherits string<DataHexString<65>>
A Raw Signature is a common Signature format where the r, s and v are concanenated 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.
Retutns 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.contants 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 an 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.
Each Data component may be an valid BytesLike.
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 uneccessary, 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 conguent 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 fixed128x80.
Explain what hash functions are?
The Cryptographic Hash Functions are a specific family of hash functions.
The Ethereum Identity function computs 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.
When using the Solidity abi.packEncoded(...) 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 respecive 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.
TODO: Explain BIP32 BIP-39 and whatnot here...
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 otehr 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.
Checks that target is not kind and performs the same operatons 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.
There was an error communicating with a server.
The amount of data needed is more than the amount of data required, which would cause the data buffer to read past its end.
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.
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.
An Ethereum network validation error, such as an invalid chain ID.
The nonce being specified has already been used in a mined transaction.
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.
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 infomational, warnings and errors.
Only log output for warnings and errors.
Only log output for errors.
Do not output any logs.
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 begine with 0x04.
The compressed public key for this Signing Key. It will always be 33 bytes (66 nibbles) and begine 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.
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.
Tra la la
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, spliting 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 acheive 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 addres this transaction is to.
The nonce of this transaction.
The gas limit for this transaction.
The gas price 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 trasaction 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.
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 ropsten with an account also used on homestead, it would be possible for a transaction signed on ropsten 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.
Parses the transaction properties from a serialized transactions.
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 optiona 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 before rejecting with a timeout error.
Additional headers to include in the connection.
The amount of time allowed to ellapse 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 availalbe in at `ethers.wordlists`. In the browser, only the english langauge 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 overcview 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 langauge 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: Exmaples
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: exmples
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 restul 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-leve 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 emtpty 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 arary 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 instnace 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 shoud 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 expect 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.
Te 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 shoud 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 targetted 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.
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 compatibile 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 it interacting with the signer outside of using this class.
Bump the current transaction count (nonce) by count.
This may be useful it 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, debuging 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 disassemle 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 stablizes. This allows for more compact jump destinations and for code to be 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 gsas 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 conjuction 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 geneate 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 is expected and throw and 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 resovled 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 exectuion 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 nhas 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.
Cooking...
Here are some migration guides when upgrading from older versions of Ethers or other libraries.
TODO
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.
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 fucntions have been moved 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.
Here goes info about testing
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.
So, 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
- 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 to problem/feature. :)
If you wish to modify the source code, there are a few steps involved in setting up your environment.
Since the library uses a monorepo, you must install an initial required set of libraries, which can then be used to install the remaining libraries used within each package, as well as link all the packages within the repo with each other.
TODO: Add more information here.
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 symblinks in the future
- In general, I aim for xonsistency; 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.
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 executed with some simple substitution.
A bare //! on a line is replaced with the result of the last statement. Building will fail if an error is thrown.
A bare //!error is replaced with the throw error. Building will fail if an error is not thrown.
Also any code included between the lines // <hide> and // </hide> will be omitted from the output, which can be used to setup variables.
The language can be specified using the @lang extension.
| Language | Notes | |
| javascript | Syntax highlights and evaluates the JavaScipt | |
| 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 varaible name must being 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 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.