ordinals-api: API returns provenance owner, not current owner

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.

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

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

Our DB should be ready tomorrow by EOD 🤞🏻

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

Explorer now shows owned by and inscribed by ✅

@lgalabru any updates here by chance? 🙏

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

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

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

Any update here?