docs: update docs

README.md

@@ -17,6 +17,7 @@ The core logic of **Cada** is implemented and executed on the Cosmos chain.
 
 In the Cada module:
 - At each block interval, the `PreBlocker` ABCI method sends a request to the `Relayer`, specifying the range of block heights ready to be posted to the **Avail** Data Availability (DA) network.
+![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c)
 - The chain is responsible for aggregating vote extensions from all validators and verifying whether the data has been made available on Avail.
 - Since verification requires communicating with the light client, an asynchronous voting mechanism is needed. **Vote extensions** enable this asynchronous voting mechanism for verification purposes.
 
@@ -30,12 +31,12 @@ The **Relayer** facilitates communication between the Cosmos Chain, the Avail li
 
 - **Data Verification**: During verification, the relayer communicates with the Avail light client to confirm whether the data is truly available at the specified height.
 
-![Data Submission](https://github.com/user-attachments/assets/4e17b98f-ca8c-4b4c-a79e-8c60f123cb2c)
+
 
 ## 3. Avail Light Node
 The **Avail Light Client** allows interaction with the Avail DA network without requiring a full node, and without having to trust remote peers. It leverages **Data Availability Sampling (DAS)**, which the light client performs on every newly created block.
 
-- The chain communicates with the Avail light client via the relayer during the data availability verification process.
+- The chain communicates with the Avail light client via the relayer during the data submission and data availability verification processes.
 
 Find more details about the Avail Light Client [here](https://docs.availproject.org/docs/operate-a-node/run-a-light-client/Overview).