Refund user on ZetaChain when a CCTX is aborted

[lumtis]

We currently have this logic when ERC20 cctx can't be reverted (because of non-existing pool for getting gas):
https://github.com/zeta-chain/node/blob/develop/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L182

This logic could be generalized for all CCTX types (where the sender address can be compatible) in the idea where we consider that a aborted CCTX is "stuck" on ZetaChain with an amount that can't be recovered.

[brewmaster012]

one idea is to introduce a "stuck" terminal state of CCTX,
and deposit user fund into ZRC20 instead (credit context.origin). (this only works for EVM chains, need to think about BTC case)
They can claim refund by going to zetachain ZRC20 contract for withdraw.

[lumtis]

one idea is to introduce a "stuck" terminal state of CCTX, and deposit user fund into ZRC20 instead (credit context.origin). (this only works for EVM chains, need to think about BTC case) They can claim refund by going to zetachain ZRC20 contract for withdraw.

What would be the difference between stuck and the aborted status we currently have?

[lukema95]

We currently have this logic when ERC20 cctx can't be reverted (because of non-existing pool for getting gas): https://github.com/zeta-chain/node/blob/develop/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L182

This logic could be generalized for all CCTX types (where the sender address can be compatible) in the idea where we consider that a aborted CCTX is "stuck" on ZetaChain with an amount that can't be recovered.

Is the link of codes changed? Do you mean the codes below?
https://github.com/zeta-chain/node/blob/6567637545769a01a8406fd8fc9ad4427b7cb725/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L193-#L200

[lukema95]

one idea is to introduce a "stuck" terminal state of CCTX, and deposit user fund into ZRC20 instead (credit context.origin). (this only works for EVM chains, need to think about BTC case) They can claim refund by going to zetachain ZRC20 contract for withdraw.

What would be the difference between stuck and the aborted status we currently have?

Can we think that abort means that the transaction handled the exception normally, for example, the transaction failed but the refund operation was performed correctly, while stuck means that the transaction failed to handle the exception correctly, for example, the refund failed to the user, resulting in The refund steps are not completed.

[lumtis]

As discussed: let's work on a MsgRefundAbortedCCTX message @kingpinXD

[kingpinXD]

@lumtis @brewmaster012
Decided to replace Aborted with two states Aborted_Refundable and Aborted_Non_Refundable . The MsgRefundAbortedCCTX can only refund the Aborted_Refundable states.

We now need to differentiate between which one we can refund and which we cant

Here is a draft list of refundable abort

• InBoundTX EVM deposit and coin type ZETA
• InBoundTX Crosschain Swap returns error in PayGasAndUpdateCctx or UpdateNonce ( Internal error )
• OutBountTX Revert Failed
• OutBoundTX Error during processing Internal error

Adding a list of scenarios in which the CCTX can get into a aborted state , so that it would be easier to review my statement above

• AbortStuckCCTX Msg called by an admin.
• Inbound TX
  • EVM deposit,
    • Internal error,
    • The contract call was reverted, and the sender chain was unable to be fetched.
    • Contract call reverted, unable to fetch senderChain gas limit.
    • Unable to set revert CCTX, ( tries to refund on zeta chain if coin type is ERC20 )
  • Crosschain swap returns error in PayGasAndUpdateCctx or UpdateNonce ( Internal error )
• Outbound Tx
  • Coin type CMD
  • The sender chain is zeta chain
  • Revert Failed
  • Error during processing Internal error

[lumtis]

Is there a single scenario where an aborted CCTX could not be refundable? I would prefer to keep it simple at first