EVM Build Doc Edits.

docs/build/evm/accounts.md

@@ -6,21 +6,21 @@ sidebar_position: 7
 
 :::info
 
-Are you a Cadence developer looking for information about Accounts on Cadence? If so, check out the Cadence specific documentation [here](../cadence/basics/accounts.md)
+Are you a Cadence developer who wants information about Accounts on Cadence? If so, check out the Cadence specific documentation [here]
 
 :::
 
 # Accounts
 
 There are three types of accounts used for Flow EVM.
 
-1. **Externally Owned Accounts (EOA)**: EOAs are controlled by private individuals using cryptographic keys and can initiate transactions directly. They are the primary account type for users to interact with the blockchain, holding and sending cryptocurrency or calling smart contract functions.
+1. **Externally Owned Accounts (EOA)**: EOAs are controlled by private individuals with cryptographic keys and can initiate transactions directly. They are the primary account type for users to interact with the blockchain, hold and send cryptocurrency, or call smart contract functions.
 2. **Contract Accounts**: These accounts hold smart contract code and are governed by this code's logic. Unlike EOAs, Contract Accounts do not initiate transactions on their own but can execute transactions in response to calls they receive from EOAs or other contracts.
-3. **Cadence Owned Accounts (COA)**: This is an account type unique to Flow EVM. These accounts are managed by [Cadence resources](https://cadence-lang.org/docs/language/resources) and can be used to interact with the Flow EVM from within the Cadence environment.
+3. **Cadence Owned Accounts (COA)**: This is an account type unique to Flow EVM. These accounts are managed by [Cadence resources] and you can use them to interact with the Flow EVM from within the Cadence environment.
 
-EOAs and Contract accounts function the same as on other EVM networks. Users may interact with these accounts using the standard EVM JSON-RPC API ([see endpoints here](./using.mdx)). You can read more about EOAs and Contract accounts on the [Ethereum docs](https://ethereum.org/developers/docs/accounts).
+EOAs and Contract accounts function the same as on other EVM networks. Users may interact with these accounts with the standard EVM JSON-RPC API ([see endpoints here]). You can read more about EOAs and Contract accounts on the [Ethereum docs].
 
-However, in order to leverage all the features of Cadence, developers will need to utilize Cadence Owned Accounts.
+However, to leverage all the features of Cadence, developers will need to use Cadence Owned Accounts.
 
 :::danger
 
@@ -36,34 +36,46 @@ We're working with major wallet providers to block such transfers, and recommend
 
 ## Cadence Owned Accounts
 
-A Cadence Owned Account (COA) is a natively supported EVM smart contract wallet type that allows a Cadence resource to own and control an EVM address. This native wallet type provides the primitives needed to bridge or control assets across Flow EVM and Cadence facilitating composability between environments.
+A COA is a natively supported EVM smart contract wallet type that allows a Cadence resource to own and control an EVM address. This native wallet type provides the primitives needed to bridge or control assets across Flow EVM and Cadence, which facilitates composability between environments.
 
 ![Account-Model](./flow-evm-account-model.png)
 
 ### Why use COAs?
 
 COAs create powerful new opportunities to improve the UX, functionality and utility of EVM applications by taking advantage of Cadence. Key benefits include:
 
-- **Enhanced Composability**: Applications written in Solidity can be extended and composed upon within Cadence. This allows developers to build upon existing EVM applications and deliver a more feature-rich user experience.
+- **Enhanced Composability**: Within Cadence, developers can extend and compose upon applications written in Solidity. This allows developers to build upon current EVM applications and deliver a more feature-rich user experience.
 
-- **Atomic Interactions**: Developers are able to execute multiple EVM transactions atomically from a COA. This is particularly useful for applications that require multiple transactions to be executed within a single block, or require all prior transactions' state changes to revert if a single transaction in the batch fails. This is not possible natively using EOAs or with `UserOperations` when using the ERC-4337 standard; in both cases each individual transaction is distinct and cannot be reverted back once state has changed.
+- **Atomic Interactions**: Developers can execute multiple EVM transactions atomically from a COA. This is particularly useful for applications that require multiple transactions to be executed within a single block, or require all prior transactions' state changes to revert if a single transaction in the batch fails. This is not possible natively with EOAs or with `UserOperations` when they use the ERC-4337 standard. In both cases, each individual transaction is distinct and cannot be reverted back after state changes.
 
-- **Native Account Abstraction**: COAs are controlled by Cadence resources, which are in turn owned by Flow accounts. [Flow accounts](./accounts.md) have built-in support for multi-signature authentication, key rotation, and account recovery. As a Cadence resource, COAs naturally inherit [these features](../cadence/advanced-concepts/account-abstraction.md).
+- **Native Account Abstraction**: COAs are controlled by Cadence resources, which are in turn owned by Flow accounts. [Flow accounts] have built-in support for multi-signature authentication, key rotation, and account recovery. As a Cadence resource, COAs naturally inherit [these features].
 
-- **Fine-Grained Access Control**: As Cadence resources, access to a COA can be governed by more sophisticated policies than those available with basic EVM accounts. By utilizing powerful Cadence access control primitives such as [capabilities and entitlements](https://cadence-lang.org/docs/language/access-control), developers can restrict who is able to interact with a COA and what actions they are permitted to perform.
+- **Fine-Grained Access Control**: As Cadence resources, access to a COA can be governed by more sophisticated policies than those available with basic EVM accounts. When developers use powerful Cadence access control primitives such as [capabilities and entitlements], they can restrict who can interact with a COA and what actions they can perform.
 
-### Differences from Traditional EVM Accounts
+### Differences from traditional EVM accounts
 
-COAs are smart contracts that are deployed to, and are fully accessible within, Flow EVM. However, unlike traditional EVM accounts (e.g. EOAs or smart contract accounts), COAs are owned by a Cadence resource. This means that COAs can be created and controlled natively within the Cadence execution environment.
+COAs are smart contracts that are deployed to, and are fully accessible within, Flow EVM. However, unlike traditional EVM accounts (for example, EOAs or smart contract accounts), a Cadence resource owns COAs. This means that the Cadence execution can natively create and control COAs.
 
-Unlike EOAs, COAs do not have an associated key, but are assigned a 20-byte EVM address upon creation from Cadence. This address is based on the UUID of the Cadence resource and is prefixed with `0x000000000000000000000002`. This address determines the location of the COA smart contract deployment and is the EVM address that is used to interact with the COA.
+Unlike EOAs, COAs do not have an associated key, but are assigned a 20-byte EVM address when they're created from Cadence. This address is based on the UUID of the Cadence resource and is prefixed with `0x000000000000000000000002`. This address determines the location of the COA smart contract deployment and is the EVM address that is used to interact with the COA.
 
-A COA may instantiate transactions itself (where the COA's EVM address acts as `tx.origin`). This behaviour differs from other EVM environments, where only externally owned accounts (EOAs) may instantiate transactions.
+A COA may instantiate transactions itself (where the COA's EVM address acts as `tx.origin`). This behavior differs from other EVM environments, where only EOAs may instantiate transactions.
 
-Because COAs are owned by Cadence resources, an EVM transaction is not required to trigger a transaction from a COA (e.g. a transaction to make a call to `execute` or EIP-4337's `validateUserOpMethod`). Instead, call transactions may be triggered directly from the Cadence resource that owns the COA. By invoking the `call` method on this resource, a transaction event will be emitted within the EVM environment.
+Because Cadence resources own COAs, an EVM transaction is not required to trigger a transaction from a COA (for example, a transaction to make a call to `execute` or EIP-4337's `validateUserOpMethod`). Instead, call transactions may be triggered directly from the Cadence resource that owns the COA. When developers invoke the `call` method on this resource, a transaction event will be emitted within the EVM environment.
 
-### More Information
+### More information
 
-To learn how to create and interact with COAs in Cadence, see the guide for [Interacting with COAs from Cadence](../../blockchain-development-tutorials/cross-vm-apps/interacting-with-coa.md).
+To learn how to create and interact with COAs in Cadence, see the guide for [Interacting with COAs from Cadence].
 
-For more information about Cadence Owned Accounts, see the [Flow EVM Support FLIP](https://github.com/onflow/flips/pull/225/files)
+For more information about Cadence Owned Accounts, see the [Flow EVM Support FLIP].
+
+<!-- Reference-style links, will not render on page. -->
+
+[here]: ../cadence/basics/accounts.md
+[Cadence resources]: https://cadence-lang.org/docs/language/resources
+[see endpoints here]: ./using.mdx)
+[Ethereum docs]: https://ethereum.org/developers/docs/accounts
+[Flow accounts]: ./accounts.md
+[these features]: ../cadence/advanced-concepts/account-abstraction.md
+[capabilities and entitlements]: https://cadence-lang.org/docs/language/access-control
+[Interacting with COAs from Cadence]: ../../blockchain-development-tutorials/cross-vm-apps/interacting-with-coa.md
+[Flow EVM Support FLIP]: https://github.com/onflow/flips/pull/225/files

docs/build/evm/fees.md

@@ -6,11 +6,13 @@ sidebar_position: 6
 
 :::info
 
-Are you a Cadence developer looking for information about Fees on Cadence? If so, check out the Cadence specific documentation [here](../cadence/basics/fees.md)
+Are you a Cadence developer who wants information about Fees on Cadence? If so, check out the Cadence specific documentation [here](../cadence/basics/fees.md)
 
 :::
 
-EVM transactions are ultra low-cost and use the native FLOW token as gas. [Externally Owned Accounts (EOAs)](./accounts.md) function the same on Flow as other EVM networks like Ethereum.
+# Fees
+
+EVM transactions are ultra low-cost and use the native FLOW token as gas. [Externally Owned Accounts (EOAs)] function the same on Flow as other EVM networks like Ethereum.
 
 <details>
 <summary><h2>How Transaction Fees are Computed on EVM</h2></summary>
@@ -22,9 +24,9 @@ Transaction fee on EVM = surge x [inclusion fee + (execution effort * unit cost)
 ```
 
 - `Surge' factor` dynamically accounts for network pressure and market conditions.
-- `Inclusion fee` accounts for the resources required to process a transaction due to its core properties (byte size, signatures). This is currently constant at 1E-4 FLOW, but subject to change with community approval.
-- `Execution fee` The fee that accounts for the operational cost of running the transaction script, processing the results, sending results for verification, generating verification receipts, etc. and is calculated as a product of `computation units` and the `cost per unit`.
-  - `Execution Effort (measured in computation units)` is based on transaction type and operations that are called during the execution of a transaction. The weights determine how costly (time-consuming) each operation is.
+- `Inclusion fee` accounts for the resources required to process a transaction due to its core properties (byte size, signatures). This is currently constant at 1E-6 FLOW, but subject to change with community approval.
+- `Execution fee` The fee that accounts for the operational cost of running the transaction script, processing the results, sending results for verification, generating verification receipts, and so on, and is calculated as a product of `execution effort units` and the `cost per unit`.
+  - `Execution Effort (computation)` is based on transaction type and operations that are called during the execution of a transaction. The weights determine how costly (time consuming) each operation is.
   - `Execution Effort Unit Cost` = `4E-05 FLOW` (currently constant, but subject to change with community approval)
 
 <h3>Calculation of Execution Effort</h3>
@@ -198,12 +200,22 @@ Thus
 Transaction fee = [1E-4 FLOW + (47.8 * 4E-05 FLOW)] x 1 = 2.012E-03 FLOW
 ```
 
-**Note**: Please be aware that this example serves solely for illustrative purposes to elucidate the calculations. Actual transaction fees may differ due to various factors, including the byte size of the transaction.
+:::info
+
+Be aware that this example serves solely for illustrative purposes to elucidate the calculations. Actual transaction fees may differ due to various factors, such as the byte size of the transaction.
+
+:::
 
 </details>
 
 ## Gasless Transactions
 
-Fees needed to execute transactions on a Web3 app are often a major challenge for new users and can be a barrier to adoption. Builders can easily extend their apps with Cadence to create ‘gasless’ experiences by specifying their app as the [sponsor](../cadence/advanced-concepts/account-abstraction.md#sponsored-transactions) instead of the user.
+Fees needed to execute transactions on a Web3 app are often a major challenge for new users and can be a barrier to adoption. To easily extend their apps with Cadence to create ‘gasless’ experiences, builders can specify their app as the [sponsor] instead of the user.
+
+To learn more about storage fee and transaction fee, visit [Flow Tokenomics page].
+
+<!-- Reference-style links, will not render on page. -->
 
-To learn more about storage fee and transaction fee, visit [Flow Tokenomics page](https://flow.com/flow-tokenomics/technical-overview).
+[Externally Owned Accounts (EOAs)]: ./accounts.md
+[sponsor]: ../cadence/advanced-concepts/account-abstraction.md#sponsored-transactions
+[Flow Tokenomics page]: https://flow.com/flow-tokenomics/technical-overview).