This repo has been moved to https://github.com/osmosis-labs/fee-abstraction
The concrete use cases which motivated this module include:
- The desire to use IBC token as transaction fees on any chain instead of having to use native token as fee.
- To fully take advantage of the newly represented Osmosis
swap router
with theibc-hooks
module and theasync-icq
module.
Fee abstraction modules enable users on any Cosmos chain with IBC connections to pay fee using ibc token.
Fee-abs implementation:
- Fee-abs module imported to the customer chain.
The implememtation also uses Osmosis swap router and async-icq module which are already deployed on Osmosis testnet.
Fee-abs mechanism in a nutshell:
- Pulling
twap data
and update exchange rate:
- Periodically pulling
twap data
from osmosis by ibc-ing toasync-icq
module on Osmosis, thistwap data
will update the exchange rate of osmosis to customer chain's native token.
- Handling txs with ibc-token fee:
- The exchange rate is used to calculate the amount of ibc-token needed for tx fee allowing users to pay ibc-token for tx fee instead of chain's native token.
- Swap accumulated ibc-token fee:
- The collected ibc-token users use for tx fee is periodically swaped back to customer chain's native token using osmosis.
We'll goes into all the details now:
For this to work, we first has to set up an ibc channel from feeabs
to async-icq
. This channel set-up process can be done by anyone, just like setting up an ibc transfer channel. Once that ibc channel is there, we'll use that channel to ibc-query Twap data. Let's call this the querying channel.
The process of pulling Twap data and update exchange rate :
Description :
For every update exchange rate period
, at fee-abs BeginBlocker()
we submit a InterchainQueryPacketData
which wrapped QueryArithmeticTwapToNowRequest
to the querying channel on the customer chain's end. Then relayers will submit MsgReceivePacket
so that our QueryTwapPacket
which will be routed to async-icq
module to be processed. async-icq
module then unpack InterchainQueryPacketData
and send query to TWAP module. The correspone response will be wrapped in the ibc acknowledgement. Relayers then submit MsgAcknowledgement
to the customer chain so that the ibc acknowledgement is routed to fee-abs to be processed. Fee-abs then update exchange rate according to the Twap wrapped in the ibc acknowledgement.
We modified MempoolFeeDecorator
so that it can handle ibc-token as fee. If the tx has ibc-token fee, the AnteHandler will first check if that token is allowed (which is setup by Gov) we basically replace the amount of ibc-token with the equivalent native-token amount which is calculated by exchange rate
* ibc-token amount
.
We have an account to manage the ibc-token user used to pay for tx fee. The collected ibc-token fee is sent to that account instead of community pool account.
Fee-abstraction will use osmosis's Cross chain Swap (XCS) feature to do this. We basically ibc transfer to the osmosis crosschain swap contract with custom memo to swap the osmosis fee back to customer chain's native-token and ibc transfer back to the customer chain.
- Create a ibc transfer message with a specific MEMO to work with ibc
packet-forward-middleware
which is path-unwinding (an ibc feature that allow to automatic define the path and ibc transfer multiple hop follow the defined path) - Ibc transfer the created packet to get the fee Ibc-token on Osmosis
Ex: When you sent STARS on Hub to Osmosis, you will get Osmosis(Hub(STARS)) which is different with STARS on Osmosis Osmosis(STARS). It will reverse back Osmosis(Hub(STARS)) to Osmosis(STARS):
After reverse the ibc-token, XCS will :
- Swap with the specific pool (which is defined in the transfer packet from Feeabs-chain) to get Feeabs-chain native-token
- Transfer back Feeabs-chain native-token to Feeabs module account (will use to pay fee for other transaction)
Current version of fee-abstraction working with XCSv2