Distinguish ZKsync batch commitment, proof and execution on L1
A batch can have a commitment transaction on Ethereum while its validity proof or execution transaction has not yet appeared. A single posted flag hides the operational stage that needs investigation.
Read the three transaction references
Replace example batch number 42 with the L1 batch containing the target L2 transaction. Inspect commitTxHash, proveTxHash and executeTxHash as well as the associated timestamps where available. Use parent-chain receipts to confirm observed transactions.
{"jsonrpc":"2.0","id":1,"method":"zks_getL1BatchDetails","params":[42]}
If commitment and proof references are present but the execution reference is absent, show the batch as awaiting its recorded execution stage. Avoid labeling the L2 transaction hash as the proof or using its L2 block number as the batch number.
Handle indexing delays
A null or missing field from one endpoint can reflect its current indexing progress. Compare the canonical parent records and the RPC backend’s synchronization state before escalating a delayed stage. Keep application execution success from the L2 receipt as a separate fact. docs.zksync.io ZKsync documentation