Reconstruct a Starknet L1 handler’s sender argument
An Ethereum-to-Starknet message includes a handler selector and an array of user payload felts. The resulting L1_HANDLER transaction supplies the L1 sender as an additional first calldata element.
Compare the two representations
Decode the core contract’s L1 message event and keep the sending L1 contract, target Starknet address, selector, nonce and payload. For the example, a two-element user payload produces three elements in the handler transaction calldata.
L1 payload = [recipient, amount]
L1-handler calldata = [L1 sender, recipient, amount]
A bridge decoder that treats the first handler argument as the beneficiary will instead record the L1 source. Match the selector to the L2 handler ABI and verify the expected L1 source address before assigning application fields.
Keep nonce outside the application arguments
The core contract’s message nonce distinguishes repeated L1 messages in protocol hashing. It is not an extra business parameter automatically appended to the user payload. Use the full protocol identity when correlating repeated transfers. docs.starknet.io Starknet documentation