Rafael Cárdenas

leaving here for reference, [this line](https://github.com/hirosystems/ordhook/blob/main/components/ordhook-core/src/core/protocol/inscription_sequencing.rs#L349-L350) causes the error because some data for this block exists which causes the sequencing code to skip some previously-seen inscriptions

@chresko this could definitely be done, however, we'll need to integrate this third party dependency into our current API indexing flow, i.e. we would not only need to consume events...

thanks @GregorWedlich I'll investigate

@markmhendrickson we are planning on adding the `estimated_balance` key to the balances response, however, we first need to adjust the Etag generation logic a bit to make it be account...

@314159265359879 it's the confirmed balance plus any inbound or outbound STX from unconfirmed transactions in the mempool. We don't go so far as to look into post conditions or contract...

> I think we could join from the fetched inscription to a brc20_event via location Definitely @janniks , I think this is also easy to do... Are you up for...

hi @kobby-pentangeli we're currently working on moving the BRC-20 indexing from the API into Ordhook. With this change, you'll be able to index BRC-20 in ordhook using regtest and then...

After investigating, I've found that this particular query is very slow because it is trying to count results with several filters at the same time which don't fall inside of...

@louisdv7192 can you share your API logs to see if it's receiving block data from ordhook correctly?

From your images, I suspect the API is not reaching ordhook. Make sure `ORDHOOK_NODE_RPC_PORT` matches the open port you have on ordhook (usually should be port 20456)