Answer a few questions from developers

[NicNomadic]

We received the following legitimate questions from some developers using the Tezos X features in Etherlink 7.x:

Q1 — Out-of-gas on the far side of a NAC call. The documentation covers revert propagation, but not out-of-gas specifically. Is an OOG inside the callee runtime surfaced to the caller as an ordinary catchable failure, with the same rollback guarantees? Our non-custody argument depends on "burn and release cannot be separated" holding under every failure mode, including gas exhaustion mid-way.

• add short answer: explanation for OOG catching for EVM->Michelson calls
• We might want to expand on what we mean by Atomicity and what are the provided guarantees, maybe provide high-level examples to illustrate ? It's quite important and maybe deserve a bit if yapping.

Q2 — Alias derivation: canonical formula and stability. The accounts & aliases page documents the EVM→Michelson alias as KT1(blake2b_160(raw 20-byte evm_address)), but on previewnet we observe that the implementation hashes the lowercase 0x… string instead: KT1(blake2b_160(utf8(lowercase("0x…")))). Our wiring uses the empirically verified formula. Which one is canonical? And more broadly: are alias derivations committed to being stable across protocol/kernel upgrades? Our wiring is deliberately immutable, so an alias-derivation change would permanently brick both bridges.

• It's documented correctly (as using lowercase 0x string) on https://docs.etherlink.com/ but not on x.tezos.com/docs
  • redirect x.tezos.com to docs.etherlink.com: see https://gitlab.com/tezos/xdocs/-/merge_requests/24
• Document the originOf/resolveAddress interface:
  • separately handled in docs: document originOf, resolveAddress and the alias RPCs #459

Q3 — Gas guidance for cross-interface calls. What is the recommended practice for a contract like ours — forward all remaining gas to callMichelson, or cap as we do? Is the conversion coefficient a protocol constant we can size the cap against, and can the Michelson-side budget ever be insufficient in a way that does not surface as a revert? Relatedly, wallet-side gas estimators only see one runtime, so cross-interface transactions need manually raised limits today (~200k for a wrapped ERC-721 transfer) — is estimator support planned?

• first part is also answered by the short answer to Q1 (see above)
• eth_estimateGas does take the Michelson runtime into account, so maybe there is a workaround here, not sure it's super satisfactory though (not only related to doc)

Q4 — The Michelson gateway's %call entrypoint. Besides call_evm, the gateway exposes a %call entrypoint (pair string (list (pair string string)) bytes nat option) whose semantics we could not determine — five plausible encodings all produced an opaque tezlink_error. Not blocking (call_evm suffices), but documentation would help.

• Do we want to document the low-level %call?

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs-etherlink	Ready	Preview	Oct 7, 2026 6:48am UTC

[pecornilleau]

For Q3 we could include examples of getting gas estimate from the EVM and the Michelson side (using the simulation as for L1, it works with NACs)

[NicNomadic]

For Q3 we could include examples of getting gas estimate from the EVM and the Michelson side (using the simulation as for L1, it works with NACs)

Notwithstanding a more complete example, for the time being, I added a link to the NAC walkthrough in page EVM NAC, does this improve things already?