evm: line edits

src/technical/evm/coreLayer.md

@@ -4,9 +4,6 @@ This section will explain how to properly interact with the Wormhome Core Layer
 
 ## Configuring the Interface
 
-- Get the interface from the repo
-- Instantiate it with the core layer contract address for your blockchain. This is dependent on your development ecosystem and blockchain. This value is usually stored in your contract state.
-
 [Here](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/ethereum/contracts/interfaces/IWormhole.sol) is the interface for applications to interact with Wormhole's Core Contract to publish messages or verify and parse a received message.
 
 Instantiating the interface will depend on your development ecosystem and blockchain. The Wormhole Core Layer contract address is usually stored in your contract address.
@@ -20,34 +17,25 @@ IWormhole core_bridge = IWormhole(wormhole_core_bridge_address);
 
 ## Primary functions
 
-The Wormhole Core Layer effectively only has two important interactions - (1) the ability to emit messages, and (2) the ability to parse and verify messages which originated from other chains.
+The Wormhole Core Layer effectively only has two important interactions -- (1) emit messages, and (2) parse and verify messages that originated from other chains.
 
 ### Emitting a Message
 
-- Always uses publish message
-- explain every argument
-- be sure to mention batch VAAs
-
 To emit a message, always use `publishMessage` which takes in the following arguments:
 
 1.  `nonce` (uint32): a number assigned to each message
     - The `nonce` gives the receving contract a mechanism by which to make sure it does not double process messages
     - Batch VAAs allow for easier compsability and better gas efficiency of multiple messages. To do this, messages emitted within the same transaction with the same nonce are bundled together into one aggregate message. Messages with a nonce of `0` will not be included in a Batch VAA and emitted individually.
-2.  `Consistency` (uint8): the number of blocks that Guardians will wait before signing a message.
+2.  `Consistency` (uint8): the number of blocks that Guardians will wait before signing a message
     - Each blockchain has different finality periods. In general, higher consistencies mean more security against blockchain reorgs.
     - [Here]() are the consistency levels by blockchain that are used by the xAsset layer to have a high level of guarantee against reorgs.
-3.  `Payload` (bytes[]): raw bytes to emit.
+3.  `Payload` (bytes[]): raw bytes to emit
     - It is up to the emitting contract to properly define this arbitrary set of bytes.
 
 `publishMessage` will output a `sequence` (uint64) that is used in conjunction with `emitterChainID` and `emitterAddress` to retrive the generated VAA from the Guardian Network.
 
 ### Parsing and Verifying a Message
 
-- Explain how a message should be taken in as a byte array
-- Be cognizant of Batch VAAs vs Single VAAs
-- entrypoint code vs module code. If using single VAAs, these are the same, but batch VAAs are more complicated to verify
-- remember to collect your gas after all the VAAs have been verified
-
 Parsing and Verifying a message will depend on the type of VAA that your application expects: a Single VAA or a Batch VAA.
 
 For either message type, remember to collect gas fees associated with submitting them on-chain after all VAAs have been verified.
@@ -56,7 +44,8 @@ For either message type, remember to collect gas fees associated with submitting
 
 To properly parse and verify a single VAA, always use `parseAndVerifyVM` which takes in one argument: `encodedVM` (bytes). This function will return three arguments:
 
-1. `vm` (VM): Structured data that reflects the content of the VAA. A breakdown of this message format is described in the [VAA](../../wormhole/4_vaa.md) section. It is up to the receving contracting to properly parse this data structure for the necessary information.
+1. `vm` (VM): Structured data that reflects the content of the VAA.
+    - A breakdown of this message format is described in the [VAA](../../wormhole/4_vaa.md) section. It is up to the receving contracting to properly parse this data structure for the necessary information.
 2. `valid` (bool): Boolean that reflects whether or not the VAA was properly signed by the Guardian Network
 3. `reason` (string): Explanatory error message if a VAA is invalid, or an empty string if it is valid.
 

src/technical/evm/overview.md

@@ -1,9 +1,14 @@
 # EVM
 
-explain that this is not a beginners guide to using EVM ecosystems, but rather a guide for how to use wormhole for experienced EVM developers.
+**Disclaimer**: This section is written as a guide for how to use Wormhole for experienced EVM developers. If you are new to using the EVM ecosystem, it's recommended for you to get started with a tutorial like [this]().
 
-For our purposes, EVM refers to any blockchain in the Wormhole ecosystem utilizing the EVM contracts of Wormhole. This includes not only Ethereum, but also blockchains like Polygon and Avax, as well as EVM+ environments like Acala.
+For our purposes, EVM refers to any blockchain in the Wormhole ecosystem that utilizes EVM contracts of Wormhole -- this includes blockchains beyond Ethereum such as Polygon or Avalanche, as well as EVM+ evnrionments such as Acala.
 
-Link to some recommended tooling
-ethers library,
-foundry is preferred and increasingly used by the core repository, truffle and hardhat also options
+### Recommended Tooling for EVM
+
+**Development**
+- [Ethers](https://docs.ethers.io/v5/) library
+
+**Testing**
+- [Foundry](https://github.com/foundry-rs/foundry) is preferred and increasingly used by the core repository
+- [Truffle](https://trufflesuite.com/) and [Hardhat](https://hardhat.org/) are also options

src/technical/evm/xassetLayer.md

@@ -4,12 +4,10 @@ This section will explain how to properly interact with the Wormhome Core Layer
 
 # Configuring the interface
 
-- Same as instantiating any other EVM interface / Core Layer / NFT Layer,
-
 [Here]() is the interface for applications to interact with Wormhole's xAsset layer.
 //TODO link to file in github so doesn't become stale
 
-Instantiating the interface will depend on your development ecosystem and blockchain. The Wormhole Core Layer contract address is usually stored in your contract address.
+Instantiating the interface will depend on your development ecosystem and blockchain. The Wormhole xAsset contract address is usually stored in your contract address.
 
 Below is an example line of code to instantiate the interface for mainnet Ethereum:
 
@@ -20,26 +18,14 @@ ITokenBridge token_bridge = ITokenBridge(wormhole_token_bridge_address);
 
 ## Registering New Tokens
 
-- Only needs to be done once globally ever
-- Reattesting will update metadata, can be done over and over
-- Generally not done by the xDapp contract, but instead by an off-chain process or by hand
-- Probably don't need code examples, as it's not advised to do this on chain for most usecases
-
 Attesting a token from EVM needs to happen once per token. If a token is not attested, it will not be claimable until so. However, there are no restrictions to reattesting a token; doing so will update the metadata.
 
-It is not advised to attest tokens on-chain for most usecases.
-
-To attest a token by an off-chain process, you can either do it by hand through one of the Token Bridge UIs (for example [Portal](https://www.portalbridge.com/#/transfer)) or using the JS SDK.
+It is not advised to attest tokens on-chain for most usecases. To attest a token by an off-chain process, you can either do it by hand through one of the Token Bridge UIs (for example [Portal](https://www.portalbridge.com/#/transfer)) or using the [JS SDK](https://www.npmjs.com/package/@certusone/wormhole-sdk).
 
 // If we want to show how to attest with JS SDK, have the example [here](https://book.wormhole.com/development/portal/evm/attestingToken.html)
 
 ## Basic Transfer
 
-- Code example for transferring an ERC-20, explain all the args, WORMHOLE ADDRESSES
-- Transferring native currency is a special case. Use transferETH for the native currency regardless of which EVM you are on.
-- Use this only if you are transferring to an end user wallet. If you're transferring to a smart contract (which you control), use transferWithPayload instead. Explain why
-- Mention public relayers, unwrapping conventions, fee schedule.
-
 Basic transfer should only be used if you are transferring messages to an end user wallet. If the end destination is a contract, you should only use Contract Controlled Transfers (described below). 
 
 It is important to note the transferring native currency is a special case of the Basic Transfer. As such, a different function call is provided as a QoL improvement when initiating and completing the transfer messaging when unwrapping the ETH is desired.
@@ -86,9 +72,6 @@ completeTransferAndUnwrapETH(VAA);
 
 ## Contract Controlled Transfer
 
-- Differences when compared to a basic transfer: has a payload, can only be redeemed if msg.sender == the recipient, doesn't have a relayer fee field because of the redemption restriction.
-- Always use this when the destination is a contract
-
 For any message transfers where the destination is a contract, you should always used Contract Controlled Transfers.
 
 There are a few main differences between Contract Controlled Transfers and Basic Transfers:
@@ -137,17 +120,3 @@ token_bridge.completeTransferWithPayload(VAA);
 // To complete transfer of native currency
 completeTransferAndUnwrapETHWithPayload(VAA);
 ```
-
-## Redemption
-
-### Basic Token Redemption
-
-- completeTransfer for everything
-- completeTransfer and unwrap Eth only for the case where unwrapping ETH is desired
-
-### Contract Controlled Transfer redemption
-
-- completeTransferWithPayload for everything,
-- completeTransferAndUnwrapETH as a QoL function. Unwraps the ETH before giving it to the contract.
-
-LUMPED THIS INTO PREVIOUS SECTIONS