API returns provenance owner, not current owner

[diwakergupta]

Relaying from a builder:

address field is showing the provenance/genesis address and not the current owner
https://api.hiro.so/ordinals/v1/inscriptions/3091c2a50590892f2cf65a37d5eba652949e046c23c80af2ec910fb80615bf37i0

observed: bc1pva89n5e9ekae5v5l89enmcp78elzhuqrcef8f6wrlsgf4qe7ptdsx4cfme
expected: bc1ppltka86dpzdkw2w3k4pnxcce9h7jxlv6l9zgae57hmvuhmx5mfaqns58kc

[rafaelcr]

Thanks @diwakergupta . This is a known issue that will be solved very soon

[0xWhiteleaf]

@rafaelcr Thanks for this API, really useful 👍
Could you close this issue when the problem is solved, so we can test again?

[Jamil]

Just wanted to see if there was any update here :)

Also, curious what the address field shows when a tx spending the UTXO is in the mempool — ideally it doesn’t “disappear”. We have some problems with other Ordinals APIs in that case.

[rafaelcr]

Still working on this @Jamil , we'll hopefully have a solution very soon

Also, curious what the address field shows when a tx spending the UTXO is in the mempool — ideally it doesn’t “disappear”.

Our current design will make sure we only update an inscription location (and owner) when the transaction is mined in a block, so you won't have this problem

[markmhendrickson]

Just adding a note here that we're ready to integrate this API into Hiro Wallet, though this appears to be the main blocker.

[0xWhiteleaf]

I want to add that this is also the case for the location, output and value fields. I'm adding this here because I think it's related.

https://api.hiro.so/ordinals/v1/inscriptions/127fe2d8da299f2b7a4dfcc3c9433b5d2a78b41aebdf42b3c58ea5678e9f3eeci0

Observed:
"location": "127fe2d8da299f2b7a4dfcc3c9433b5d2a78b41aebdf42b3c58ea5678e9f3eec:0:0", "output": "127fe2d8da299f2b7a4dfcc3c9433b5d2a78b41aebdf42b3c58ea5678e9f3eec:0", "value": "10000",

Expected:
"location": "1d4101d775fd7004e34f47acb8e9a1465fd098d18e3856cceccead6016a8f449:0:0", "output": "1d4101d775fd7004e34f47acb8e9a1465fd098d18e3856cceccead6016a8f449:0", "value": "7225",

Maybe the offset field is also concerned but not for this inscription.
Thanks

[IM-Apple]

How to add logo to BRC-20 token?

[diegoxter]

Hello!

I'm interested in this functionality, it would open some interesting possibilities with ordinal interactions

[smcclellan]

We are waiting on an indexing to finish, then index the API, then deploy new version to production to complete.

[markmhendrickson]

@smcclellan Has this new version been deployed by now? 🙏

[kitdesai]

Any update here?

[lgalabru]

Hey there! quick update on this.
When we started the API, we extracted some the indexing logic from ord and dropped it into our indexing engine - Chainhook.
We shipped our first version of the API with this approach, and started working on our own implementation of the ordinal theory, that would address some caveat that we identified in ord - biggest issue being that the index produced by ord ends up being corrupted as soon as a reorg is detected.
We finally got our new version deployed, and it is now powering the ordinals API (transition was made over the weekend).
We spent a lot of time comparing the data from ord and hord, and we're observing a complete convergence on inscriptions numbers and ordinals numbers - quite exciting.

There is a big new feature, with this new version: tracking of inscription transfers, you can now track all the transfers for a given inscription, using the endpoint:
https://api.hiro.so/ordinals/v1/inscriptions/<id>/transfers (will be part of the documentation once stabilized)

The list of transfers returned by the API look currently incomplete, and I'm in the process of retracing transfers and identifying deltas.
I will update here when the list of transfers per inscription is exhaustive.

[markmhendrickson]

@lgalabru any updates here by chance? 🙏

[lgalabru]

Our DB should be ready tomorrow by EOD 🤞🏻

[jack-linden]

Hi @lgalabru

I'm not sure if this is related and/or will be accounted for in your latest sweep but it also looks like the "address" field is inaccurate for inscriptions which transferred during marketplace purchases.

https://api.hiro.so/ordinals/v1/inscriptions/82fd4462f1bd6570eaeba9daf0e45a6b95641e423b00154eb03089da6e7140fci0

Expected: bc1p3gcq2cld5vpfp9p6299efatfaj9fr64ggf7z4527tv7gxw0pqc3qpvw699
Observed: 3GoD1CLdezMkRco6jjNcNWjF5RDHmRh4Xf

Interestingly, 3GoD1CLdezMkRco6jjNcNWjF5RDHmRh4Xf is the cardinal address which paid for the marketplace purchase (https://mempool.space/tx/140f2ea99d226ca11cc5105ba38b3d4be21e1fcab32c521b55addb2980bfffdc).

[lgalabru]

hey @jack-linden! this is related yes. hopefully fixed soon, but looking at the indexing pace, we might need an additional day.

[janniks]

Explorer now shows owned by and inscribed by ✅

[markmhendrickson]

We've integrated the API here and are prepared to release: leather-io/extension#3654

@lgalabru is indexing 100% complete? 🙏

[lgalabru]

The traffic is now being routed to the new API. I've made a bunch of checks but certainly not 5M, so if you see something, feel free to reopen this issue and say something!

And enjoy our new, unique Transfers API endpoint - courtesy of @rafaelcr 🚀

cc @jack-linden @markmhx @kitdesai @diegoxter @IM-Apple @0xWhiteleaf @Jamil

[captain-munch]

this is awesome news, great work to everyone involved 🚀