/utxos endpoint lets you query unspent transaction outputs on the Sundial L2 for any address. The response reflects the current mempool-ledger state — meaning confirmed UTxOs and any unconfirmed outputs from pending mempool transactions are included together. Use this endpoint to source inputs when building L2 transactions before submitting them via POST /submit.
GET /utxos is available on full (monolith) nodes only. It is not served by api-role nodes in horizontally scaled deployments. Direct your UTxO queries to a full-node URL such as https://rpc.testnet.sundialprotocol.com.GET /utxos — Query UTxO Set
Return all spendable unspent transaction outputs locked at a given address on the Sundial L2.Query Parameters
string
required
Bech32 address to query. On testnet, addresses must start with
addr_test1. The address must parse successfully and carry a valid payment credential — script addresses and addresses without payment credentials are rejected.Example
Responses
- Success (200)
- Invalid Address Type (400)
- Invalid Address Format (400)
- General Parse Failure (400)
The response contains a An address with no spendable UTxOs returns an empty array:
utxos array. Each entry carries the raw CBOR hex for the output reference (outref) and the full transaction output (value). Both fields are hex-encoded CBOR — decode them with the Cardano Multiplatform Library (CML) or any compatible library.Decoding UTxO Data
UTxO output references and transaction outputs are returned as CBOR hex strings. To work with them in TypeScript, use the Cardano Multiplatform Library:Using UTxOs to Build Transactions
The standard workflow for building and submitting an L2 transaction is:1
Fetch UTxOs
Call
GET /utxos with the sender’s address to retrieve spendable outputs.2
Select inputs
Choose one or more UTxOs whose combined value covers your output amount plus the minimum fee (
minFeeA: 44, minFeeB: 155381).3
Build the transaction
Use Lucid Evolution with a custom
MidgardNodeProvider that routes getUtxos calls to this endpoint. See the Transactions page for a full provider implementation.4
Sign and submit
Sign the transaction with your private key or a CIP-30 browser wallet, then submit via
POST /submit.Address Validation Rules
The node applies a three-tier validation to theaddress parameter:
Tier 1 — Type check
Tier 1 — Type check
The
address parameter must be a string. Any other type (number, boolean, missing) returns 400 {"error": "Invalid address type: <address>"}.Tier 2 — Bech32 parse and payment credential check
Tier 2 — Bech32 parse and payment credential check
The address must successfully parse through Lucid’s
getAddressDetails and must carry a payment credential. Addresses without a payment credential — such as bare stake addresses — are rejected with 400 {"error": "Invalid address format: <address>"}.Tier 3 — General parse fallback
Tier 3 — General parse fallback
Any remaining parse failure returns
400 {"error": "Invalid address: <address>"}. This covers malformed bech32 strings, incorrect network prefixes, and similar issues.