It might be worth considering following a similar approach to that taken in the sequencer-relayer for confirm_submission which is essentially doing the same thing, but targeting Celestia rather than a sequencer.

The main differences are:

• it tries forever, hence the function doesn't return a Result
• when the server sends a success response, but indicates the tx hash wasn't found, the retry interval stays at the minimum
• because we can keep retrying fairly frequently, there's a logging strategy to avoid spamming the logs

If you decide to go that way, then bear in mind that the timing consts were chosen for a Celestia block time of 12 seconds, whereas the sequencer block times are closer to 2 seconds I believe.

Thanks for the tip! I changed the logic to reflect the function you sent over. The only differences are:

• used millis instead of secs since the timeframe of this is much shorter
• kept the result return value. If we get a response which has a non-ok error code or doesn't include proof of the tx's inclusion in the block, I think it would probably still be good to throw an error.

It looks like we're always returning Ok, so maybe the return type can be changed to just tendermint_rpc::endpoint::tx::Response?

Should we also have a wrapper function with a timeout, similar to the one you sent? Seems like it may be problematic to introduce code which will try forever unchecked instead of erroring out at some point.