Defining new standard for BTC inbound data

[lumtis]

Describe the Issue With inscription support we now have ability to provide inputs up to 4MB in the inbound, this gives flexibility for more complete inbound structure.

This issue is about to define a standard on how to parse the inbound data for a Bitcoin deposit.

Example:

• Explicitly defining if the function is a deposit or depositAndCall
• Explicitly setting the receiver instead of using first x bytes
• Allowing to provide revertOptions, choosing for example the address on ZetaChain that should receive funds in case of cctx abort

[fadeev]

I propose we use ABI. This way we'll have the exact same code in a universal contract decoding messages from all connected chains. We use ABI as standard on EVM, we can use ABI on Solana and we can now use ABI with Bitcoin as well.

[lumtis]

For Solana we are splitting the memo to represent receiver and message separately but the idea of using a standard among all chains adapted to EVM is interesting

[bitSmiley]

Hi all, just from testing inscription based memo on testnet sharing a few thoughts here.

This feature is quite critical for inscription based memo, because(long story short) inscription happens in two btc transactions, the current revert txn will send funds back to the "tapscript" address instead of the correct sender. Funds are difficult to retrieve. I think this might happen, probably more edge cases, to OP_RETURN as well because there could be multiple inputs to the funding transaction, currently only the first one is picked as revert address.

One way we were thinking to get around is in our zeta connector contract, it never reverts. We track the error with target revert BTC address embedded in the inscription and performs batch refund. But of course the protocol can handle it would be even better.

From trying and testing BTC inscription, kind of feel it's ok to introduce some kind of envelop to memo, such as prepending:

[Envelop][Memo]

Actually the current structure of memo has the above, such as [address][calldata]. At least for inscription based envelop, the following envelop mighe be considered:

[Version][Envelop Details]

The version is just a single byte(u8) or two bytes(u16) indicating the version of the payload, for better upgradability. Then envelop details could be whatever bytes/protocol for the corresponding version.

For our immediate use case, it would be great maybe call it as version 0, with envelop details such as:

[Header][Optional Field 1][Optional Field 2][ReceivingAddress]

The header is just a single byte(u8) and each bit represents if the optional fields are included for interpretation. Currently only optional field is revert receiving address, a single byte header perhaps is good enough.

[ws4charlie]

@bitSmiley Thanks for your providing the thoughts (in detail) and feedback during the inscription integration. We're going to work on this and figure out a consistent (across supported chains) way to enable the options on inbound txs.

[ws4charlie]

Here is a proposed standard format of non-EVM chain inbound memo. Please let me know your thoughts @fadeev, cc @lumtis and @bitSmiley

[fadeev]

@ws4charlie looks good! I especially like the idea of versioning. Do we want to use versioning for EVM interface as well.

[ws4charlie]

@ws4charlie looks good! I especially like the idea of versioning. Do we want to use versioning for EVM interface as well.

EVM gateway currently doesn't have a versioning on the events. It seems to me it is can be done only thru gateway contract upgrading though.