Skip to main content

What You Will Build

This guide walks you through the full Utexo SDK integration flow: installing the SDK, generating and initializing a wallet, funding it with testnet BTC, creating UTXOs to anchor RGB state, generating an RGB invoice and completing your first USDT on Bitcoin transfer. By the end of this guide you will have:
  • A working UTEXOWallet instance connected to testnet
  • A funded wallet with UTXOs ready to receive RGB assets
  • Successfully sent and verified a USDT on Bitcoin transfer
Estimated time: 15 minutes, not counting testnet faucet confirmation time (usually 1–5 minutes, but can vary).

How RGB Transfers Work

Before writing any code, it helps to understand the flow:
  1. The receiver generates a blinded invoice tied to one of their UTXOs
  2. The sender calls .send() with that invoice — the RGB state transition is constructed and broadcast
  3. Both wallets call .refreshWallet() to sync the latest on-chain state
  4. The receiver’s balance updates to reflect the new asset allocation
All asset state is validated client-side. Neither party needs to trust a third party — the Bitcoin UTXO provides the settlement anchor.
New to RGB or UTXOs? See the Glossary for definitions, and Architecture for how Bitcoin, Lightning, and RGB fit together.

Prerequisites

Before you start, make sure you have the following:
  • Node.js v18 or laterDownload here
  • A testnet BTC balance for transaction fees. Get testnet BTC from the Utexo Telegram faucet bot @Utexo_RLN_bot — send /getbtc followed by your Bitcoin address.
  • Basic familiarity with async/await JavaScript
This guide uses testnet. Never use mainnet keys or real funds while following this tutorial. Testnet assets have no monetary value.

Network Endpoints (Testnet)

The SDK connects to the following endpoints by default on testnet. No configuration is needed to follow this guide. For mainnet endpoint configuration, see the SDK Reference.

Step 1: Install the SDK

The Utexo SDK is Node.js only and is not browser-compatible. It requires access to the file system and native crypto modules.

Step 2: Generate Wallet Keys

Start by generating a BIP-39 mnemonic. This 12-word seed phrase is the only way to recover your wallet — store it securely before proceeding.
Back up your mnemonic immediately. If you lose it, your wallet and any assets it holds cannot be recovered. Never commit mnemonics to source control.

Step 3: Initialize the Wallet

Create and initialize a UTEXOWallet instance using your mnemonic. Initialization connects to the default RGB transport and Bitcoin indexer endpoints for testnet.
initialize() performs the initial sync with the Bitcoin indexer and RGB transport layer. This may take a few seconds on first run.

Step 4: Get a Deposit Address

Get your wallet’s Bitcoin deposit address. You will use this to receive testnet BTC from the Telegram faucet bot — a small BTC balance is required to pay RGB transaction fees.
Send /getbtc with this address to @Utexo_RLN_bot (see Prerequisites). Wait for at least 1 confirmation before continuing.
You only need a small amount — a few thousand satoshis is enough to cover fees for this tutorial.

Step 5: Create UTXOs

RGB asset state must be anchored to Bitcoin UTXOs. Before you can receive any RGB asset, your wallet needs dedicated UTXOs created for this purpose.
Parameter reference:
refreshWallet() syncs the wallet’s local state with the Bitcoin chain. Always call it after any on-chain operation before querying balances or generating invoices.

Step 6: Get the RGB USDT Asset ID

Before generating an invoice, you need the asset ID of the RGB USDT token on testnet. This ID uniquely identifies the asset contract in the RGB protocol.
If no assets appear, your wallet may not yet have been assigned any RGB assets. You can also obtain the canonical testnet USDT asset ID from the SDK Reference or by asking in the Utexo Discord.

Step 7: Generate an RGB Invoice (Receiver Side)

The receiver generates a blinded invoice to share with the sender. The blinded invoice hides the receiver’s UTXO from the sender while still allowing the transfer to be verified client-side.
Parameter reference:
Invoices expire after durationSeconds. The sender must complete the transfer before the invoice expires, otherwise the sender will need a new invoice.

Step 8: Send an RGB Asset (Sender Side)

The sender uses the invoice from Step 7 to transfer the asset. The sender must already hold a balance of the RGB asset being transferred.
The send() call constructs the RGB state transition, attaches it to a Bitcoin transaction, and broadcasts it. The RGB transport layer (rpcs://) is used to communicate the state transition to the receiver.
The amount and assetId in the send() call must exactly match those in the invoice. Mismatches will cause the transfer to be rejected by the receiver’s client-side validator.

Step 9: Verify the Transfer

After both wallets have called refreshWallet(), check the balances to confirm the transfer completed successfully.
Expected result: the receiver’s asset list shows a balance of 100 for the USDT asset. If the transfer is still pending confirmation, call refreshWallet() again after the next Bitcoin block.
RGB transfers require Bitcoin confirmation to finalize. On testnet, a new block typically arrives every 1–10 minutes.

Troubleshooting

If you encounter an issue not listed here, join the Utexo Discord for community support.

Next Steps

  • SDK Reference — Full method reference for UTEXOWallet, including Lightning channel management
  • Architecture — Understand how Bitcoin, Lightning, and RGB fit together
  • Glossary — Definitions for RGB, PSBT, blinded invoice, UTXO, and other key terms