Feat: Implement fee mechanism for IBC transfer in Cronos

[thomas-nguy]

In order to bridge with cosmos tokens, we need to implement a fee mechanism to cover relayer cost

ICS29 in ibc-go might help with it is still WIP
#234

Another solution is to implement a fee deduction mechanism in cronos

• For Crypto.org Chain -> Cronos

The fee can be deducted after ibc-transfer by adding fee deduction logic in ibc-hooks

• For Cronos -> Crypto.org Chain

The fee can be deducted before ibc-transfer in evm-hooks during a "__CronosSendToIbc" event hook before sending back to IBC coins to the user

Fees are sent to a community account and redistributed to the validators

The fee deducted can be a fixed percentage of the transferable token define in genesis with a max cap [TBD]
Few options for the fee strategy

• option 1: fix value per tokens
• option 2: global percentage of the transferred token
• option 3: percentage of the transferred token with cap

[calvinaco]

Here I try to summarize some discussions I have with @thomas-nguy offline and at the end propose two solutions: one solution is based on @thomas-nguy solution above and I try to add concrete details, another solution is an attempt for a generic solution.

To get started with, there are a few common questions that needs to be addressed and my opinion with the current suggestions.

Issues to be addressed

Issue 1: Bridge fee receiver

Which address should receive the bridge fee charged?

1. fee_collector module account

Fees go to fee_collector module account and at the end of each block these fees go to the validators as part of the transaction fee. This based on the fact that the major relayer operator is also running validator on Cronos right now.

But this assumption is weak because there is no absolute relationship between validator and relayer. Validators already receive their shares of the transaction fees from processing IBC messages MsgTransfer MsgAcknowledgement MsgTimeout MsgUpdateClient etc, so sending fee to fee_collector does not guarantee relayer are compensated.

2. community_pool module account

Fees go to community_pool module account and relayer operators can submit CommunityPoolaSpend proposal (Ref) to claim for the relayer operational cost from the pool.

Each relayer operator can claim the IBC transfer they have relayed and the relayer should also provide the proves to help validators to confirm relayer are claiming what they deserve. One difficulty arose when there are multiple relayers running, there will be cases where the same transfer is relayed by both relayers, or relayer A forwards the MsgRecv, but relayer B forwards the MsgAcknowledgement back. In such case my opinion is we send the fee to the relayer which facilitates the actual funds movement (i.e. MsgRecv and MsgTimeout) because these are the more important messages.

3. Address specified by client (Bridge App/UI)

Allow user to specify the bridge fee receiver. Changes to the bridge UI and Cronos smart contract event hook is needed.

Issue 2: Who can update the bridge fee?

• Governance proposal
• Cronos admin address
• Relayer software

Issue 3: How should bridge fee be charged

• Fixed per channel
• Global percentage of the transferred token (with/o cap)

Issue 4: Should the bridge fee be charged in CRO or transferred token?

Charged in CRO is not feasible because the sender may not always have CRO, e.g. Source chain is non-CRO chain. So transferred token is preferred.

Issue 5: Refund on failure

Should we refund the bridge fee on failures such as timeout? On the relayer perspective it already pay for some fess to send the MsgTimeout and the relayer deserves the compensation, but at the same time this may receive fireback as the transfer does not succeed. An alternative would be to charge in half.

Issue 6: Fee distribution and refund

Instead of distributing the fee upon MsgTransfer, we can put the bridge fee to an escrow account (module account) managed by the cronos module. That way it offers extra flexibility on fee distribution and refund.

The IBC hook could wait until receiving MsgAcknoledgement and MsgTimeout before deciding it. This is particularly useful if want to pay the relayer the full bridge fee upon successful transfer but refund in full/half to sender if it's timeout.

Desired Properties

Before going to the solution, here are a list of desired properties I could think of:

• Required changes to Cronos and relayer software only.
• Controllable bridge fee to reflect token price changes
• Do no block future migration to ICS-029. As long as the existing fee solution and ICS-029 can be run in parallel, then bridge UI provider can choose to migrate to ICS-029 at their own pace.
• Simple to implement. Given ICS-029 is the long term solution, the fee solution maybe better deemed as an intermediate solution and we should avoid making it too complicated.

Solution 1: On-chain bridge fee logic

Overview

In this solution the bridge fee logic is fully implemented on chain, IBC MsgTransfer sender are charged with a fee of the transferred token and the fee goes to a designated account. The charged fee and bridge fee receiver are controlled by on-chain governance or the Cronos admin account.

Issues to be addressed

Most of the above issues to be address are valid for this solution and has to be decided.

Client and Relayer changes

To complete this solution, the client and relayer have to enforce a minimum token amount allowed. Otherwise it opens an attack vector to send a very small amount of token that doesn't even pay for the fee.

Solution 2: Enhanced client + relayer

Overview

In this solution client is responsible to enforce the bridge fee charged to user. If it is transfer to Cronos, it can be in the form of an extra MsgSend to the relayer operator. If it is transfer from Cronos, it can be invoking a new smart contract methods to specify the fee the user is willing to pay. This solution also relies on the relayer software to reject transaction which does not pay enough fee. Hence the fee logic is implemented on client (Bridge UI provider) and relayer software.

Issues to be addressed

Issue 2 onwards of the above issues to be address are valid for this solution and has to be decided.

CRC20 Contract Updates

This is an imaginary new method and its signature (code is not meant to be syntactically correct) that illustrate the changes.

    function send_to_ibc_with_fee(string memory recipient, uint amount, string fee_recipient, uint fee) public {
        unsafe_burn(msg.sender, amount + fee);
        emit __CronosSendToIbc(msg.sender, recipient, amount);
        emit __CronosSendToIbcFee(msg.sender, fee_recipient, fee);
    }