diff --git a/docs/build/evm/accounts.md b/docs/build/evm/accounts.md index cb6ff52253..3e88152bc8 100644 --- a/docs/build/evm/accounts.md +++ b/docs/build/evm/accounts.md @@ -6,7 +6,7 @@ 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] ::: @@ -14,13 +14,13 @@ Are you a Cadence developer looking for information about Accounts on Cadence? I 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,7 +36,7 @@ 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) @@ -44,26 +44,38 @@ A Cadence Owned Account (COA) is a natively supported EVM smart contract wallet 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]. + + + +[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 \ No newline at end of file diff --git a/docs/build/evm/fees.md b/docs/build/evm/fees.md index b68c8bef6f..060b1facb4 100644 --- a/docs/build/evm/fees.md +++ b/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.

How Transaction Fees are Computed on EVM

 @@ -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)

Calculation of Execution Effort

@@ -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. + +:::
## 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]. + + -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). \ No newline at end of file diff --git a/docs/build/evm/how-it-works.md b/docs/build/evm/how-it-works.md index 5ab153ed57..a02f1f3af3 100644 --- a/docs/build/evm/how-it-works.md +++ b/docs/build/evm/how-it-works.md @@ -6,14 +6,12 @@ sidebar_position: 3 # How Flow EVM Works -## Introduction - -The Flow network uses [Cadence](https://cadence-lang.org/) as its main execution environment. Cadence offers a safe, efficient, and developer-friendly experience for building smart contracts and decentralized applications. Cadence can be used to extend EVM apps built in solidity by unlocking gasless experiences, new business models and fine-tuned access control. With Flow offering full EVM support, existing applications and tools already deployed in the EVM ecosystem can simply onboard to the network with [no code changes](https://developers.flow.com/evm/about). +The Flow network uses [Cadence] as its main execution environment. Cadence offers a safe, efficient, and developer-friendly experience to build smart contracts and decentralized applications. Cadence extends EVM apps built in Solidity. It unlocks gasless experiences, new business models, and fine-tuned access control. Since Flow offers full EVM support, current applications and tools already deployed in the EVM ecosystem can simply onboard to the network with [no code changes]. Flow EVM is designed with these major goals in mind: -- Supporting EVM equivalency: Ensure that any tools and applications deployed to or run on Ethereum can also be deployed and run on Flow. -- Minimizing breaking changes to the Cadence ecosystem, software and tools +- Support EVM equivalency: Ensure that any tools and applications deployed to or run on Ethereum can also be deployed and run on Flow. +- Minimize breaking changes to the Cadence ecosystem, software and tools. - Maximum composability across environments: Allowing atomic and smooth interaction between EVM and Cadence environments.
@@ -28,85 +26,84 @@ Flow EVM is designed with these major goals in mind: >
-### EVM - A Smart Contract In Cadence +### EVM - a smart contract in Cadence -To satisfy the design goals and thanks to the extensibility properties of the Cadence runtime, Flow EVM is designed as a higher-level environment incorporated as a smart contract deployed to Cadence. This smart contract is not owned by anyone and has its own storage space, allows Cadence to query, and is updated through EVM transactions. EVM transactions can be wrapped inside Cadence transactions and passed to the EVM contract for execution. The artifacts of EVM transaction execution (e.g. receipts and logs) are emitted as special Cadence events (TransactionExecuted, BlockExecuted) and available to the upstream process (Flow transaction) to enable atomic operations. +To satisfy the design goals and thanks to the extensibility properties of the Cadence runtime, Flow EVM is designed as a higher-level environment incorporated as a smart contract deployed to Cadence. This smart contract is not owned by anyone and has its own storage space, allows Cadence to query, and is updated through EVM transactions. EVM transactions can be wrapped inside Cadence transactions and passed to the EVM contract for execution. The artifacts of EVM transaction execution (such as receipts and logs) are emitted as special Cadence events (TransactionExecuted, BlockExecuted) and available to the upstream process (Flow transaction) to turn on atomic operations. -The EVM environment has its own concept of blocks, and every Flow block includes at most one EVM Block. The EVM block is formed at the end of Flow Block execution and includes all the transaction executed during the EVM block execution. Note that since EVM blocks are formed onchain and Flow provides fast finality, as long as the user of these events waits for Flow block finality, it doesn’t have to worry about EVM block forks, uncle chains, and other consensus-related challenges. +The EVM environment has its own concept of blocks, and every Flow block includes at most one EVM Block. The EVM block is formed at the end of Flow Block execution and includes all the transaction executed during the EVM block execution. Since EVM blocks are formed onchain and Flow provides fast finality, as long as the user of these events waits for Flow block finality, it doesn’t have to worry about EVM block forks, uncle chains, and other consensus-related challenges. -### No Shared Memory Design +### No shared memory design -The interaction between two environments is through atomic calls and none of the environments has access to the raw memory of the other. This maintains the security properties of each environment. Cadence can submit transactions to the EVM environment and EVM transactions can make calls to a special precompiled contract called Cadence Arch. You can read more about this in the Precompiled section. +The interaction between two environments is through atomic calls and none of the environments has access to the raw memory of the other. This maintains the security properties of each environment. Cadence can submit transactions to the EVM environment and EVM transactions can make calls to a special precompiled contract called Cadence Arch. You can read more about this in the [Precompiled contracts] section. -### No New Native Token +### No new native token Flow EVM uses the same native token as Cadence (FLOW token). No new token is minted at the genesis block of EVM and all the tokens have to be bridged over from the Cadence side into the EVM side. To facilitate this a native bridge is provided by the EVM contract. ### EVM Equivalency -Under the hood, Flow EVM uses [the standard EVM implementation](https://github.com/ethereum/go-ethereum) and regularly applies updates through Flow’s height-coordinated updates (e.g. Execution layer changes planned for the Ethereum Prague update). This means anything that can run on Ethereum after the Pectra upgrade can run on Flow EVM. This means many useful EIPs such as [EIP-1014](https://eips.ethereum.org/EIPS/eip-1014), [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656), [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780), … are supported automatically. +Under the hood, Flow EVM uses [the standard EVM implementation] and regularly applies updates through Flow’s height-coordinated updates (such as execution layer changes planned for the Ethereum Prague update). This means anything that can run on Ethereum after the Pectra upgrade can run on Flow EVM. This means many useful EIPs such as [EIP-1014], [EIP-1559], [EIP-4844], [EIP-5656], [EIP-6780], are supported automatically. Yet a small set of differences between Flow EVM and Ethereum might be seen (mostly of the nature of extension) for two reasons: - A set of extensions has been added to ensure seamless and easy interaction between the two environments. -- Flow EVM is secured by the Flow network and benefits from its robust network properties, such as fast block production and finalization, making issues like handling uncle chains irrelevant. +- Flow EVM is secured by the Flow network and benefits from its robust network properties, such as fast block production and finalization, which makes issues like handling uncle chains irrelevant. ## Gateways -As mentioned, Flow EVM runs on top of the Flow network and its consensus model. Flow EVM does not leverage `geth` or introduce new node types to the existing architecture. Operators wishing to participate in securing the network stake tokens and run one of the Flow node types. +As mentioned, Flow EVM runs on top of the Flow network and its consensus model. Flow EVM does not leverage `geth` or introduce new node types to the current architecture. Operators who want help secure the network stake tokens and run one of the Flow node types. -To support `web3.js` clients, the [EVM Gateway](https://github.com/onflow/flow-evm-gateway) honors the Ethereum [JSON-RPC specification](https://ethereum.org/en/developers/docs/apis/json-rpc/). The gateway integrates with Flow access nodes and can be run by anyone (unstaked). It serves two purposes: +To support `web3.js` clients, the [EVM Gateway] honors the Ethereum [JSON-RPC specification]. The gateway integrates with Flow access nodes and can be run by anyone (unstaked). It serves two purposes: -### Gateway As A Light Client +### Gateway as a light client -The gateway follows Flow's block production, collecting, verifying and indexing EVM-related events. The gateway provides the necessary endpoints and services all JSON-RPC requests for third-party dapps interacting with Flow EVM. EVM events include all information needed to reconstruct the EVM state since the genesis block (replayability). By re-executing transactions, the gateway can collect traces and maintain a local and archival copy of the EVM state over time. +The gateway follows Flow's block production to collect, verify, and index EVM-related events. The gateway provides the necessary endpoints and services all JSON-RPC requests for third-party dApps that interact with Flow EVM. EVM events include all information needed to reconstruct the EVM state since the genesis block (replayability). When the gateway re-executes transactions, it can collect traces and maintain a local and archival copy of the EVM state over time. -### Gateway As a Sequencer +### Gateway as a sequencer -As mentioned, Flow EVM can be seen as a higher-level environment built on top of Cadence. Thus, all EVM transactions are ultimately handled using a Flow transaction (a wrapped call to the EVM). The gateway accepts EVM transactions, runs an internal mempool of transactions, wraps batches of EVM transactions in Flow transactions, and submits them. +As mentioned, Flow EVM can be seen as a higher-level environment built on top of Cadence. Thus, all EVM transactions are ultimately handled with a Flow transaction (a wrapped call to the EVM). The gateway accepts EVM transactions, runs an internal mempool of transactions, wraps batches of EVM transactions in Flow transactions, and submits them. -Note that the safety of transaction execution is not dependent on the gateway; they only relay the transaction. The safety measures of the EVM environment (e.g., Nonce, etc.) ensure that each transaction is executed at most once. Since gateways are submitting Flow transactions, they have to pay the related transaction fees. Part of these fees is associated with the computation fees of the EVM transaction. +The safety of transaction execution is not dependent on the gateway; they only relay the transaction. The safety measures of the EVM environment (for example, Nonce) ensure that each transaction is executed at most once. Since the gateways submit Flow transactions, they have to pay the related transaction fees. Part of these fees is associated with the computation fees of the EVM transaction. -To facilitate the repayment of fees, the `evm.run` function accepts a `coinbase` address, which collects gas fees from the transaction, and pays it to the address provided by the gateway node. Essentially, the transaction wrapper behaves similarly to a miner, receives the gas usage fees on an EVM address, and pays for the transaction fees. The gas price per unit of gas creates a marketplace for these 3rd parties to compete over transactions. +To facilitate the repayment of fees, the `evm.run` function accepts a `coinbase` address, which collects gas fees from the transaction, and pays it to the address provided by the gateway node. Essentially, the transaction wrapper behaves similarly to a miner, receives the gas usage fees on an EVM address, and pays for the transaction fees. The gas price per unit of gas creates a marketplace for these third parties to compete over transactions. -**Censorship Resistance and MEV Protection** +**Censorship resistance and MEV protection** -Since Flow EVM runs on the Flow network, it benefits from Flow’s protections against censorship and MEV attacks. The Flow network natively provides censorship & MEV resistance which is achieved by designating specific validators for building transaction bundles that are separated from the validators proposing blocks (proposer-builder separation). More details about this are available in Flow’s protocol [white papers](https://flow.com/technical-paper). -For extra protection on the EVM side, the gateway software is designed to be fully configurable and as lightweight as possible. This enables anyone with an account on Flow (e.g., any application) to run their own instances. +Since Flow EVM runs on the Flow network, it benefits from Flow’s protections against censorship and MEV attacks. The Flow network natively provides censorship and MEV resistance, which it achieves by designating specific validators to build transaction bundles that are separated from the validators that propose blocks (proposer-builder separation). More details about this are available in Flow’s protocol [white papers]. +For extra protection on the EVM side, the gateway software is designed to be fully configurable and as lightweight as possible. This allows anyone with an account on Flow (for example, any application) to run their own instances. -**Fee Market Change (EIP-1559)** +**Fee market change (EIP-1559)** -[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) is supported by the Flow EVM and Gateway nodes can decide on the inclusion of the transactions based on the tips or gas fees. The parameters for the EIP 1559 are adjustable by the Flow network. Currently, the base fee is set to zero, as EVM transactions are wrapped by the Flow transactions. +[EIP-1559] is supported by the Flow EVM and Gateway nodes can decide on the inclusion of the transactions based on the tips or gas fees. The parameters for the EIP 1559 are adjustable by the Flow network. Currently, the base fee is set to zero, as EVM transactions are wrapped by the Flow transactions. ## Block hash calculation difference -Developers using the GoLang Ethereum client to integrate with Flow will find that the block hash calculated by the Flow EVM RPC endpoints `eth_getBlockByNumber` and `eth_getBlockByHash` differ from the hash calculated locally by `go-ethereum`. This is due to underlying -differences in the `Block` implementation to support EVM on Flow. For more information see https://github.com/onflow/flow-evm-gateway/issues/719. +Developers who use the GoLang Ethereum client to integrate with Flow will find that the block hash calculated by the Flow EVM RPC endpoints `eth_getBlockByNumber` and `eth_getBlockByHash` differ from the hash calculated locally by `go-ethereum`. This is due to underlying differences in the `Block` implementation to support EVM on Flow. For more information, see [the issue in GitHub]. ## Opcodes -Flow EVM supports opcodes listed [here](https://www.evm.codes/?fork=cancun), except for the following changes. +Flow EVM supports opcodes listed [here], except for the following changes: - **COINBASE** (`block.coinbase`) - Similar to Ethereum it returns the address of block’s beneficiary address. In the case of Flow EVM, it returns the address of the current sequencer's fee wallet (see Gateway section for more details). + Similar to Ethereum, it returns the address of block’s beneficiary address. In the case of Flow EVM, it returns the address of the current sequencer's fee wallet (see the [Gateways] section for more details). - **PREVRANDAO** (`block.prevrandao`) - On Ethereum, this value provides access to beacon chain randomness (see [EIP-4399](https://eips.ethereum.org/EIPS/eip-4399)), Since Flow uses a different approach in consensus and verifiable randomness generation, this value is filled with a random number provided by the Flow protocol. While Flow EVM provides such opcode, it is recommended not to rely on this value for security-sensitive applications, as it is the case on Ethereum. In order to benefit from the full power of secure randomness on Flow, it's recommended to use the [Cadence Arch precompiles](https://github.com/onflow/docs/blob/main/docs/evm/how-it-works.md#precompiled-contracts). + On Ethereum, this value provides access to beacon chain randomness (see [EIP-4399]), Since Flow uses a different approach in consensus and verifiable randomness generation, this value is filled with a random number provided by the Flow protocol. While Flow EVM provides such opcode, it is recommended not to rely on this value for security-sensitive applications, as it is the case on Ethereum. In order to benefit from the full power of secure randomness on Flow, we recommend that you use the [Cadence Arch precompiles]. -## Precompiled Contracts +## Precompiled contracts -Besides all the precompiled contracts supported by Ethereum (see here for [the list](https://www.evm.codes/precompiled?fork=cancun)), Flow EVM has augmented this with a unique precompiled contract, the Cadence Arch, that provides access to the Cadence world. +Besides all the precompiled contracts supported by Ethereum (see here for [the list]), Flow EVM has augmented this with a unique precompiled contract, the Cadence Arch, that provides access to the Cadence world. Cadence Arch is a multi-function smart contract (deployed at `0x0000000000000000000000010000000000000001`) that allows any smart contract on Flow EVM a limited set of interactions with the Cadence environment. Functions currently available on the Cadence Arch smart contract are: -- `FlowBlockHeight() uint64` (signature: `0x53e87d66`) returns the current Flow block height, this could be used instead of Flow EVM block heights to trigger scheduled actions given it's more predictable when a block might be formed. -- `VerifyCOAOwnershipProof(bytes32 _hash, bytes memory _signature)(bool success)` returns true if the proof is valid. An ownership proof verifies that a Flow wallet controls a COA account (see the next section for more details on COA). -- `revertibleRandom() uint64` returns a safe pseudo-random value that is produced by the Flow VRF (using Flow internal randomness beacon). The function invokes Cadence's `revertibleRandom` described [here](https://developers.flow.com/build/cadence/advanced-concepts/randomness). Although the random value is safe, a transaction may revert its results in the case of an unfavourable outcome. The function should only be used by trusted calls where there is no issue with reverting the results. `getRandomSource` must be used instead with untrusted calls. -- `getRandomSource(uint64) bytes32` should be used when implementing a [commit-reveal](https://developers.flow.com/build/cadence/advanced-concepts/randomness#commit-reveal-scheme) scheme. It returns a secure random source from the Cadence randomness history contract. Learn more about the secure usage of randomness on Flow [here](https://developers.flow.com/build/cadence/advanced-concepts/randomness). +- `FlowBlockHeight() uint64` (signature: `0x53e87d66`) returns the current Flow block height. This could be used instead of Flow EVM block heights to trigger scheduled actions, given that it's more predictable when a block might be formed. +- `VerifyCOAOwnershipProof(bytes32 _hash, bytes memory _signature)(bool success)` returns true if the proof is valid. An ownership proof verifies that a Flow wallet controls a COA account (see the next section for more details on [COA]). +- `revertibleRandom() uint64` returns a safe pseudo-random value that is produced by the Flow VRF (via the Flow internal randomness beacon). The function invokes Cadence's `revertibleRandom` described [here]. Although the random value is safe, a transaction may revert its results in the case of an unfavourable outcome. The function should only be used by trusted calls where there is no issue if the result reverts. `getRandomSource` must be used instead with untrusted calls. +- `getRandomSource(uint64) bytes32` should be used when you implement a [commit-reveal] scheme. It returns a secure random source from the Cadence randomness history contract. Learn more about the secure usage of randomness on Flow [here]. -Here is a sample demonstrating how to call the Cadence Arch. +Here is a sample that demonstrates how to call the Cadence Arch. ```solidity address constant public cadenceArch = 0x0000000000000000000000010000000000000001; @@ -119,41 +116,72 @@ Here is a sample demonstrating how to call the Cadence Arch. } ``` -## Special Addresses +## Special addresses -### Native Token Bridge +### Native token bridge -Both Cadence and Flow EVM use the same token (FLOW) to run their operations. No new token is minted on the EVM side. Moving FLOW tokens easily across two environments has been supported natively by the EVM smart contract. Because the EVM have limited visibility into Cadence and to make tracking funds easier, every time Flow tokens are withdrawn from the Cadence side and deposited into an EVM address, the balance would be added to a special address `0x0000000000000000000000010000000000000000` (native token bridge) and then transferred to the destination EVM address. The bridge address always maintains a balance of zero. Clearly, this EOA address is a network address and is not controlled by public key. +Both Cadence and Flow EVM use the same token (FLOW) to run their operations. No new token is minted on the EVM side. The EVM smart contract natively supports easy FLOW token movement across two environments. Because the EVM have limited visibility into Cadence and to make tracking funds easier, every time Flow tokens are withdrawn from the Cadence side and deposited into an EVM address, the balance is added to a special address `0x0000000000000000000000010000000000000000` (native token bridge) and then transferred to the destination EVM address. The bridge address always maintains a balance of zero. Clearly, this EOA address is a network address and is not controlled by public key. ### Cadence-Owned Accounts (COAs) -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 provides the primitives needed to bridge or control assets across Flow EVM and Cadence. From the EVM perspective, COAs are smart contract wallets that accept native token transfers and support several ERCs including [ERC-165](https://eips.ethereum.org/EIPS/eip-165), [ERC-721](https://eips.ethereum.org/EIPS/eip-721), [ERC-777](https://eips.ethereum.org/EIPS/eip-777), [ERC-1155](https://eips.ethereum.org/EIPS/eip-1155), [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271). +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 provides the primitives needed to bridge or control assets across Flow EVM and Cadence. From the EVM perspective, COAs are smart contract wallets that accept native token transfers and support several ERCs including [ERC-165], [ERC-721], [ERC-777], [ERC-1155]. These smart contract wallets are only deployable through the Cadence environment and their address starts with the prefix `0x000000000000000000000002`. The address `0x0000000000000000000000020000000000000000` is reserved for COA factory, an address that deploys contracts for COA accounts. -A COA is not controlled by a key. Instead, every COA account has a unique resource accessible on the Cadence side, and anyone who owns that resource submits transactions on behalf of this address. These direct transactions have COA’s EVM address as the `tx.origin` and a new EVM transaction type (`TxType = 0xff`) is used to differentiate these transactions from other types of EVM transactions (e.g, DynamicFeeTxType (`0x02`). Currently, to make integration and tracking of these transactions byte EVM ecosystem tools, these types of transactions are encoded as legacy EVM transactions (hash computation is based on legacy tx rlp encoding). -Controlling through a resource makes a COA a powerful smart contract wallet. It makes the transfer of ownership of the EVM address super easy without the need to transfer all the assets that an EVM address owns. It also allows a Cadence smart contract to take ownership of an EVM address and makes fully decentralized exchange and bridges across environments possible. +A COA is not controlled by a key. Instead, every COA account has a unique resource accessible on the Cadence side, and anyone who owns that resource submits transactions on behalf of this address. These direct transactions have COA’s EVM address as the `tx.origin` and a new EVM transaction type (`TxType = 0xff`) is used to differentiate these transactions from other types of EVM transactions (for example, DynamicFeeTxType (`0x02`)). Currently, to make integration and tracking of these transactions byte EVM ecosystem tools, these types of transactions are encoded as legacy EVM transactions (hash computation is based on legacy tx rlp encoding). + +Control via a resource makes a COA a powerful smart contract wallet. It makes the transfer of ownership of the EVM address super easy without the need to transfer all the assets that an EVM address owns. It also allows a Cadence smart contract to take ownership of an EVM address and makes fully decentralized exchange and bridges across environments possible. -To learn more about how to interact with a COA from the Cadence side, [see here](../../blockchain-development-tutorials/cross-vm-apps/interacting-with-coa.md). +To learn more about how to interact with a COA from the Cadence side, [see here]. ## Proofs **Inclusion proof of execution artifacts (logs and receipts)** -Similar to other EVM environments, proof can be constructed for artifacts such as receipts. As mentioned earlier, all the EVM execution artifacts are collected as part of a Cadence event. Cadence events are similar to EVM logs, and the root hash of all events (event commitment) of a block is included in Flow's block content. The Cadence event inclusion proof functionality enables constructing proofs for any artifact. For example, if one wants to construct an external proof for the inclusion of a specific EVM log or receipt, here are the steps: +Similar to other EVM environments, proof can be constructed for artifacts such as receipts. As mentioned earlier, all the EVM execution artifacts are collected as part of a Cadence event. Cadence events are similar to EVM logs, and the root hash of all events (event commitment) of a block is included in Flow's block content. The Cadence event inclusion proof functionality allows you to construct proofs for any artifact. For example, if you want to construct an external proof for the inclusion of a specific EVM log or receipt, here are the steps: -- Flow block validation: Anyone following the Flow blocks can validate the Flow block headers. +- Flow block validation: Anyone who follows the Flow blocks can validate the Flow block headers. -- EVM block validation: Since each Flow block has the root hash of Cadence events emitted during block execution. It can construct and verify the inclusion of the specific Event. In this case, every time an EVM block is executed an `evm.BlockExecuted` event is emitted that contains the full EVM block information. +- EVM block validation: Since each Flow block has the root hash of Cadence events emitted during block execution, it can construct and verify the inclusion of the specific Event. In this case, every time an EVM block is executed an `evm.BlockExecuted` event is emitted that contains the full EVM block information. - Receipt inclusion: Each EVM block includes the root hash for the receipts generated during block execution. Similar to other EVM chains, a proof can be constructed to prove inclusion of a log or receipt. **Inclusion proof of transactions** -Each Flow EVM block (TransactionHashRoot) includes the Merkle root hash of all the transaction hashes executed during this block. Despite similar functionality, this root is a bit different than TransactionRoot provided by Ethereum, It is a commitment over the list of transaction hashes instead of transactions, so each leaf node in the Merkle tree has the transaction hash as the value instead of full RLP encoding of transaction. So verifying the proofs requires an extra calling to the hash function. +Each Flow EVM block (TransactionHashRoot) includes the Merkle root hash of all the transaction hashes executed during this block. Despite similar functionality, this root is a bit different than TransactionRoot provided by Ethereum. It is a commitment over the list of transaction hashes instead of transactions, so each leaf node in the Merkle tree has the transaction hash as the value instead of full RLP encoding of transaction. So, proof verification requires an extra call to the hash function. **Account proofs** Another type of proof that EVM environments provide is proof for the state of accounts. These proofs depend on the trie structure of the execution environment. Flow EVM benefits from the advanced storage and proof system that makes Flow’s multi-role architecture possible. -Flow’s state system provides ways to construct inclusion and non-inclusion proofs and one can construct proofs for EVM account’s meta data (account balances, nonce, … ). A less common proof type is proof over the storage state of an account (mostly used for smart contracts). The first release of Flow EVM won’t support these type of proofs. +Flow’s state system provides ways to construct inclusion and non-inclusion proofs and you can construct proofs for EVM account’s meta data (account balances, nonce, and so on). A less common proof type is proof over the storage state of an account (mostly used for smart contracts). The first release of Flow EVM won’t support these type of proofs. + + + +[Cadence]: https://cadence-lang.org +[no code changes]: https://developers.flow.com/evm/about +[Precompiled contracts]: #precompiled-contracts +[the standard EVM implementation]: https://github.com/ethereum/go-ethereum +[EIP-1014]: https://eips.ethereum.org/EIPS/eip-1014 +[EIP-1559]: https://eips.ethereum.org/EIPS/eip-1559 +[EIP-4844]: https://eips.ethereum.org/EIPS/eip-4844 +[EIP-5656]: https://eips.ethereum.org/EIPS/eip-5656 +[EIP-6780]: https://eips.ethereum.org/EIPS/eip-6780 +[EVM Gateway]: https://github.com/onflow/flow-evm-gateway +[JSON-RPC specification]: https://ethereum.org/en/developers/docs/apis/json-rpc/ +[white papers]: https://flow.com/technical-paper +[EIP-1559]: https://eips.ethereum.org/EIPS/eip-1559 +[the issue in GitHub]: https://github.com/onflow/flow-evm-gateway/issues/719 +[here]: https://www.evm.codes/?fork=cancun +[Gateways]: #gateways +[EIP-4399]: https://eips.ethereum.org/EIPS/eip-4399 +[Cadence Arch precompiles]: https://github.com/onflow/docs/blob/main/docs/evm/how-it-works.md#precompiled-contracts +[here]: https://developers.flow.com/build/cadence/advanced-concepts/randomness +[commit-reveal]: https://developers.flow.com/build/cadence/advanced-concepts/randomness#commit-reveal-scheme +[COA]: #special-addresses +[ERC-165]: https://eips.ethereum.org/EIPS/eip-165) +[ERC-721]: https://eips.ethereum.org/EIPS/eip-721 +[ERC-777]: https://eips.ethereum.org/EIPS/eip-777 +[ERC-1155]: https://eips.ethereum.org/EIPS/eip-1155 +[ERC-1271]: https://eips.ethereum.org/EIPS/eip-1271) +[see here]: ../../blockchain-development-tutorials/cross-vm-apps/interacting-with-coa.md \ No newline at end of file diff --git a/docs/build/evm/networks.md b/docs/build/evm/networks.md index c183b9464e..75b8d96794 100644 --- a/docs/build/evm/networks.md +++ b/docs/build/evm/networks.md @@ -30,12 +30,12 @@ Flow EVM has the following public RPC nodes available: | Currency Symbol | FLOW | | Block Explorer | https://evm-testnet.flowscan.io | -## EVM Specification +## EVM specification -- Flow EVM is a virtual EVM-based blockchain using the latest EVM byte-code interpreter `Geth v1.13` -- Utilizes `FLOW` token for transactions, with balances denominated in `Atto-FLOW` (1 `FLOW` = 10^18 `Atto-FLOW`) -- The [EVM Gateway](https://github.com/onflow/flow-evm-gateway) exposes the standard EVM API (Ethereum JSON-RPC) -- Read more about the implementation in [FLIP 223: EVM integration interface](https://github.com/onflow/flips/blob/main/protocol/20231116-evm-support.md) +- Flow EVM is a virtual EVM-based blockchain with the latest EVM byte-code interpreter `Geth v1.13`. +- Uses `FLOW` token for transactions, with balances denominated in `Atto-FLOW` (1 `FLOW` = 10^18 `Atto-FLOW`). +- The [EVM Gateway] exposes the standard EVM API (Ethereum JSON-RPC). +- Read more about the implementation in [FLIP 223: EVM integration interface]. ## JSON-RPC Methods @@ -94,8 +94,11 @@ Flow EVM has the following public RPC nodes available: **Legend**: ❌ = not supported. 🚧 = work in progress. ✅ = supported. -Read more about the [EVM Gateway](https://github.com/onflow/flow-evm-gateway) on Flow and how it implements the Ethereum JSON-RPC API. +Read more about the [EVM Gateway] on Flow and how it implements the Ethereum JSON-RPC API. + + +[FLIP 223: EVM integration interface]: https://github.com/onflow/flips/blob/main/protocol/20231116-evm-support.md [web3_clientVersion]: https://ethereum.org/en/developers/docs/apis/json-rpc/#web3_clientversion [web3_sha3]: https://ethereum.org/en/developers/docs/apis/json-rpc/#web3_sha3 [net_listening]: https://ethereum.org/en/developers/docs/apis/json-rpc/#net_listening @@ -168,3 +171,5 @@ Read more about the [EVM Gateway](https://github.com/onflow/flow-evm-gateway) on [txpool_status]: https://geth.ethereum.org/docs/rpc/ns-txpool#txpool_status [parity_pendingTransactions]: https://openethereum.github.io/JSONRPC-parity-module#parity_pendingtransactions [EIP-1186]: https://eips.ethereum.org/EIPS/eip-1186 +[EVM Gateway]: https://github.com/onflow/flow-evm-gateway + diff --git a/docs/build/evm/quickstart.md b/docs/build/evm/quickstart.md index ed2b4108d5..5e5b19dee5 100644 --- a/docs/build/evm/quickstart.md +++ b/docs/build/evm/quickstart.md @@ -17,9 +17,9 @@ keywords: # EVM Quickstart -Flow EVM is an EVM-equivalent blockchain that combines the advantages of Flow, including security, low-cost gas, and native VRF with compatibility with existing blockchain applications tools and contracts. If it works on another EVM-equivalent blockchain, it should work on Flow EVM! +Flow EVM is an EVM-equivalent blockchain that combines the advantages of Flow, such as security, low-cost gas, and native VRF with compatibility with current blockchain applications tools and contracts. If it works on another EVM-equivalent blockchain, it should work on Flow EVM! -This guide is a self-contained quickstart that walks you through deploying a contract on Flow EVM testnet with [Hardhat] and testing it with [testnet Flowscan]. +This guide is a self-contained quickstart that walks you through how to deploy a contract on Flow EVM testnet with [Hardhat] and test it with [testnet Flowscan]. If you prefer, check out our tutorials for [Remix] and [Foundry] for information on how to deploy a contract with those platforms. @@ -54,18 +54,18 @@ Flow EVM has the following public RPC nodes available: ## Objectives -After completing this guide, you'll be able to: +After you complete this guide, you'll be able to: -- Fund a wallet with testnet tokens from the [Flow Faucet] -- Deploy a contract on Flow EVM Testnet -- Interact with a contract using [Flowscan] -- Utilize automatically sponsored gas with the [Flow Wallet] on testnet **and mainnet** +- Fund a wallet with testnet tokens from the [Flow Faucet]. +- Deploy a contract on Flow EVM Testnet. +- Interact with a contract using [Flowscan]. +- Use automatically sponsored gas with the [Flow Wallet] on testnet **and mainnet**. ## Prerequisites ### Traditional cryptocurrency wallet -EVM [Accounts] created by the Flow wallet have unique properties that allow for powerful features, but they do **not** have recovery phrases or private keys that can be exported in a way that's compatible with [Hardhat]. As a result, you'll need to use a traditional EOA and [MetaMask] or the wallet of your choice to deploy your contracts. +EVM [Accounts] created by the Flow wallet have unique properties that allow for powerful features, but they do **not** have recovery phrases or private keys that you can export in a way that's compatible with [Hardhat]. As a result, you'll need to use a traditional EOA and [MetaMask] or the wallet of your choice to deploy your contracts. ## Deploy your contract @@ -100,7 +100,7 @@ Open a terminal window and navigate either to the folder where you wish to creat 3. Enter `.` if you ran the command from an empty folder, or enter a path. -4. Choose the defaults for the remaining options, then open the project in your editor. +4. Choose the defaults for the last options, then open the project in your editor. ### Environment setup @@ -121,7 +121,7 @@ The [private key] functions the same as the recovery phrase for a wallet. Anyone ### Hardhat config -We'll be using [OpenZeppelin Contracts] in the following steps: +We'll use [OpenZeppelin Contracts] in the following steps: 1. Install them and then open the project in your editor: @@ -151,7 +151,7 @@ We'll be using [OpenZeppelin Contracts] in the following steps: The default config is pretty bare. We'll need to add quite a few items. We'll do these one at a time, then provide a complete copy at the end. -5. Add a `networks` property containing the network information for Flow Testnet and Mainnet: +5. Add a `networks` property that contains the network information for Flow Testnet and Mainnet: ```tsx networks: { @@ -173,7 +173,7 @@ We'll be using [OpenZeppelin Contracts] in the following steps: } ``` -7. In it, add a property for `apiKey` and add keys for Flow Mainnet and Testnet. Note that the Etherscan API requires this to be here, but at the time of writing, API keys aren't actually needed. Any text can be used: +7. In it, add a property for `apiKey` and add keys for Flow Mainnet and Testnet. The Etherscan API requires this to be here, but currently, API keys aren't actually needed. You can use any text: ```tsx apiKey: { @@ -316,7 +316,7 @@ Deploy the contract with: npx hardhat ignition deploy ./ignition/modules/ClickToken.ts --network flowTestnet ``` -You should see something similar to: +You will see something similar to: ```bash ✔ Confirm deploy to network flowTestnet (545)? … yes @@ -351,7 +351,7 @@ Successfully verified contract "contracts/ClickToken.sol:ClickToken" for network - https://evm-testnet.flowscan.io//address/0x64366c923d5046F8417Dcd8a0Cb4a789F8722387#code ``` -## Testing the contract +## Test the contract To test the contract: @@ -360,35 +360,35 @@ To test the contract: ![read write contract](read-write.png) -3. Find the `mintTo` function and expand the UI to mint yourself a few tokens. You can click the `self` button to automatically add your address without needing to copy/paste. +3. Find the `mintTo` function and expand the UI to mint yourself a few tokens. You can click the `self` button to automatically add your address without the need to to copy and paste. -4. Once you've "earned" a few tokens, use `balanceOf` to see how many tokens you have. You can also use `getAllScores` to get a list of everyone with the tokens, and how many they have. +4. After you've "earned" a few tokens, use `balanceOf` to see how many tokens you have. You can also use `getAllScores` to get a list of everyone with the tokens, and how many they have. -### Testing with free gas +### Test with free gas -If you don't have it yet, set up the [Flow Wallet], connect, and try minting some more tokens. You'll see that the wallet automatically sponsors your gas: +If you don't have it yet, set up the [Flow Wallet], connect, and try to mint some more tokens. You'll see that the wallet automatically sponsors your gas: ![flow-wallet](sponsored-gas.png) -Even better, the [Flow Wallet] is currently **sponsoring transactions on mainnet** too! +Even better, the [Flow Wallet] currently **sponsors transactions on mainnet** too! ## Conclusion In this tutorial, you learned how to: -- Fund a wallet with testnet tokens from the [Flow Faucet] -- Deploy a contract on Flow EVM Testnet using Hardhat +- Fund a wallet with testnet tokens from the [Flow Faucet]. +- Deploy a contract on Flow EVM Testnet with Hardhat. - Interact with a contract using [Flowscan] -- Utilize automatically sponsored gas with the [Flow Wallet] on testnet and mainnet +- Use automatically sponsored gas with the [Flow Wallet] on testnet and mainnet. -You've now mastered the basics of deploying and interacting with EVM contracts on Flow. But this is just the beginning! Flow EVM's true power lies in its ability to combine the best of both worlds: EVM compatibility with Flow's native features. +You've now mastered the basics of how to deploy and interact with EVM contracts on Flow. But this is just the beginning! Flow EVM's true power lies in its ability to combine the best of both worlds: EVM compatibility with Flow's native features. -In our [Cross-VM Apps] tutorial series, you'll learn how to supercharge your EVM applications by integrating them with Flow Cadence. You'll discover how to: +In our [Cross-VM Apps] tutorial series, you'll learn how to supercharge your EVM applications when you integrate them with Flow Cadence. You'll discover how to: -- Build hybrid applications that seamlessly connect to both Flow EVM and Flow Cadence -- Use Cadence's powerful features to enhance your EVM contracts -- Enable multi-call contract writes with a single signature -- Take advantage of Flow's native features like VRF and sponsored transactions +- Build hybrid applications that seamlessly connect to both Flow EVM and Flow Cadence. +- Use Cadence's powerful features to enhance your EVM contracts. +- Enable multi-call contract writes with a single signature. +- Take advantage of Flow's native features like VRF and sponsored transactions. Ready to unlock the full potential of Flow EVM? Start with our [Batched Transactions] tutorial to learn how to build your first cross-VM application. diff --git a/docs/build/evm/using.mdx b/docs/build/evm/using.mdx index 963841f7ec..8d40c0b458 100644 --- a/docs/build/evm/using.mdx +++ b/docs/build/evm/using.mdx @@ -18,9 +18,9 @@ Flow Wallet is available on [Android](https://play.google.com/store/apps/details To use the Flow Wallet Chrome extension: 1. Open the Flow Wallet browser extension and create your account. -2. Connect to an app using Flow Wallet. +2. Connect to an app with Flow Wallet. -## Other EVM Wallets +## Other EVM wallets Applications deployed to Flow EVM will work with popular EVM-compatible wallets such as [MetaMask](https://chromewebstore.google.com/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn), all you need to do is add the correct [RPC endpoint](./networks) as a custom network. @@ -33,14 +33,14 @@ Applications deployed to Flow EVM will work with popular EVM-compatible wallets }} -### Add Manually to MetaMask +### Add manually to MetaMask Manual method: Add Flow EVM as a custom network to MetaMask: -1. Open the MetaMask browser extension -2. Open the network selection dropdown menu by clicking the dropdown button at the top of the extension -3. Click the **`Add network`** button -4. Click **`Add a network manually`** +1. Open the MetaMask browser extension. +2. Click the dropdown at the top of the extension to open the network selection dropdown menu. +3. Click **`Add network`**. +4. Click **`Add a network manually`**. 5. In the **`Add a network manually`** dialog that appears, enter the following information: | Name | Value | @@ -52,9 +52,9 @@ Manual method: Add Flow EVM as a custom network to MetaMask: | Currency Symbol | FLOW | | Block Explorer | https://evm.flowscan.io/ | -6. Tap the Save button to save Flow EVM as a network. +6. Tap Save to save Flow EVM as a network. -You should now be able to connect to the Flow EVM by selecting it from the network selection dropdown menu. +To connect to the Flow EVM select, it from the network selection dropdown menu. To additionally add the Flow EVM Testnet to MetaMask, follow the same steps as above, but use the following information: @@ -67,4 +67,4 @@ To additionally add the Flow EVM Testnet to MetaMask, follow the same steps as a | Currency Symbol | FLOW | | Block Explorer | https://evm-testnet.flowscan.io | -Use the [Flow Testnet Faucet](https://faucet.flow.com/fund-account) to fund your account for testing. +Use the [Flow Testnet Faucet](https://faucet.flow.com/fund-account) to fund your account for testing. \ No newline at end of file