Understanding the life cycle of a Molten transaction
FINALITY CHECK: Trusted / Soft Confirmation At this phase, the client’s acceptance of finality relies on trusting the Sequencer. A malicious/faulty Sequencer could deviate between what it promised in the transaction receipt and what is ultimately published in a batch.NOTE: Even a malicious/faulty Sequencer can only, at worst, reorder or temporarily delay transactions; it cannot, e.g., forge a client’s transaction or propose an invalid state update.
FINALITY CHECK: Ethereum-Equivalent Finality! At this stage, assuming that a client believes there to be at least one well-behaved active Molten validator, the client can treat their transaction’s finality as equivalent to an ordinary Ethereum transaction. In other words, their L3 transaction has the same finality as the L2 transaction that recorded it in a batch.
FINALITY CHECK: STILL THE SAME Ethereum-Equivalent Finality! Even during a dispute, Molten nodes continue to execute, and active validators continue to make assertions on the valid leaf in the state-tree; nothing that can happen in phase 4 has any effect on the L2-level finality we’ve already locked in at phase 3.
FINALITY CHECK: L3-to-L2 Messages Executable on L2 If our client’s transaction didn’t include any L3-to-L2 messages (e.g., withdrawals), phase 5 has no material effect on their transaction. If it did include an L3-to-L2 transaction, it is only after confirmation that the message can be executed in the Outbox on L2.NOTE: Even before phase 5, the client has L2 finality on the result of their L3-to-L2 message, they just can’t execute it yet; i.e., they have a guarantee that they’ll eventually be able to, e.g., finalize their withdrawal, they just can’t claim their funds on L2 until the RBlock is confirmed.