> ## Documentation Index
> Fetch the complete documentation index at: https://docs.utexo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# General Overview

RGB Node is a self-hosted REST service for applications that need on-chain RGB functionality without embedding the full RGB protocol stack. It manages watch-only wallets, exposes wallet and asset operations, and never holds private keys or signs transactions.

<Info>
  Source repository: [`UTEXO-Protocol/rgb-node-api`](https://github.com/UTEXO-Protocol/rgb-node-api).
</Info>

<Warning>
  RGB Node supports NIA (Non-Inflatable Asset) issuance only. For CFA or UDA assets, use the [RGB Lightning Node](/cloud/rgb-lightning-node-api).
</Warning>

## Who should use RGB Node

* **Backend operators** can integrate RGB Node into exchange, settlement, or custody infrastructure that needs watch-only RGB wallet access.
* **Wallet and client applications** should normally integrate through the [Utexo SDK](/product-suite/sdk). The SDK exposes the same core RGB functionality without requiring the application team to operate node infrastructure directly.

RGB Node does not provide Lightning channels or Lightning payments. Use RGB Lightning Node when those capabilities are required.

## What RGB Node provides

| Capability             | Description                                                                              |
| ---------------------- | ---------------------------------------------------------------------------------------- |
| Watch-only wallets     | Register wallet contexts using vanilla and colored xPubs plus a BIP32 master fingerprint |
| Asset issuance         | Issue NIA assets on Bitcoin L1                                                           |
| Balances and state     | Read BTC balances, RGB assets, UTXOs, transactions, and transfers                        |
| Receive invoices       | Generate blinded RGB receive invoices                                                    |
| UTXO creation          | Build unsigned PSBTs for RGB-capable UTXO creation                                       |
| Asset transfers        | Build unsigned send PSBTs and finalize transfers after client-side signing               |
| Multi-wallet operation | Select an independent wallet context with the three wallet-identification headers        |
| Synchronization        | Refresh wallet state and mark eligible pending transfers as failed                       |

## Architecture: watch-only, external signing

RGB Node keeps the custody boundary on the client side:

1. The client identifies a wallet with `xpub-van`, `xpub-col`, and `master-fingerprint`.
2. `POST /wallet/register` creates or loads the corresponding watch-only wallet context.
3. For UTXO creation or asset sends, a `*begin` endpoint returns an unsigned PSBT.
4. The client signs the PSBT outside RGB Node.
5. The matching `*end` endpoint finalizes the operation with the signed PSBT.

The wallet-identification headers are not credentials. They select wallet state but do not authenticate or authorize the caller.

<Warning>
  Deploy RGB Node only within infrastructure you control. Protect it with TLS and an authentication or private-network layer, and restrict access to xPubs, wallet activity, and UTXO metadata. Do not expose the service directly to untrusted clients.
</Warning>

## External dependencies

An RGB Node deployment requires:

* A Bitcoin RPC endpoint
* An Electrum- or Esplora-compatible indexer
* One or more RGB transport or proxy endpoints
* Persistent storage for watch-only wallet state
* A client-side signer for PSBT operations

The repository includes a local regtest profile and helper commands for starting `bitcoind`, `electrs`, and `rgb-proxy`.

## Underlying library

RGB Node uses Utexo's `rgb-lib` integration for RGB state management and PSBT construction. Most integrators interact with the REST API rather than calling the library directly.

## Next step

Use the [RGB Node API reference](/cloud/rgb-node/api-reference) for configuration, endpoints, request headers, signing flows, and error behavior.