Transaction lifecycle diagram

I am posting here a diagram that is an outcome of discord discussion with @FeedTheFed about StarkNet transaction lifecycle. It is a documentation of current state of affairs not a design document. Expect changes in the future.


Great diagram! Are the arrows possible transitions? And if so, why is it possible to go backwards? (ie ACCEPTED_ON_L2 β†’ RECEIVED )

1 Like
  • ACCEPTED_ON_L2 β†’ RECEIVED - state update failed due to l1 reorg or sequencer creating invalid proof
  • ACCEPTED_ON_L1 β†’ RECEIVED - l2 state rewind due to a deep l1 reorg
  • REJECTED β†’ RECEIVED - due to l1 reorg unprovable state might become provable because reorged l1 state might create another set of l1->l2 messages.

I am not sure how transactions that will be canceled by a reorg (I mean there are no corresponding l1->l2 messages after the reorg) should be treated. REJECTED? @FeedTheFed

I was learning about this some time ago as well, came up with this diagram. It’s pretty similar to @maciejka’s but the tx and block statuses are split and I’ve added some more comments (because I forget these things).

1 Like