Adds a POC for implementation of dual queue ibc rate limits, allowing authorized addresses to grant an address the ability to bypass rate limit evaluation up to a specific value.
Specification
An address can be granted the ability to send up to X tokens which bypass rate limit evaluation on a given channel+denom
The queue is single use such that any transfer which triggers a rate limit bypass removes the bypass
The undo_X functionality is a bit tricky to handle with the addition of the bypass queue so this has been omitted for now
Intents allow senders to declare an amount of assets to transfer that will bypass rate limit evaluation after a 24 hour period has elapsed since intent submission. It is a one time bypass and the transfer must send the exact amount of tokens.
Intents can be removed before they are consumed
Intent and Bypass functions are limited to invocation from the ibc or gov modules only
For Osmosis Team
What thresholds should be set for the bypass usage?
Possible Future Improvements
One possible improvement would be to automatically add 24 hour delays to transfers above a certain threshold. When delayed the assets being transferred can be held by the rate limit contract until the delay period is over and the transfer is finalized.
However I don't believe it would be possible to integrate such functionality into the current ibc middleware implementation so it's likely a v2 would need to be written.
Notes
The cosmwasm_storage crate does not seem to support nested map serialization for state key-value entries
Might be worth switching from the current vector which stores rate limit bypass permissions to the dequeue type? See the following error message for the error triggered when attempting to serialize nested maps
Overview
Adds a POC for implementation of dual queue ibc rate limits, allowing authorized addresses to grant an address the ability to bypass rate limit evaluation up to a specific value.
Specification
undo_X
functionality is a bit tricky to handle with the addition of the bypass queue so this has been omitted for nowIntents
allow senders to declare an amount of assets to transfer that will bypass rate limit evaluation after a 24 hour period has elapsed since intent submission. It is a one time bypass and the transfer must send the exact amount of tokens.For Osmosis Team
Possible Future Improvements
One possible improvement would be to automatically add 24 hour delays to transfers above a certain threshold. When delayed the assets being transferred can be held by the rate limit contract until the delay period is over and the transfer is finalized.
However I don't believe it would be possible to integrate such functionality into the current ibc middleware implementation so it's likely a v2 would need to be written.
Notes
cosmwasm_storage
crate does not seem to support nested map serialization for state key-value entriesdequeue
type? See the following error message for the error triggered when attempting to serialize nested maps