# Acala EVM Smart Contracts Documentation
This will be published on [wiki](https://wiki.acala.network/)
Supplementary design doc on miro [here](https://miro.com/app/board/o9J_lYGSfSo=/?utm_source=notification&utm_medium=email&utm_campaign=mentions&utm_content=header)

## LEARN

- Learn
- Basics
- Acala EVM
- Why Acala EVM (Background, Current Solution)
- Unique Offerings
- How it Works
- Test Drive

- Build
- Development Guide
- Smart Contracts
- Get Started
- Acala Nodes
- Set up Acala Console
- Set up EVM Playground
- Use Remix
- Use Waffle
- Deploy Contracts via Playground
- Advanced Topics
- Single Account for Substrate & EVM
- Use Native (Cross-chain) Tokens in EVM
- Flexi Fee: Pay fees in any token
- On-chain Auto Scheduler
- Coming Soon

### Background

EVM is currently the most popular smart contract platform. Many new generation blockchains who claim to be faster and cheaper than Ethereum, would still keep the Ethereum compatibility, to attract Solidity developers allowing them to reuse existing toolchains and migrate existing contracts with minimal effort. Despite how bloated and expensive Ethereum has become, none of the challenger chains have taken any significant market share thus far.

It is clear to us that building a better, faster and cheaper Ethereum is not nearly enough. Just like Ethereum can do things Bitcoin can never do, which subsequently inspired many new innovations, Substrate and Polkadot are categorically different from Ethereum that will empower many new (chain level) innovations outside of the EVM sandbox.

On the Acala chain, there’re DeFi primitives (stablecoin, DeX and liquid staking), liquidity and users that can be tapped into, there are also innovations that are simply not possible on Ethereum - customizable economic policy, flex-Fee, allowing users to pay transaction fee with any supported tokens; native cross-chain capabilities; on-chain governance apparatus (no more locked funds); full upgradability (no more contract migrations) and more.

We’d love to have all of these composable and compatible with EVM.

### Current Solutions

Current Substrate EVM compatibility solution i.e. [Frontier](https://github.com/paritytech/frontier) emulates the Ethereum node. It aims to implement the full set of Ethereum RPC and to emulate Ethereum block production process. This allows existing Ethereum tools such as Metamask and Remix to work with a Frontier enabled node seamlessly.

Integrating Frontier has revealed the following challenges by their severity:

#### 1. **Confined inside the EVM Sandbox**
Frontier allows users to interact with EVM via Metamask or other existing Ethereum tools, none of which fully support Substrate yet. Any functionalities from native modules of Substrate, such as Acala DeX, token pallets that support multiple currency and cross-chain capability, and any other pallets built by any parachains such as margin trading pallet by Laminar can not be accessed via Metamask or other existing Ethereum tools.

This means users will need to use a Substrate wallet (e.g. Polkadot-js Extension) and Metamask at the same time if they ever want to taste the real power of Acala, Substrate or Polkadot for that matter. This is certainly a deal-breaker for us.

#### 2. **Making Nodes more Expensive**
Frontier is heavy by design. Substrate does not store transactions by hash nor historical events, nor does it provide any event filtering ability. Substrate nodes are lightweight by design in order to minimize resource usage (disk space & CPU).

Ethereum nodes, on the other hand, allow users to query transactions by hash and offer powerful event log querying API. Frontier injects special block importing logic, storing the transactions and events into an off-chain auxiliary store in order to power the query API required by Ethereum.

This adds maintenance costs as it requires more powerful machines and larger disk space to operate a node. This goes against the goal to have a lightweight node to lower barriers for people from anywhere to run nodes which helps the network to be more decentralized.

### Acala EVM - Code Name: Project Bodhi

Acala and all Substrate-based chains are fundamentally different from Ethereum. If we are trying to emulate an Ethereum node, we will suffer from the worst of both worlds. It will be a step backwards for us to inherit all the restrictions from a legacy blockchain platform.

We see EVM as one part of the Acala/Substrate/Polkadot, but EVM in itself does not provide the categorically different experience. Acala EVM will try to achieve these design goals

1. Enable users to have a complete full-stack Acala (and Substrate) experience seamlessly with a single wallet.
2. Enable protocol composability for EVM and runtime
3. Enable developers to develop and deploy DApps on Acala with great tooling support.

The Acala EVM delivers the following benefits from the best of both Ethereum and Substrate platforms:

#### 1. **Fully Composable DeFi Primitives in EVM and Runtime**
Smart Contract Dapps deployed in Acala EVM can directly use native and cross-chain assets such as DOT, ACA, aUSD, renBTC etc. ERC-20 tokens deployed in EVM can also be made available at runtime level, to be listed in the DeX, or (by governance approval) to be used as fee token. For example, Amplforth will deploy AMPL contract on Acala EVM, which will be made available as native token, so it can be used to pay transaction fees and listed direclty on our DeX.

Smart Contract Dapps can soon directly use Acala DeFi primitives (DeX, stablecoin lending, and liquid staking), bridges, native and cross-chain liqudity to compose various interesting DeFi applications, such as lending, special-purpose DeX, financial products based on staking and more.

The process is seamless for users and developers, but behind the scene native tokens and runtime modules are made available in EVM in the form of precompiled contracts. A transaction initiated by a smart contract in EVM are translated into a Substrate transaction and signed by any Polkadot extensions using polkadot.js. The response will be processed by the SDK ([bodhi.js](https://github.com/AcalaNetwork/bodhi.js)) and converted into an Ethereum compatible format.

#### 2. **Flexi Transaction Fees**
On Acala, fees can be paid in any accepted tokens e.g. ACA, aUSD, DOT, BTC etc. More tokens can be supported as native fee token with governance approval.

Behind the scene, Acala DeX is being used as unified liquidity pool for settling the fees into the network token, but the experience is completely transparent to users and developers.

#### 3. **Single Wallet, Single Account Experience**
Users can use **one extension/wallet**, and **a single Substrate account** to interact with the Substrate runtime, contracts in EVM, and wasm contracts or a hybrid of these. If a user wants to use a particular Ethereum address, then simply link it with his/her Substrate address (basically proving the user owns both addresses), thereafter the user can just use the Substrate account to sign any Ehtereum transactions seamlessly.

This allows users to use all functionalities within Acala and cross-chain capabilities without managing multiple accounts or wallets.

#### 4. Keep Nodes Lightweight while Query Capability Intact
We retain the standard Substrate node which is lightweight and easily maintainable. For querying transactions and event logs, we offer an indexer node that is open sourced and anyone can run a copy of it like a full-node.

For convenience, we'd offer one docker image to run both nodes, but it is important that there's a choice for people who want to run one or another for their pruposes.

#### 5. **Upgradable Smart Contracts**.
In Acala EVM, developers no longer need to write complex migration contracts to fix bugs or make improvements to exisitng applications. Contract maintainer can simply send a transaction with the new contract byte-code to seamlessly upgrade the contracts, without the need to `migrate` users nor liquidity.

There's also a two-staged deployment process to reduce the risk of directly testing on mainnet with the public.
- **Deployed Private Contract**: Once a contract is deployed, it is by default private to the public and visible only to the `Contract Maintainer` (who deployed the contract) and opt-in developers. All necessary testing and final verification can be done before making it public. `Contract Maintainer` can also remove the contract at this stage if needed.
- **Deployed Public Contract**: `Contract Maintainer` can make the contract public aka open business to the public.

To incentivize users to be mindful of acquiring storage on a public ledger, and also in effect to reduce scams, we use `State Renting` mechanism. `Contract Maintainer` is required to put up a bond when deploying a contract, which will be refunded when the contract is removed from the chain.

Some barriers of entry would encourage more responsible behaviours, and we are constantly researching the space for better mechanisms to achieve this.

#### 5. **Compatible Developer Tooling**
Acala EVM enables developers to develop, test and deploy DApps with existing tooling support, such as [Remix](https://remix.ethereum.org/) and [Waffle](https://getwaffle.io/). More toolchains will be added as we progress.

Existing Solidity DApps and node.js applications can communicate with Acala nodes with minimum changes. Developers can use Acala's web3 provider [bodhi.js](https://github.com/AcalaNetwork/bodhi.js) to interact with an Acala node seamlessly.

#### 5. No dust accounts
There are cases when acounts are almost emptied, leaving small amount of funds not enough to pay for a transaction. These are called "dust accounts". In Acala we use "Existensial Deposit" (ED) as minimum amount of funds the account can hold. If the threshhold is hit, the account is emptied, and "dust" goes to the Acala tresury.
ED is different depends on the asset, and and for now it works only for Native Tokens and are not applied to ERC-20 tokens in Acala EVM.
ED helps to keep blockchain cleaner from abandoned accounts which in long term sustains small size of nodes and cheaper transaction fee.

### How does Acala EVM work?

Project Bodhi is Acala’s answer to composable EVM compatibility.


Instead of emulating the full Ethereum RPC node ([Frontier](https://github.com/paritytech/frontier) approach), we emulate Ethereum JavaScript SDK client experience (by implementing a web3 provider as Bodhi.js).

This initiative has received an Open Grant from Web3 Foundation, and is under development. Read more [here](https://github.com/AcalaNetwork/Open-Grants-Program/blob/master/applications/project_bodhi.md).

# Development Guide

## Getting started

### Acala Nodes

To test out Acala EVM, you need to be connected to the Acala Network. And here you have 2 options:
1. run a local Acala test node
2. connect to a deployed test network (maintained by Acala)

#### Run a local Acala test node

To run your own node, you need to have installed [Docker](https://www.docker.com/) on your machine. If you don't have it installed, please follow the instructions [here](https://docs.docker.com/get-docker/).

To check whether Docker is successfully installed run command:

docker version

If you receive the version number, you can start your local Acala node typing:

docker run -it -p 9944:9944 -p 9933:9933 acala/aca-node:726aa9a --dev --ws-external --rpc-external

The output of your node should look like this:


#### Connect to a deployed test network
Find all available testnet nodes [here](https://wiki.acala.network/learn/get-started/public-nodes#mandala-test-network-nodes)

### Setting up Acala Substrate Console

Substrate console is used to communicate with runtime modules, through it you can transfer funds, vote for proposals, stake your coins and interact with any endpoint accessible in the network.

To open the Substrate Console, navigate to https://console.acala.network/.

Open a dropdown on the top right corner

Select "Development" section and there you can choose between custom endpoint and Local Node


If you are running your own node, pick "Local Node", otherwice select "Custom" and paste in the "custom endpoint" input next:

wss://node-6757141250775003136.rz.onfinality.io/ws?apikey=086df60c-6a2d-414e-add2-cc0b74b6d00b

After pressing "Switch" on the top, wait till network will restart. If your current endpoint matches your selection, "Switch" button will be disabled.

To Verify that the console is properly connected, let's try to check the balance.

In Substrate console pick Developer in top navigation tab, and in opened list select "Chain State".


In the opened window pick selected state query - select "token" from opened dropdown; choose "accounts" method and select AccountId - Alice and Token - DOT. After press "+" button to initiate the call.


If below appeared the box with current state of balance of Alice, everything works well.


### Setting up Acala EVM Playground

We have created EVM playground for easy development and deployment Solidity smart contracts in Acala EVM.

To launch the playground, please navigate to https://acala-evm.vercel.app/.

By default the playground is trying to connect to test sustained by Acala test network, or, if you used playground previously, to the last accessed network.
To select connection endpoint press setting button in bottom right corner.


if you open dropdown with list of networks, you will see:
- Local Node (standart local node address/port)
- Acala (test network)


If you running Acala Locally, pick "Local Node", otherwise use "Acala".
Optionally you can use custom endpoint.

To verify that the you are connected and can interact with EVM, let's check your DOT's balance.

On the left sidebar press "Execute". You will see list of precompiled contracts - they essentially expose native assets like ACA, aUSD and DOT to be used in the EVM. Select the one with name "DOT" and press "Execute" under it.


In the opened page select Account - Alice. Pick "Message to Send" - "balanceOf". After the account find "EVM address" and copypaste it to the "owner: address" field. And press "Call" in the bottom of the page.


Below should appear window "Call results", it will contain the state of Alice's account.

If you see it, everything works well!

---

Now as we finish setting up the environment, we can explore developing and compiling Solidity smart contracts.

You can use
- online web app Remix OR
- cli / programming tools like waffle.js

### Compile a Solidity Contract using Remix

This guide walks through the process of creating and deploying a Solidity-based smart contract to the Acala standalone node using the [Remix](http://remix.ethereum.org/). Remix is one of the commonly used development environments for smart contracts on Ethereum.

#### 1. Launch Remix
Navigate to https://remix.ethereum.org/. In the main screen, under `Environments`, select `Solidity` to configure Remix for Solidity development, then navigate to the File Explorers view.

Here's an example to compile an ERC20 contract using Remix.


We will create a new file to save the Solidity smart contract. Hit the "+" button under File Explorers and enter the name "BasicToken.sol" into the popup dialogue:

#### 2. Compile the Solidity code

Now let's paste the following smart contract into the editor tab that comes up:

pragma solidity ^0.7.0;

import 'https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v3.2.0-solc-0.7/contracts/token/ERC20/ERC20.sol';

// This ERC-20 contract mints the specified amount of tokens to the contract creator.
contract BasicToken is ERC20 {
  constructor(uint256 initialSupply) ERC20("BASICT", "BAT") public {
    _mint(msg.sender, initialSupply);
  }
}

This is a simple ERC-20 contract based on the current Open Zeppelin ERC-20 template. It creates BasicToken with symbol BAT and mints the entirety of the initial supply to the creator of the contract.

Once you have pasted the contract into the editor it should look like this:


Now navigate to the compile sidebar option to press the “Compile BasicToken.sol” button. You will see Remix download all of the Open Zeppelin dependencies and compile the contract.

#### 3. Get the ABI File
Navigate to files and in "artefacts" section copy the content of `BasicToken.json` file.

Save the copied content** in a `BasicToken.json` file.


### Compile Solidity Contract using Waffle

**Note:** you can skip this section if you compiled the smart contract with Remix.

This guide walks through the process of deploying a Solidity-based smart contract to Acala using [Waffle](https://github.com/EthWorks/Waffle). Waffle is one of the most commonly used smart contract development framework for Ethereum.

#### 1. Check Prerequisites

First, we need to install Node.js (we use v15.x in this example) and the npm package manager. You can do this by running in your terminal:

curl -sL https://deb.nodesource.com/setup_15.x | sudo -E bash -

sudo apt install -y nodejs

We can verify that everything installed correctly by querying the version for each package:

node -v

npm -v

#### 2. Install Waffle

You can download the project with all the dependencies here: [AcalaNetwork/evm-examples](https://github.com/AcalaNetwork/evm-examples).
To do this, clone the repository and install dependencies:

git clone https://github.com/AcalaNetwork/evm-examples
cd evm-examples

npm install 
# or
yarn install

To explore the process in more details, you can create this project following step-by-step instuctions:

Create a folder

mkdir smart-contract-waffle
cd smart-contract-waffle

Init npm dependencies

npm init -y

Install all required dependencies

npm i -D @openzeppelin/contracts@3.3.0 ethereum-waffle@3.2.1 

We recommend installing dependencies with exact versions to avoid breaking changes in future releases.

After, create a waffle settings file

touch waffle.json

and paste the following in the json file

 {
    "compilerType": "solcjs",
    "compilerVersion": "0.6.2",
    "sourceDirectory": "./contracts",
    "outputDirectory": "./build"
  }

This sets up the solidity compiler with version `0.6.2`, compiles contracts from "./contracts" folder and saves the bytecode output and ABI files to "./build" folder.

#### 3. Compile the Solidity Conract

Now let's create "./contracts" folder and add our first smart contract:

mkdir contracts
touch contracts/BasicToken.sol

Insert into contracts/BasicToken.sol the content:

pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

// Example class - a mock class using delivering from ERC20
contract BasicToken is ERC20 {
    constructor(uint256 initialBalance) public ERC20("Basic", "BSC") {
        _mint(msg.sender, initialBalance);
    }
}

Now everything is ready to compile the smart contract into ABI and bytecode. Type in your terminal:

npx waffle

#### 4. Get the ABI file
Waffle will generate output into `./build` folder. For the next section we will need `./build/BasicToken.json` file to deploy it to Acala. Note: the same file was created with Remix in previous section.

Waffle also provides a full suite of testing utilities, check out their documentation and code samples [here](https://github.com/EthWorks/Waffle).

### Deploying Contracts in Acala EVM Playground
We created a web application `Acala EVM Playground` to test various functionalities of Acala EVM. The source code is [here](https://github.com/AcalaNetwork/evm-playground) and it's a fork from parity `canvas-ui`.

#### 1. Upload Contract ABI
Let's deploy the ABI file (compiled contracts) by navigating to https://acala-evm.vercel.app/. Go to the `Upload` tab.


Fill in the contract name, then upload the contract ABI`BasicToken.json`.


Then it would display a list of available methods in the contract. Then click `Upload`.

#### 2. Deploy the Contract

After uploading the ABI, the Playground would automatically navigate to the `Upload` step. If not, just select `Deploy` in the left sidebar. You shall see the ABI bundle there.

Click the `Deploy` button, and choose `Alice` as deployment account.

Note: the test node has been pre-loaded with a bunch of developer accounts, and Alice is one of the pre-funded accounts.


Set the initial supply of your new token (e.g. `10000000000000`) and press `Deploy`.


Now you can see the deployed contract in the execute section.


#### 3. Interacte with the Contract

Navigate to the `Execute` tab. You can see the deployed contract there. Click the `Execute` button.


#### 4. Query balance

Use the dropdown list for executable methods. Query Alice's balance using `balanceOf`. Find Alice's Ethereum address, and provide it as the method argument.


Press `Call` and check out returned results below.

**Note:** Solidity smart contracts can have 2 kinds of methods: `views` and `executable` methods. `Views` are used to query information from the blockchain without writing data to it. `Views` transactions are free. Click the `Call` button to execute it.

`Executable` methods can write data onto the blockchain, and these transactions aren't free. Click the `Execute` button to execute it.


You should see the balance of Alice in the appeared section below ("Call results").

#### 5. Transfer
Let's transfer some BasicTokens to Bob's Account.

Select Bob's account from the `Call from Account` dropdown, then copy its Ethereum address (`EVM address`).

Switch account back to Alice, select `transfer` from the `Message to Send` dropdown.

Paste Bob's EVM address in the `recipient address` input box.

Then set the amount to send (note that the amount should have at least 5 zeros).

Click `Execute`.


A notification would pop-up to confirm the transaction is successful.


Now check the balances of Alice and Bob, how have they changed?



### Single Account for Substrate and EVM

#### Auto Generated EVM Account

By default, the system automatically generates an EVM address for each Substrate account. When funds are sent to a Substrate address inside EVM, it will automatically be synced to the Substrate-generated EVM account.

Any balance changes of native tokens such as ACA, DOT, and aUSD on the generated EVM account, will be synced to the linked Substrate account to ensure integrity.

[TODO] provide address format details of EVM address.

#### Use Exisitng Ethereum Addresses

In any case if users want to use an existing Ethereum address, he/she will need to bind this address to a Substrate account. One Substrate account can only be linked to one Ethereum address at a time. All previous balances on the Ethereum address will be synced to the newly binded Ethereum address.

Binding requires users to prove they also own the Ethereum addresses, by signing a `claim` transaction.

Below are two potential use cases of binding an existing Ethereum address.

##### Use Case 1

For example, a DeFi protocol on Ethereum is now expanding its operation to Polkadot, by deploying their contracts on the Acala network. They will this new branch by airdropping tokens to their existing users if they also use the protocols on Acala.

The easiest way is to airdrop tokens to existing Ethereum addresses on Acala. Hence users would just bind their current Ethereum address to a Substrate address, use it for any EVM transactions, and receive airdrops.

##### Use Case 2

For DApps like [Linkdrop](https://linkdrop.io/), users are required to sign messages using Ethereum private key. Using Linkdrop on Acala, would require users to claim their existing Ethereum address, and bind it to their Substrate account. Thereafter they can send transactions on behalf of the Ethereum account.

#### Binding an Existing Ethereum account

Navigate to "EVMAccount" in left sidebar.

In the opened page, pick a free account and press "Claim":


Note, claim an Ethereum address is a transaction that are not free, so be sure to fund the account with any native tokens native tokens e.g. ACA, DOT or aUSD on the Acala Substrate Consle before sending it.

## Advanced EVM Features

### 1. Using Native Tokens in EVM.

All Acala Native tokens (defined in the runtime) including ACA, DOT, aUSD, renBTC etc. are also deployed as pre-compiled contracts in the EVM. They are accessible by any smart contracts, and their balances are synchronized between Substrate and associated Ethereum addresses.

#### Native Token Pre-Compiled Contract Addreses
Below is a list of smart contract addresses for native tokens:

| Symbole | Address |
| -------- | -------- |
| **ACA** | `0x0000000000000000000000000000000000000800` |
| **AUSD** | `0x0000000000000000000000000000000000000801` |
| **DOT** | `0x0000000000000000000000000000000000000802` |
| **ACA** | `0x0000000000000000000000000000000000000800` |
| **ACA** | `0x0000000000000000000000000000000000000800` |
| **ACA** | `0x0000000000000000000000000000000000000800` |
| **ACA** | `0x0000000000000000000000000000000000000800` |

- name: **XBTC**
address: `0x0000000000000000000000000000000000000803`

- name: **LDOT**
address: `0x0000000000000000000000000000000000000804`

- name: **RENBTC**
address: `0x0000000000000000000000000000000000000805`

- name: **StateRent**
address: `0x0000000000000000000000000000000000000806`

- name: **Oracle**
address: `0x0000000000000000000000000000000000000807`

#### Check Balances of Native Tokens via Susbtrate

Each native token transactions in EVM would call upon functions in the corresponding runtime modules/pallets. Subsequently it will synchronize Substrate accounts with their assoicated Ethereum addresses, and vice versa.

Let's make a transaction in Substrate to see how it affects EVM. Ensure that your EVM Playground and Substrate console connected to the same network (check the guide [here](...fill link)).

Let's check the current balance of test Account `Alice` via the console. Navigate to `Developer` - `Chain State` to query balances.


In opened tab, select "token" module.

Select module function "Accounts" (likely to be preselected), choose `Alice` in `AccountId` dropdown, then pick `DOT` from the `TokenId` dropdown.

Click the `+` button on the top right corner to query.


Note down the current balance of Alice.

Repeat the above process with `Bob` and note down Bob's balance of DOT.


#### Check Balances of Native Tokens via EVM

Go to EVM Playground https://acala-evm.vercel.app/, navigate to the `Execute` tab, select the `DOT` contract, then click `Execute` button.


In the execution page, select `Alice` as the `Call from Account`, pick `balanceOf` method as the `Message to Send`.

Paste Alice's ethereum address as the `owner: address` in the argument. Then press `Call`.


Scroll down to the bottom to see the result.


**Note** the difference between what's returned here versus in the console. The console returns `668.4390 kACA`, the Playground returns`668439000000000000000000`. All tokens on Acala have 18 decimals. 'kACA' represents a thousand of DOTs. So these two results are essentially different unit representation for the same amount.

Future releases will improve the UX to use `kDOT` or respective symbols for different tokens.

Repeat the same process to check Bob's balance.


#### Transfer Native Tokens via EVM

Next, let's transfer some DOTs from Alice to Bob.

Under the `Execute` tab, navigate to the `DOT` contract.

Then change the `Call from Account` to Alice, select `transfer` as the `Message to Send`.

Paste Bob's address in the `to: address` argument.

Enter value e.g. `10000000000000000000` (10 DOTs = 1x10^18).

And press `Execute`.


After the transaction is completed, check balances of Bob and Alice in the EVM Playground.

Also, check them on the console to verify the accounts are synchronized.


In above example, Alice's Substrate account was reduced by 10 DOTs (`668,439` kDOT to `668,429` kDOT).

#### Transfer Native Tokens via Substrate

Next, let's send 10 DOTs back form Bob to Alice via Susbtrate console and see how it is reflected in Acala EVM.

In Acala console select "Extrinsics" under "Developer" tab

Select module `currencies`, function `transfer`, pick Bob's account as a receiver, choose DOT as currency and put value to send `10` and press `Submit Transaction`.


Checking balances in Substrate and in Acala EVM accounts, they should show that they are synchronized.

Below it shown history of Alice's balances. We transferred 10 DOTs from EVM, after returned them from Substrate Console.

Congratulations! We learned how to send funds through both of the accounts, how to check balances and experienced how synchronization works both ways.

## 2. Flexi Fees. Example how to pay TX Fees in different currencies [work-in-progress]

For now, flexi token fee functionality works in the following way:
- when transaction is requested, it looks for ACA token to charge;
- if ACA balance is empty, it looks for DOT token and so on.
The queue of tokens to pay TX Fee with is currently hardcoded.
To show how TX Fee in EVM can be charged with different tokens, we need to empty balances of other tokens.

We agreed to wait till the next implementation to fill up this part.

## 3. Deploy smart contracts that use precompiled contracts [work-in-progress]

Show the process of pre-deploying / deploying contract (maintainer role, when charged, so on).

**WIP: currently in test networks all contracts are immediately deployed to public access without pre-deploy state, it should be changed to show all the deployment, testing flow**

## Playground improvements:
- adding transaction fee calculation with select of a native token to pay with (wireframe is in mira board : https://miro.com/app/board/o9J_lYGSfSo=/)
- adding "copy" button near EVM Address
- deleting gasLimit as we aren't using it
- Adding description what "Value" is when we want to execute transaction. It is an amount of ACA tokens that we want to send along with the transaction. This is barely used function, and mostlty developers use ERC-20 tokens to send transactions
- (maybe) pre-compiled contracts don't need to have button "forget" as they can be crucial for development
- adding tools for pre-deploying smart-contract, allowing testing it together with other users (**currently, in our test network all contracts are deployed instantly, skipping pre-deployment stage, activating of this feature is gonna be postponed**)
- adding helpers for Existential Deposit (ED: for example giving user "keep alive" checkbox which prevents submitting transaction if after charging the fee, funds go below the ED, liquidating the remaining "dust". Or giving user hints how many average transactions fees left to hit the ED threshhold (if for example it's getting close to it). **this feature is postponed in activating**