# JavaScript (client wallets)

# Introduction

Our Javascript library is designed so you can rapidly and easily provide secure financial services to your users using standard web development knowledge. You no longer have to be a blockchain wizard to give the powers of magic internet money to your customers.

With this library you will be able to create advanced, non-custodial, in-browser wallets.

The mainnet library is currently in a beta stage. Things may change randomly. There is no backward compatibility guarantee yet, even though we try not to break things too often.

# Let's get programming

Note that this tutorial mostly describes Browser + IndexedDB approach, which means that the wallets will be created and persisted inside of a user browser.

See calling the REST API or Other programming languages for other approaches.

# node.js / webpack

Install using:

npm install mainnet-js


If you are bundling a production webapp, see detailed notes on using mainnet-js in a webapp.

# <script> tag in HTML

To get started using Bitcoin Cash on your site, include this tag in your <head> section:

<script src="https://cdn.mainnet.cash/mainnet-0.4.28.js"

Note that the integrity part guarantees that the script haven't been tampered with. So if a hacker replaces it, the user's browser will not run the script. Or you can download the library and serve it locally.

Now, you can create a test wallet:

const wallet = await TestNetWallet.newRandom();

This wallet will not be persisted, if a user closes his browser, it's gone forever. See below for persistent wallets.

This creates a TestNet wallet.

What is TestNet? Where to get TestNet money and a wallet?

TestNet is where you test your application. TestNet money has no price. Opposite of TestNet is MainNet, which is what people usually mean when they talk about Bitcoin Cash network. You can get free TestNet money using the getTestnetSatoshis() call (see below) or here (opens new window).

If you need a wallet that supports the TestNet, download Electron Cash (opens new window) and run it using electron-cash --testnet flag. For example, on MacOS that would be:

/Applications/Electron-Cash.app/Contents/MacOS/Electron-Cash --testnet

To create a MainNet wallet (Bitcoin Cash production network):

const wallet = await Wallet.newRandom();

If you want to create a wallet from a mnemonic seed phrase, use this call:

const wallet = await Wallet.fromSeed('.....');


Seed phrase wallets use the derivation path m/44'/0'/0'/0/0 by default (Bitcoin.com wallet compatibility)

Optionally, a BIP44 (opens new window) derivation path may be added as a second argument.

const wallet = await Wallet.fromSeed("horse duck stapler...", "m/44'/1'/145'/0/0");

If you want to create a wallet from a WIF (private key), use this call:

const wallet = await Wallet.fromWIF('.....');

Keep the private key and the seed phrase secret

Remember to keep the private key (in "WIF" form) and/or the seed phrase (aka "mnemonic") secret as they allow spending money from this wallet. You can access them using wallet.privateKeyWif and wallet.mnemonic (you'll also need the derivation path from wallet.derivationPath)

Available networks:

  • mainnet: Wallet
  • Testnet: TestNetWallet
  • RegTest: RegTestWallet (see below)


You can see a working demo here (opens new window) and a video of it here (opens new window)

# Named wallets (persistent)

Named wallets are used to save the private key generated by the browser, so that you can run await Wallet.named(`user`) and always get the same wallet back.

Note that it's better to run something like await Wallet.named(`user:${id}`), i.e. use some ID of the user, so that if the same browser has multiple users, they'll all get their own wallet. (Like, if a user has multiple accounts on your site)

To create a persistent wallet (saved to the IndexedDB of user's browser):

const wallet = await TestNetWallet.named('user:1234');

user:1234 is an optional name for the wallet. The wallet is saved in user's browser for future re-use.

To check if a named wallet already exists in the storage, you can invoke:

const walletExists = await TestNetWallet.namedExists('user:1234');

Say a user of your application has wiped the website data and his IndexedDB is now empty. But they still has the seed and derivation path info. A named wallet can be replaced (recovered) with the existing walletId:

const seed = "diary caution almost ...";
const derivationPath = "m/44'/0'/0'/0/0";
const walletId = `seed:testnet:${seed}:${derivationPath}`;
const wallet = await TestNetWallet.replaceNamed('user:1234', walletId);

If the wallet entry does not exist in the DB, it will be created. If it does - it will be replaced without exception.

# Watch-only wallets

Watch-only wallets do not have private keys and unable to send funds, however they are very useful to keep track of adress' balances, subscribe to its incoming and outgoing transactions, etc.

They are constructed from a cashaddress as follows:

const wallet = await TestNetWallet.watchOnly('bchtest:qq1234567...');

# Getting the balance

To get the balance of the wallet you can use getBalance method:

await wallet.getBalance() // { bch: 0.20682058, sat: 20682058, usd: 91.04 }

If you want to receive balance as number denominated in a unit of your choice, you can call getBalance with an argument:

await wallet.getBalance('usd') // 91.04
await wallet.getBalance('bch') // 0.20682058
await wallet.getBalance('sat') // 20682058

You can ask for usd, sat, bch (or satoshi, satoshis, sats - just in case you forget the exact name).

  • 1 satoshi = 0.000 000 01 Bitcoin Cash
  • 1 Bitcoin Cash = 100,000,000 satoshis

usd returns the amount at the current exchange rate, fetched from CoinGecko or Bitcoin.com.

# Sending money

Let's create another wallet and send some of our money there:

const seller = await TestNetWallet.named('seller');

const txData = await wallet.send([
    cashaddr: seller.getDepositAddress(),
    value: 0.01,
    unit: 'usd',

// or alternatively
const txData = await wallet.send([seller.getDepositAddress(), 0.01, 'usd']);

... which returns an object containing the remaining balance and the transaction ID:

  txId: "2fc2...af",
  balance: {bch: 1.0, sat: 100000000, usd: 1000.00}

Note that you can send to many addresses at once.

If your address holds SLP tokens, you have to use the wallet.slpAware().send([...]) method to prevent accidental token burning. SLP checks are a bit slow, so they are opt-in.

# Options

There is also an options parameter that specifies how money is spent.

  • utxoIds holds an array of strings and controls which UTXOs should be spent in this operation. Format is ["txid:vout",...] , e.g., ["1e6442a0d3548bb4f917721184ac1cb163ddf324e2c09f55c46ff0ba521cb89f:0"]
  • slpAware is a boolean flag (defaulting to false) and indicate that operation should be SLP token aware and not attempt to spend SLP UTXOs
  • changeAddress cash address to receive change to
  • queryBalance is a boolean flag (defaulting to true) to include the wallet balance after the successful send operation to the returned result. If set to false, the balance will not be queried and returned, making the send call faster.
  • awaitTransactionPropagation is a boolean flag (defaulting to true) to wait for transaction to propagate through the network and be registered in the bitcoind and indexer. If set to false, the send call will be very fast, but the wallet UTXO state might be invalid for some 500ms.

# Getting balance

Let's print the balance of the seller's wallet:

console.log(await seller.getBalance('USD'));
// 0.01

Great! You've just made your first transaction!

Now you can send all of your money somewhere else:

const txData = await seller.sendMax(wallet.getDepositAddress());

... which also supports options object and returns:

  txId: "2fc2...af",
  balance: {bch: 0, sat: 0, usd: 0}

If you want to know the maximum amount of available funds to send, e.g. your balance minus the network fees, you can use:

const sendRequestOptions = { slpAware: true, utxoIds: [] };
const options = { outputCount: 1, options: sendRequestOptions };
const maxAmount = await wallet.getMaxAmountToSend(options);

This method returns a balance response object. The options object allows for fine-grained fee calculation based on the output count, slp awareness and specific UTXOs you are willing to spend. By default the method will target to spend all UTXOs into one output.

# Watching/Waiting methods

# QR codes

Let's say you want to display a QR code for you user to pay you money and show an alert when money arrives?

Let's display a QR code first. Create a placeholder first:

<p style="text-align: center;">
    <img src="https://cdn.mainnet.cash/wait.svg" style="width: 15em;" id="deposit">

Then you can replace it with an actual QR code of the deposit address:

document.querySelector('#deposit').src = wallet.getDepositQr().src;

# Watching/Waiting for transaction

You can watch for incoming wallet transaction with watchAddress and watchAddressTransactions methods with the difference that the former will monitor transaction hashes and the latter will receive the decoded transactions in verbose format as per specification (opens new window). Both methods return an async function which when evaluated will cancel watching.

wallet.watchAddress((txHash) => {

const cancelWatch = wallet.watchAddressTransactions((tx) => {
  if (tx.hash === someHash) {
    await cancelWatch();

You can also wait for a wallet transaction and halt the program execution until it arrives:

const options = {
  getTransactionInfo: true,
  getBalance: false,
  txHash: undefined
const response = await wallet.waitForTransaction(options);

If txHash is supplied method will wait for a transaction with this exact hash to be propagated through and registered in the network by the Fulcrum indexer, otherwise any address transaction will trigger a response.

Response: Object {transactionInfo: any, balance: any} depending on the options supplied.

transactionInfo Raw transaction in verbose format as per specification (opens new window)

balance: balance response object as per getBalance request.

If you are willing to spy on monitor transactions of an address you do not own, you can create a watchOnly wallet.

# Watching/Waiting for balance

You can watch for wallet balance changes with watchBalance method (which also returns a cancellation function). The balance object sent to the callback has the same type as returned from getBalance method.

const cancelWatch = wallet.watchBalance((balance) => {
  await cancelWatch();

You can watch for wallet balance changes which are also sensitive to BCH/USD rate changes. The callback will be fired even if there are no actual transactions happening. You can change the polling interval by setting usdPriceRefreshInterval parameter, which defaults to 30000 milliseconds.

const cancelWatch = wallet.watchBalanceUsd((balance) => {
  await cancelWatch();
}, 5000);

You can wait for a certain minimal balance on the wallet using the waitForBalance function.

const balance = await wallet.waitForBalance(1.0, 'usd');

The balance variable contains the actual balance of the wallet.

# Watching/Waiting for block

You can watch for incoming blocks with watchBlocks method:

const cancelWatch = wallet.watchBlocks((block) => {
  await cancelWatch();

If you want to wait for the next block or wait for blockhain to reach certain block height you can use the following method:

const nextBlockInfo = await wallet.waitForBlock();

const futureBlockInfo = await wallet.waitForBlock(770000);

The response object's schema (opens new window) is simple:

  height: number;
  hex: string;

# Sending data with OP_RETURN

You can store arbitrary data on blockchain using the OP_RETURN opcode. It is useful not only to store simple text messages, many protocols such as MEMO and SLP are utilizing it to build complex applications.

You can send OP_RETURN messages as simple strings (supporting UTF8) or binary buffers as follows:

await wallet.send([ OpReturnData.from("MEMO\x10LÖL😅") ]);
await wallet.send([ OpReturnData.from(Buffer.from([0x4c, 0x4f, 0x4c])) ]);

// or alternatively

await wallet.send([ ["OP_RETURN", "MEMO\x10LÖL😅"] ]);
await wallet.send([ ["OP_RETURN", Buffer.from([0x4c, 0x4f, 0x4c])] ]);

You can simply pass raw buffer containing your opcodes. If your buffer lacks the OP_RETURN and OP_PUSHDATA (followed by the length of the message) opcodes, they will be prepended.

Sending funds and OP_RETURN messages can be mixed together, the output order will be preserved:

await wallet.send([
  { cashaddr: otherWallet.cashaddr!, value: 546, unit: "sats" },

# Simple Ledger Protocol (SLP)

We currently fully support the SLP type 1 tokens specification (opens new window)

The interfaces were designed to be largely similar to those of BCH wallets.

Creating an SLP enabled wallet is similar to a BCH one, just add an .slp static accessor after the wallet class you want to use:

const wallet = await TestNetWallet.slp.newRandom();

The SLP wallets are using the m/44'/245'/0'/0/0 BIP44 derivation path unlike normal BCH wallets which use m/44'/0'/0'/0/0. This is done to lower the chances of accidental token burns.

If you want to instantiate an SLP wallet which will use a different derivation path (assuming you already have your BIP39 seed phrase):

const wallet = await Wallet.slp.fromSeed("diary caution almost ...", "m/44'/123'/0'/0/0");

Note, that SLP-enabled wallets are by default SLP aware and token burn checks are ensured when spending UTXOs.

The SLP functions are then available via Wallet.slp accessor:

const slpAddress = wallet.slp.getDepositAddress();

const qrCode = wallet.slp.getDepositQr();

Note, that working with SLP tokens requires a certain amount of BCH available in your wallet so that you can pay miners for the SLP transactions.

# Token creation - Genesis

To create your own token you should prepare and broadcast a special genesis transaction containing all the information about the token being created: token name, ticker, decimals - number of significant digits after comma, initial token amount, url you want to associate with token. Some of these properties are optional.

With the endBaton parameter you can decide to keep the possibility of additional token creation, which is governed by so called minting baton or immediately discard this baton to make the token circulation amount to be fixed.

The transaction id in which the token is created will become its permanent and unique identifier.

Note, that there might be many tokens with the same name. Remember, that only 64 character long string-ids do identify your token uniquely und unambiguously.

In the following example 10000.00 MNC tokens will be created.

const genesisOptions = {
  name: "Mainnet coin",
  ticker: "MNC",
  decimals: 2,
  initialAmount: 10000,
  documentUrl: "https://mainnet.cash",
  endBaton: false
const {tokenId} =  await wallet.slp.genesis(genesisOptions)

# Looking up token information

If you want to get the genesis information of some token, you can simply call getTokenInfo:

const info = await wallet.slp.getTokenInfo(tokenId);

# Additional token creation - Minting

If you decide to increase the token circulation supply, you would need to mint more tokens. You are required to have the ownership of the minting baton to do so. Similarly to genesis, you can keep the baton or discard it.

In the following example we issue 50 more tokens we just created in genesis:

const mintOptions = {
  value: "50",
  tokenId: tokenId,
  endBaton: false,
  tokenReceiverSlpAddr: "slptest:qqm4gsaa2gvk7flvsvj7f0w4rlq32vqhkq32uar866",
  batonReceiverSlpAddr: "slptest:qqm4gsaa2gvk7flvsvj7f0w4rlq32vqhkq32uar866"

const {txId, balance} = await wallet.slp.mint(mintOptions);

Optional tokenReceiverSlpAddr and batonReceiverSlpAddr allow to specify the receiver of tokens and minting baton. This is how you can pass the minting baton to other authority.

# Sending tokens

Sending tokens around is easy and is very similar to sending BCH. You can include many send requests in one call too!

const {txId, balance} = await wallet.slp.send([
    slpaddr: bobWallet.slp.slpaddr,
    value: 5,
    tokenId: tokenId

Or you can send all tokens available with a simple sendMax method

const result = await wallet.slp.sendMax(otherWallet.slp.slpaddr, tokenId);

Note, you can not send several different tokens in one go.

# Token balances

You can get all token balances of your wallet or a balance of a specific token with the following methods:

const tokenBalance = wallet.slp.getBalance(tokenId);
const allBalances = wallet.slp.getAllBalances();

# SLP address UTXOs

If you want to get the information about SLP UTXOs of an address, look up the locked satoshi values, etc., you can do the following call:

const utxos = wallet.slp.getFormattedSlpUtxos();

# Watching/waiting for transactions

You can set up a hook to monitor SLP transactions with the following:

const cancelFn = wallet.slp.watchTransactions((tx) => {
}, tokenId);

Leave out the tokenId to monitor all token transactions.

Call the cancelFn() to unsubscribe from receiving callback calls.

If you want just to wait for the next transaction you can use the following call:

const tx = await wallet.slp.waitForTransaction(tokenId);

This will halt the program execution until the transaction arrives.

# Watching/waiting for balance

Similarly a to transaction watching/waiting we provide the convenient methods to watch/wait for balance.

const cancelFn = wallet.slp.watchBalance((balance) => {
}, tokenId);

You can wait for the SLP wallet to reach a certain minimal token balance:

const actualBalance = await wallet.slp.waitForBalance(10, tokenId);

This will halt the program execution until the balance reaches the target value.

# Non-fungible tokens (NFT)

NFT1 is a simple extension to the SLP token type 1 protocol which allows many NFT tokens to be grouped together using a single ID. Having the ability to group NFTs in a provable manner opens the doors for many more token applications, and makes SLP more similar to other NFT protocols (e.g., ERC-721). NFT1 uses the same validation rules as SLP token type 1 with a few additional constraints. See reference (opens new window). Non-fungible tokens can be produced by simply minting a non-divisible token supply of 1 without a minting baton.

All operations apart from genesis and minting, which are used for SLP tokens Type1, support the NFT tokens and are used the same way with same interfaces.

# NFT Parent Genesis

To create the NFT parent group use the following code snippet

const genesisOptions = {
  name: "Mainnet NFT Parent",
  ticker: "MNC_NFTP",
  decimals: 0,
  initialAmount: 10000,
  documentUrl: "https://mainnet.cash",
  endBaton: false
const genesisResult =  await wallet.slp.nftParentGenesis(genesisOptions);
const parentTokenId = genesisResult.tokenId;

Note: these tokens are transferrable and mintable. Decimal places of 0 is advised.

# NFT Child Genesis

NFT child tokens are unique and one of a kind. To create an NFT child token use the following code snippet

const genesisOptions = {
  name: "Mainnet NFT Child",
  ticker: "MNC_NFTC",
  decimals: 0,
  initialAmount: 1,
  documentUrl: "https://mainnet.cash",
  endBaton: true,
  parentTokenId: parentTokenId
const {tokenId} =  await wallet.slp.nftChildGenesis(genesisOptions);

In the process of the child genesis, a parent token of quantity 1 will be spent, so ensure you possess some. If you have more than 1 (n), the tokens will be split into (n-1) and 1.

Note: these tokens are transferrable but not mintable. Regardless of options supplied, the following options will be overridden: endBaton will be set to true, initialAmount: 1, decimals: 0. Otherwise they will be considered as invalid by the SLP validators.

# List of your NFTs

See Token Balances

# Configuring SLP provider and endpoints

You can switch between the default SLPDB and experimental Graph Search++ SLP providers by changing the static property Wallet.slp.defaultProvider. Valid values are slpdb and gspp. All other values will be not recognized and will default to SLPDB provider. The changes to this property will take effect globally next time you create a new wallet. If you want to change the provider for a single wallet only, you can do wallet.slp.setProvider(...).

You can change SLP provider data source and event source endpoints by changing static properties SlpDbProvider.defaultServers and GsppProvider.defaultServers. The changes will take effect globally next time you create a new wallet. If you want to change the endpoints for a single wallet only, you can do wallet.slp.provider.servers = ....

# TestNet faucet

You can have some TestNet satoshi or SLP tokens for your convenience. Visit our faucet refilling station at https://rest-unstable.mainnet.cash/faucet.html (opens new window)

Your address will be refilled up to 10000 TestNet satoshi or up to 10 SLP tokens upon a call. There are request rate limiters set up to prevent abuse.

We've integrated the faucet into the library so that you can do easy calls like the following:

const txid = await wallet.getTestnetSatoshis();
const sendResponse = await wallet.returnTestnetSatoshis();

Same for SLP:

const txid = await wallet.getTestnetSlp(tokenId);
const slpSendResponse = await wallet.returnTestnetSlp(tokenId);

# Escrow contracts


Alpha release

# Getting the mainnet-cash Contract package

To keep the size of the packages small, both CashScript contract and Ethereum style functionality have been broken out into separate add-on packages (@mainnet-cash/contract & @mainnet-cash/smartbch).

# Via npm / yarn

If you are developing in node or for a webapp, import or require from @mainnet-cash/contract after installing the separate package using:

npm install @mainnet-cash/contract
# or 
yarn add @mainnet-cash/contract

# <script> tag in HTML

To get started using CashScript Contracts on your site, include this tag in your <head> section:

<script src="https://cdn.mainnet.cash/contract/contract-0.4.28.js"

This will enable code required for Cashscript in the global scope of your browser.

Note that the integrity part guarantees that the script haven't been tampered with. So if a hacker replaces it, the user's browser will not run the script. Or you can download the library and serve it locally.

# Using the pre-defined contract

Ok, let's now assume that you are building a service where you want to connect a buyer and a seller (a freelance marketplace or a non-custodial exchange), but at the same time you don't want to hold anyone's money, but only act as an arbiter in case something goes wrong. It's possible in Bitcoin Cash and it's called "an escrow contract".

You'll need three addresses for this: buyer, seller and arbiter.

Note: The source for the contract is here (opens new window).

  1. Buyer sends the money to the contract and could then release the money to the seller
  2. The seller could refund the buyer
  3. Arbiter can either complete the transaction to the seller or refund to the buyer, but cannot steal the money
let escrow = new EscrowContract({
  arbiterAddr: arbiter.getDepositAddress(),
  buyerAddr: buyer.getDepositAddress(),
  sellerAddr: seller.getDepositAddress(),
  amount: 5000

You can now send money to the contract:

await buyer.send([ [ escrow.getAddress(), 8700, "satoshis" ], ]);

Check the balance of the contract (in satoshis):

await escrow.getBalance()
// 8700

Note: Escrow contract is big (in bytes) and requires a big fee, so the minimum what you can send to it is about 3700 satoshis.

Now, we can execute the necessary functions:

  1. Buyer releases the funds
await escrow.call(buyer.privateKeyWif, "spend");
  1. Seller refunds
await escrow.call(seller.privateKeyWif, "refund");
  1. Arbiter releases the funds or refunds
await escrow.call(arbiter.privateKeyWif, "spend");
await escrow.call(arbiter.privateKeyWif, "refund");

# Saving the contract to the database

The arbiter needs to save the contract somewhere (in a database or some other storage), so that when the time comes, he could execute the necessary functions:


const escrowContractId = escrow.toString();

Restore it later:

const restoredEscrow = EscrowContract.fromId(escrowContractId);

The escrow object implements a CashScript contract from a stock template, but if the template doesn't suit your needs, it is also possible to use any contract written in CashScript (opens new window).

pragma cashscript ^0.6.1;
contract escrow(bytes20 sellerPkh, bytes20 buyerPkh, bytes20 arbiterPkh, int contractAmount, int contractNonce) {

    function spend(pubkey signingPk, sig s, int amount, int nonce) {
        require(hash160(signingPk) == arbiterPkh || hash160(signingPk) == buyerPkh);
        require(checkSig(s, signingPk));
        require(amount >= contractAmount);
        require(nonce == contractNonce);
        bytes34 output = new OutputP2PKH(bytes8(amount), sellerPkh);
        require(hash256(output) == tx.hashOutputs);

    function refund(pubkey signingPk, sig s, int amount, int nonce) {
        require(hash160(signingPk) == arbiterPkh||hash160(signingPk) == sellerPkh);
        require(checkSig(s, signingPk));
        require(amount >= contractAmount);
        require(nonce == contractNonce);
        bytes34 output = new OutputP2PKH(bytes8(amount), buyerPkh);
        require(hash256(output) == tx.hashOutputs);

# Generic CashScript


Alpha release

What is CashScript?

From CashScript.org:

CashScript (opens new window) is a high-level programming language for smart contracts on Bitcoin Cash. It offers a strong abstraction layer over Bitcoin Cash' native virtual machine, Bitcoin Script. Its syntax is based on Ethereum's smart contract language Solidity, but its functionality is very different since smart contracts on Bitcoin Cash differ greatly from smart contracts on Ethereum. For a detailed comparison of them, refer to the blog post Smart Contracts on Ethereum, Bitcoin and Bitcoin Cash (opens new window).

In the EscrowContract example in the previous section, the contract source is hardcoded. But with a generic Contract, the full script is defined by the user.

Contracts are objects that simply wrap a CashScript Contract, with utilities to serialize and deserialize them. In addition, there are some functions on wallets to facilitate sending arguments to the contract.

For example, taking a simple pay with timeout example from the CashScript playground (opens new window):

pragma cashscript ^0.5.0;

contract TransferWithTimeout(pubkey sender, pubkey recipient, int timeout) {
    // Require recipient's signature to match
    function transfer(sig recipientSig) {
        require(checkSig(recipientSig, recipient));

    // Require timeout time to be reached and sender's signature to match
    function timeout(sig senderSig) {
        require(checkSig(senderSig, sender));
        require(tx.time >= timeout);

This can be loaded up by passing the script, constructor arguments and network to a new Contract.

Before you dive in, it might be a good time to consider using RegTest?

The below code is for TestNet, but it's highly recommended to develop and test your contracts on RegTest. Besides the ability to give yourself free coins, it's also possible to mine blocks to test your contract functioning over different time conditions.

const script = `contract TransferWithTimeout(pubkey sender, pubkey recipient, int timeout) {
    // Require recipient's signature to match
    function transfer(sig recipientSig) {
        require(checkSig(recipientSig, recipient));

    // Require timeout time to be reached and sender's signature to match
    function timeout(sig senderSig) {
        require(checkSig(senderSig, sender));
        require(tx.time >= timeout);
const alice = await TestNetWallet.newRandom();

In the case that you only have Charlie's cashaddr, it won't be possible to get the full public key, but a public key hash may be used in the contract instead

const charlie = await TestNetWallet.watchOnly("bchtest:qqz52tne6ny78tltw82f0tufcum0752zg5tnwcf0v9")

In javascript, the contract can take a binary argument as a Uint8Array or hexadecimal strings just like CashScript, but passing passing true here causes getPublicKey() to return hex, (in case you wanted to paste into the data into CashScript playground.) the default is a Uint8Array.

const alicePk = alice.getPublicKey(true);
const charliePk = charlie.getPublicKey(true);

Next pass the script, arguments and network to create a new Contract.

// Some block height very far in the past.
const after = 215;

let contract = new Contract(
  [alicePk, charliePk, after],

`Contract is not a function` got you down?

See the note at the top of the previous section about getting the @mainnet-cash/contract package.

This will give you a contract object that can be serialized and deserialized just like a wallet:

// serialized to a string
let contractStr = contract.toString()

// recreate the Contract object from a string
let contractCopy = Contract.fromId(contractStr)

The deposit address is available with the same interface as a wallet.


The interface to list utxos is identical to wallets as well...

await contract.getUtxos()
// [
//  {
//   txid: "8806ef4f1185f268a5083fbd651d974b939d2c68afa2be28652c4ccce06703c4", 
//   vout: 0, 
//   satoshis: 1000, 
//   height: 0
//  }
// ]

Once the contract is funded, contract functions may be called just like in CashScript:

let transferFn = contract.getContractFunction("transfer");

// the signature template for charlie is available on the wallet
const sig = charlie.getSignatureTemplate();
const charlieAddr = charlie.getDepositAddress()

// The function may be called by passing the arguments to the function
// specifying a `to` destination and a CashScript function method, i.e. send
let txn = await transferFn(sig).to(charlieAddr, 7000).send();  

Wallets have the following convenience methods for passing data to CashScript:

Wallet Method Returns CashScript Type
getSignatureTemplate() SignatureTemplate sig
getPublicKeyCompressed() Hex String or Uint8Array pubkey
getPublicKeyHash() Hex String or Uint8Array bytes20

In Javascript, passing either hex or a Uint8Array to CashScript will work.

In the case that a contractId is stored, or received from another party, a convenience method exists to list information contained in a contractId, the info() interface is available to return the parsed data.

The return should be an object with the same contractId, deposit cashaddr, script source, input parameters and a contract nonce that is added for uniqueness.

// {
//   "contractId": "contract:testnet:TURRellXWTNabVF5WmpVeVpUa3dNVFEzTldOa1pEUXhPRFZoWWpWa1ptVmlZamMyTXpNM09EQTVNV0psTVRrd1lXUXlOMkZrTXpRM1lUZGtPR1kwTmpOa1pqSXlaVE5sT0dKbFlUaGtaRGcwTldKaE1XUXlNR00xWmpCbFl6QTJNek13WmpNM01ETTFZbUpsTkdFME1UZzNPVEUzTVRCaVlUbGpNakUxWkRaa05RPT06TURSbE9EZGtOV1ZrTlRCbU16VXdZVFZtTjJFMk16aG1abVkyT0RFek5HTTNOekJsT1RGaVlUUTFNV0l4TXpSaVlqTTVOVEJqTUdVMk9ETTJNR0poWW1JNE0ySTJOMlF3TnpSaU16WTFOVFl4WVdVMU0ySmxaVEV6TXpBNFl6TTFPVEF6TnpOaU5qTm1aV1F6TVRKallXVTNNMlk0TXpWaE56SmlaR00xWldFek53PT06TWpFMQ==:Y29udHJhY3QgVHJhbnNmZXJXaXRoVGltZW91dChwdWJrZXkgc2VuZGVyLCBwdWJrZXkgcmVjaXBpZW50LCBpbnQgdGltZW91dCkgewogICAgLy8gUmVxdWlyZSByZWNpcGllbnQncyBzaWduYXR1cmUgdG8gbWF0Y2gKICAgIGZ1bmN0aW9uIHRyYW5zZmVyKHNpZyByZWNpcGllbnRTaWcpIHsKICAgICAgICByZXF1aXJlKGNoZWNrU2lnKHJlY2lwaWVudFNpZywgcmVjaXBpZW50KSk7CiAgICB9CgogICAgLy8gUmVxdWlyZSB0aW1lb3V0IHRpbWUgdG8gYmUgcmVhY2hlZCBhbmQgc2VuZGVyJ3Mgc2lnbmF0dXJlIHRvIG1hdGNoCiAgICBmdW5jdGlvbiB0aW1lb3V0KHNpZyBzZW5kZXJTaWcpIHsKICAgICAgICByZXF1aXJlKGNoZWNrU2lnKHNlbmRlclNpZywgc2VuZGVyKSk7CiAgICAgICAgcmVxdWlyZSh0eC50aW1lID49IHRpbWVvdXQpOwogICAgfQp9:544951395",
//   "cashaddr": "bchtest:ppv649rmxcd9fpwgk78pq0yek30krgwreva8unzm0x",
//   "script": "contract TransferWithTimeout(pubkey sender, pubkey recipient, int timeout) {\n    // Require recipient's signature to match\n    function transfer(sig recipientSig) {\n        require(checkSig(recipientSig, recipient));\n    }\n\n    // Require timeout time to be reached and sender's signature to match\n    function timeout(sig senderSig) {\n        require(checkSig(senderSig, sender));\n        require(tx.time >= timeout);\n    }\n}",
//   "parameters": [
//     "043af7fd2f52e901475cdd4185ab5dfebb763378091be190ad27ad347a7d8f463df22e3e8bea8dd845ba1d20c5f0ec06330f37035bbe4a418791710ba9c215d6d5",
//     "04e87d5ed50f350a5f7a638fff68134c770e91ba451b134bb3950c0e68360babb83b67d074b365561ae53bee13308c3590373b63fed312cae73f835a72bdc5ea37",
//     "215"
//   ],
//   "nonce": 544951395
// }

Combined with the getPublicKeyHash() method described above, another party could verify that the script of the contract matched an agreement and that the counter-party's public key hash was indeed a parameter to the contract.

# Debugging Contracts

For developing, testing, or debugging contracts, it's useful to run your script on a local regtest "network".

In this section, we'll revisit the escrow contract and see ways to cause the contract not to release funds and how to debug why that is happening.

# Before you begin

  1. Have docker-compose installed
  2. Have the meep (opens new window) Bitcoin Cash debugger installed, and the go language if necessary.
  3. See the regtest wallets section below.
  4. Checkout a copy of the mainnet-js repository.
  5. From the mainnet-js project root, run:
yarn regtest:up 

This should give you all the services used by mainnet-js in the background configured in regtest mode, which you may check with docker ps.

When you want to shut regtest down, use:

yarn regtest:down 

# Step 1, "Neglect the fees"

Small transaction fees are currently used on Bitcoin Cash to make the cost of a large spam attack non-trivial to the attacker. There are other finite measures, such as coindays (or the age of coins being spent). However, for a the time being, Bitcoin Cash software largely agrees to use 1 sat/byte, because the mechanism was simple to implement across a lot of diverse and interconnected software.

So a common way to break the escrow transaction flow is to neglect the fees, which we'll do below.

Let's create our contract parties again.

You can do this by importing mainnet into nodejs, using a live coding tool or the console of web browser using yarn relaod at localhost:8080.

seller = await RegTestWallet.newRandom()
buyer = await RegTestWallet.newRandom()
arbiter = await RegTestWallet.newRandom()

Next we need the buyer to have some funds. Luckily we know an address on your regtest network with lots of bitcoin mined to it when docker starts.

miner = await RegTestWallet.fromWIF("cNfsPtqN2bMRS7vH5qd8tR8GMvgXyL5BjnGAKgZ8DYEiCrCCQcP6")
await miner.send([
    cashaddr: buyer.getDepositAddress(),
    value: 100000,
    unit: "satoshis",

Next, let's create a contract between our parties:

escrow = new EscrowContract({
  arbiterAddr: arbiter.getDepositAddress(),
  buyerAddr: buyer.getDepositAddress(),
  sellerAddr: seller.getDepositAddress(),
  amount: 20000

Next the buyer sends funds for the transaction to the contract address, and checks the balance:

await buyer.send({cashaddr:escrow.getDepositAddress(), value: 20000, unit:'sat'})
await escrow.getBalance()
// 20000

Since the contract is funded for the full amount, let's try to release funds to the seller using the buyer's private key:

await escrow.call(buyer.privateKeyWif, "spend");

But instead of sending the funds successfully, this returns an error:

Uncaught (in promise) Error: Error: The contract amount (20000) could not be submitted for a tx fee (836) with the available with contract balance (20000)

In the above case, we attempted to spend 20,000 sat using the unlocking script, from an address with only 20,000 sat, we neglected to include enough to cover the transaction fee of 836 sats.

If we send another input to the contract address...

await buyer.send({cashaddr:escrow.getDepositAddress(), value: 836, unit:'sat'})
await escrow.getBalance()
/// 20836
await escrow.call(buyer.privateKeyWif, "spend");

... we'll be greeted with another error:

Uncaught (in promise) Error: Error: The contract amount (20000) could not be submitted for a tx fee (1596) with the available with contract balance (20836)

The fees went up to 1596 sats!

This error occurred because funds are now being spent from two inputs (20,000 & 836), so the resulting transaction is larger and requires a larger fee. Although the fee we added would have been enough to spend the first output, it's not enough to spend two outputs.

Since the unlocking script is included for each input, we can double the amount needed to spend from one unspent transaction output and should be able to spend the full amount from three inputs:

await buyer.send({cashaddr:escrow.getDepositAddress(), value: 1656, unit:'sat'})
await escrow.getBalance()
/// 22492

If the buyer attempts to spend funds now, the transaction will succeed.

await escrow.call(buyer.privateKeyWif, "spend");

// ​Object { inputs: (3) […], locktime: 645, outputs: (1) […], version: 2, txid: "612ca1da16492503d9fea53106800073fa8b3f573d7663aed1ab92e41d38d979",
// hex: "0200000003a5e92065f28ba406b0ac020b961caba285fcb438535775978524ebe5c9d1b92800000000fdcf020488bcc30802a84e41020424b6ede0258de98a4d77770a7282878634ba348e3ef520853cfc13c0987d979d6f5574e49ba04f65d74003ac43da837a5ce7edd111b17b3ecdce0a223b7941210384ddcc77b7177d8fe61b9a5b8c8ee3d1c225e525ac986d249e2c9b4a26920c8b4d7d01020000009e..."

# Step 2, Rejection by network rules.

A library can handle some common errors around a static contract, but if you develop your own contract (or have issues with the builtin escrow contract), a transaction may be rejected by the network because the rules of the contract don't authorize funds to be spent.

Let's do this with the same escrow contract from above and see how to figure out what happened.

Let's fund the contract address, with enough fee to spend...

await buyer.send({cashaddr:escrow.getDepositAddress(), value: 20837, unit:'sat'})
await escrow.getBalance()
// 20837

Now lets attempt to break the rules by spending to the seller's address, with the seller's key

await escrow.call(seller.privateKeyWif, "spend");

Uncaught (in promise) Error: Error: Transaction failed with reason: the transaction was rejected by network rules.

mandatory-script-verify-flag-failed (Script failed an OP_VERIFY operation) (code 16)

meep debug --tx=0200000001f0a7e4ace8584c254a12e65a1ff0b6b3b876160d102a8eec2456095ef7e6000700000000fdcf020488bcc30802214e410bcba486912488ef15eb1e9a1cac56768823ff750b9bec35106b75e698f53d69ca483acd26f9441f683aa4975078f73e11e803788255849fb9d6dbb87667a4204121025fc8b68ce77607a82169849b8ae03384948644b4c8d42655aa2a99803df56d474d7d010200000000d6d779b71176a783ff0d427e00ccc504cd3ee027dc4d8792392be2e562fdc718606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198f0a7e4ace8584c254a12e65a1ff0b6b3b876160d102a8eec2456095ef7e6000700000000e00488bcc30802204e140048249a5b92081ed9899c8bc15767c7ad45b033149ec12aee1e1266036ae546b93620f1a7aebfc39614d20194262d3b448d55154b52ef69e13581d4af815579009c635679820128947f7701207f755879a9547a875879a9547a879b69577a577a6e7c828c7f75597aa87bbbad5579537aa269557a537a9d537a5880041976a9147e7b7e0288ac7eaa877767557a519d5579820128947f7701207f755779a9547a875779a9537a879b69567a567a6e7c828c7f75587aa87bbbad5479537aa269547a537a9d7b5880041976a9147e7b7e0288ac7eaa87686551000000000000feffffff492b5e32f70d2c63e07cc0c5e08fcaecc34ec34237919d9d1675dbcf7f3065c9d700000041000000004ce00488bcc30802204e140048249a5b92081ed9899c8bc15767c7ad45b033149ec12aee1e1266036ae546b93620f1a7aebfc39614d20194262d3b448d55154b52ef69e13581d4af815579009c635679820128947f7701207f755879a9547a875879a9547a879b69577a577a6e7c828c7f75597aa87bbbad5579537aa269557a537a9d537a5880041976a9147e7b7e0288ac7eaa877767557a519d5579820128947f7701207f755779a9547a875779a9537a879b69567a567a6e7c828c7f75587aa87bbbad5479537aa269547a537a9d7b5880041976a9147e7b7e0288ac7eaa8768feffffff01214e0000000000001976a914d20194262d3b448d55154b52ef69e13581d4af8188acd7000000 --idx=0 --amt=20837 --pkscript=a914721245359aa9cb99428df5e449fd9e6a16270ee487
    _sendMax webpack://mainnet-js/./src/contract/escrow/EscrowContract.ts?:245

In the above error output, we see the operation that failed was OP_VERIFY and we're provided with the meep debug command to step through this specific transaction.

meep (opens new window) is a Bitcoin Cash script debugger written in golang. After ensuring you have it installed, and it's callable on your computer, you may use the above supplied command to see where exactly in execution of the unlock script OP_VERIFY failed.


Stepping through the Bitcoin Script in meep, we can see the translation of the CashScript contract to Bitcoin Script. The contract repeats the same pattern with the spend and refund blocks in an if,else,endif structure. And that the failure occurs on an OP_VERIFY in the first or spend block.

We can also see in the RedeemScript section that the nonce (88bcc308), amount (204e), as well as the public key hashes for the arbiter (0048...b033), buyer and seller. These are the arguments to our CashScript function, but in reversed order.

Walking through the contract with meep, we can see that there are two OP_HASH160 operations performed and then the contract fails on OP_VERIFY. Looking at the escrow contract, it should be clear that this corresponds to the highlighted line in the spend function, where the contract requires that either the arbiterPkh or buyerPkh match the signingPkh provided.


pragma cashscript ^0.6.1;
contract escrow(bytes20 sellerPkh, bytes20 buyerPkh, bytes20 arbiterPkh, int contractAmount, int contractNonce) {

    function spend(pubkey signingPk, sig s, int amount, int nonce) {
        require(hash160(signingPk) == arbiterPkh || hash160(signingPk) == buyerPkh);
        require(checkSig(s, signingPk));
        require(amount >= contractAmount);
        require(nonce == contractNonce);
        bytes34 output = new OutputP2PKH(bytes8(amount), sellerPkh);
        require(hash256(output) == tx.hashOutputs);

    function refund(pubkey signingPk, sig s, int amount, int nonce) {
        require(hash160(signingPk) == arbiterPkh||hash160(signingPk) == sellerPkh);
        require(checkSig(s, signingPk));
        require(amount >= contractAmount);
        require(nonce == contractNonce);
        bytes34 output = new OutputP2PKH(bytes8(amount), buyerPkh);
        require(hash256(output) == tx.hashOutputs);

The above process can be repeated to trace back which particular step the contract was rejected on, and what the state of the stack was when that rejection occurred.

To examine the execution of a transaction that would succeed, we can call a the escrow function with getHexOnly set to true:

await escrow.call(buyer.privateKeyWif, "spend", undefined, true);

This will return the hex of the transaction with the buyer spending the funds.

  "hex": "020000000191eb6277d54c659a5683822667a2e7cc0b23140e993af8c6e999348e15b3e4cc00000000fdcf020437dd393402214e41863b47e9de111d43b48c4dc4f7d87fa8c07daab8cf3ee45753a1eba31d71933c2088f1716c8f9b1b0f3f123137c656d55bf5721af754dd418b063d3fb267c3f4412103a7ca01e2f5eaaa30e36d2d6687a88dae3cb4531ec6573f2793bcf37d1cb200e34d7d0102000000af4e505b95af3b69f119865b3e1f81bad1ba191e4adc2c61bd5fa450359eda9618606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe19891eb6277d54c659a5683822667a2e7cc0b23140e993af8c6e999348e15b3e4cc00000000e00437dd393402204e149592c19950bf410418469916583e3b99ec74ab0314b7cada9cde2ace5cc17dca136fc2ba7c9d58d1de141136f7ac42b3d65345906b2228d5644f0f1c7c3b5579009c635679820128947f7701207f755879a9547a875879a9547a879b69577a577a6e7c828c7f75597aa87bbbad5579537aa269557a537a9d537a5880041976a9147e7b7e0288ac7eaa877767557a519d5579820128947f7701207f755779a9547a875779a9537a879b69567a567a6e7c828c7f75587aa87bbbad5479537aa269547a537a9d7b5880041976a9147e7b7e0288ac7eaa87686551000000000000feffffff947dfa2869621f5af52e85b6c88641f864c9e36791808a8db94b6491f0dc443f8502000041000000004ce00437dd393402204e149592c19950bf410418469916583e3b99ec74ab0314b7cada9cde2ace5cc17dca136fc2ba7c9d58d1de141136f7ac42b3d65345906b2228d5644f0f1c7c3b5579009c635679820128947f7701207f755879a9547a875879a9547a879b69577a577a6e7c828c7f75597aa87bbbad5579537aa269557a537a9d537a5880041976a9147e7b7e0288ac7eaa877767557a519d5579820128947f7701207f755779a9547a875779a9537a879b69567a567a6e7c828c7f75587aa87bbbad5479537aa269547a537a9d7b5880041976a9147e7b7e0288ac7eaa8768feffffff01214e0000000000001976a9141136f7ac42b3d65345906b2228d5644f0f1c7c3b88ac85020000"

This can be passed to meep to see how the Bitcoin Script would be executed.

meep debug --tx=020000000191eb6277d54c659a5683822667a2e7cc0b23140e993af8c6e999348e15b3e4cc00000000fdcf020437dd393402214e41863b47e9de111d43b48c4dc4f7d87fa8c07daab8cf3ee45753a1eba31d71933c2088f1716c8f9b1b0f3f123137c656d55bf5721af754dd418b063d3fb267c3f4412103a7ca01e2f5eaaa30e36d2d6687a88dae3cb4531ec6573f2793bcf37d1cb200e34d7d0102000000af4e505b95af3b69f119865b3e1f81bad1ba191e4adc2c61bd5fa450359eda9618606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe19891eb6277d54c659a5683822667a2e7cc0b23140e993af8c6e999348e15b3e4cc00000000e00437dd393402204e149592c19950bf410418469916583e3b99ec74ab0314b7cada9cde2ace5cc17dca136fc2ba7c9d58d1de141136f7ac42b3d65345906b2228d5644f0f1c7c3b5579009c635679820128947f7701207f755879a9547a875879a9547a879b69577a577a6e7c828c7f75597aa87bbbad5579537aa269557a537a9d537a5880041976a9147e7b7e0288ac7eaa877767557a519d5579820128947f7701207f755779a9547a875779a9537a879b69567a567a6e7c828c7f75587aa87bbbad5479537aa269547a537a9d7b5880041976a9147e7b7e0288ac7eaa87686551000000000000feffffff947dfa2869621f5af52e85b6c88641f864c9e36791808a8db94b6491f0dc443f8502000041000000004ce00437dd393402204e149592c19950bf410418469916583e3b99ec74ab0314b7cada9cde2ace5cc17dca136fc2ba7c9d58d1de141136f7ac42b3d65345906b2228d5644f0f1c7c3b5579009c635679820128947f7701207f755879a9547a875879a9547a879b69577a577a6e7c828c7f75597aa87bbbad5579537aa269557a537a9d537a5880041976a9147e7b7e0288ac7eaa877767557a519d5579820128947f7701207f755779a9547a875779a9537a879b69567a567a6e7c828c7f75587aa87bbbad5479537aa269547a537a9d7b5880041976a9147e7b7e0288ac7eaa8768feffffff01214e0000000000001976a9141136f7ac42b3d65345906b2228d5644f0f1c7c3b88ac85020000 --idx=0 --amt=20837 --pkscript=a91430392b5580c38e409fec5810045d59a62531ef2f87

Passing the hex with appropriate arguments will show the execution stack for your Bitcoin Script at each stage, using the above command, it should finish without error.

# Utilities

# Decoding transactions

You can decode a transaction by its hash (if it already exists on the blockchain) or full raw contents in hex format using the following snippet:

  const decoded = await Wallet.util.decodeTransaction("36a3692a41a8ac60b73f7f41ee23f5c917413e5b2fad9e44b34865bd0d601a3d", true);

The returned object is compatible with this specification (opens new window) with extra information about input values and cash addresses if loadInputValues parameter is specified and set to true.

# Currency conversions

Need to find out how many BCH are there currently in 1 USD, or find out how many satoshis are there in 100 USD? Easy!

await convert(100, "usd", "sat")
// 28067024

# Signed Messages

One of the perks of having a wallet is the ability to sign message text or verify the signatures of other parties using their public key.

Full-nodes and SPV wallets often include this feature as standard.

# Signing a message with a wallet

Let's try signing with an example from a common test case:

message = "Chancellor on brink of second bailout for banks"
francisWallet = await Wallet.fromWIF(

// "bitcoincash:qqehccy89v7ftlfgr9v0zvhjzyy7eatdkqt05lt3nw"

signature = (await francisWallet.sign(message)).signature;
// H/9jMOnj4MFbH3d7t4yCQ9i7DgZU/VZ278w3+ySv2F4yIsdqjsc5ng3kmN8OZAThgyfCZOQxZCWza9V5XzlVY0Y=

// or 

sigResult = await francisWallet.sign(message);

Where the full sigResult result is:

  "raw": {
    "ecdsa": "/2Mw6ePgwVsfd3u3jIJD2LsOBlT9VnbvzDf7JK/YXjIix2qOxzmeDeSY3w5kBOGDJ8Jk5DFkJbNr1XlfOVVjRg==",
    "schnorr": "rSeWfhxN6tI+3hNQpHwU6E+pZC34rk6gR/h8hqxS0YjUd6mxsOd4OCmMkGJXsqNvVZ1F/Fs/Y81dyzSDBhxp9w==",
    "der": "MEUCIQD/YzDp4+DBWx93e7eMgkPYuw4GVP1Wdu/MN/skr9heMgIgIsdqjsc5ng3kmN8OZAThgyfCZOQxZCWza9V5XzlVY0Y="
  "details": {
    "recoveryId": 0,
    "compressed": true,
    "messageHash": "gE9BDBFAOqW+yoOzABjnM+LQRWHd4dvUVrsTR+sIWsU="
  "signature": "H/9jMOnj4MFbH3d7t4yCQ9i7DgZU/VZ278w3+ySv2F4yIsdqjsc5ng3kmN8OZAThgyfCZOQxZCWza9V5XzlVY0Y="

Please be aware

The above contains both ECDSA and Schnorr signatures. If they had been created using the same random nonce, an attacker could derive the private key. To avoid this risk, the underlying library (libauth (opens new window)) uses nonces for Schorr signatures with the additional data field set to Schnorr+SHA256. Such measures are an important security requirement for any financial software producing both types of signatures.

For most cases, the relevant information here is the "signature" field, which can be used in an SPV wallet such as electron cash or with bitcoin.com's verify tool (opens new window). The following signature will validate as belonging to Francis' address:

Bitcoin Address: bitcoincash:qqehccy89v7ftlfgr9v0zvhjzyy7eatdkqt05lt3nw

Message: Chancellor on brink of second bailout for banks

Signature: H/9jMOnj4MFbH3d7t4yCQ9i7DgZU/VZ278w3+ySv2F4yIsdqjsc5ng3kmN8OZAThgyfCZOQxZCWza9V5XzlVY0Y=

It should also be noted that the signature is "recoverable", meaning the publicKey can be derived from it and the message. This is important when validating against a cashaddr, because only a publicKeyHash can be derived from a cashaddr.

If one of the "raw" signatures are used instead, the publicKey may have to be passed manually.

# Verifying a message with a wallet

To verify the above signature (without having access to the private key), by using a watchOnly wallet to represent the party in the example above.

francisPublic = await Wallet.watchOnly("bitcoincash:qqehccy89v7ftlfgr9v0zvhjzyy7eatdkqt05lt3nw")

message = "Chancellor on brink of second bailout for banks"
sig = "H/9jMOnj4MFbH3d7t4yCQ9i7DgZU/VZ278w3+ySv2F4yIsdqjsc5ng3kmN8OZAThgyfCZOQxZCWza9V5XzlVY0Y="

verifyResult = await francisPublic.verify(message, sig);

where verifyResult is

  "valid": true,
  "details": {
    "signatureValid": true,
    "signatureType": "recoverable",
    "messageHash": "gE9BDBFAOqW+yoOzABjnM+LQRWHd4dvUVrsTR+sIWsU=",
    "publicKeyHashMatch": true

In the default case, with a "signatureType" of "recoverable", the cashaddr publicKeyHash has been checked against the hashed publicKey, which is recovered from the provided message and signature.

Under the hood, all signature types, the message is serialized or formatted in four parts before hashing:

\x18                       // 1) length the prefix
Bitcoin Signed Message:\n  // 2) A prefix w/newline
<\x???>                    // 3) length of the message
<message>                  // 4) the message string as utf8 encoded binary 

The above message formatting is typically handled automatically by the signing software (i.e. wallet.sign(...)), and the messageHash is the double sha256 of the above as binary. For verification, only if the signature itself is valid and the recovered publicKey is valid for the provided cashaddr will the response have "valid":true, and the additional details given may be safely ignored in most cases.

# RegTest wallets

During the local development and testing, you might not want to use TestNet coins, so you can use so-called "RegTest wallets".

What is RegTest?

Regression testing is the practice of testing software after a change to ensure previous code still works. Bitcoin full node software can be started in RegTest mode, which you can use to run your Bitcoin Cash node locally, and you can get as many test coins as you need, but they exist on your machine only. RegTest wallets are supported by the mainnet library.

A full Bitcoin node, an Electrum server and open Postgres server configuration is available for testing in a Docker Compose file at jest/regtest-docker-compose.yml

It can be brought up with:

yarn regtest:up

To stop it:

yarn regtest:down

The Electrum server (Fulcrum) is available at ws:// on your local machine.
The regtest BCHN node is on port 18443 available with RPC using credentials in .env.regtest. An open Postgres server is also available on port 15432

A wallet is configured with the rewards from the first 215 blocks of the regtest network, you can get an instance of the wallet with this code:

# WebSockets

We provide some functionality over websockets where traditional REST servers would timeout. Examples are waiting for transactions and watching balances . Websockets allow to subscribe to server events, sending responses and notifications asynchronously.

Check out the jsfiddle demo (opens new window)

Websockets are supported by all major browsers and using them is easy, no external libraries are needed:

let socket = new WebSocket("wss://rest-unstable.mainnet.cash/api/v1/wallet");
socket.onopen = (event) => {
  const request = {method: "watchBalance", data: {cashaddr: address}};

socket.onmessage = (event) => {
  const balance = JSON.parse(event.data);
  // do something

The output of this code snippet will look like this:

  bch: 0.00009383,
  sat: 9383,
  usd: 0.029358468699999998

See websocket API reference

# Changing Electrum Servers

By default, creating a new wallet will use a common connection to a single server communicating with the electrum cash protocol (opens new window).

These connections are stored on globalThis under a variable matching ticker for the network (BCH, tBCH, rBCH).

If you need to create a new connection manually, it can be done by passing the network and servers, where servers is either a single url or an array of urls.

let conn = new Connection(
await conn.networkProvider.getBlockHeight()
// 669347

This connection can be used to replace the common provider on globalThis.BCH or assigned to a particular wallet by overwriting the provider object of the wallet:

globalThis.BCH = conn.networkProvider;
// or
wallet.provider = conn.networkProvider;