Dual Queue PoC

[bonedaddy]

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

• 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

/home/solidity/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-json-wasm-0.4.1/src/ser/mod.rs:403:9:
internal error: entered unreachable code