You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The limit should be same as that of ibc-go. If there is no limit in ibc-go, then we don't need to have a limit either. However, we wanna consider a large limit (days) due to aggregation use case. Same goes for ibc-go
I think it makes sense to have a limit, especially as we move to seconds (and someone might by accident try to use nanoseconds). I think the limit can be relatively high, but should ideally error out if things get too crazy.
I think the limit set previously was 24 hours, I thought this was too high, but I wasn't thinking about aggregation, but assuming we would want to aggregate something like 25 - 30 packets, in the last 24 hours there were 11k+ transfers on cosmos hub, almost 39k on osmosis. I guess some of the smaller chains have 10s to 100s of transfers in 24 hours. I think this is reasonable, and can't imagine smaller chains having their own market maker for fast transfer, and then waiting 24 hours + for your packet to arrive doesn't make sense.
As per #88 (comment) we should have some kind of limit on the timeout.
We need to figure out:
The text was updated successfully, but these errors were encountered: