Last updated
Last updated
Deprecation of Hethers.js by October 20, 2023
As we continue to evolve and improve the Hedera ecosystem, we are committed to ensuring that our developer tools and resources remain easy to use and up-to-date. With this goal in mind, the Hethers.js library will be deprecated by October 20, 2023.
A Signer in hethers is an abstraction of a Hedera Account, which can be used to sign messages and transactions and send signed transactions to the Hedera Network to execute state-changing operations.
The available operations depend largely on the sub-class used.
The Signer class is abstract and cannot be directly instantiated. Instead, use the Wallet.
signer.connect( provider )
⇒ Sub-classes must implement this. Returns a new instance of the Signer, connected to the provider.
signer.getAddress( )
⇒ Promise< string< > >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.
Signer.isSigner( object )
⇒ booleanReturns the balance of this wallet.
signer.getChainId( )
⇒ Promise< number >Returns the chain ID this wallet is connected to.
Returns the result of calling using the transactionRequest, with this account address being used as the from
field. Contrary to other EVM networks, static calls in Hedera are paid, thus executing a call
method is performed through the Signer
. The provider interface executes a ContractLocalCall
query under the hood. This is useful for calling getters on Contracts.
Note: to
can be either an address or an alias.
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
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.
Signs the transaction with the key given upon creation. Transaction can be:
FileCreateTransaction
- when there is only fileChunk
field in the transaction.customData
object
FileAppendTransaction
- when there is both fileChunk
and a fileId
fields
ContractCreateTransaction
- when there is a bytecodeFileId
field
ContractExecuteTransaction
- when there is a to
field present. Ignores the other fields
TransferTransaction
- when there is both to
and a value
fields
AccountCreateTransaction
- when there is a publicKey
field in the transaction.customData
object, also initialBalance
can be provided as optional field in customData
A sub-class must extend Signer and must call super()
.
This is generally not required to be overridden, but may be needed to provide custom behaviour in sub-classes.
This should return a copy of the transactionRequest, with any properties needed by call
and populateTransaction
(which is used by sendTransaction). It should also throw an error if any unknown key is specified.
The default implementation checks only if valid TransactionRequest properties exist and adds from
to the transaction if it does not exist.
If there is a from
field it must be verified to be equal to the Signer's address.
This is generally not required to be overridden, but may be needed to provide custom behaviour in sub-classes.
This should return a copy of transactionRequest, follow the same procedure as checkTransaction
and fill in any properties required for sending a transaction. The result should have all promises resolved; if needed the resolveProperties utility function can be used for this.
The default implementation calls checkTransaction
and resolves to
, adds customData
based on the related operations on Signer.
Create a new Wallet instance for privateKey and optionally connected to the provider. Note: Using only a private Key for wallet initialization is not enough for further transaction execution in Hedera Network. Connecting to an account is mandatory for a fully operational wallet.
Note: ECDSA privateKeys which do not start with 0x
are also accepted.
Create an instance by decrypting an encrypted JSON wallet.
If progress is provided it will be called during decryption with a value between 0 and 1 indicating the progress towards completion.
Create an instance from an encrypted JSON wallet.
This operation will operate synchronously which will lock up the user interface, possibly for a non-trivial duration. Most applications should use the asynchronous fromEncryptedJson
instead.
Create an instance from a mnemonic phrase.
The address for the account this Wallet represents.
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.
Return a new instance of a fully operational wallet, that can be used for transaction signing and sending.
Return a new instance, connected to the provider.
The transaction receipt containts the ID of the newly created account in the TransactionReceipt.accountAddress
field.
wallet.getAddress()
⇒ Promise< string >The address for the account this Wallet represents.
wallet.encrypt( password , [ options = {} , [ progress ] ] )
⇒ Promise< string >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.
This is an interface that contains a minimal set of properties required for Externally Owned Accounts(EOA) which can have certain operations performed, such as encoding as a JSON wallet.
The privateKey of this EOA.
The account Id of the EOA.
Returns true if and only if object is a .
Sub-classes must implement this, however they may throw if sending a transaction is not supported or if the Wallet is offline and not connected to a .
It is very important that all important properties of a are immutable. Since Hedera Hashgraph is very asynchronous and deals with critical data, 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.
The Wallet class inherits and can sign transactions and messages using a private key and account ID as a standard Externally Owned Account ().
Create a new Wallet instance for and optionally connected to the provider.
Note: That wallet is fully operational, and can sign or send transactions, if accountId or address and privateKey are set up in the ExternallyOwnedAccount
object.
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. The library supports , thus the created wallet will have an alias populated. In order for the wallet to be fully functional (be able to send transactions), it must be created by sending hbars to the alias for example.
The provider this wallet is connected to, which will be used for any . This can be null.
Note: There are two ways you can create an account either by using an existing account or by using an alias. If you have an existing account, you can use that account to create a new account and to pay for the associated transaction fees in hbar. If you do not have access to an existing account, you can create a testnet account via the or a mainnet account through one of the options listed .
The of this EOA.