I don't think creating a CCTX just to show the error message is a good idea
@ws4charlie Did a great job with the considerations; there are a few more I would like to add, though

• The voting cost can increase with the number of observers

• The voting cost can also increase with increased zeta token value

• The ErrMessage Field would be unused by almost 90% (if not more cctxs). It also adds minor amount of additional logic to the VoteInbound, which is one of the most complicated sections of our code.

• Would it be possible to limit changes to zeta-client and have a way to inform the user that the inbound was not observed becuase the Fee is too low,

• Instead of the CCTX, would you consider a simple mapping between inboundHash -> ErrMessage, which only gets saved for these transactions (I would still prefer handling it at the client level, though, if it's possible )

Here is a draft PR that registers an aborted CCTX for failed inbounds due to insufficient fee: #3358

Considering the team might have other considerations, it is open for discussions.

So, in order to allow the users to track the status of a failed inbound, we need to record a status for each inboundHash. This status can be on-chain or off-chain. For successful ones, we already have CCTX status, for failed ones

If on-chain: the error will be written to Zetachain or Bitcoin.

If off-chain: the error will be written to some database/server/indexer and queries needs to be publicly available to users.

I think @fadeev could also share some insights from developer experience perspective.

I understand the concerns @kingpinXD outlined, but having this on-chain is still preferable compared to an off-chain solution with a database.

Alternatively, we write a client-side function that can definitively tell if a specific tx has been processed or rejected due to deposit fees.

We have 9 observers for mainnet and therefore 9 individual databases. The status of an inbound needs to be a consensus-based outcome through voting, developer can't trust one individual observer. Also, observer database is temporary, erasable and for observer private usage.

I see your point; however, even if there are 9 individual DBSs, there might be inconsistency between them. Would that be an option for exploitation?
I would assume this error message would only be used for debugging and showing an error message on explorer. There is no interaction with the core at all .

Yeah. The data inconsistency, lacking persistency and public access availability are the concerns.

Usually, triggering a failed inbound (less deposit fee) in Bitcoin is more expensive than a triggering a successful inbound on other chains.

Example Bitcoin inbound ($1.31): https://mempool.space/tx/7877075d50e645b76d4fb402699cac6e992ce8f88c506b47c94039baa1c40023
Example Polygon inbound ($0.00, 0.003818732773603 POL): https://polygonscan.com/tx/0x873182b28d66a4854676e867b207907ac2def0f4d7d42a516822f83e7a106464
Example Base inbound ($0.007194): https://basescan.org/tx/0xda2797193e92c57fa694cdb6ee0e70ca90e3f1536da6af9bb08d305b1c96c401

Yeah that's true
I also think 1.31$, for now, is more than the fee paid by the observers to vote, even if we account for all the nine votes
But

• The price of zeta might go up
• We can increase the gas-price (We were considering doing that slowly over time )
• The number of observers might increase, etc

I do think having the cctx is the best for user experience, but we should exhaust all other options before finalizing this