consistency level changes

src/technical/evm/bestPractices.md

@@ -17,7 +17,7 @@ When sending messages, you should follow the same paradigm as is used by the Wor
 // A module is just a piece of code which knows how to emit a composable message
 // which can be utilized by other contracts.
 function emitMyMessage(address intendedRecipient, uint32 nonce)
-        public returns (uint64 sequence) {
+        public payable returns (uint64 sequence) {
 
     // Nonce is passed though to the core bridge.
     // This allows other contracts to utilize it for batching or processing.
@@ -26,9 +26,8 @@ function emitMyMessage(address intendedRecipient, uint32 nonce)
     // This field will allow the destination contract to enforce
     // that the correct contract is submitting this VAA.
 
-    // 1 is the consistency level,
-    // this message will be emitted after only 1 block
-    sequence = core_bridge.publishMessage(nonce, "My Message to " + intendedRecipient, 1);
+    // consistency level 200 means instant emission
+    sequence = core_bridge.publishMessage(nonce, "My Message to " + intendedRecipient, 200);
 
     // The sequence is passed back to the caller, which can be useful relay information.
     // Relaying is not done here, because it would 'lock' others into the same relay mechanism.

src/technical/evm/coreLayer.md

@@ -32,8 +32,11 @@ To emit a VAA, always use `publishMessage` which takes in the following argument
 
 1.  `nonce` (uint32): a number assigned to each message
     - The `nonce` provides a mechanism by which to group messages together within a Batch VAA. How the `nonce` is used is described below.
-2.  `Consistency` (uint8): the number of blocks that Guardians will wait before signing a message
-    - Each blockchain has different finality periods based on the consensus mechanism. In general, higher consistency values provides more security against blockchain reorgs. [Here](../../reference/contracts.md) are the consistency levels by blockchain that are used by the xAsset layer to have a high level of guarantee against reorgs.
+2.  `Consistency` (uint8): the level of finality the guardians will reach before signing the message
+    - Consistency should be considered an enum, not an integer.
+    - On all EVM chains, 200 will result in an instant message, while all other values will wait for finality.
+    - On BSC, the consistency denotes how many block confirmations will be waited before producing the message.
+    - More information about finality can be found [Here](../../reference/contracts.md)
 3.  `Payload` (bytes[]): raw bytes to emit
     - It is up to the emitting contract to properly define this arbitrary set of bytes.
 
@@ -86,6 +89,6 @@ To properly parse and verify a batch VAA, always use `parseAndVerifyBatchVM` whi
 
 In most scenarios, you'll want to set `cache` equal to true.
 
-This will return a VM2 object, containing all the 'headless' VAAs contained inside the batch VAA. These headless VAAs can be verified by `parseAndVerifyVM`, which means that modules which verify messages in an xDapp can be agnostic as to whether a message came from a batch VAA or a single VAA. 
+This will return a VM2 object, containing all the 'headless' VAAs contained inside the batch VAA. These headless VAAs can be verified by `parseAndVerifyVM`, which means that modules which verify messages in an xDapp can be agnostic as to whether a message came from a batch VAA or a single VAA.
 
 The [Best Practices](./bestPractices.md) section goes into more depth of how to interact with the coreLayer.

src/technical/evm/relayer.md

@@ -61,7 +61,7 @@ struct DeliveryParameters {
 - `relayParameters`: information required to relay to the target env. Contains compute budget
 - `chainPayload`: information used for computation efficiency when relaying to other ecosystems
 - `nonce` (_optional_): If included, only messages with this nonce will be relayed
-- `consistencyLevel`: how long to wait before emitting the relay request
+- `consistencyLevel`: what level of consistency / finality to reach before emitting the message
 - `msg.value`: payment in native currency to relayer that must cover the compute budget specified in the relayer parameters
 
 ## Compute Budget

src/wormhole/3_coreLayerContracts.md

@@ -1,6 +1,6 @@
 # Core Contracts
 
-The Core Contracts are the mechanism by which all Wormhole messages are emitted. All xDapps either interact directly with the Core Contract or interact with another contract that does. There is one Core Contract on each blockchain in the ecosystem, and this is the contract which the Guardians are required to observe. 
+The Core Contracts are the mechanism by which all Wormhole messages are emitted. All xDapps either interact directly with the Core Contract or interact with another contract that does. There is one Core Contract on each blockchain in the ecosystem, and this is the contract which the Guardians are required to observe.
 
 The Wormhole Core Contracts are one of the most pivotal pieces of the Wormhole ecosystem. They serve as a great place to start when learning about how data flows through the ecosystem.
 
@@ -8,7 +8,7 @@ In general, Core Contracts are simple and can be broekn down to a **sending** an
 
 ### Sending
 
-Below is the mechanism by which Wormhole messages (aka Verified ACtion Approval, VAA) are emitted:
+Below is the mechanism by which Wormhole messages (aka Verified Action Approval, VAA) are emitted:
 
     publishMessage(
         int nonce,
@@ -16,17 +16,17 @@ Below is the mechanism by which Wormhole messages (aka Verified ACtion Approval,
         int consistencyLevel
     ) returns int sequenceNumber
 
- Let's break it down a bit:
+Let's break it down a bit:
 
 - **payload** - The content of the emitted message and an arbitrary byte array. It may be capped to a certain maximum length due to the constraints of individual blockchains.
 
-- **consistencyLevel** - The number of blocks which the Guardians should wait prior to emitting a VAA for this message. This number is usually either 1 or equal to the chain's finality period. This is a defense against transactions being orphaned.
+- **consistencyLevel** - The level of finality to reach before emitting the Wormhole VAA. This is a defense against reorgs and rollbacks.
 
-- **nonce** -  An index number for the message that is used to produce Batch VAAs. How this is generated is elaborated in the [CoreLayer](../technical/evm/coreLayer.md) section.
+- **nonce** - An index number for the message that is used to produce Batch VAAs. How this is generated is elaborated in the [CoreLayer](../technical/evm/coreLayer.md) section.
 
 - **sequenceNumber** - A unique index number for the message. When combined with the emitter contract address and emitter chain ID, the corresponding VAA can be retrieved from a guardian network node.
 
-The implementation strategy for publishMessage differs by chain, but the general strategy consists of the Core Contract posting the emitterAddress (the contract which called publishMessage), sequenceNumber, and consistencyLevel into the blockchain logs. Once the desired consistencyLevel has elapsed and the message passes all of the Guardians' optional checks, the Guardian Network will produce the requested VAAs.
+The implementation strategy for publishMessage differs by chain, but the general strategy consists of the Core Contract posting the emitterAddress (the contract which called publishMessage), sequenceNumber, and consistencyLevel into the blockchain logs. Once the desired consistencyLevel has been reached and the message passes all of the Guardians' optional checks, the Guardian Network will produce the requested VAAs.
 
 Currently there are no fees to publish a message (with the exception of publishing on Solana) but this is not guaranteed to always be the case in the future.
 

src/wormhole/4_vaa.md

@@ -20,7 +20,7 @@ The Header is used by the Core Contract to determine the authenticity of the VAA
     u16         emitter_chain             (Wormhole ChainId of emitter contract)
     [32]byte    emitter_address           (Emitter contract address, in Wormhole format)
     u64         sequence                  (Strictly increasing sequence, tied to emitter address & chain)
-    u8          consistency_level         (How many blocks were waited before emitting this VAA)
+    u8          consistency_level         (What finality level was reached before emitting this message)
     []byte      payload                   (VAA message content)
 
 The Body is the relevant information for consumers and is handed back from 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.
@@ -33,7 +33,7 @@ Because baseline VAAs have no destination, they are effectively multicast. They
 
 Certain blockchains support version 2 VAAs, also referred to as **Batch VAAs** which are designed to provide an easier paradigm for composability and better gas efficiency when multiple cross-chain actions are involved in a single transaction.
 
-Batch VAAs are designed to be automatically generated for all messages that come from a single transaction. 
+Batch VAAs are designed to be automatically generated for all messages that come from a single transaction.
 
 In an extreme composability scenario or advanced integration, there may be some messages in a transaction that may not be relevant to one another. To control the create of additional batches, some messages can be created with the same `nonce` to _additionally_ group them.
 
@@ -43,10 +43,10 @@ Go [here](../technical/evm/coreLayer.md) for a more detailed description of how
 
 _Note: Batch VAAs are not currently live on mainnet, but will have initial support on all EVM chains when they launch._
 
-> How to leverage Batch VAAs 
-> 
+> How to leverage Batch VAAs
+>
 > Imagine a transaction generates three messages (A, B, C) that a consuming contract needs to know about.
-> 
+>
 > If each message is independent of each other, the consuming contract can handle and validate each of these VAAs individually like [A], [B], [C].
 >
 > If all of the messages are related to each other, the consuming contract can handle and validate the Batch VAA of the entire transaction that is automatically generated like [A, B, C].