Reconstruct the source hash of an OP Stack user deposit
An L1 transaction can emit more than one deposit event. Using only its transaction hash as the key merges distinct L2 deposits and gives the wrong value for the deposit transaction’s sourceHash.
Use the receipt’s block-wide log index
Locate the TransactionDeposited event from the configured OptimismPortal and record its canonical L1 block hash and logIndex. Encode the index as a 32-byte big-endian integer. The zero domain in this formula applies to a user deposit.
depositId = keccak256(l1BlockHash || uint256(logIndex))
sourceHash = keccak256(bytes32(0) || depositId)
If the same L1 transaction emits matching logs at indices 9 and 10, compute two deposit IDs and two source hashes. The local position within a filtered receipt is insufficient: retain the original log index.
Distinguish the source hash from the L2 transaction hash
The derived sourceHash is one field in the typed L2 deposit transaction. The L2 transaction hash covers the full serialized transaction. An L1 reorganization can also change the source block hash, so bind observations to the canonical inclusion. specs.optimism.io OP Stack specification