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 routerwith theibc-hooksmodule.
Fee abstraction modules enable users on any Cosmos chain with IBC connections to pay fee using ibc token.
Fee-abs implementation composes of 2 pieces of software :
- Fee-abs module imported to the customer chain.
- A smart contract for querying TWAP deployed on Osmosis.
Other than those two, the implememtation also uses Osmosis swap router which is already deployed on Osmosis testnet.
Firstly, we narrow the feature of fee-abs from allowing general ibc token as tx fee to allowing only ibc-ed osmosis as tx fee. If thing goes smoothly , we'll work on developing the full feature of fee-abs.
Fee-abs mechanism in a nutshell:
- Pulling
twap dataand update exchange rate:
- Periodically pulling
twap datafrom osmosis by ibc-ing to our osmosis contract, thistwap datawill update the exchange rate of osmosis to customer chain's native token.
- Handling txs with ibc-osmosis fee:
- The exchange rate is used to calculate the amount of ibc-osmosis needed for tx fee allowing users to pay ibc-osmosis for tx fee instead of chain's native token.
- Swap accumulated ibc-osmosis fee:
- The collected ibc-osmosis 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 fee-abs to our osmosis contract. 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 EndBlocker() we submit a query twap packet to the querying channel on the customer chain's end. Then relayers will submit MsgReceivePacket so that our QueryTwapPacket which will be routed to our osmosis contract to be processed. Our osmosis contract then query twap price and put it 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-osmosis as fee. If the tx has osmosis fee, we basically replace the ibc-osmosis amount with the equivalent native-token amount which is calculated by exchange rate * ibc-osmosis amount.
We have an account to manage the ibc-osmosis user used to pay for tx fee. The collected osmosis fee is sent to that account instead of community pool account.
We use osmosis's ibc hook 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.
OsmosisTwapExchangeRate is fetched at the end of every epoch.
The process of pulling Twap data and update exchange rate :
A user can query and interact with the feeabs module using the CLI.
The query commands allow users to query feeabs module state
feeappd query feeabs -h
The host-chain-config command allow users to query host chain config for a given ibc denom.
feeappd query feeabs host-chain-config [ibc-denom] [flags]
The module-balances command allow users to query feeabs module balances.
feeappd query feeabs module-balances [flags]
The osmo-arithmetic-twap command allow users to query Osmosis twap for an ibc denom.
feeappd query feeabs osmo-arithmetic-twap [ibc-denom] [flags]
- Main repo: https://github.com/notional-labs/fee-abstraction
- Contract repo: https://github.com/notional-labs/feeabstraction-contract