Quickstarts

Encode a Call's Content Hash

STEP 1 OF 3

NEXT WALKTHROUGH: How to read a remote contract's state →

YOUR CALL · EIGHT FIELDS, IN HASH ORDER

isStatic · bool sourceAddress sourceRollupId

targetAddress targetRollupId

value · uint256 callGas · uint64

data · bytes

TWO OF THE EIGHT ARE NOT YOURS TO CHOOSE

All eight fields are editable here so you can watch the hash move. On-chain, two of them are written by whichever manager the call leaves, not by you — put your own values in either and the hash you compute will never match an entry.

sourceRollupId is forced by the side you are leaving — L1 hardcodes rollup id 0, an L2 passes its own ROLLUP_ID. Neither reads an argument.

callGas is 0 for every call a manager hashes on the way out, except a call leaving an L2 deployed with USE_GAS_LEFT = true (off in every current deployment) — there it is the gasleft() the L2 manager samples after its proxy checks and any value transfer, just before hashing. One more exception: when L2's executeIncomingCrossChainCall checks an entry, it hashes that inbound call's own gas field.

FOR ENTRY BUILDERS

Under USE_GAS_LEFT the hash is gas-dependent — a value you cannot predict off-chain is in the preimage. That is why a top-level or static miss on L2 carries a payload: EntryNotFound(bytes32 crossChainCallHash, uint64 callGas) hands back the observed gas so whoever builds the entry can reproduce the key. A nested mutable miss does not revert there: it records CALL_NOT_FOUND, and the entry fails later with RollingHashMismatch. Outside the two exceptions above, the constant ZERO_CALL_GAS is folded in.

keccak256(abi.encode(⋯)) ·

SAME EIGHT VALUES, source ⇆ target SWAPPED

Nothing was added or removed — only the order changed. Every on-chain hash check and every off-chain tool that pre-computes this would disagree.

8 FIELDS · THIS ORDER · LOAD-BEARING

1. isStatic

2. sourceAddress

3. sourceRollupId

4. targetAddress

5. targetRollupId

6. value

7. callGas

8. data

PINNED

eez-core-protocol/src/base/EEZBase.sol:285 ↗

DAPP DEVELOPERS

How to encode a call's content hash

In the Quickstart, card 03 showed how the manager matches your call to an entry by its hash. This card shows the full 8-field hash at the pinned commit.

One value, several names: card 03's proxyEntryHash, the content hash here, and the crossChainCallHash the managers compute with computeCrossChainCallHash are the same call hash.

Eight fields describe a cross-chain call, in this exact order. Hash them together and one bytes32 identifies the call.

WHAT YOU'LL LEARN

01 · 8 FIELDS, FIXED ORDEREight fields describe a cross-chain call, in this exact order.
02 · ONE HASH OUTHash them together — one bytes32 identifies the call.
03 · ORDER IS LOAD-BEARINGReorder them and you get a different hash.

RUN IT YOURSELF · forge test --match-test test_matchesIndependentlyDerivedDigest -vv — from eez-demos/snippets, Foundry only.

Verified against eez-core-protocol Git commit 9a1f815; interfaces may move.

UP NEXTHow to read a remote contract's state