Improve Executor README

agents/agents/executor/README.md

@@ -1,5 +1,5 @@
 # Executor
-The Executor is an agent responsible for executing messages on the `Destination.sol` contract. It verifies that the message has been accepted by verifying a merkle proof, as well as the message's optimistic period.
+The Executor is an agent responsible for executing messages on the `Destination.sol` contracts. It verifies that the message has been accepted by verifying a merkle proof, as well as the message's optimistic period.
 
 ## Components
 The Executor operates with four main components:
@@ -10,6 +10,22 @@ The Executor operates with four main components:
 <br /> <br > `setMinimumTime` sets the minimum unix time for a message before it has passed the optimistic period and can be executed. It works by going through all messages in the database that haven't been set, and checks for attestations to set each message's time.
 <br /> <br > `executeExecutable` is the function that executes messages. It looks through all messages that have a time set from `setMinimumTime` and executes them if the minimum time is past the current time.
 
+### Message Lifecycle
+As a message gets sent by a user on an Origin chain, there are a few important variables with the message that guide its execution.
+* `Origin`: The chain ID of the chain the message is originating from
+* `Nonce`: The nonce of the message for all messages sent on this origin (if 5 other messages by other users were sent before on this origin, the nonce would be 6)
+* `Destination`: The chain ID of the chain the message is targeting
+* `OptimisticSeconds`: How many seconds should be allocated for fraud catching before the message is able to be executed on the `Destination`
+
+Once a message is constructed with all of these fields and is dispatched via the `SendBaseMessage` function on the `Origin`'s Origin.sol contract, the message starts its lifecycle in the SIN. Let's say this message has nonce `N`.
+1. A <a href="../guard/README.md">Guard</a> captures a State of the Origin with a nonce of `N`. So messages from 1 to N are all included in this State.
+2. The Guard collects different States across various chains and submits them all in a Snapshot to the SynChain.
+3. A <a href="../notary/README.md">Notary</a> looks at all States that Guards have submitted to the SynChain, and creates a Snapshot with the new states. So a Notary sees the state that was caputred in step 1 and submits it in a Snapshot on SynChain.
+4. After the Notary is submitted, a Snapshot Root, representing a Merkle Tree of all the data in the Snapshot has been saved. Now, the message is included in a Notary's Snapshot on SynChain and is ready to be delivered to the `Destination`.
+5. A Notary (same or different than the one that performed step 3) now submits an Attestation to the `Destination`. Once this Attestation is accepted on the `Destination`, the message's `OptimisticSeconds` timer starts.
+
+Now, it is the executors job to ensure that a message that it has seen on `Origin` has gone through the whole lifecycle, while proving inclusion at various steps, before it is able to wait for the message's optimistic period and execute the message.
+
 ### Execute
 `Execute` works in 3 parts.
 1. Verify that the optimistic period for the message has passed. This is done by checking the timestamp that the attestation was accepted on the Destination, then checking the timestamp of the last block.