Zero Cost EthereumTransaction on Success

[Nana-EC]

Description:
On many EVM chains execution costs are fully captured in gas. Thus submitting transactions to execution nodes bears no
cost to the relay node. On Hedera it is necessary to charge a fee for EthereumTransaction HAPI submissions (just like
all other HAPI transactions).

This HIP suggests the network logic not charge successful EthereumTransaction submissions, but instead only charge the
regular HAPI fee for badly formed transactions.

Related issue(s):

Fixes #1083

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[netlify]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	6ea815f
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/673e4650440fe80008859b9c
😎 Deploy Preview	https://deploy-preview-1084--hedera-hips.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Neurone]

on Success
[...]
2. As a relay operator I will pay the HAPI transaction fee for EthereumTransaction submissions that fail.

I think referring to success/failure can be misleading in the HIP's title and description. I suggest using something like well-formed, formally valid, etc.

• If the EthereumTransaction succeeds, do not charge the AccountId submitter
• If the EthereumTransaction fails, charge the AccountId submitter

I recommend dropping the success/failure wording and clearly stating the list of results for which the submitter will be charged $0.0001 (e.g., WRONG_NONCE, INVALID_SIGNATURE, etc.).

Any results not in the list above will be free for the submitter, whether it's an EVM error or not (e.g., CONTRACT_REVERT_EXECUTED, SUCCESS, etc.).

[rbair23]

@Neurone I agree, the text has been updated, but I think it would benefit from being even more precise.

[quiet-node]

This indeed highlights a list of prechecks performed by the Relay to validate transactions and reject them if any conditions are met, ensuring they are not forwarded to the network unnecessarily, thus avoiding charges. Notably, the Hedera JSON-RPC Relay already handles and rejects these scenarios. However, there are additional prechecks currently performed by the Relay that are not mentioned here:

• Transaction type
• Gas price
• Gas limit
• Chain ID
• Value
• calldata size (not exceed 128KB maximum)

I recommend considering these prechecks and including them in this HIP for greater clarity and completeness.