grammarly fixes

Author: Ilaria Enache

learn/infrastructure/vaas.md

@@ -1,13 +1,8 @@
 ---
 title: VAAs
-description:  Learn about Verified Action Approvals (VAAs) in Wormhole, their structure, validation, and role in cross-chain communication.
+description: Learn about Verified Action Approvals (VAAs) in Wormhole, their structure, validation, and role in cross-chain communication.
 ---
 
-<!--
-code boxes need to be displayed in another way
-[link](#){target=\_blank}
--->
-
 # Verified Action Approvals
 
 VAAs are Wormhole's core messaging primitive. They are packets of cross-chain data that are emitted any time a cross-chain application contract interacts with the Core Contract.
@@ -42,20 +37,20 @@ Where each `signature` is:
 
 ### Body 
 
-The body is _deterministically_ derived from an on-chain message. Any two Guardians must derive the exact same body. This requirement exists so that there is always a one-to-one relationship between VAAs and messages to avoid double processing of messages.
+The body is _deterministically_ derived from an on-chain message. Any two Guardians must derive the same body. This requirement exists so that there is always a one-to-one relationship between VAAs and messages to avoid double-processing of messages.
 
 - `timestamp` ++"u32"++ - the timestamp of the block this message was published in
 - `nonce` ++"u32"++
 - `emitter_chain` ++"u16"++ - the id of the chain that emitted the message
 - `emitter_address` ++"[32]byte"++ - the contract address (wormhole formatted) that called the core contract
-- `sequence` ++"u64"++ - the auto incrementing integer that represents the number of messages published by this emitter
+- `sequence` ++"u64"++ - the auto-incrementing integer that represents the number of messages published by this emitter
 - `consistency_level` ++"u8"++ - the consistency level (finality) required by this emitter
 - `payload` ++"[]byte"++ - arbitrary bytes containing the data to be acted on
 
-The body is the relevant information for consumers and is handed back from a call like `parseAndVerifyVAA`. Because the `emitterAddress` is included as part of the body, the developer is able to tell if this VAA originated from a trusted contract.
+The body contains relevant information for consumers and is handed back from a call like `parseAndVerifyVAA`. Because the `emitterAddress` is included as part of the body, the developer can tell if this VAA originated from a trusted contract.
 
 !!! note
-    Because VAAs have no destination, they are effectively multicast. They will be verified as authentic by any Core Contract on any chain in the network. If a VAA has a specific destination, it is entirely the responsibility of relayers to complete that delivery appropriately.
+    Because VAAs have no destination, they are effectively multicast. Any Core Contract on any chain in the network will verify them as authentic. If a VAA has a specific destination, relayers are entirely responsible for completing that delivery appropriately.
 
 ## Signatures
 
@@ -72,11 +67,11 @@ The body of the VAA is hashed twice with `keccak256` to produce the signed diges
 
 ## Payload Types
 
-Different applications that are built on Wormhole may specify a format for the payloads attached to a VAA. This payload provides information on the target chain and contract so it can take some action (e.g., minting tokens to a receiver address).
+Different applications built on Wormhole may specify a format for the payloads attached to a VAA. This payload provides information on the target chain and contract so it can take action (e.g., minting tokens to a receiver address).
 
 ### Token Transfer
 
-Tokens are transferred from one chain to another using a lockup/mint and burn/unlock mechanism. While many bridges work on this basic premise, this implementation achieves this by relying on the generic message-passing protocol provided by Wormhole to support routing the lock and burn events from one chain to another. This makes Wormhole's token bridge ultimately chain-agnostic. An implementation can be quickly incorporated into the network as long as a wormhole contract exists on the chain we wish to transfer to. Due to the generic message-passing nature of Wormhole, programs emitting messages do not need to know anything about the implementation details of any other chain.
+Tokens are transferred from one chain to another using a lockup/mint and burn/unlock mechanism. While many bridges work on this basic premise, this implementation achieves this by relying on the generic message-passing protocol provided by Wormhole to support routing the lock and burn events from one chain to another. This makes Wormhole's token bridge ultimately chain-agnostic. An implementation can be quickly incorporated into the network if a wormhole contract exists on the chain we wish to transfer to. Due to the generic message-passing nature of Wormhole, programs emitting messages do not need to know anything about the implementation details of any other chain.
 
 To transfer tokens from A to B, we must lock the tokens on A and mint them on B. The tokens on A must be proven to be locked before the minting can occur on B. To facilitate this process, chain A first locks the tokens and emits a message indicating that the locking has been completed. This message has the following structure and is referred to as a transfer message:
 
@@ -96,7 +91,7 @@ Note that Chain B is agnostic regarding how the tokens on the sending side were
 
 The Transfer event above needs an important detail added. While the program on Chain B can trust the message to inform it of token lockup events, it has no way of knowing what the token being locked up actually is. The address alone is a meaningless value to most users. To solve this, the Token Bridge supports token attestation.
 
-For a token attestation, Chain A emits a message containing metadata about a token which Chain B may use to preserve the name, symbol, and decimal precision of a token address.
+For a token attestation, Chain A emits a message containing metadata about a token, which Chain B may use to preserve the name, symbol, and decimal precision of a token address.
 
 The message format for this action is as follows:
 
@@ -110,23 +105,23 @@ The message format for this action is as follows:
 Attestations use a fixed-length byte array to encode UTF8 token name and symbol data.
 
 !!! note
-    Because the byte array is fixed length, the data contained may truncate multibyte unicode characters.
+    Because the byte array is fixed length, the data contained may truncate multibyte Unicode characters.
 
 When sending an attestation VAA, we recommend sending the longest UTF8 prefix that does NOT truncate a character and right-padding it with 0 bytes.
 
 When parsing an attestation VAA, we recommend trimming all trailing 0 bytes and converting the remainder to UTF8 via any lossy algorithm.
 
 !!! note
-    Be mindful that different on-chain systems may have different VAA parsers, which may result in different names/symbols on different chains if the string is long or contains invalid UTF8.
+    Be mindful that different on-chain systems may have different VAA parsers, resulting in different names/symbols on different chains if the string is long or contains invalid UTF8.
 
-An essential detail of the token bridge is that an attestation is required before a token can be transferred. This is because without knowing a token's decimal precision, it is not possible for Chain B to correctly mint the correct amount of tokens when processing a transfer.
+An essential detail of the token bridge is that an attestation is required before a token can be transferred. Without knowing a token's decimal precision, Chain B cannot correctly mint the correct amount of tokens when processing a transfer.
 
 ### Token + Message
 
 !!! note
     This VAA type is also referred to as a payload3 message or a Contract Controlled Transfer.
 
-The Token + Message data structure is identical to the token-only data structure with the addition of a `payload` field that contains arbitrary bytes. This arbitrary byte field is where an app may include additional data in the transfer to inform some application-specific behavior.
+The Token + Message data structure is identical to the token-only data structure with the addition of a `payload` field containing arbitrary bytes. In this arbitrary byte field, an app may include additional data in the transfer to inform some application-specific behavior.
 
 - `payload_id = 3` ++"u8"++ - token transfer with wessage 
 - `amount` ++"u256"++ - amount of tokens being transferred
@@ -150,7 +145,7 @@ Governance messages contain pre-defined actions, which can target the various Wo
 - `chain`  ++"u16"++ - chain the action is targeting, 0 = all chains
 - `args`  ++"..."++ - arguments to the action
 
-Here is an example message containing a governance action triggering a code upgrade to the Solana core contract. The module field here is a right-aligned encoding of the ASCII "Core", represented as a 32-byte hex string.
+Below is an example message containing a governance action triggering a code upgrade to the Solana core contract. The module field here is a right-aligned encoding of the ASCII "Core", represented as a 32-byte hex string.
 
 ```js
 --8<-- 'code/learn/infrastructure/VAAs/snippet-2.js'
@@ -161,7 +156,7 @@ Here is an example message containing a governance action triggering a code upgr
 The meaning of each numeric action is pre-defined and documented in the Wormhole design documents. For each application, the relevant definitions can be found via these links:
 
 - Core governance actions are documented in the their [whitepaper](https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0002_governance_messaging.md){target=\_blank}
-- Token Bridge governance actions are documented in the their [whitepaper](https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0003_token_bridge.md){target=\_blank}
+- Token Bridge governance actions are documented in their [whitepaper](https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0003_token_bridge.md){target=\_blank}
 - NFT Bridge governance actions are documented in their [whitepaper](https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0006_nft_bridge.md){target=\_blank}
 
 ## Lifetime of a Message
@@ -172,6 +167,6 @@ The meaning of each numeric action is pre-defined and documented in the Wormhole
 With the concepts now defined, we can illustrate what a full flow for a message passing between two chains looks like. The following stages demonstrate each stage of processing the Wormhole network performs in order to route a message.
 
 1. **A message is emitted by a contract running on chain A** - any contract can emit messages, and the Guardians are programmed to observe all chains for these events. Here, the Guardians are represented as a single entity to simplify the graphics, but the observation of the message must be performed individually by each of the 19 Guardians
-2. **Signatures are aggregated** - Guardians observe and sign the message independently. Once enough Guardians have signed the message, the collection of signatures are combined with the message and metadata to produce a VAA
-3. **VAA submitted to target chain** - the VAA acts as proof that the Guardians have collectively attested the existence of the message payload; in order to complete the final step, the VAA itself is submitted (or relayed) to the target chain to be processed by a receiving contract
+2. **Signatures are aggregated** - Guardians observe and sign the message independently. Once enough Guardians have signed the message, the collection of signatures is combined with the message and metadata to produce a VAA
+3. **VAA submitted to target chain** - the VAA acts as proof that the Guardians have collectively attested the existence of the message payload; to complete the final step, the VAA itself is submitted (or relayed) to the target chain to be processed by a receiving contract