fix: minor fixes in "Transaction lifecycle" (#527)

* minor fix

* minor fix

* minor fix

* minor fix

---------

Co-authored-by: JameStark <113911244+JameStark@users.noreply.github.com>

components/StarkNet/modules/architecture_and_concepts/pages/Blocks/transaction-life-cycle.adoc

@@ -9,7 +9,7 @@ The following are the possible statuses of a transaction from the moment it's se
 [id="not_received"]
 === NOT_RECEIVED
 
-Transaction is not yet known to the sequencer
+Transaction is not yet known to the sequencer.
 
 [id="received"]
 === RECEIVED
@@ -20,16 +20,7 @@ Transaction will now either execute successfully or be rejected.
 [id="pending"]
 === PENDING
 
-Transaction executed successfully and entered the xref:./transaction-life-cycle.adoc#the-pending-block[pending block].
-
-[id="rejected"]
-=== REJECTED
-
-Transaction executed unsuccessfully and thus was skipped (applies both to a pending and an actual created block).
-Possible reasons for transaction rejection:
-
-* An assertion failed during the execution of the transaction (in Starknet, unlike in Ethereum, transaction executions do not always succeed).
-* The block may be rejected on L1, thus changing the transaction status to `REJECTED`
+Transaction executed successfully and entered the xref:./transaction-life-cycle.adoc#the_pending_block[pending block].
 
 [id="accepted_on_l2"]
 === ACCEPTED_ON_L2
@@ -41,12 +32,21 @@ Transaction passed validation and entered an actual created block on L2.
 
 Transaction was accepted on-chain.
 
+[id="rejected"]
+=== REJECTED
+
+Transaction executed unsuccessfully and thus was skipped (applies both to a pending and an actual created block).
+Possible reasons for transaction rejection:
+
+* An assertion failed during the execution of the transaction (in Starknet, unlike in Ethereum, transaction executions do not always succeed).
+* The block may be rejected on L1, thus changing the transaction status to `REJECTED`.
+
 [id="the_pending_block"]
 == The pending block
 
 Today, Starknet supports querying the new block before its construction is complete. This feature improves the responsiveness of the system prior to the decentralization phase, but will probably become obsolete once the system is decentralized, as full nodes will only propagate finalized blocks through the network.
 
-During the construction of the block, as it is accumulating new transactions, the block's status is `PENDING`. While status is `PENDING`, new transactions are dynamically added to the block. Once the sequencer decides to `close` the block, it becomes `ACCEPTED_ON_L2` and its hash is computed.
+During the construction of the block, as it is accumulating new transactions, the block's status is `PENDING`. While status is `PENDING`, new transactions are dynamically added to the block. Once the sequencer decides to close the block, it becomes `ACCEPTED_ON_L2` and its hash is computed.
 
 The following example is a query for the pending mainnet block: