diff --git a/.github/styles/Grammarly.csv b/.github/styles/Grammarly.csv
index d534942f..a261516c 100644
--- a/.github/styles/Grammarly.csv
+++ b/.github/styles/Grammarly.csv
@@ -189,6 +189,7 @@ StrakEx,StarkEx,"typo fix"
"the Neon,The Neon","Neon","In most instances, 'The Neon EVM' can be stated as Neon EVM"
"the Mainnet,The Mainnet","Mainnet","In most instances, The Mainnet can be stated as Mainnet"
"the Devnet,The Devnet","Devnet","'The Devnet' should most often simply be stated as Devnet"
+"toke,Toke,tokes,Tokes","token","Do you really mean to smoke/smokes?!"
"token account,Token account,token Account,token-account",Token Account,"Existing style, maintain consistency"
"unbeatable","competitive","Warning -- this is a legally sensitive term. However, context is everything: it may be that the original text is more appropriate."
"Undetectable","Discreet","Warning -- this is a legally sensitive term. However, context is everything: it may be that the original text is more appropriate."
diff --git a/README.md b/README.md
index 6a3578de..0c603086 100644
--- a/README.md
+++ b/README.md
@@ -86,6 +86,8 @@ You can either lint **all** Markdown files with `vale .`, or you can name a spec
### Tabs boilerplate
+> Warning Heading links do not work *within* tabs >> Only once the correct tab is selected would a link function making them useless for cross-page linking (there is probably a workaround/plugin todo).
+
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
@@ -107,6 +109,41 @@ import TabItem from '@theme/TabItem';
with authentication via [GitHub](https://github.com/anonNeon)
+## Walkthrough boilerplate
+
+When creating user walkthroughs, it is important to think about what structure and heirachy supports end users. The style applied in this dev portal is:
+
+[H2] TL;DR
+Tell the user in 3 bullet points or less what they need to know to either
+- avoid using the tutorial entirely
+- decide whether they will use it
+{todo: in the future, we want to add a time required for the walkthrough here}
+
+[H2] Introduction
+The assumption is that less than 30% of users need an intro >> this item supports the bottom tail
+
+[H2] Prerequisites
+What does the user need to have or know to achieve success? NB stay sane else the list could become long!
+
+[H2]How to do this thing
+The first heading gathers the entire tutorial into one structure
+
+[H3] Step 1: Do this first thing
+Break the tutorial down into logical chunks, e.g. 1. go clone and install a repo 2. configure a file 3. Run the configured program
+The H3 is the final item that will be shown in the TOC (table of contents) on the RHS of the page, this allows the user to scan the TOC to gain an impression of what they are getting themselves into and to skip ahead according to their setup/knowledge level
+
+## Information pages boilerplate
+[H2] TL;DR
+Tell the user in 3 bullet points or less what they need to know to either
+- avoid reading the page entirely
+- decide whether they want to read it
+
+[H2] Introduction
+Tell the users what this page is about
+
+[H2]/[H3] Content -- nest the content into H2s and H3s for TOC presence -- H4 and H5 can be applied, but remember these are nested within the page and do not appear in the TOC. The user should be able to get an idea of what the page is about *without* reading the full intro -- just by using the TL;DR and/or TOC.
+
+Example page: docs/evm_compatibility/overview
## Troubleshooting
@@ -114,4 +151,8 @@ You pull main and can no longer build. Don't fret, someone probably changed a de
`npm install`
and then build or serve and see if that fixes it
+## End user support
+
+The current search is provided by algolia.com
+We wish to expand this functionality by implementing Mava AI (ticket with FE team)
diff --git a/docs/about/why_neon.mdx b/docs/about/why_neon.mdx
index 9e417ed2..557c3f8c 100644
--- a/docs/about/why_neon.mdx
+++ b/docs/about/why_neon.mdx
@@ -24,7 +24,7 @@ Neon EVM enables Solidity- and Vyper-based dApps to tap into Solana’s network
From a developer’s perspective, this means creating Solana-compatible contracts using tools you’re familiar with from the Ethereum Ecosystem.
-Neon EVM makes the key Ethereum dApp tools compatible with Solana, including Vyper, Solidity, [MetaMask](/docs/wallet/metamask_setup), [Hardhat](/docs/developing/deploy_facilities/using_hardhat), [Remix](/docs/developing/deploy_facilities/using_remix), (and [Truffle](/docs/developing/deploy_facilities/using_truffle)). The solution allows any Ethereum application to run on Solana with minimal reconfiguration, this includes Uniswap, SushiSwap, 0x, and MakerDAO.
+Neon EVM makes the key Ethereum dApp tools compatible with Solana, including Vyper, Solidity, [MetaMask](/docs/wallet/metamask_setup), [Foundry](/docs/developing/deploy_facilities/using_foundry), [Hardhat](/docs/developing/deploy_facilities/using_hardhat), [Remix](/docs/developing/deploy_facilities/using_remix), (and [Truffle](/docs/developing/deploy_facilities/using_truffle)). The solution allows any Ethereum application to run on Solana with minimal reconfiguration, this includes Uniswap, SushiSwap, 0x, and MakerDAO.
### Who uses Neon EVM?
@@ -40,7 +40,7 @@ Neon EVM offers a better solution: by bringing Solana's sophisticated and low-co
With Neon EVM, developers retain:
* Familiar languages: Solidity, Vyper
-* Well-known Ethereum tools: MetaMask, Hardhat, Remix, etc.
+* Well-known Ethereum tools: MetaMask, Foundry, Hardhat, Remix, etc.
* Ethereum RPC API compatibility
* Ethereum Accounts, Signatures, Token standards (ERC-20 and ERC-721)
diff --git a/docs/developing/connect_rpc.md b/docs/developing/connect_rpc.md
index 18470177..9351d58f 100644
--- a/docs/developing/connect_rpc.md
+++ b/docs/developing/connect_rpc.md
@@ -4,10 +4,11 @@ proofedDate: 20231101
iterationBy: na
includedInSite: true
approvedBy: na
-comment:
+comment: todo Find out from Yury whether we can have a NeonLabs youtube domain to support the video material that has been created to complement this page
---
-import chainlist_raw from '@site/static/img/doc-images/developing/chainlist/chainlist-raw-3.png';
+import chainlist_gotcha from '@site/static/img/doc-images/developing/chainlist/chainlist4.png';
+import chainlist from '@site/static/img/doc-images/developing/chainlist/chainlist-raw-3.png';
## TL;DR
@@ -41,7 +42,7 @@ One Proxy may be available on different networks (i.e. Devnet and Mainnet). The
To view the available RPC endpoints, expand the card details of the network of your choice.
-> 
+> 
Notice that if several Proxy Operators offer public RPC endpoints, you have a choice over who to use.
@@ -53,13 +54,21 @@ The preceding steps demonstrate how to connect to a Solana cluster via Chainlist
## Connect dev tools to Neon EVM
-To connect to a Proxy using Remix or Hardhat, check out the following resources:
-
-- [Using Remix](developing/deploy_facilities/using_remix.md)
-- [Using Hardhat](developing/deploy_facilities/using_hardhat.md)
+To connect to a Proxy check out the following resources:
+* [Using Foundry](developing/deploy_facilities/using_foundry.md)
+* [Using Hardhat](developing/deploy_facilities/using_hardhat.mdx)
+* [Using Remix](developing/deploy_facilities/using_remix.md)
+* [Using Truffle](developing/deploy_facilities/using_truffle.md)
Please note that, for Hardhat, you need to set up the configuration file by setting the URL and the `network_id`/`chainId` to the RPC URL (and ID) selected from Chainlist. This is described in detail in the relevant tutorial sections.
+## Gotchas
+
+Should the main "Connect Wallet" button not function, use the dropdown and use the "Connect Wallet" for a specified RPC server address.
+
+> 
+
## What next?
-If you wish to transact via your RPC, then check out the [supported RPC API methods](/docs/evm_compatibility/json_rpc_api_methods).
+If you wish to transact via your RPC, then checkout the [supported RPC API methods](/docs/evm_compatibility/json_rpc_api_methods).
+
diff --git a/docs/developing/deploy_facilities/configure_foundry.md b/docs/developing/deploy_facilities/configure_foundry.md
index fbe9e848..606294fc 100644
--- a/docs/developing/deploy_facilities/configure_foundry.md
+++ b/docs/developing/deploy_facilities/configure_foundry.md
@@ -4,7 +4,7 @@ proofedDate: 20231116
iterationBy: na
includedInSite: true
approvedBy: na
-comment: Killing the ## What next? See the [tutorial on how to use Foundry](/docs/developing/deploy_facilities/using_foundry) to deploy to Neon EVM. as this is killing the build todo -- return this later
+comment: Trying to return link that was killing the build todo test
---
Foundry is a blazing fast, portable,modular toolkit for Ethereum application development written in Rust.
@@ -34,4 +34,4 @@ The parameters for `forge create` command include:
* `--legacy`: This parameter is being passed to use legacy transactions _(Neon EVM currently [doesn't support EIP-1559 transactions](/docs/evm_compatibility/overview#shared-standards-and-features))_
-
+## What next? See the [tutorial on how to use Foundry](/docs/developing/deploy_facilities/using_foundry) to deploy to Neon EVM.
diff --git a/docs/developing/deploy_facilities/configure_hardhat.mdx b/docs/developing/deploy_facilities/configure_hardhat.mdx
index 3dedd67f..7b4c8c09 100644
--- a/docs/developing/deploy_facilities/configure_hardhat.mdx
+++ b/docs/developing/deploy_facilities/configure_hardhat.mdx
@@ -25,7 +25,7 @@ The Hardhat framework isn't described here; find that in the [Hardhat documentat
-We provide a full example of the `hardhat.config.js` configuration file for connecting Hardhat to a Devnet Proxy using the one-way library on Node.js:
+The following config file provides a full example of the `hardhat.config.js` for connecting Hardhat to a Devnet Proxy using the one-way library on Node.js:
### hardhat.config.js
diff --git a/docs/developing/deploy_facilities/using_foundry.md b/docs/developing/deploy_facilities/using_foundry.md
new file mode 100644
index 00000000..be1eb06c
--- /dev/null
+++ b/docs/developing/deploy_facilities/using_foundry.md
@@ -0,0 +1,153 @@
+---
+title: Deploy with Foundry
+proofedDate: 20231116
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import mm_p_key from '@site/static/img/doc-images/developing/deploy_facilities/foundry-metamask.png';
+
+This tutorial walks through deploying a contract describing an ERC-20 token to Neon Devnet.
+
+## Introduction
+
+This tutorial is based on an [example in GitHub](https://github.com/neonlabsorg/neon-tutorials/tree/main/foundry).
+
+:::info
+This page is a quickstart based on a specific example program. For more details on installing Foundry, refer to the *[Foundry documentation](https://book.getfoundry.sh/getting-started/installation)*.
+:::
+
+## Prerequisites
+
+- An EVM-compatible wallet, such as MetaMask [connected to Devnet](/docs/developing/connect_rpc#connect-via-chainlist)
+- A balance in [Devnet NEON](https://neonfaucet.org/)
+
+### Step 1: Installation
+
+1.1 Clone the example Foundry project from the remote repository and navigate to it:
+
+```sh
+git clone https://github.com/neonlabsorg/neon-tutorials
+cd neon-tutorials/foundry
+```
+
+1.2 Install Foundryup with:
+```sh
+curl -L https://foundry.paradigm.xyz | bash
+foundryup
+```
+
+:::info
+`foundryup` installs the latest _(nightly)_ precompiled binaries: forge, cast, anvil, and chisel.
+:::
+
+
+1.3 Install the required libraries:
+```sh
+forge install foundry-rs/forge-std --no-commit
+forge install openzeppelin/openzeppelin-contracts --no-commit
+```
+
+
+### Step 2: Set up an environment file
+
+:::info
+This step requires an EVM-compatible wallet such as MetaMask, connected to Neon Devnet, with a balance in Devnet NEON available from [NeonFaucet](https://neonfaucet.org/).
+
+The following tutorials assist you to meet these prerequisites:
+- Learn how to [install a MetaMask wallet and connect it to Devnet](/docs/wallet/metamask_setup)
+> Or [connect an existing wallet to Devnet](/docs/developing/connect_rpc#connect-via-chainlist)
+:::
+
+
+
+2.1 Obtain the private key for your wallet account.
+
+> To obtain the private key from MetaMask, from the hamburger menu, click **Account Details** > **Show Private Key**, enter your password, and click **Confirm** for access to the private key for that account.
+> 
+
+2.2 Create a .env file and add these lines:
+
+```
+RPC_URL_DEVNET=https://devnet.neonevm.org
+CHAIN_ID_DEVNET=245022926
+RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
+CHAIN_ID_MAINNET=245022934
+PRIVATE_KEY=
+VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api
+```
+:::important
+Replace with your data.
+:::
+
+2.3 Run:
+```
+source .env
+```
+
+
+### Step 3: Compile contracts
+
+The contracts are located in the project's `src/` directory. Before these contracts can be run, they must first be compiled.
+
+3.1 To compile the project's contracts, run the following command:
+```sh
+forge build
+```
+
+After running this step, you should see output similar to the following:
+```
+[⠢] Compiling...
+[⠒] Compiling 24 files with 0.8.21
+[⠃] Solc 0.8.21 finished in 2.48s
+Compiler run successful!
+```
+
+3.2 (Optional) test the smart contracts with:
+```sh
+forge test
+```
+
+### Step 4: Deploy Contracts
+
+4. To deploy the project's contracts, run:
+```sh
+forge create --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY src/TestERC20/TestERC20.sol:TestERC20 --constructor-args "Test ERC20 Token" "TERC20" --legacy
+```
+
+On running this step you should get console output similar to:
+```
+[⠰] Compiling...
+No files changed, compilation skipped
+Deployer: 0x4455E84Eaa56a01676365D4f86348B311969a4f4
+Deployed to: 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9
+Transaction hash: 0x6de9dab8a526cbac33008056d185b93dff725605efb791bf116b6bece4f0c486
+```
+
+### Step 5: Contract verification
+
+5.1 Verify the deployment of our smart contract on the explorer [Neon Blockscout](https://neon-devnet.blockscout.com) using following command:
+```sh
+forge verify-contract --chain-id $CHAIN_ID_DEVNET src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout
+```
+
+:::important
+Replace `` with your smart contract address.
+:::
+
+After successfully running this step you should get console output similar to:
+```
+Start verifying contract `0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9` deployed on 245022926
+Submitting verification for [src/TestERC20/TestERC20.sol:TestERC20] "0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9".
+Submitted contract for verification:
+ Response: `OK`
+ GUID: `5537599aa2f97dd60a66342522a465a7f2e40ff9654118b3`
+ URL:
+ https://neon-devnet.blockscout.com/api?/address/0x5537599aa2f97dd60a66342522a465a7f2e40ff9
+```
+
+5.2 Copy/paste this link in your browser, remembering to replace `contract_address` with your freshly deployed contract address:
+
+```https://neon-devnet.blockscout.com/address/```
\ No newline at end of file
diff --git a/docs/developing/deploy_facilities/using_hardhat.md b/docs/developing/deploy_facilities/using_hardhat.md
deleted file mode 100644
index 44a41752..00000000
--- a/docs/developing/deploy_facilities/using_hardhat.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: Deploy with Hardhat
-proofedDate: na
-iterationBy: na
-includedInSite: true
-approvedBy: na
-comment:
----
-
-*This page outlines the steps for deploying and testing contracts in the Neon EVM using the Hardhat tool.*
-
-Before beginning the tutorial below, make sure that you have properly [configured Hardhat](configure_hardhat) for the Neon EVM.
-
-## How to Use Hardhat: A Tutorial
-The example this tutorial is based on is located in [this repository](https://github.com/neonlabsorg/examples/tree/main/simple-erc20-hardhat).
-
-By the end of this tutorial, you will deploy a contract describing an ERC-20 token to the Neon Devnet. You will then test this contract by minting 10000 test tokens that are deposited to the first wallet specified in the configuration file (see above), and then transferred to the second wallet address.
-
-### Step 1: Installation
-> **Note:** This page is just a quickstart based on a specific example program. For more details on installing Hardhat, refer to the *[Hardhat documentation](https://hardhat.org/hardhat-runner/docs/getting-started#overview)*.
-
-Using Git, clone the example Hardhat project from the remote repository and navigate to it:
-```sh
-git clone https://github.com/neonlabsorg/examples.git
-cd examples/simple-erc20-hardhat
-```
-
-Then, run the following command:
-```sh
-npm install
-```
-This will install all the necessary packages to continue with the example. These packages include the `Hardhat` library.
-
-If the above command results in an error, run:
-```sh
-npm cache clear --force
-npm install
-```
-
-### Step 2: Set Up MetaMask Accounts
-To interact with the soon-to-be-deployed contracts, you'll need to create two new accounts in MetaMask. Before you begin, make sure that MetaMask is connected to the Neon Devnet.
-
-In MetaMask, create two new accounts. This can be done by clicking on your current account's icon in the top right of the MetaMask extension pop-up, and then clicking on 'Create an Account' in the drop-down menu that appears. Then, obtain some Devnet NEON tokens for these accounts (up to 100 NEON per account) using the [NeonFaucet](../utilities/faucet).
-
-Finally, copy the new accounts' private keys and paste them into the `hardhat.config.js` file described above, replacing the placeholder text in lines 11 and 12 of that file. To obtain the private keys, click on the three vertical dots to the right of your currently displayed account name and wallet address. In this drop-down menu, click on 'Account Details', then on 'Export Private Key', and enter your password and click 'Confirm' to get access to the private key for that account.
-
-> **Note:** When adding the private keys to the configuration file, make sure to add the prefix **0x** to the key obtained via MetaMask.
-
-### Step 3: Compile Contracts
-All of the contracts are located in the project's `contracts/` directory. Before these contracts can be run, they must first be compiled. To compile the project's contracts, run the following command:
-```sh
-./node_modules/.bin/hardhat compile
-```
-
-After running this step, you should see output similar to the following:
-```
-Compiled 2 Solidity files successfully
-```
-
-### Step 4: Run Tests
-Make sure to test your code before you migrate it to the network. All test files should be located under the `test/` directory.
-
-To run all tests, simply run the command below:
-```sh
-./node_modules/.bin/hardhat test
-```
-
-This command compiles all the contracts in the `contracts/`, deploys them to the Neon Devnet, and runs all the tests in the `test/` directory. The output should look something like this:
-```
- Testing TestERC20 contract
- ✔ should successfully mint 10000 ERC20 in the first account (15967ms)
- ✔ should transfer token correctly (31327ms)
-
-
- 2 passing (53s)
-```
-
-### Step 5: Deploy Contracts
-To deploy the project's contracts, simply run the command below to run the deployment script in the `scripts/` directory:
-```sh
-./node_modules/.bin/hardhat run ./scripts/deploy.js
-```
-
-After running this command, you should see console output similar to the following:
-```
-Deploying contracts with the account: 0xf71c4DACa893E5333982e2956C5ED9B648818376
-Contract address is: 0x49DCDEc367bba4271876259AE473890aa5AABc2e
-Minting 100000000000 tokens...
-```
-
-### Step 6: Connect Project to MetaMask
-To import your project as an asset in MetaMask, follow the instructions [here](https://support.metamask.io/hc/en-us/articles/360015489031-How-to-add-unlisted-tokens-custom-tokens-in-MetaMask#h_01FWH492CHY60HWPC28RW0872H) and use the contract address from the previous step as the 'Token Contract Address' in MetaMask.
-
-Once you complete this final step, you will be able to see your new ERC-20 assets in the MetaMask profiles of the new test accounts.
diff --git a/docs/developing/deploy_facilities/using_hardhat.mdx b/docs/developing/deploy_facilities/using_hardhat.mdx
new file mode 100644
index 00000000..2c5bdc37
--- /dev/null
+++ b/docs/developing/deploy_facilities/using_hardhat.mdx
@@ -0,0 +1,107 @@
+---
+title: Deploy with Hardhat
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import mm_p_key from '@site/static/img/doc-images/developing/deploy_facilities/foundry-metamask.png';
+
+*This page outlines the steps for deploying and testing contracts in the Neon EVM using the Hardhat tool.*
+
+Before beginning the tutorial below, make sure that you have properly [configured Hardhat](configure_hardhat) for the Neon EVM.
+
+## How to Use Hardhat: A Tutorial
+The example this tutorial is based on is located in [this repository](https://github.com/neonlabsorg/neon-tutorials/tree/main/hardhat).
+
+By the end of this tutorial, you will deploy a contract describing an ERC-20 token to the Neon Devnet.
+
+### Step 1: Installation
+> **Note:** This page is just a quickstart based on a specific example program. For more details on installing Hardhat, refer to the *[Hardhat documentation](https://hardhat.org/hardhat-runner/docs/getting-started#overview)*.
+
+Using Git, clone the example Hardhat project from the remote repository and navigate to it:
+```sh
+git clone https://github.com/neonlabsorg/neon-tutorials
+cd neon-tutorials/hardhat
+```
+
+Then, run the following command:
+```sh
+npm install
+```
+This will install all the necessary packages to continue with the example. These packages include the `Hardhat` library.
+
+If the above command results in an error, run:
+```sh
+npm cache clear --force
+npm install
+```
+
+### Step 2: Set Up MetaMask Accounts
+:::info
+This step requires an EVM-compatible wallet such as MetaMask, connected to Neon Devnet, with a balance in Devnet NEON available from [NeonFaucet](https://neonfaucet.org/).
+
+The following tutorials assist you to meet these prerequisites:
+- Learn how to [install a MetaMask wallet and connect it to Devnet](/docs/wallet/metamask_setup)
+> Or [connect an existing wallet to Devnet](/docs/developing/connect_rpc#connect-via-chainlist)
+:::
+
+2.1 Obtain the private key for your wallet account.
+
+> To obtain the private key from MetaMask, from the hamburger menu, click **Account Details** > **Show Private Key**, enter your password, and click **Confirm** for access to the private key for that account.
+>
+
+2.2 Create a .env file and add these lines:
+
+```
+PRIVATE_KEY_OWNER=
+```
+:::important
+Replace with your data.
+:::
+
+2.3 Run:
+```
+source .env
+```
+
+### Step 3: Compile Contracts
+All of the contracts are located in the project's `contracts/` directory. Before these contracts can be run, they must first be compiled. To compile the project's contracts, run the following command:
+```sh
+npx hardhat compile
+```
+
+After running this step, you should see output similar to the following:
+```
+Compiled 23 Solidity files successfully
+```
+
+### Step 4: Deploy Contracts
+To deploy the project's contracts, simply run the command below to run the deployment script in the `scripts/` directory:
+```sh
+npx hardhat run scripts/TestERC20/deploy.js --network neondevnet
+```
+
+After running this command and deploying our TestERC20 smart contract now we can take the newly deployed contract address and included it inside `scripts/TestERC20/transfer.js` where we can intitiate a token transfer:
+```sh
+npx hardhat run scripts/TestERC20/transfer.js --network neondevnet
+```
+The outpout should look like:
+```
+Sender balance before transfer 1000000000000000000000n
+Receiver balance before transfer 0n
+Sender balance after transfer 990000000000000000000n
+Receiver balance after transfer 10000000000000000000n
+```
+
+### Step 5: Contract verification
+```
+npx hardhat verify --network neondevnet
+```
+
+This command is how we verify contracts on [Neonscan](https://devnet.neonscan.org). More info about verifying smart contracts thru Hardhat can be found [here](https://hardhat.org/hardhat-runner/docs/guides/verifying).
+:::important
+Replace with your smart contract address.
+:::
\ No newline at end of file
diff --git a/docs/developing/dev_environment/local_proxy_remote_solana.md b/docs/developing/dev_environment/local_proxy_remote_solana.md
index 189fbad3..5e6d5652 100644
--- a/docs/developing/dev_environment/local_proxy_remote_solana.md
+++ b/docs/developing/dev_environment/local_proxy_remote_solana.md
@@ -76,23 +76,23 @@ mv {PATH_TO_WHITELISTED_KEYS} keys/
- For Mainnet, use: `NeonVMyRX5GbCrsAHnUwx1nYYoJAtskU1bWUo6JGNyG`
- `SOLANA_URL`
- Refer to the [RPC Endpoints table](#rpc-endpoints)
- - `PROXY_VERSION`
+ - `REVISION` - neon proxy revision
For example,
```bash
export EVM_LOADER=eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU
export SOLANA_URL=http://api.devnet.solana.com/
-export PROXY_VERSION=latest
+export REVISION=latest
```
3. Download the `docker-compose` [file](https://github.com/neonlabsorg/proxy-model.py/blob/develop/docker-compose/docker-compose-remote-solana.yml). This file should be placed in the same folder with the `keys/` directory.
```bash
-wget https://raw.githubusercontent.com/neonlabsorg/proxy-model.py/develop/proxy/docker-compose-remote-solana.yml
+wget https://raw.githubusercontent.com/neonlabsorg/proxy-model.py/develop/docker-compose/docker-compose-remote-solana.yml
```
4. Start the local environment.
```bash
-docker-compose -f docker-compose-remote-solana.yml up -d
+docker-compose -f docker-compose-remote-solana.yml up postgres dbcreation proxy indexer -d
```
If you want to destroy the local environment, run the following command:
diff --git a/docs/developing/get-started.md b/docs/developing/get-started.md
index 91beeabf..8c3fd937 100644
--- a/docs/developing/get-started.md
+++ b/docs/developing/get-started.md
@@ -11,8 +11,9 @@ import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
:::note
-This is a bare-bones Get Started; alternatively, browse the full support available in this site.
-:::
+This is a bare bones Get Started; alternatively browse the full support available in this site.
+:::
+
## Get test NEON for Neon Devnet
@@ -61,7 +62,7 @@ neonmainnet: {
See the [Hardhat tutorial](https://docs.neonfoundation.io/docs/developing/deploy_facilities/configure_hardhat)
-
+
diff --git a/docs/operating/transaction-gas.md b/docs/operating/transaction-gas.mdx
similarity index 78%
rename from docs/operating/transaction-gas.md
rename to docs/operating/transaction-gas.mdx
index f5f35202..3642704b 100644
--- a/docs/operating/transaction-gas.md
+++ b/docs/operating/transaction-gas.mdx
@@ -1,12 +1,15 @@
---
title: Fees & Gas
-proofedDate: na
+proofedDate: 20231204
iterationBy: na
includedInSite: true
approvedBy: na
-comment: wip items inline
+comment: todo the zero gas for testing setup (see commented out section)
---
+import Formula from '../single-source-snippets/_price_formula.mdx'
+import Price from '../single-source-snippets/_gas_price_calc.mdx'
+
## TL;DR
Operators:
@@ -29,29 +32,27 @@ The Neon EVM calculates gas usage by tracking the SOL spent by the Neon Operator
### Pass on gas savings
-Because the Neon EVM operates on Solana, not Ethereum it takes advantage of Solana’s inexpensive transaction costs and favourable approach to only charge for storage allocation. This contrasts with Ethereum, where calculations require much more gas, and gas is charged for every change in data stored in Ethereum. As a result, gas usage on Solana is much cheaper than on Ethereum, and the Neon EVM passes these savings on to users.
+Because the Neon EVM operates on Solana, not Ethereum, it takes advantage of Solana’s inexpensive transaction costs and favorable approach to only charge for storage allocation. This contrasts with Ethereum, where calculations require much more gas, and gas is charged for every change in data stored in Ethereum. As a result, gas usage on Solana is much cheaper than on Ethereum, and the Neon EVM passes these savings on to users.
## Gas price: the Operator fee
The Neon Proxy obtains the current prices of SOL and NEON tokens from the [pyth.network](http://pyth.network) oracles.
-Gas price = $SOL / $NEON * (1 + `PRX_OPERATOR_FEE`)
+
-> This ensures that the Neon Operator receives enough NEONs to cover the transaction cost in SOLs.
+> This ensures that the Neon Operator receives enough NEON to cover the transaction cost in SOL.
-The Neon Operator configures the value of `PRX_OPERATOR_FEE` where 1.0 represents 100% of the potential fee extraction, i.e. PRX_OPERATOR_FEE = "1.0”
+The Neon Operator configures the value of `PRX_OPERATOR_FEE`, where 1.0 represents 100% of the potential fee extraction. The value of this parameter is currently set to **1**.
-For example:
+Parameter `PRX_GAS_PRICE_SLIPPAGE` provides a buffer against transactions getting stuck in the mempool if there is volatility in prices of $SOL and $NEON. The value of this parameter is currently set to **0.25**.
-- $NEON = $0.25
-- $SOL = $10
-- PRX_OPERATOR_FEE = "1"
-- Gas price = 10 / 0.25 * (1 + 1) = 80 Galan
+For example:
+
-Neon recommends that Neon Operators should initially set `PRX_OPERATOR_FEE` to “1.0” for Mainnet launch. This allows Operators to cover their hardware costs while transaction demands are low. As demand grows, Operators may adjust their fees in response.
+Neon recommended that Neon Operators should initially set `PRX_OPERATOR_FEE` to “1.0” for Mainnet launch. This allows Operators to cover their hardware costs while transaction demands are low. As demand grows, Operators may adjust their fees in response.
-> For example, `PRX_OPERATOR_FEE` = “0.1” → 10% of the total possible Neon Operator fee.
+> A `PRX_OPERATOR_FEE` = “0.1” → 10% of the total possible Neon Operator fee.
## Minimum gas price
@@ -75,9 +76,12 @@ The Neon Proxy has several settings that accommodate the calculation of gas-pric
- `PRX_PYTH_MAPPING_ACCOUNT`: the Solana address of the Pyth mapping account; select the address on (https://pyth.network/developers/accounts) based on the type of network (Devnet/Mainnet)
- `PRX_UPDATE_PYTH_MAPPING_PERIOD_SEC`: the time period to reread the Pyth mapping account. The Neon Proxy reads the Pyth mapping account at the start, gets the addresses of $NEON and $SOL accounts, and rechecks the address from the Pyth Mapping account only after `UPDATE_PYTH_MAPPING_PERIOD_SEC`. It is recommended to set this generously (e.g. 1/3/10 hours), because the price feed accounts don’t change often.
- `PRX_MINIMAL_GAS_PRICE`: the minimum gas price to accept transactions into the mempool for on-chain execution
+
+