phase 2: auto-trade reward token revenue via routes in params

[ethan-stride]

This PR is the logic for phase 2 of the community pools where foreign ibc denoms can be treated as revenue.

Tech Spec and Diagrams

https://docs.google.com/document/d/1U9ah95DABkg_ofSGgkDnhzr4wyJdHCCBExCKCX-t_WM/edit
https://app.excalidraw.com/l/9UFOCMAZLAI/2ErXWeealJE

Phase 2: Automatically convert revenue of foreign "reward" denom to host denom

There are 4 logical steps kicked off by epochly triggered ICQs:

1. ICQ the reward denom in the withdrawal address on hostZone, transfer all found tokens with unwinding through the reward chain to a trade ICA on the trade chain (Osmosis). ICQ is number 1 in the excalidraw, transfer is number 2.
2. ICQ the reward denom in the trade ICA, callback fires ICA messages to perform a swap to the host chain's denom up to the allowed max swap size. ICQ is number 3 in the excalidraw, swap ICA is number 4.
3. ICQ the host chain denom in the trade ICA, transfer all found tokens back to the withdrawal ICA on the hostZone. ICQ is number 5 in the excalidraw, transfer is number 6.

The first and last ICQs here are done on a stride epoch cadence, because the swap is limited by a max swap size to prevent slippage, the swaps can happen in smaller more frequent triggers so the middle ICQ is done on an hourly cadence.

Also for safety, a min acceptable output amount is computed using the last known swap price. There is an independent hourly ICQ to get this "spot price" for the pool (which is a ratio of input to output denom in that pool) and this value is persisted to the TradeConfig type inside the TradeRoute information on the keeper state. Swaps use whatever value is found (which could be up to 1 hour out of date) when computing the minimum expected output for the swap. If a swap fails, the tokens just remain in the trade ICA and will be attempted again on the next epochly call to the swap action.

There are governance gated transactions to create, delete, and update the TradeRoute data stored on the keeper state. The most common expected use case is to update which pool the TradeRoute uses to do the swap or to change the max swap size.

Testing

bash ./dockernet/tests/run_all_tests.sh
integration_tests.bats
 ✓ [INTEGRATION-BASIC-GAIA] host zones successfully registered
 ✓ [INTEGRATION-BASIC-GAIA] ibc transfer updates all balances
 ✓ [INTEGRATION-BASIC-GAIA] liquid stake mint and transfer
 ✓ [INTEGRATION-BASIC-GAIA] tokens on GAIA were staked
 ✓ [INTEGRATION-BASIC-GAIA] LSM liquid stake
 ✓ [INTEGRATION-BASIC-GAIA] LSM liquid stake with slash query
 ✓ [INTEGRATION-BASIC-GAIA] packet forwarding automatically liquid stakes
 ✓ [INTEGRATION-BASIC-GAIA] redemption works
 ✓ [INTEGRATION-BASIC-GAIA] claimed tokens are properly distributed
 ✓ [INTEGRATION-BASIC-GAIA] rewards are being reinvested, exchange rate updating
 ✓ [INTEGRATION-BASIC-GAIA] rewards are being distributed to stakers

11 tests, 0 failures

[github-actions]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. Thank you!

[sampocs]

open

[sampocs]

Beautifully done once again!!

One larger open question - should we handle the case where the price query fails? Would be a bit messy to keep track of how recent it is, but I'd be worried of the case where we just keeping using a stale value.

Feels like our options are:

• Include no staleness check
• Include a staleness check (would require additional state to track when the price was last updated)
• Update the price to indicate if the query failed (e.g. set it to zero/nil)

[sampocs]

🚢!