You can initialize Mesh Wallet with:

• mnemonic phrases
• private keys
• Cardano CLI generated keys
• address (read only wallet)

First, we initialize a Provider, which we will assign blockchainProvider to the fetcher and submitter.

Mnemonic phrases

We can load wallet with mnemonic phrases:

With the wallet loaded, you can sign transactions, we will see how to do this in the next section, for now lets get the wallet's address:

Private keys

We can load wallet with private keys:

Cardano CLI generated skeys

We can load wallet with CLI generated keys by providing the skey generated by Cardano CLI. There are two files generated by Cardano CLI, by default it is named signing.skey and stake.skey. Opening the signing.skey file it should contains:

We can get the cborHex from the signing.skey file, and load wallet with Cardano CLI generated skeys. Stake key is optional, but without it, you cannot sign staking transactions.

Address

We can load wallet with address, this is useful for read-only wallets. A read-only wallet can only query the blockchain, it cannot sign transactions. This is useful for monitoring wallets. We can load wallet with the address type:

You can generate deterministic keys based on the Bitcoin BIP39. These mnemonic phrases allow you to recover your wallet.

Once you have your mnemonic phrase, you can use it to generate your deterministic keys. It will typically generate a series of private keys and corresponding public keys, which you can use to manage your cryptocurrencies.

You can also generate private keys directly by adding true in the brew function.

Returns a list of assets in the wallet. This API will return every assets in the wallet. Each asset is an object with the following properties:

• A unit is provided to display asset's name on the user interface.
• A quantity is provided to display asset's quantity on the user interface.

Example:

Returns an address owned by the wallet that should be used as a change address to return leftover assets during transaction creation back to the connected wallet.

This function shall return a list of one or more UTXOs (unspent transaction outputs) controlled by the wallet that are required to reach AT LEAST the combined ADA value target specified in amount AND the best suitable to be used as collateral inputs for transactions with plutus script inputs (pure ADA-only UTXOs).

If this cannot be attained, an error message with an explanation of the blocking problem shall be returned. NOTE: wallets are free to return UTXOs that add up to a greater total ADA value than requested in the amount parameter, but wallets must never return any result where UTXOs would sum up to a smaller total ADA value, instead in a case like that an error message must be returned.

Example of a response returned by this endpoint:

This API accepts the addressType parameter, where you can specify the type of address you want to get. The available options are:

• payment (default)
• enterprise

Returns the network ID of the currently connected account. 0 is testnet and 1 is mainnet but other networks can possibly be returned by wallets. Those other network ID values are not governed by CIP-30. This result will stay the same unless the connected account has changed.

Returns a list of reward addresses owned by the wallet. A reward address is a stake address that is used to receive rewards from staking, generally starts from `stake` prefix. Example:

Returns a list of unused addresses controlled by the wallet. For example:

Returns a list of used addresses controlled by the wallet. For example:

Return a list of all UTXOs (unspent transaction outputs) controlled by the wallet. For example:

This API accepts the addressType parameter, where you can specify the type of address you want to get. The available options are:

• payment (default)
• enterprise

This endpoint utilizes the CIP-8 - Message Signing to sign arbitrary data, to verify the data was signed by the owner of the private key.

signData takes two arguments, the first one is the payload to sign and the second one is the address (optional).

Example of a response from the endpoint:

Continue reading this guide to learn how to verify the signature.

Requests user to sign the provided transaction (tx). The wallet should ask the user for permission, and if given, try to sign the supplied body and return a signed transaction. partialSign should be true if the transaction provided requires multiple signatures.

As wallets should already have this ability to submit transaction, we allow dApps to request that a transaction be sent through it. If the wallet accepts the transaction and tries to send it, it shall return the transaction ID for the dApp to track. The wallet can return error messages or failure if there was an error in sending it.

Collateral is used to guarantee that nodes are compensated for their work in case phase-2 validation fails. Thus, collateral is the monetary guarantee a user gives to assure that the contract has been carefully designed and thoroughly tested. The collateral amount is specified at the time of constructing the transaction. Not directly, but by adding collateral inputs to the transaction. The total balance in the UTXOs corresponding to these specially marked inputs is the transaction’s collateral amount. If the user fulfills the conditions of the guarantee, and a contract gets executed, the collateral is safe.

Example:

Returns a list of assets in wallet excluding lovelace, example:

Return the lovelace balance in wallet. 1 ADA = 1000000 lovelace.

Return a list of assets' policy ID. An example response would be:

Returns a list of assets from a policy ID. If no assets in wallet belongs to the policy ID, an empty list is returned. Query for a list of assets' policy ID with wallet.getPolicyIds().