hirosystems
Ordinals-aware UTXO endpoint
The Hiro Wallet needs the UTXOs of a given address, in addition to its inscriptions. I imagine many other apps dealing with inscriptions might also need to work with the corresponding UTXOs.
Currently, or our use case, we need to recurse a given wallet's address indexes, and for each address, check its UTXOs and its inscriptions. One API to get the UTXOs, and another for inscriptions.
The one-to-many relationship between UTXOs and inscriptions, and the way the available APIs right now return this data, require us to make separate requests.
The problems being:
- UTXO endpoints aren't Ordinals-aware
- Inscription endpoints don't show UTXO data for those that aren't inscribed
The ideal API for us would, for a given address (or set of addresses), return the UTXOs and their inscriptions.
{
"limit": 20,
"offset": 0,
"total": 5276440,
"results": [
{
"txid": "31d19182ffa67ee3290fc4c3ae6aafd96278e23bf76fc76f89186e0b62ea8bdd",
"vout": 0,
"value": 10000,
"inscriptions": [
{
"offset": 0,
"sat_ordinal": "378120471756144",
"sat_rarity": "common"
// ...
},
{
"offset": 5000,
"sat_ordinal": "378120471761144",
"sat_rarity": "common"
// ...
},
]
},
{
"txid": "...",
// UTXO has no inscriptions
"inscriptions": []
// ...
}
]
}
As an API consumer, this then makes it trivial to:
- Filter the array for all spendable, uninscribed UTXOs
- Flat map to an array of all inscriptions
cc/ @alter-eggo
@kyranjamie just to see if I understand correctly: the proposed new endpoint would return a list of inscribed UTXOs each with an array of inscriptions? Or do you need a list of all UTXOs for an address (inscribed and uninscribed)?
We could give you the former but not the latter because we currently only index UTXOs that have inscriptions within them.
After a second read, I think you mean the latter. This would need us to modify the chainhooks indexing and I'm not sure if that's feasible at this time cc @lgalabru
Yeah the latter, ideally all UTXOs. Inscriptions can essentially be seen as metadata of a UTXO. Right now it's difficult for a wallet to get the data it needs, and requires fetching all the data in isolation, when it's very closely related.
I think this is typically the kind of endpoint (probably priority 1) that we should have in our incoming (?) bitcoin api. The design of the ordinals api is centered around inscriptions, not utxos. If my understanding is correct, you're asking for an api centered around users / addresses (that we could definitely sprinkle with ordinals dust) where the scaling challenge is pretty different. TLDR: Let's do it, but in another service?
