Update AggLayer.md

minor edits

Author: 0xgraciegrace

docs/learn/agglayer.md

@@ -26,7 +26,7 @@ In this context, "atomic" means a user can send a set of transactions to multipl
 
 The most basic example of this is a cross-chain transfer. Let’s say that Alice wants to send 1 ETH to Bob, but Alice is on Rollup A, and Bob is on Rollup B. Assuming a shared native bridge for both rollups, Alice can burn her ETH on Rollup A and mint ETH on Rollup B which is transferred to Bob. But it’s critical to guarantee that she can’t mint ETH without burning it or vice-versa - either she could lose her ETH or under-collateralize the bridge.
 
-This is why we need atomic transactions are necessary to ensure low-latency interactions can occur between the chains so the UX *feels* like using a single chain with the Polygon ecosystem. Any L1 or L2 connecting to the Polygon AggLayer, these chains still maintain complete sovereignty, but the ecosystem delivers **high composability** and **uniform cryptographic security** with Ethereum as the global settlement layer.
+This is why we need atomic transactions to ensure low-latency interactions between the chains so the UX *feels* like using a single chain with the Polygon ecosystem. Any L1 or L2 connecting to the Polygon AggLayer, these chains still maintain complete sovereignty, but the ecosystem delivers **high composability** and **uniform cryptographic security** with Ethereum as the global settlement layer.
 
 ## AggLayer design sketch
 
@@ -99,19 +99,19 @@ While it's possible that a chain could collude with the aggregation layer to for
 
 We can allow batches to be optimistically confirmed without proofs if we ensure that chains can safely receive messages. We do so as follows.
 
-1. Chain A submits a batch and message queue without a validity proof to the aggregation layer.
+1. Chain A submits a batch and message queue without a validity proof to the AggLayer.
 2. A user on Chain B submits a transaction that reads a message from Chain A before the validity proof is generated.
-3. Chain B can confirm with the aggregation layer the current pre-confirmed state of Chain A.
+3. Chain B can confirm with the AggLayer the current pre-confirmed state of Chain A.
 4. Chain B submits a batch and includes a claimed Batch Root and Message Queue for Chain A.
 5. The validity proof for Chain B commits to the claimed Message Queue for Chain A.
-6. The recursive proof generated by the aggregation layer checks that the Message Queue for Chain A is consistent with the *claimed* Message Queue for Chain A by Chain B.
+6. The recursive proof generated by the AggLayer checks that the Message Queue for Chain A is consistent with the *claimed* Message Queue for Chain A by Chain B.
 7. Either:
     - Chain A submits a validity proof that is consistent with the pre-confirmed batch, in which case the recursive proof can be generated.
     - Chain A fails to submit a validity proof. Chain B must roll back the transaction that depends on Chain A. Chain A is slashed. 
 
 Fundamentally, this approach provides safety because it guarantees that a batch from Chain B that relies on a pre-confirmed batch from Chain A cannot be submitted to Ethereum if Chain A equivocates or has pre-confirmed an invalid batch. 
 
-This is critical, because otherwise Chain B could read a message from Chain A, mint some number of tokens, and then Chain A could equivocate and mint the same number of tokens on Chain C, undercollateralizing the bridge. Using this approach, we can provide both low latency and safety.
+This is critical, because otherwise Chain B could read a message from Chain A, mint some number of tokens, and then Chain A could equivocate and mint the same number of tokens on Chain C, undercollateralizing the bridge. Using this approach, we can obtain both low latency and safety.
 
 ### Atomic Cross-Chain Interaction
 
@@ -161,7 +161,7 @@ The atomic mode for cross-chain interaction largely follows the Shared Validity
 2. Transactions from the bundle are forwarded to their respective chains by the worker.
 3. Chains take a lock on the state affected by each transaction and sequence the bundle in a new block, returning the resulting message queue to the worker. If another transaction is received that touches state affected by the bundle, it's queued for execution until after the bundle is either confirmed or rejected.
 4. If each transaction in the bundle executed correctly and the resulting message queues are consistent (ie tokens minted matches tokens burned), then the bundle is included by the aggregation layer.
-5. Each chain generates a validity proof for the block containing the bundle. When all validity proofs are received by the aggregator layer, chains can release the lock on affected state and execute queued transactions.
+5. Each chain generates a validity proof for the block containing the bundle. When all validity proofs are received by the AggLayer, chains can release the lock on affected state and execute queued transactions.
 
 #### Failure Modes