-
-1. User sends signed Ethereum-like Tx (using an Ethereum-compatible wallet) to Neon RPC end-point ([How to Connect to Neon RPC](/docs/wallet/metamask_setup))
-2. Neon Proxy
- * Estimates gas usage for transaction execution
- * Wraps Ethereum-like Tx into Solana Tx
- * Sends it to Solana RPC, calling Neon EVM program
- * Extracts Neon EVM receipt from Solana receipt and passes it to the client
-3. Neon EVM program
- * Unwraps Ethereum-like Tx and **checks user signature**
- * Loads EVM state, including account data and smart contracts code, from Solana storage
- * Executes Ethereum-like Tx inside Solana BPF
- * Saves new EVM state back into Solana state
diff --git a/docs/about/how_it_works.mdx b/docs/about/how_it_works.mdx
new file mode 100644
index 00000000..22a27a66
--- /dev/null
+++ b/docs/about/how_it_works.mdx
@@ -0,0 +1,47 @@
+---
+title: How It Works
+proofedDate: 20230427
+iterationBy: HB
+includedInSite: true
+approvedBy: YYY
+comments: #1 TODO see inline comment 2.3
+---
+import {ImgTheme} from '@site/src/components/ImageTheme';
+
+
+
+This page provides a high-level overview of how Neon EVM coordinates communication between Ethereum dApps and Solana.
+
+## Neon EVM's transaction lifecycle
+
+Effecting a user-initiated transaction (tx) from an Ethereum dApp on Solana requires three main steps:
+
+1. The user initiates a tx. A tx is a signed Ethereum-like tx directed to a Neon RPC endpoint.
+
+> See [How to Connect to the Neon RPC](/docs/wallet/metamask_setup) via an Ethereum-compatible wallet.
+
+The Ethereum API passes the tx to the Neon Proxy via the [Neon API service](docs/developing/connect_rpc.md).
+
+
+
+2. This request is received by the Neon Proxy.
+
+ > 2.1 The Neon Proxy processes the request, providing:
+ > - Gas usage estimate for tx execution
+ > - Broadcast initiation: wrapping the Ethereum-like tx as a Solana tx
+
+ > 2.2. The Neon Proxy passes the wrapped tx to the Neon EVM program hosted on Solana. This results in the following:
+ > - A Solana receipt
+ > - A corresponding Neon EVM receipt
+
+ > 2.3 The Neon smart contract then:
+ > - Unwraps the tx and checks the user's signature
+ > - Loads the EVM state, including account data and the smart contract's code, from Solana storage
+ > - Executes the tx inside [Solana BPF](https://docs.solana.com/developing/runtime-facilities/programs#bpf-loader)
+ > - Updates Solana's state to reflect the new Neon EVM state
+
+
+
+3. Solana and Neon EVM undertake a state change.
+
+This completes the tx request.
diff --git a/docs/about/img/how_it_works.png b/docs/about/img/how_it_works.png
deleted file mode 100644
index 3fb47cb6..00000000
Binary files a/docs/about/img/how_it_works.png and /dev/null differ
diff --git a/docs/about/img/neon_ecosystem.png b/docs/about/img/neon_ecosystem.png
deleted file mode 100644
index 56cab026..00000000
Binary files a/docs/about/img/neon_ecosystem.png and /dev/null differ
diff --git a/docs/about/img/neon_ecosystem.svg b/docs/about/img/neon_ecosystem.svg
deleted file mode 100644
index 40951b98..00000000
--- a/docs/about/img/neon_ecosystem.svg
+++ /dev/null
@@ -1,663 +0,0 @@
-
diff --git a/docs/about/introduction.md b/docs/about/introduction.md
deleted file mode 100644
index 9be1bb01..00000000
--- a/docs/about/introduction.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Introduction
----
-
-*The Neon EVM is an [Ethereum virtual machine](https://ethereum.org/en/developers/docs/evm/) on Solana that enables dApp developers to use Ethereum tooling to scale and get access to liquidity on Solana.*
-
-## Abstract
-
-The Neon EVM is a tool that allows Ethereum-like transactions to be processed on [Solana](https://docs.solana.com/introduction), taking full advantage of the functionality native to Solana, including the ability to execute transactions in parallel. As such, the Neon EVM allows dApps to operate with the low gas fees, high transaction speed, and high throughput of Solana, while also offering access to the growing Solana market.
-
-The Ethereum state is represented by a [Merkle-Patricia Tree](about/terminology.md/#merkle-patricia-trie) that stores key-value data for all smart contracts, and smart contracts written in Solidity do not have separate references to shared data and contract code. Therefore, these smart contracts have to be executed in sequence to ensure deterministic behavior. This limits throughput. Highly optimized blockchains with EVM are capable of processing up to a maximum of 1,500 transactions per second (TPS).
-
-Solana, however, is designed to support massive scaling of decentralized applications, with a maximum throughput of more than 50,000 TPS. To take full advantage of Solana's functionality, Neon EVM is built as a smart contract of Solana. This flexibility also ensures that the Neon EVM can be updated with ease when new Ethereum functionality is introduced.
-
-In the case of the Neon EVM, Ethereum-like transactions are wrapped into Solana transactions by an intermediary proxy server and sent to the Neon EVM, which executes them in parallel. To facilitate this parallel execution of smart contracts, the Neon EVM ensures that each contract keeps its data in its own Solana storage, and account balances used to pay for Neon transactions are also separated.
-
-The solution allows any Ethereum application to be run on Solana without any changes to its codebase, including Uniswap, SushiSwap, 0x, and MakerDAO. All key Ethereum dApp tools can also work on Solana, including Solidity, MetaMask, Remix, and Truffle.
-
-Neon EVM is best suited to developers who want to enjoy a first-mover advantage and reach new customers on Solana, or those who want to scale with the low gas fees and high throughput that Solana provides. It is also good for developers looking to tap into liquidity on Solana.
-
-## Why Neon EVM
-Ethereum is set to remain a booming blockchain ecosystem. The number of active dApps on Ethereum is hovering above 300, and the number of active users of these dApps is close to 6 million, with the number of transactions on the rise. Ethereum’s popularity is not only down to its processing of smart contracts, but also its sophisticated infrastructure for application development.
-
-Solana is one of the most technically advanced and innovative blockchains, offering low gas fees and high throughput of transactions. Among these innovations is its Proof-of-Stake (PoS) consensus system, which is reinforced via a Proof-of-History protocol, a transaction parallelization technology that optimizes resources and ensures that Solana can scale horizontally across GPUs and SSDs, along with an optimized mempool system that speeds up throughput.
-
-The Neon EVM is a cross-chain solution that allows dApp developers to access the advantages of Solana to expand their services, to offer new products like arbitrage or high-frequency trading, grow their user base, and decrease costs where possible, including gas fees. Neon EVM enables full compatibility with Ethereum on Solana.
diff --git a/docs/about/neon_ecosystem.md b/docs/about/neon_ecosystem.md
deleted file mode 100644
index 072a6392..00000000
--- a/docs/about/neon_ecosystem.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Quick Look at Neon EVM
----
-import { QuickLookNeonImage } from '@site/src/components/QuickLookNeonImage'
-
-
-
-
-## Neon EVM Core
-
-**Neon EVM** facilitates the usage of Ethereum tooling by dApp developers to scale and access liquidity on Solana. Neon EVM offers Ethereum ecosystem dApp developers increased throughput and swift block time on Solana, with low gas prices and no need for changing code – anyone can run Ethereum contracts on Solana with Neon EVM.
-
-**Ethereum Tooling**: [MetaMask](/docs/wallet/metamask_setup), [Hardhat](/docs/developing/deploy_facilities/using_hardhat), [Truffle](/docs/developing/deploy_facilities/using_truffle), [Remix](/docs/developing/deploy_facilities/using_remix)
-
-**The Neon EVM program** is a smart contract on the Solana blockchain. This allows Neon EVM to receive Ethereum-like transactions and process them on Solana according to Ethereum rules. Ethereum transactions going through Neon EVM, called Neon Transactions, are used as inputs for the targeted Neon clients.
-
-The [NEON token](/docs/tokens/neon_token) is used to pay the [gas fees](/docs/tokens/gas_fees) required for transaction execution
-**Neon Proxy** is an essential tool for packaging a Neon transaction into a Solana transaction. It improves the user experience for operators in the Neon ecosystem, and it allows Ethereum dApps to be ported to Neon with virtually no code or configuration changes, as all the “translating” is handled by the proxy.
-
-**Neon operators** run Neon Proxy servers, which helps facilitate seamless execution of Ethereum-like transactions on Solana. This allows Ethereum dApps to be ported to Neon with no code change.
-
-**Tokens** - on Neon EVM you can use:
-* [NEON token](/docs/tokens/neon_token) as a gas
-* [ERC-20 with SPL](/docs/developing/deploy_facilities/interacting_with_spl_tokens) under the hood
-* [NeonPass](/docs/token_transferring/neonpass_usage) to transfer tokens between Solana and Neon EVM
-
-
-## Integrations
-
-**Tracing API** is an extension for Neon Proxy. For historical requests, Neon Labs implemented a Tracing API to help developers better test, debug, and understand their smart contracts on Neon EVM. The API will give developers a full externality trace on any transaction executed on the chain. They’ll be able to rerun historic transactions, run new transactions on historic states, and analyze the state of the blockchain after the execution of each instruction. More details are available in [our blog](https://medium.com/neon-labs/neon-proxy-tracing-api-fdb3842a80fa)
-
-**Oracles** provide a way for the decentralized Web3 ecosystem to access price feeds and other external (off-chain) data sources. Neon EVM supports querying data from Solana deployed Oracles:
-* [Chainlink](/docs/developing/integrate/oracles/integrating_chainlink)
-* [Pyth](/docs/developing/integrate/oracles/integrating_pyth)
diff --git a/docs/about/neon_ecosystem.mdx b/docs/about/neon_ecosystem.mdx
new file mode 100644
index 00000000..be4e6ec3
--- /dev/null
+++ b/docs/about/neon_ecosystem.mdx
@@ -0,0 +1,106 @@
+---
+title: Neon Ecosystem
+proofedDate: 20230427
+iterationBy: HB
+includedInSite: true
+approvedBy: YYY
+links: The ecosystem image links to /docs/tokens/neon_token and /docs/tokens/gas_fees
+comment: #2 TODO Tracer API needs internal linking to replace Medium article todo we have more wallets than just MetaMask -- perhaps add an FAQ and link there? TODO what was the outcome of Anton not wanting to use BPF?
+---
+
+import { NeonEcosystemView } from '@site/src/components/NeonEcosystemView';
+
+
+
+**Neon EVM** is _the_ solution that makes Solana's throughput, swift block speeds, and low gas prices available to Ethereum contracts. Neon EVM interacts directly with Solana nodes to carry out transactions on Solana. The service is made up of three main components:
+
+- Neon EVM
+- Neon Proxy
+- Neon DAO
+
+This page presents a high-level overview of each, and the native tools and integrations available within the Neon Ecosystem.
+
+## Neon EVM program
+
+The **Neon EVM program** is a smart contract on the Solana blockchain. The Neon EVM program accepts Ethereum-like transactions and processes them on Solana according to Ethereum rules. Ethereum transactions directed to the Neon EVM are called Neon Transactions.
+
+> **Neon Transactions**: a [subset of Ethereum's JSON-RPC Specification](/docs/evm_compatibility/json_rpc_api_methods) may be directed to the Neon EVM to be used as inputs for the targeted Neon clients.
+
+## Neon Proxy
+
+It's the Neon Proxy that allows Ethereum dApps to be ported to Neon with minimal reconfiguration. Neon Proxy packages a EVM transaction into a Solana transaction. The Proxy is provided as a containerized solution that's intuitive for [Operators](/docs/operating/operator-introduction).
+
+:::info
+**Neon Operators** run Neon Proxy servers to facilitate the seamless execution of Ethereum-like transactions on Solana. It is this proxy service that allows Ethereum dApps to be ported to Neon with minimal reconfiguration. Operators accept payment in NEON (although the roadmap will expand the options) and make payments within the Solana Ecosystem in SOL.
+:::
+
+### The NEON token
+
+The NEON token is a utility token with 2 functions:
+
+#### 1. Payment of gas fees
+
+The Neon Proxy Operator accepts payment from the user in [NEON tokens](/docs/tokens/neon_token) to pay the [gas fees](/docs/tokens/gas_fees) required for transaction execution.
+
+#### 2. Governance
+
+Owners of the Neon token may engage in the Neon DAO activities.
+
+## Neon DAO
+
+The DAO provides custodial services to Neon Foundation, assisting the foundation to direct future research and development. The Neon DAO exists as a series of contracts deployed on Solana to provide a governance layer to control the functionality of Neon EVM. DAO participants utilize a web interface to allow the community, i.e. NEON holders, to raise and vote on proposals that impact the functioning of the Neon EVM.
+
+## Neon Tools
+
+### Block explorer
+
+[NeonScan](https://neonscan.org/) provides a block explorer and analytics platform to examine Neon transactions within Solana.
+
+### NeonPass
+
+[NeonPass](https://devnet.neonpass.live/) transfers ERC-20 tokens between Solana and Neon EVM. The [ERC-20 SPL wrapper](/docs/developing/deploy_facilities/interacting_with_spl_tokens) makes such transfers possible via (non-custodial) wallets.
+
+> See the [NeonPass guide](/docs/token_transferring/neonpass_usage).
+
+### NeonFaucet
+
+[NeonFaucet](https://neonfaucet.org/) provides NEON test tokens and other ERC-20 test tokens to be used for testing applications on DevNet.
+
+## Integrations
+
+Neon EVM integrates with several essential services:
+
+### Oracles
+
+Oracles enable the decentralized Web3 ecosystem to access price feeds and other external (off-chain) data sources. Neon EVM supports querying data from Solana deployed Oracles:
+
+- [Chainlink](/docs/developing/integrate/oracles/integrating_chainlink)
+- [Pyth](/docs/developing/integrate/oracles/integrating_pyth)
+
+### Wallets
+
+Neon EVM is supported by EVM-compatible wallets such as MetaMask's non-custodial wallet.
+
+> This allows dApp devs to sign deployment transactions and mint tokens.
+
+
+
+### Protocols
+
+Neon EVM integrates with the popular WalletConnect protocol that provides a decentralized standard to connect Web3 wallets and dApps.
+
+### Tracer API
+
+Neon's Tracer API is an extension for Neon Proxy. It assists developers to test, debug, and understand the behavior of their smart contracts on Neon EVM. The API provides a full externality trace on any Neon transactions executed on the Solana blockchain.
+
+The Tracer API supports a rerun of historical transactions, runs transactions on historical states, and analyzes the state of the Solana blockchain after the execution of each instruction.
+
+> More details are available in [our blog](https://medium.com/neon-labs/neon-proxy-tracing-api-fdb3842a80fa).
+
+## Development tools
+
+Various tools such as:
+
+- [Hardhat](/docs/developing/deploy_facilities/using_hardhat)
+- [Remix](/docs/developing/deploy_facilities/using_remix)
+- [Foundry](/docs/developing/deploy_facilities/using_foundry)
diff --git a/docs/about/terminology.md b/docs/about/terminology.md
deleted file mode 100644
index 0f2237d5..00000000
--- a/docs/about/terminology.md
+++ /dev/null
@@ -1,273 +0,0 @@
----
-title: Terminology
----
-
-### Application Binary Interface (ABI)
-A JSON-based description on how to convert user actions between their JSON and binary representations. The ABI may also describe how to convert the database state to/from JSON. Once you have described your contract via an ABI, this allows developers and users to interact with your contract seamlessly via JSON.
-
----
-
-### Account
-A unique identifier that is required to interact with Solana. Unlike most other cryptocurrencies, transfers are sent to a readable account name instead of a public key, while keys attributed to the account are used to sign transactions.
-
----
-
-### Block
-A special structure for recording a group of transactions in blockchain systems. A block consists of a header and a list of transactions. The block header includes its hash, the hash of the previous block, transaction hashes, and additional overhead information.
-
----
-
-### Blockchain
-A database with a strict structure and certain rules for building chains of transactions and accessing information which excludes data theft, fraud, violation of property rights, and more.
-
----
-
-### Block log
-An append-only log of blocks written to disk and containing all the irreversible blocks.
-
----
-
-### Berkeley Packet Filter (BPF)
-A technology used in computer operating systems to analyze network traffic. It provides a raw interface to data link layers, permitting raw link-layer packets to be sent and received.
-
----
-
-### Container
-An object created using a Docker image and containing all the necessary components for the operation of the application. The container is a secure platform for the operation of the application.
-
----
-
-### Cryptographic Hash Function (CHF)
-A type of hash function that takes an input (or `message`) and returns a fixed-size alphanumeric string. The alphanumeric string is called the `hash value`, `message digest`, `digital fingerprint`, `digest`, or `checksum`.
-
----
-
-### Daemon
-A program on Linux systems that is launched by the system itself and runs in the background without direct user interaction.
-
----
-
-### Decentralized Application (dApp)
-An application built on a decentralized network that combines a smart contract and a frontend user interface.
-
----
-
-### Digital signature
-A mathematical algorithm used to verify the authenticity and integrity of digital messages or documents. A valid digital signature helps to reassure the recipient that the message was created by a known sender, and that the message was not altered in transit. Digital signatures are a standard feature of most cryptographic protocol suites, and are also commonly used for software distribution, financial transactions, contract management software, and other cases where it is important to detect and/or prevent forgery or tampering.
-
----
-
-### Docker
-Software used to automate application installation in the virtualization environment at the operating system level. Packages an application, along with all its environments and dependencies, into a container that can be ported to any Linux system with cgroups support in the kernel, and also provides a container management environment.
-
----
-
-### Docker Compose
-A command line tool for managing multiple Docker multi-container applications.
-
----
-
-### Dockerfile
-A file containing instructions and parameters for creating a Docker image for specific tasks.
-
----
-
-### Docker image
-A read-only template on the Docker platform that is used to create containers.
-
----
-
-### Delegated Proof-of-Stake (DPoS)
-A consensus algorithm initially developed by Daniel Larimer in 2013 for BitShares. It is sometimes referred to as the more “democratic” version of Proof-of-Stake (PoS).
-
----
-
-### ERC-20
-The token standard used for Ethereum smart contracts. Developed in 2015, ERC-20 defines a common list of rules that Ethereum tokens must implement. This gives developers the ability to program how new tokens will function within the Ethereum ecosystem.
-
----
-
-### ERC-721
-A more complex token standard than ERC-20 that is split across a number of contracts with multiple optional extensions. Unlike ERC-20, tokens of this standard are not interchangeable. No two ERC-721 tokens are the same, and each have different characteristics.
-
----
-
-### Gwei
-A denomination, or smaller unit, of the cryptocurrency ETH, which is used on the Ethereum network. Gwei is the most commonly used unit of ETH because gas prices are easily specified in gwei. For example, instead of saying that your gas costs *0.000000001* ETH, you can say your gas costs *1* gwei.
-
----
-
-### Head block
-The head block is the last block written to the blockchain, stored in reversible blocks.
-
----
-
-### Key
-A string of characters (bit string) that is used by the cryptographic algorithm for encrypting and decrypting messages, setting and verifying digital signatures, and identification. Keys are symmetric (the same key is used for encryption and decryption), and asymmetric (public and private).
-
----
-
-### Merkle Mountain Range
-A type of merkle tree that can be visualized as many (perfect) merkle trees which are then combined into 1, by creating a single root from all of their peaks.
-
----
-
-### Merkle-Patricia Tree
-A hash tree that stores key-value pairs, with the keys being represented in binary form. The nodes of this tree consist of two types: prefix nodes that contain part of the path, and end nodes that contain the stored value.
-
----
-
-### MetaMask
-A software cryptocurrency wallet that is used to interact with the Ethereum blockchain. It allows users to access their Ethereum wallet through a browser extension or mobile app, which can then be used to interact with decentralized applications.
-
----
-
-### Minimum Viable Product (MVP)
-A product with minimal features and/or functionality, but enough to satisfy early consumers. Its purpose is to gather feedback and learnings to inform further product development.
-
----
-
-### NeonPass
-An open-source service for transferring SPL tokens to Neon EVM.
-
----
-
-### NeonSwap
-An open-source service being a fork of [Uniswap V2](https://uniswap.org/blog/uniswap-v2) and modified to work with Neon EVM.
-
----
-
-### Node
-A separate software device that is connected to the blockchain network according to the client-server scheme. Nodes are active elements and form the basis of the blockchain network technology.
-
----
-
-### Phantom
-A software cryptocurrency wallet reimagined for DeFi. Phantom makes it safe and easy for you to store, send, receive, collect, and swap tokens on the Solana blockchain.
-
----
-
-### Plugin
-A software component built as a separate module that adds new capabilities to the main program.
-
----
-
-### Private key
-A secret number (code string) that you can use to securely access your wallet or bitcoin address, and do transactions.
-
----
-
-### Proof-of-History (PoH)
-The blockchain algorithm for time synchronization. Instead of using the traditional timestamps, PoH is able to prove that a message or event occurred at a certain time after one event, but before another.
-
----
-
-### Proof-of-Stake (PoS)
-Proof-of-Stake is a method of cryptocurrency protection in which the probability of forming the next block on the blockchain depends on the existing stake of the participant and not on powerful equipment, as is the case with Proof-of-Work (PoW).
-
----
-
-### Public key
-A publicly available key that is required for users to receive transactions into their account. A public key can be inferred from a signature.
-
----
-
-### Remix
-An online Integrated Development Environment (IDE) used to write, compile, deploy, and debug Solidity code. This web tool can be connected with MetaMask and used to deploy smart contracts to both the Solana Testnet and Solana Mainnet.
-
----
-
-### Remote Procedure Call (RPC)
-A system that lets users send queries and commands to a system remotely.
-
----
-
-### Rivest-Shamir-Adleman (RSA)
-A public key cryptosystem that is widely used for secure data transmission.
-
----
-
-### Serialization
-The process of turning an object in memory into a stream of bytes so it can be stored on disk or sent over the network.
-
----
-
-### Signature
-A mathematical algorithm used to demonstrate the authenticity of digital messages or documents.
-
----
-
-### Slippage
-The difference between where the computer signaled the entry and exit for a trade and where actual clients, with actual money, entered and exited the market using the computer’s signals.
-
----
-
-### Slot
-The period of time during which a block is created. Collectively, slots create a logical clock. Slots are ordered sequentially and non-overlapping, comprising roughly equal time.
-
----
-
-### Smart contract
-A computer protocol intended to facilitate, verify, or enforce the negotiation or performance of a contract.
-
----
-
-### Sollet
-Sollet (Sollet.io) is browser-based wallet for Solana and SPL tokens. It was created by the Project Serum team.
-
----
-
-### Solana Program Library (SPL)
-A contract containing a system registry of tokens that are in the system along with the Solana balances of their accounts.
-
----
-
-### SPL token
-A token registered in the *[Solana Program Library (SPL)](https://spl.solana.com/token)*.
-
----
-
-### Staked tokens
-Tokens allocated for a stake acquisition that can’t be used for anything else in this state. The user can stake active tokens listed on their balance, or deposit them. The user can also perform the reverse operation: withdraw tokens from the staked state to active.
-
----
-
-### Tmpfs
-A temporary file storage paradigm implemented in many Unix-like operating systems. It is intended to appear as a mounted file system, but data is stored in volatile memory instead of a persistent storage device.
-
----
-
-### Transaction
-A combination of one or more actions that results in a complete all-or-nothing change to the blockchain. Usually the executional result of a smart contract.
-
----
-
-### Uniswap
-A decentralized exchange. Liquidity providers can earn fees by providing the required tokens or ETH for both sides of a trade. Uniswap is widely used and therefore has one of the highest liquidities for a wide range of tokens.
-
----
-
-### USDT
-USDT is the ticker symbol for the Tether stablecoin cryptocurrency.
-
----
-
-### Wallet
-Wallets are clients that store keys that may or may not be associated with the permissions of one or more accounts. Ideally a wallet has a locked (encrypted) and unlocked (decrypted) state, which is protected by a high entropy password.
-
----
-
-### Web3
-In the context of Ethereum, Web3 is a collection of decentralized apps that run on the blockchain and allow anyone to participate without monetizing their personal data.
-
----
-
-### Wormhole
-The Solana Wormhole is an Ethereum bridge that helps transfer wealth from the Ethereum blockchain to the Solana blockchain. It also helps transfer liquidity between the Ethereum ERC-20 token standard to the Solana SPL token standard.
-
----
-
-### ZK-STARK
-Zero-Knowledge Scalable Transparent Argument of Knowledge (zk-STARK) is a cryptographic protocol that uses public zero-knowledge probabilistically-verifiable proofs. This technology allows users to exchange verified information without disclosing it, or to perform computations with a third party without disclosing the computation.
-
----
diff --git a/docs/about/why_neon.md b/docs/about/why_neon.md
deleted file mode 100644
index d190e8b4..00000000
--- a/docs/about/why_neon.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Why Neon EVM
----
-
-*Neon EVM is a solution for anyone looking to scale Ethereum dApps on Solana in a developer-friendly manner and get access the growing Solana Ecosystem.*
-
-## Neon EVM
-
-Neon EVM is a viable solution that allows dApp developers to access the advantages of Solana to expand their services, to offer new products like arbitrage or high-frequency trading, grow their user base, and decrease costs where possible, including gas fees. Neon EVM enables full compatibility with Ethereum on Solana.
-
-The solution allows any Ethereum application to be run on Solana without any changes to its codebase, including Uniswap, SushiSwap, 0x, and MakerDAO. All key Ethereum dApp tools can also work on Solana, including Solidity, MetaMask, Remix, and Truffle.
-
-So Neon EVM is best suited to developers who want to enjoy a first-mover advantage and reach new customers on Solana, or those who want to scale with the low gas fees and high throughput that Solana provides. It is also good for developers looking to tap into liquidity on Solana.
-
-## The Best from Ethereum World
-
-Ethereum is set to remain a booming blockchain ecosystem. The number of active dApps on Ethereum is hovering above 300, and the number of active users of these dApps is close to 6 million, with the number of transactions on the rise. Ethereum’s popularity is not only down to its processing of smart contracts, but also its sophisticated infrastructure for application development.
-
-* Familiar languages: Solidity, Vyper
-* Well-known Ethereum tools: MetaMask, Hardhat, Truffle, Remix, etc.
-* Ethereum RPC API compatibility
-* Ethereum Accounts, Signatures, Token standarts (ERC-20, ERC-721)
-* No code changes required
-
-## The Best from Solana World
-
-Solana is one of the most technically advanced and innovative blockchains, offering low gas fees and high throughput of transactions. Among these innovations is its Proof-of-Stake (PoS) consensus system, which is reinforced via a Proof-of-History protocol, a transaction parallelization technology that optimizes resources and ensures that Solana can scale horizontally across GPUs and SSDs, along with an optimized mempool system that speeds up throughput.
-
-* parallel execution of transactions
-* low gas fee - number from site
-* high transaction speed - number from site
-* access to the growing Solana Ecosystem
-* uses Solana consensus mechanism and state, no additional validators
diff --git a/docs/about/why_neon.mdx b/docs/about/why_neon.mdx
new file mode 100644
index 00000000..f9c085dc
--- /dev/null
+++ b/docs/about/why_neon.mdx
@@ -0,0 +1,68 @@
+---
+title: Why Neon EVM?
+proofedDate: 20230426
+iterationBy: HB
+includedInSite: true
+approvedBy: YYY
+comments: na
+---
+
+import { ImgTheme } from '@site/src/components/ImageTheme';
+
+_Neon EVM is a low-friction solution to scale Ethereum dApps on Solana._
+
+
+
+## Neon EVM
+
+Neon EVM is a fully compatible Ethereum environment solution built on the Solana blockchain. The platform allows developers to deploy Ethereum dApps without undertaking any reconfiguration.
+
+:::info
+Minimal reconfiguration required: allowing Ethereum developers to build without Rust.
+:::
+
+Neon EVM enables Solidity- and Vyper-based dApps to tap into Solana’s network benefits: low fees, high transaction speeds, and parallel transaction execution capabilities.
+
+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), [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?
+
+Teams interested in significant savings (thanks to the low gas fees, or scaling with the high throughput that Solana provides) are likely to be the first movers. Neon EVM serves any developers or product teams who wish that their dApp could reach customers on Solana. Neon EVM also opens up the liquidity on Solana to DeFi products.
+
+## The best from Ethereum
+
+Ethereum has firmly established itself as a significant blockchain ecosystem, providing a robust settlement layer. However, Ethereum's gas prices and transaction speeds create such challenges for dApps that an entire L2 and rollup ecosystem has erupted to address these issues.
+
+Neon EVM offers a better solution: by bringing Solana's sophisticated and low-cost transaction capabilities to Ethereum builders.
+
+With Neon EVM, developers retain:
+
+- Familiar languages: Solidity, Vyper
+- Well-known Ethereum tools: MetaMask, Hardhat, Foundry, Remix, etc.
+- Ethereum RPC API compatibility
+- Ethereum Accounts, Signatures, Token standards (ERC-20 and ERC-721)
+
+## The best from Solana
+
+Solana is one of the most technically advanced and innovative blockchains: offering low gas fees and high throughput of transactions. Among these innovations is its Proof-of-Stake (PoS) consensus system, that is reinforced via a Proof-of-History (PoH) protocol. Solana's transaction parallelization technology optimizes resources and ensures horizontal scaling across GPUs and SSDs. Furthermore, Solana's optimized mempool system speeds up throughput.
+
+Solana offers developers:
+
+- Parallel execution of transactions (txs)
+- Low gas fees: 0.000015 SOL/tx
+- High transaction speed: 2,000+ tps
+- Access to the growing Solana Ecosystem
+- Solana's consensus mechanism and state, with no additional validators
+
+## Public and audited
+
+Not only is Neon EVM available on [GitHub](https://github.com/neonevm/neon-evm) for interested parties to examine and review, it has also passed several audits, such as:
+
+- [Neon EVM audit](https://github.com/neonevm/neon-evm/tree/develop/audit)
+- [Neon Proxy audit](https://github.com/neonevm/proxy-model.py/tree/develop/audit)
+- [DAO governance protocol audit](https://github.com/neonevm/neon-spl-governance/tree/main/audit)
diff --git a/docs/api/neon-api.mdx b/docs/api/neon-api.mdx
new file mode 100644
index 00000000..eb38ac1f
--- /dev/null
+++ b/docs/api/neon-api.mdx
@@ -0,0 +1,354 @@
+---
+title: Neon API
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: Needs version control process -- just tabs v1 v2 ...? will we use semantic versioning https://semver.org/spec/v2.0.0.html // todo BUG The UX is not great with tabs -- menu bar unable to locate heading items within the currently-unused tab ONLY once that tab is entered does menu work. Is this worth investing in FE fix OR do I have to flatten?
+source:
+---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import JSONSchemaViewer from "@theme/JSONSchemaViewer";
+import CodeBlock from '@theme/CodeBlock';
+import neon_versions_request from "@site/static/schemas/neon-api/v1/neon_versions/request.json";
+
+import neon_gasPrice_request from "@site/static/schemas/neon-api/v1/neon_gasPrice/request.json";
+import neon_getLogs_request from "@site/static/schemas/neon-api/v1/neon_getLogs/request.json";
+import neon_getTransactionReceipt_request from "@site/static/schemas/neon-api/v1/neon_getTransactionReceipt/request.json";
+import neon_getSolanaTransactionByNeonTransaction_request from "@site/static/schemas/neon-api/v1/neon_getSolanaTransactionByNeonTransaction/request.json";
+import neon_versions_response from "@site/static/schemas/neon-api/v1/neon_versions/response.json";
+import neon_emulate_request from "@site/static/schemas/neon-api/v1/neon_emulate/request.json";
+import neon_gasPrice_response from "@site/static/schemas/neon-api/v1/neon_gasPrice/response.json";
+import neon_getLogs_response from "@site/static/schemas/neon-api/v1/neon_getLogs/response.json";
+import neon_getTransactionReceipt_response from "@site/static/schemas/neon-api/v1/neon_getTransactionReceipt/response.json";
+import neon_getSolanaTransactionByNeonTransaction_response from "@site/static/schemas/neon-api/v1/neon_getSolanaTransactionByNeonTransaction/response.json";
+import neon_emulate_response from "@site/static/schemas/neon-api/v1/neon_emulate/response.json";
+import neon_getEvmParams_request from "@site/static/schemas/neon-api/v1/neon_getEvmParams/request.json";
+import neon_getEvmParams_response from "@site/static/schemas/neon-api/v1/neon_getEvmParams/response.json";
+
+
+
+:::danger
+
+This page is wip 👷
+
+:::
+
+## TL;DR
+
+Neon provides several endpoints to assist our users to access data related to the Neon Proxy service. Each Proxy may be queried to provide details on:
+
+- Transactions
+- Versions
+- Configurations
+
+## Neon Proxy API service
+
+This page provides the information you need to interact with the Proxy query services.
+
+## Authentication
+
+No authentication is required. All publicly-available JSON RPC endpoints are listed on [Chainlist](https://chainlist.org/?chain=245022926&testnets=true&search=Neon+EVM).
+
+:::note
+The curl request below uses P2P's public endpoint. You may select whichever Proxy Operator you prefer, or (coming soon), run your own Proxy server.
+:::
+
+## Neon API specifications
+
+All API calls use the `POST` method.
+
+For example, the following request returns the current Neon Proxy version being provided by P2P:
+
+```bash
+curl -X POST https://neon-proxy-mainnet.solana.p2p.org \
+-H "Content-Type: application/json" \
+-d '{"method":"neon_proxyVersion"}'
+```
+
+
+
+## API services
+
+The following services are available in Neon API V1:
+
+### 1. Version information
+
+The method [neon_versions](#get-versions) returns a list of components and their versions provided by the current Neon Platform. Alternatively, you may request each component's version individually.
+
+### 2. Gas price information
+
+The method [neon_gasPrice](#get-neon-gas-price) returns data on gas price.
+
+### 3. Neon transaction data
+
+- [neon_getLogs](#get-transaction-logs--): returns transaction log data
+- [neon_getTransactionReceipt](#get-transaction-receipt--): returns transaction receipt data
+- [neon_getSolanaTransactionByNeonTransaction](#get-solana-transactions--): returns a list of Solana transactions that correspond to a given Neon transaction
+- [neon_emulate](#emulate-a-neon-transaction--): returns details of an emultated transaction
+
+### 4. Parameters
+
+[neon_getEvmParams](#get-parameters--): returns parameters of the Neon EVM program deployed on Solana.
+
+## Get versions
+
+
+
+The `neon_versions` method returns a list of all the components and their version as provided by the current Neon Proxy. Alternatively, apply the following methods for granular responses:
+
+- `neon_cliVersion` returns the current version of Neon EVM CLI used by the Neon Proxy
+- `neon_evmVersion` returns the current version of the Neon EVM program deployed
+- `neon_proxyVersion` returns the current version of the Neon Proxy
+- `neon_solanaVersion` returns the version of the Solana node the Neon Proxy runs on
+
+The [JSON](#get-version-request-as-json) and examples demonstrate the verbose request.
+
+
+
+#### Get version request as JSON
+
+{JSON.stringify(neon_versions_request, null, 2)}
+
+
+
+
+
+The [JSON](#get-version-request-as-json) and examples demonstrate the verbose response.
+
+
+
+#### Get version response as JSON
+
+{JSON.stringify(neon_versions_response, null, 2)}
+
+
+
+
+
+## Get Neon Gas price
+
+Neon Gas price may be requested for an individual account or for all accounts, depending on the parameters passed.
+
+
+
+
+
+
+The [JSON](#get-neon-gas-price-request-as-json) for this request schema is available below.
+
+
+
+#### Get Neon Gas price request as JSON
+
+{JSON.stringify(neon_gasPrice_request, null, 2)}
+
+
+
+
+
+The [JSON](#get-neon-gas-price-response-as-json) for this response schema is available below.
+
+
+
+
+#### Get Neon Gas price response as JSON
+
+{JSON.stringify(neon_gasPrice_response, null, 2)}
+
+
+
+
+## Get transaction data
+
+### Get transaction logs 👷
+
+The `neon_getLogs` method returns transaction log data. This is an extended variant of the [eth_getLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs) API method.
+
+#### Request
+
+
+
+
+
+
+
+
+
+
+{JSON.stringify(neon_getLogs_request, null, 2)}
+
+
+
+
+#### Response
+
+
+
+
+
+
+
+
+
+{JSON.stringify(neon_getLogs_response, null, 2)}
+
+
+
+
+### Get transaction receipt 👷
+
+The `neon_getTransactionReceipt` method returns transaction receipt data.
+
+#### Request
+
+
+
+
+
+
+
+
+
+{JSON.stringify(neon_getTransactionReceipt_request, null, 2)}
+
+
+
+
+#### Response
+
+
+
+
+
+
+
+
+
+{JSON.stringify(neon_getTransactionReceipt_response, null, 2)}
+
+
+
+
+### Get Solana transactions 👷
+
+The `neon_getSolanaTransactionByNeonTransaction` method returns a list of Solana transactions that correspond to a given Neon transaction.
+
+#### Request
+
+
+
+
+
+
+
+
+
+{JSON.stringify(neon_getSolanaTransactionByNeonTransaction_request, null, 2)}
+
+
+
+
+#### Response
+
+
+
+
+
+
+
+
+
+{JSON.stringify(neon_getSolanaTransactionByNeonTransaction_response, null, 2)}
+
+
+
+
+
+## Emulate a Neon transaction 👷
+
+The `neon_emulate` method returns details of an emultated transaction.
+
+
+
+
+The [JSON](#get-neon-emulate-request-as-json) for this request schema is available below.
+
+
+
+#### Get Neon emulate request as JSON
+
+{JSON.stringify(neon_emulate_request , null, 2)}
+
+
+
+
+
+The [JSON](#get-neon-emulate-response-as-json) for this response schema is available below.
+
+
+
+
+#### Get Neon emulate response as JSON
+
+{JSON.stringify(neon_emulate_response, null, 2)}
+
+
+
+
+## Get Parameters 👷
+
+
+The `neon_getEvmParams` method returns details of the EVM.
+
+
+
+
+The [JSON](#get-neon-evm-parameters-request-as-json) for this request schema is available below.
+
+
+
+The `neon_getEvmParams` method returns details of the EVM.
+
+{JSON.stringify(neon_getEvmParams_request, null, 2)}
+
+
+
+
+
+The [JSON](#get-neon-evm-parameters-response-as-json) for this response schema is available below.
+
+
+
+
+#### Get Neon EVM parameters response as JSON
+
+{JSON.stringify(neon_getEvmParams_response, null, 2)}
+
+
+
diff --git a/docs/architecture/core_aspects/account.md b/docs/architecture/core_aspects/account.md
deleted file mode 100644
index 1da222d2..00000000
--- a/docs/architecture/core_aspects/account.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Ethereum Account
----
-
-*An Ethereum account is an entity with an ETH balance that can send transactions on Ethereum. Accounts can be user-controlled or deployed as smart contracts.*
-
-## Account Types
-
-Ethereum has two account types:
-* **Externally-owned** – controlled by anyone with the private keys.
-* **Contract** – a smart contract deployed to the network, controlled by code.
-
-### Key Differences
-
-**Externally-owned**
-* Creating an account costs nothing.
-* Can initiate transactions.
-* Transactions between externally owned accounts can only be ETH transfers.
-
-**Contract**
-* Creating an account has a cost because you're using network storage.
-* Can only send transactions in response to receiving a transaction.
-* Transactions from an external account to a contract account can trigger code which can execute many different actions, such as transferring tokens or even creating a new contract.
-
-## An Account Examined
-
-Ethereum accounts have four fields:
-* **Nonce** – a counter that indicates the number of transactions sent from the account.
-* **Balance** – the number of wei owned by this address. Wei is a denomination of ETH and there are 1e+18 wei per ETH.
-* **CodeHash** – refers to the code of an account on the Ethereum virtual machine (EVM). This EVM code cannot be changed, unlike the other account fields. For externally owned accounts, the codeHash field is the hash of an empty string.
-* **StorageRoot** – known as a storage hash. A 256-bit hash of the root node of a Merkle-Patricia Trie that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. This trie encodes the hash of the storage contents of this account, and is empty by default.
-
-## Externally-owned Accounts
-
-An account is made up of a cryptographic pair of keys: public and private. They help prove that a transaction was signed by the sender in order to prevent forgeries. Your private key is what you use to sign transactions, so it grants you custody over the funds associated with your account. You never really hold cryptocurrency; you hold private keys. The funds are always on Ethereum's ledger.
-
-## Account Creation
-
-When you have to create an account, most libraries will generate a random private key for you.
-A private key is made up of 64 hex characters and can be encrypted with a password.
-
-Example:
-`ffffffffffffffffffffffffffffffff48a03bbfd25e8cd036415febaaedce6a`
-
-The public key is generated from the private key using the [Elliptic Curve Digital Signature Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm). To get a public address for your account, you need to add `0x` before the last 20 bytes of the public key.
-
-## Contract Accounts
-
-Contract accounts have a 42-character hexadecimal address:
-
-Example:
-`0x02042f8cf97ae237070f9587f8e7a266dbead5de`
-
-The contract address is given when a contract is deployed to the Ethereum blockchain. The address comes from the creator's address and the number of transactions sent from that address (`nonce`).
-
-> **Note**
-> An account is not a wallet. A wallet is the keypair associated with a user-owned account, which allows a user to make transactions from or manage the account.
-
-> **More details**
-> [ETHEREUM ACCOUNTS](https://ethereum.org/en/developers/docs/accounts/)
diff --git a/docs/architecture/core_aspects/block.md b/docs/architecture/core_aspects/block.md
deleted file mode 100644
index 131cd781..00000000
--- a/docs/architecture/core_aspects/block.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Block
----
-
-*Blocks are batches of transactions with a hash of the previous block in the chain. Hashes link blocks together (in a chain) because they are cryptographically derived from the block data. One change in any block in history will invalidate all the following blocks. This feature protects the blocks in a chain from tampering.*
-
-*To preserve the transaction history, blocks are strictly ordered (every new block created contains a reference to its parent block), and transactions within blocks are strictly ordered, too.*
-
-## What is in a block?
-
-* **Timestamp** – the time at which the block was mined.
-* **Block number** – the length of the blockchain in blocks.
-* **Difficulty** – the effort required to mine the block.
-* **MixHash** – a unique identifier for that block.
-* **Parent hash** – the unique identifier for the block that came before. (This is how blocks are linked in a chain.)
-* **Transactions list** – the transactions included in the block.
-* **State root** – the entire state of the system: account balances, contract storage, contract code, and account nonces.
-* **Nonce** – a hash that, when combined with the mixHash, proves that the block has gone through proof of work.
-
-## Block Size
-
-Blocks themselves are bound in size. Each block has a block gas limit which is set by the network and the miners collectively. The total amount of gas expended by all transactions in the block must be less than the block gas limit.
-
-> **More details**
-> [Blocks](https://ethereum.org/en/developers/docs/blocks/)
diff --git a/docs/architecture/core_aspects/gas.md b/docs/architecture/core_aspects/gas.md
deleted file mode 100644
index e37c113b..00000000
--- a/docs/architecture/core_aspects/gas.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Gas
----
-
-Gas is required for the Ethereum network. This is the fuel that allows it to work, just as a car needs gasoline to run.
-
-## What is gas?
-
-Gas is a unit of measurement that determines the amount of computational effort required to perform certain operations on the Ethereum network.
-
-Since each transaction requires computational resources to execute, each transaction requires a fee. Gas refers to the fee required to successfully conduct a transaction on the network.
-
-Performing any operation on Ethereum requires gas consumption. This includes calculations, storing or manipulating data, or transferring tokens, each consuming different amounts of "gas" units. As dApp functionality becomes more complex, the number of operations a smart contract performs grows too, and all of them lead to large amounts of gas that must be paid for.
-
-## What is gas limit?
-
-Gas limit means the maximum amount of gas you are willing to consume on a transaction. A higher gas limit means more computational work can be done while interacting with smart contracts.
-
-For example, if you put a gas limit of 50,000 for a simple coin transfer, the coins would consume 21,000, and you would get back the remaining 29,000. However, if you specify too little gas, for example, a gas limit of 20,000 for a simple coin transfer, the coins will consume your 20,000 gas units attempting to fulfill the txn, but the transfer will not be completed. The EVM then reverts any changes, but since 20,000 gas units worth of work has already been done, that gas is consumed.
-
-> **More details**
-> [GAS and FEES](https://ethereum.org/en/developers/docs/gas/)
diff --git a/docs/architecture/core_aspects/proof-of-stake.md b/docs/architecture/core_aspects/proof-of-stake.md
deleted file mode 100644
index 487ec565..00000000
--- a/docs/architecture/core_aspects/proof-of-stake.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Proof-of-Stake
----
-
-Ethereum is moving to a consensus mechanism called **Proof-of-Stake (PoS)** from **Proof-of-Work (PoW)**.
-
-## What is Proof-of-Stake?
-**PoS** is a method of cryptocurrency protection in which the probability of forming the next block in the blockchain depends on the existing stake of the participant and not on powerful equipment, as is the case with **PoW**.
-
-## How does PoS work?
-
-The network itself verifies transactions. It also maintains anonymity and security, since the cryptocurrency is already distributed among the users of the network.
-
-Unlike **PoW**, validators don't need to use significant amounts of computational power because they're selected at random and aren't competing. They don't need to mine blocks; they just need to create blocks when chosen and validate proposed blocks when they're not. This validation is known as attesting.
-
-## The PoS concept
-
-* The **PoS** concept states that people can mine or verify block transactions depending on how many coins they hold. This means that the more coins miners own, the more mining power they have.
-* The probability of checking a new block is determined by how large of a share that a person holds.
-* Validators do not receive block rewards; instead, they take network commission as their reward.
-* Unlike **PoW**, **PoS** systems can be more cost-effective and efficient, but less decentralized.
-
-
-> **More details**
-> [PROOF of STAKE](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/)
diff --git a/docs/architecture/core_aspects/proof-of-work.md b/docs/architecture/core_aspects/proof-of-work.md
deleted file mode 100644
index c95dec7a..00000000
--- a/docs/architecture/core_aspects/proof-of-work.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Proof-of-Work
----
-
-**Proof-of-work (PoW)** is a consensus protocol (proof-of-work completion) that allows the decentralized Ethereum network to come to consensus or agree on things like account balances and the order of transactions. This prevents users "double spending" their coins and ensures that the Ethereum chain is incredibly difficult to attack or overwrite.
-
-## How does Ethereum's PoW work?
-
-Ethereum transactions are processed into blocks. Each block has a:
-* **Block difficulty** – for example: `3,092,324,262,183,265`
-* **MixHash** – for example: `0xf83b13079807244144bca881b07a6a09705d9f2f39a3cdf3bee29a665c5ac8bd`
-* **Nonce** – for example: `0x4fb3d26bd3ee432b`
-
-This block data is directly related to PoW.
-
-## Compared to PoS
-
-**PoW**
-Cryptocurrency mining requires expensive equipment, special knowledge, and labor. Most cryptocurrencies operate on the **PoW** protocol.
-
-**PoS**
-The number of coins in the user's account or on lease reflects their mining power. The more coins a user has, the higher their chances of creating the next block and, accordingly, receiving a reward from the transaction fee.
-
-> **More details**
-> [PROOF of WORK](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/)
-> [Proof of work](https://en.wikipedia.org/wiki/Proof_of_work)
diff --git a/docs/architecture/core_aspects/rust-evm.md b/docs/architecture/core_aspects/rust-evm.md
deleted file mode 100644
index 397d00ae..00000000
--- a/docs/architecture/core_aspects/rust-evm.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Rust-EVM
----
-(the text will be added later)
-https://docs.rs/evm/0.24.0/evm/index.html
\ No newline at end of file
diff --git a/docs/architecture/core_aspects/transaction.md b/docs/architecture/core_aspects/transaction.md
deleted file mode 100644
index 6009fbf1..00000000
--- a/docs/architecture/core_aspects/transaction.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Ethereum transaction
----
-
-An Ethereum transaction is a cryptographically signed instruction from an account. The account initiates a transaction to update the state of the Ethereum network. An Ethereum transaction refers to an action initiated by an external account, i.e. an account managed by a person, not a contract.
-
-A transaction, which changes the state of the EVM, needs to be broadcast to the whole network. Any node can broadcast a request for a transaction to be executed on the EVM. Transactions require a fee and must be mined to become valid.
-
-## What is in a transaction?
-
-A transaction includes the following information:
-* **Recipient** – recipient address
-* **Signature** – identifier of the sender (sender's signature with a private key)
-* **Value** – amount of coins to transfer from sender to recipient
-* **Data** – arbitrary data (optional field)
-* **GasLimit** – maximum amount of gas units that can be consumed by the transaction
-* **GasPrice** – fee the sender pays per unit of gas
-
-## Note
-* The block that your transaction is placed in can also contain many other transactions. Checking such a block for the validity of transactions may take more time. Higher-priority transactions are served first.
-* If the network is busy and miners aren't able to keep up, they always prioritize transactions with higher GasPrice because they get to keep the fees.
-* A transaction gets a block confirmation number. This is the number of blocks created since the block that this transaction was included in. The higher the number, the greater the certainty that the transaction was processed and recognized by the network. For higher value transactions, more block confirmations may be desired.
-
-
-> **More details**
-> [Transactions](https://ethereum.org/en/developers/docs/transactions/)
diff --git a/docs/architecture/core_aspects/web3.md b/docs/architecture/core_aspects/web3.md
deleted file mode 100644
index b512bc44..00000000
--- a/docs/architecture/core_aspects/web3.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Web3 concept
----
-
-**Web2** refers to the version of the internet most of us know today: an internet dominated by companies that provide services in exchange for your personal data.
-**Web3** refers to decentralized apps that run on the blockchain. These apps allow anyone to participate without monetizing their personal data.
-
-## The Differences Between Web2 and Web3
-
-**Web2** | **Web3**
-:-------- |:--------
-Twitter can censor any account or tweet | **Web3** tweets would be uncensorable because control is decentralized
-Payment service may decide not to allow payments for certain types of work | **Web3** payment apps require no personal data and can't prevent payments
-Servers for gig-economy apps could go down and affect worker income | **Web3** servers can't go down – they use a decentralized network of many computers as their backend
-
-## Web3 Limitations
-
-**Web3** has some limitations:
-* **Scalability** – transactions are slower on Web3 because they're decentralized.
-* **UX** – interacting with Web3 applications can require extra steps, software, and education.
-* **Cost** – most successful dApps put very small portions of their code on the blockchain as it's expensive.
-
-> **More details**
-> [Web2 vs Web3](https://ethereum.org/en/developers/docs/web2-vs-web3/)
diff --git a/docs/architecture/eth_sol_solution.md b/docs/architecture/eth_sol_solution.md
index 222c4dc8..30f26f5c 100644
--- a/docs/architecture/eth_sol_solution.md
+++ b/docs/architecture/eth_sol_solution.md
@@ -1,58 +1,63 @@
---
-title: Ethereum and Solana Capabilities in a Single Solution
+title: Ethereum & Solana in Synergy
+proofedDate: partial
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: Vladimir asked for BPF to be removed -- Yuri was going to investigate more about why -- todo in place inline. NB partial proof >> this page requires major overhaul, I am running through Grammarly to be able to accept the PR 102
---
-*This section describes a unique solution that allows Ethereum users to use the key features of Solana and vice versa.*
+This section describes a unique solution that allows Ethereum users to use the key features of Solana and vice versa.
### Terminology
- * **BPF** - the Berkeley Packet Filter virtual machine
- * **Contract** - smart contract
- * **dApp** - a decentralized application (plural: dApps)
- * **N-trx** - a neon transaction formed according to the Ethereum network and executed inside Neon EVM
- * **EVM** - the Ethereum Virtual Machine
- * **Proxy** - Neon Web3 Proxy
- * **S-trx** - a transaction formed according to the rules of the Solana network
+- **BPF**: the Berkeley Packet Filter virtual machine
+- **Contract**: smart contract
+- **dApp**: a decentralized application (plural: dApps)
+- **N-tx**: a Neon transaction formed according to the Ethereum network and executed inside Neon EVM
+- **EVM**: the Ethereum Virtual Machine
+- **Proxy**: Neon Web3 Proxy
+- **S-tx**: a transaction formed according to the rules of the Solana network
-
-## Key Capabilities of Ethereum
+## Key capabilities of Ethereum
Ethereum’s core innovation, the EVM, is a Turing-complete software that runs on the Ethereum network. The EVM allows developers to build and deploy dApps, which makes the process of creating blockchain applications much easier and more efficient. Contracts are treated as autonomous scripts or stateful dApps that are stored in the Ethereum blockchain for execution by the EVM at a later stage.
-Ethereum has a large number of developer tools available in its ecosystem, including *MetaMask*, *Remix*, and *Truffle*. The toolkit allows users to write dApps in Solidity, which is the standard language for developing contracts.
-
-Ethereum is the flagship of the crypto world. It runs numerous distributed applications that have proven themselves in the market and are in demand all over the world.
+Ethereum has a large number of developer tools available in its Ecosystem, including _MetaMask_, _Remix_, _Hardhat_, and _Foundry_. The toolkit allows users to write dApps in Solidity, which is the standard language for developing contracts.
+Ethereum is the flagship of the crypto world. It runs numerous dApps that have proven themselves in the market and are in demand worldwide.
-## Key Capabilities of Solana
+## Key capabilities of Solana
Solana is an exceptionally fast, secure, and relatively inexpensive blockchain network.
+
The Solana blockchain provides:
- * High performance, including:
- * Short block processing time
- * Processing many transactions per second due to the ability to execute transactions in parallel.
- * Low transaction fees.
- * The ability to increase the number of nodes in the network without reducing the performance of the network as a whole.
- * The capability to build in coding languages *C*, *C++*, and *Rust*.
+- High performance, including:
+ - Short block processing time
+ - Processing many transactions per second due to the ability to execute transactions in parallel
+- Low transaction fees
+- The ability to increase the number of nodes in the network without reducing the performance of the network as a whole
+- The capability to build in coding languages _C_, _C++_, and _Rust_
-## The Goal
+## The goal
-The goal is to find a solution that combined the best of both Ethereum and Solana. This solution would allow:
- * Solana users to use unique Ethereum toolkits to write dApps in Solidity.
- * Ethereum dApps to be deployed on Solana, thereby attracting a huge audience of Ethereum users to the Solana blockchain.
- * Ethereum users to significantly increase the speed of transactions and reduce the fee charged for their execution by using Solana.
+The goal was to find a solution that combined the best of both Ethereum and Solana. This solution allows:
+- Solana users to use Ethereum toolkits
+- Ethereum dApps to deploy on Solana, thereby attracting Ethereum's substantial audience to the Solana blockchain
+- Ethereum users benefit from Solana's competitive fees and fast settlement times
-## The Proposed Solution
+## The solution
-To achieve our goal, the following solution was proposed and implemented by the Neon Labs development team:
- * The EVM was integrated with Solana and named Neon EVM (an emulator implemented using Rust).
- * The Neon EVM operates inside Solana providing parallel transaction processing and a low transaction fee.
- * The Neon Web3 Proxy was created to mediate interactions between the Ethereum user (account) and Neon EVM. The main function of the proxy is to provide an API for external clients.
+Neon EVM provides:
+- An EVM integrated with Solana (an emulator implemented using Rust)
+- Solana's parallel transaction processing and low transaction fees
+- Neon Proxy: to mediate interactions between the Ethereum user (account) and Neon EVM
+ > The main function of the Proxy is to provide an API for external clients
-## The Solution in Detail
+## The solution in detail
The block diagram of the solution is shown in Fig. 1.
@@ -65,46 +70,62 @@ Fig. 1
### Berkeley Packet Filter (BPF)
-The BPF virtual machine is installed in Solana, allowing developers to embed other virtual machines inside Solana.
-Using BPF capabilities, a contract called Neon EVM is created in Solana, and the EVM was loaded inside it.
+The BPF virtual machine is installed in Solana, allowing developers to embed other virtual machines inside Solana.
+
+Using BPF capabilities, a contract called Neon EVM was created in Solana with the EVM loaded inside it.
+
+Because Solana has a contract update mechanism, the Neon EVM contract can also be updated independently from updates to the Solana node itself. This allows developers to update EVM versions without updating all the blockchain nodes.
+
+### Neon Proxy
+
+A user can form transactions under an Ethereum account and sign them with a public key generated in Ethereum. Transactions formed according to Ethereum rules are sent to the input of the Proxy component. This component converts N-txs into transactions under Solana rules.
-Because Solana has a contract update mechanism, the Neon EVM contract can also be updated independently from updates to the Solana node itself. This allows developers to update EVM versions without updating all the blockchain nodes.
+Converting a transaction in a one-to-one format is difficult due to two Solana constraints:
-### Neon Web3 Proxy
-A user can form transactions under an Ethereum account and sign them with a public key generated in Ethereum. Transactions formed according to Ethereum rules are sent to the input of the Proxy component. This component converts N-trxs into transactions under Solana rules.
+- The size of N-tx can exceed that of S-tx
+- The amount of resources that an S-tx can spend is limited
-The size of N-trx can exceed that of S-trx. Also, the amount of resources that an S-trx can spend is limited. Converting a transaction in a one-to-one format is difficult due to the potential lack of resources. Therefore, it was decided to generate multiple S-trxs for one N-trx. Each transaction generated is signed with a proxy key. The proxy sends the generated batch of transactions to Solana.
+To overcome these, Neon Proxy generates multiple S-txs for one N-tx. Each transaction generated is signed with a Neon Proxy key. Neon Proxy then sends the batch of transactions to Solana.
### Web3 API
-The proxy provides the full Web3 API to interact with external clients. In Ethereum, some contracts work at the blockchain level, and there is also an API that is supported by an Ethereum node. Clients that are created for Ethereum contracts support standard interfaces. For a client (such as MetaMask or Remix) to work in a web browser, it must work via the Web3 API. With Neon EVM, Ethereum dApps can be deployed on Solana without any edits to the source code or recompilation: dApps look and function exactly the same.
-Clients will work on a different blockchain if they are provided the same interface. You can do this by changing the address for where these clients need to go. Ethereum contracts and clients do not need to be rewritten to work in Solana; you just need to register the proxy address. Any client can run a proxy to deploy a contract inside Solana. The interface that the clients interact with will be the same as for dApps running on Ethereum.
+Neon Proxy provides the full Web3 API to interact with external clients. In Ethereum, some contracts work at the blockchain level, and there is also an API that is supported by an Ethereum node. Clients that are created for Ethereum contracts support standard interfaces. For a client (such as MetaMask or Remix) to work in a web browser, it must work via the Web3 API. With Neon EVM, Ethereum dApps can be deployed on Solana with minimal reconfiguration of the source code: dApps look and function exactly the same.
+
+Clients work on a different blockchain via the same interface by changing the address to which the clients are directed. This allows Ethereum contracts and clients to work in Solana by updating the registered proxy address and minimal reconfiguration. Any client can run a proxy to deploy a contract inside Solana. The interface that the clients interact with will be the same as for dApps running on Ethereum.
+
+
### Neon EVM
-The Neon EVM runs inside BPF, which is run by Solana. The Neon EVM is a Solana contract, so it recognizes the transaction format from the received batch. Neon EVM extracts data from each transaction, and therefore it can retrieve all the original user information that was placed in the transaction.
-The Neon EVM also validates the signature that is in the transaction. If the signature is authentic, the Neon EVM takes the contract code that the transaction is addressed to and starts to execute it. As soon as the contract code has been executed successfully, Neon EVM records a new state.
+The Neon EVM runs inside BPF, which is run by Solana. The Neon EVM is a Solana contract, so it recognizes the transaction format from the received batch. Neon EVM extracts data from each transaction, therefore, it can retrieve all the original user information placed in the transaction.
+
+
+
+The Neon EVM also validates the N-tx signature. If the signature is authentic, the Neon EVM takes the contract code that the transaction is addressed to and starts to execute it. As soon as the contract code has been executed successfully, Neon EVM records a new state.
-For example, if the transaction is a token transfer, the contract code sends tokens from one account to another. The Neon EVM simply records this new state.
+For example, if the transaction is a token transfer, the contract code sends tokens from one account to another. The Neon EVM records this new state.
-The user can also form a transaction to load a contract inside Neon EVM. In this case, the contract code will be written for Ethereum. A bytecode of this contract code will be loaded inside the Neon EVM. The contract itself and its data will be stored inside Solana.
+The user can also form a transaction to load a contract inside Neon EVM. In this case, the contract code will be written for Ethereum. A bytecode of this contract code will be loaded inside the Neon EVM. The contract itself and its data will be stored inside Solana.
-### Account Data Storage
-Solana stores account data. The Neon EVM has access to this storage, and uses the account data. After an account is registered in Solana, the account data is placed in this storage. Ethereum accounts are also stored here, but in the Solana representation. For each Ethereum address there is a corresponding account in the Solana representation. A contract code is placed in a corresponding account of this storage.
+### Account data storage
-Neon EVM interacts with a set of data that is stored on Solana's accounts. The Neon EVM can take a contract code from there using the corresponding account address to validate a transaction. The Neon EVM contains a virtual machine inside it that runs according to Ethereum rules.
+Solana stores account data in temporary storage. The Neon EVM has access to this storage, and uses the account data. After an account is registered in Solana, the account data is placed in this storage. Each Ethereum address corresponds to a Solana account, and contract code is placed into the corresponding account's storage.
+Neon EVM interacts with a set of data that is stored on Solana's accounts. The Neon EVM can take a contract code from there using the corresponding account address to validate a transaction. The Neon EVM contains a virtual machine inside it that runs according to Ethereum rules.
-## How Neon Works
+
+
+## How Neon works
A user calls a client that generates a transaction and sends it to the proxy, which is running the Neon EVM emulator inside it. (Fig. 2). The transaction is formed in accordance with the Ethereum rules, and contains mandatory fields, including:
- * **Nonce** - the number of transactions sent from the current address
- * **Signature** - generated in accordance with the Ethereum rules
- * **Gas price** - the fee the sender pays per unit of gas
- * **Gas limit** - maximum amount of gas units that can be consumed by the transaction
- * **Value** - amount of coins to transfer from sender to a recipient
- * **Recipient** - address of the recipient
+
+- **Nonce**: the number of transactions sent from the current address
+- **Signature**: generated in accordance with the Ethereum rules
+- **Gas price**: the fee the sender pays per unit of gas
+- **Gas limit**: maximum amount of gas units that can be consumed by the transaction
+- **Value**: amount of coins to transfer from sender to a recipient
+- **Recipient**: address of the recipient
@@ -114,22 +135,23 @@ Fig. 2
-To perform this transaction, the Neon EVM emulator makes a request to Solana to get state data. The proxy requests a blockchain state from Solana and makes a test launch of N-trx using the Solana state. On the basis of the data received, Proxy forms the new transaction according to Solana's rules. The transaction generated for Solana will contain the packaged N-trx, as well as the account data required to complete the transaction, including:
- * The Payer. (The account that pays for the transaction.)
- * Other accounts involved in the execution of this transaction.
+To perform this transaction, the Neon EVM emulator makes a request to Solana to get state data. The proxy requests a blockchain state from Solana and makes a test launch of the N-tx using the Solana state. On the basis of the data received, Neon Proxy forms the new transaction according to Solana's rules. The transaction generated for Solana will contain the packaged N-tx, as well as the account data required to complete the transaction, including:
-Next, the transaction is forwarded inside Solana, where participants of the transaction are determined according to the account data. The data added includes details about people who initiate and take part in processing the transaction. The operator of the proxy is specified as the payer. The payer will be rewarded for completing the transaction.
+- The payer: the account that pays for the transaction
+- Other accounts involved in the execution of this transaction
-Next, the transaction is transferred to Neon EVM, where its signature is checked according to Ethereum rules. If the signature is valid, the transaction will be transferred to the Solana blockchain for execution. Since testing of N-trx is carried out, it is possible to provide Solana with all the necessary information to run the execution of the N-trx in parallel.
+This transaction is then forwarded inside Solana, which uses the account data to determine the participants in the transaction. This data includes details about people who initiate and take part in processing the transaction. The operator of the proxy is specified as the payer. The payer will be rewarded for completing the transaction.
+Next, the transaction is transferred to Neon EVM, where its signature is checked according to Ethereum rules. If the signature is valid, the transaction will be transferred to the Solana blockchain for execution. Since testing of N-tx is carried out, it is possible to provide Solana with all the necessary information to run the execution of a batch of N-txs in parallel.
-## Benefits of the Neon Solution
+## Benefits of the Neon solution
Neon's solution offers the following benefits:
- * No changes or additional resources are required to implement dApps on Solana.
- * No need to rewrite clients for all existing dApps since the Ethereum node interface remains unchanged, and therefore clients can also run on the Solana node without changes.
- * No need to rewrite contracts for existing dApps.
- * Solana developers are given the opportunity to:
- * Use a unique toolkit created for Ethereum.
- * Create and deploy their contracts on the Solana network.
- * Unlike Ethereum, Neon EVM can be updated at any time, which means that new functionality can be added at any time and code updates can take place simply by uploading them as a new smart contract.
+
+- No changes or additional resources are required to implement dApps on Solana
+- No need to rewrite clients for all existing dApps since the Ethereum node interface remains unchanged, therefore, clients can also run on the Solana node without changes
+- Minimal reconfiguration of contracts for existing dApps
+- Solana developers are given the opportunity to:
+ - Use a unique toolkit created for Ethereum
+ - Create and deploy their contracts on the Solana network
+- Unlike Ethereum, Neon EVM can be updated at any time, which means that new functionality can extended, and code updates can take place simply by updating the Neon EVM smart contract.
diff --git a/docs/architecture/neon_evm_arch.md b/docs/architecture/neon_evm_arch.md
index da4fcc83..03c37141 100644
--- a/docs/architecture/neon_evm_arch.md
+++ b/docs/architecture/neon_evm_arch.md
@@ -1,5 +1,10 @@
---
-title: Neon EVM Architecture
+title: Architectural overview
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: review required
---
*This section describes the architectural solutions built into Neon EVM that enable fast transaction processing for Ethereum users. It also describes how tokens pass from users to final consumers.*
@@ -28,14 +33,14 @@ The components of the architecture are:
### Neon EVM User (user)
Any user who has an account in Neon EVM with a balance in ETH, ERC-20, or ERC-721 tokens.
-### Solana Transaction (S-trx)
+### Solana Transaction (S-tx)
A transaction formed according to Solana network rules with a signature produced by Solana rules.
-### Neon Transaction (N-trx)
+### Neon Transaction (N-tx)
A transaction formed according to Ethereum rules with a signature produced by Ethereum rules.
### Neon EVM Client (client)
-An application that has an EVM (Solidity, Vyper, etc.) bytecode contract loaded into Neon EVM. The application generates a transaction N-trx according to Ethereum rules and sends it to a proxy. Before sending N-trx, the client transfers the required funds to the Solana deposit to cover the costs of an operator.
+An application that has an EVM (Solidity, Vyper, etc.) bytecode contract loaded into Neon EVM. The application generates a transaction N-tx according to Ethereum rules and sends it to a proxy. Before sending N-tx, the client transfers the required funds to the Solana deposit to cover the costs of an operator.
### Neon EVM Operator (operator)
A role performed by a Solana account using a software tool. Within Neon EVM, an operator is provided with software in the form of a proxy in order to fulfill certain functions. The operator can deploy one or more proxies. The operator can also configure one proxy for multiple operators, as well as run several proxies with different settings.
@@ -45,11 +50,11 @@ The software that an operator uses to do their job. Although the proxy is not a
The proxy contains an EVM emulator that pre-tests the execution of the transaction. This testing determines the number of coins required on the operator's balance, as well as the current exchange rate of SOL to ETH. Each operator configures their proxy server with this course in mind. This relates to economic motivation.
-A proxy converts N-trx into transactions under Solana rules. N-trx is signed by a user, while S-trxs are signed by an operator. The Neon transaction text is loaded from the received S-trxs into a separate account that is created in Solana. Neon EVM receives a command to execute the transaction located at the address of this account.
+A proxy converts N-tx into transactions under Solana rules. N-tx is signed by a user, while S-txs are signed by an operator. The Neon transaction text is loaded from the received S-txs into a separate account that is created in Solana. Neon EVM receives a command to execute the transaction located at the address of this account.
-More details on how the proxy converts a N-trx to multiple S-trxs can be found [here](https://neonlabsorg.medium.com/neon-web3-proxy-facilitating-seamless-transactions-on-neon-evm-b33c2041aa08).
+More details on how the proxy converts a N-tx to multiple S-txs can be found [here](https://neonlabsorg.medium.com/neon-web3-proxy-facilitating-seamless-transactions-on-neon-evm-b33c2041aa08).
-Below is a list of the main Neon Web3 Proxy features that are implemented in the Neon EVM Testnet:
+Below is a list of the main Neon Web3 Proxy features that are implemented in the Neon EVM:
* Receiving requests over Web3 API protocol
* Shaping responses using Web3 API protocol
* Packaging a Neon transaction into a Solana transaction. The Solana transaction contains the following information:
@@ -74,7 +79,7 @@ Governance participants perform the following functions:
* Changing settings parameters such as the fee value, opening a new balance, the Mn value and the maximum number of iterations.
-### ERC-20 TKN
+### ERC-20 token
This is a contract based on the ERC-20 standard token. An ERC-20 token shows user balances for a certain ticker. After an account (user-acc) selects a type of token, this contract becomes blocked.
### SPL Token
@@ -160,9 +165,9 @@ The ERC-20 wrapper allows users to transfer their SPL tokens on the ERC-20 Balan
### Payment Queues
**The Issue**
-If the ERC-20 TKN contract contains only one map for all users and their balances, it can result in an issue: if the majority of users pay with ETH tokens, then the same contract will appear inside each N-trx, where the value will need to be changed.
+If the ERC-20 TKN contract contains only one map for all users and their balances, it can result in an issue: if the majority of users pay with ETH tokens, then the same contract will appear inside each N-tx, where the value will need to be changed.
-This will cause all N-trxs to line up “single file”, and they cannot be executed in parallel. This is because at the final step, the funds would be transferred from the user's balance to the operator's balance within one contract.
+This will cause all N-txs to line up “single file”, and they cannot be executed in parallel. This is because at the final step, the funds would be transferred from the user's balance to the operator's balance within one contract.
**The Solution**
The default token type field is added to the Neon account along with the balance. This field provides a special option that will allow a user to select a type of token for payment. The ERC-20 wrapper can be used to transfer SPL tokens from outside to an operator's account.
diff --git a/docs/architecture/solana-accounts.md b/docs/architecture/solana-accounts.md
new file mode 100644
index 00000000..5741ed49
--- /dev/null
+++ b/docs/architecture/solana-accounts.md
@@ -0,0 +1,39 @@
+---
+title: Solana accounts
+proofedDate: 20231109
+iterationBy: na
+includedInSite: true
+approvedBy: Sukanya
+comment:
+---
+
+## Introduction
+
+Neon EVM provides a competitive solution by settling on Solana. Solana offers inexpensive transaction costs and only charges for storage allocation. This contrasts with Ethereum, where calculations require much more gas, and gas is charged for every change in data stored. As a result, gas usage on Solana is much cheaper than on Ethereum, and the Neon EVM passes these savings on to users.
+
+A large part of how Solana offers such affordable transactions is through its accounts and storage. This page provides a high-level overview of the Solana holder account.
+
+## Holder accounts
+
+Solana's holder accounts are a crucial element of Neon EVM. You may think of the holder account as a temporary file in the operating system (OS). The Neon Proxy writes a large Neon transaction to the holder account as a temporary file. It then calls the Neon EVM program to execute the Neon transaction by loading it from the holder account.
+
+These enable the Neon EVM to overcome some of the compatibility challenges of settling Ethereum-like transactions to Solana:
+
+- Transaction size differences
+- Cycle/gas differences
+
+### Transaction size
+
+An Ethereum transaction and, therefore, a Neon transaction can be large: with an upper limit of 128 KiB. A Solana transaction is small, with an upper limit of 1240 B.
+
+Neon Proxy writes any large Neon transactions into a holder account before execution. This allows Neon EVM to receive big Neon transactions on-chain.
+
+### Cycle size
+
+A Solana transaction can use 1’400’000 BPF cycles. An Ethereum-like transaction has a limit of 30’000’000 gas. So, executing a long Ethereum-like transaction in **one** Solana transaction is impossible. Neon EVM executes Neon transactions in iterative mode with the EVM state stored in a holder account between iterations.
+
+Solana may interrupt the Neon EVM program due to the BPF cycle limit, so the program needs to store the current EVM state and restore it to continue executing the transaction from the interruption point.
+
+## Holder account size
+
+The default size for the holder account is 256KiB. This size is recommended because it's the HEAP size available for Neon EVM during transaction execution, i.e. it's the maximum HEAP size available for Solana programs during Solana transaction execution.
diff --git a/docs/architecture/value_token.md b/docs/architecture/value_token.md
deleted file mode 100644
index 817110b5..00000000
--- a/docs/architecture/value_token.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Transaction Value Token
----
-
-*This section contains introductory information about the *Transaction Value token* (hereinafter *Value token*), which is analogous to the ETH token in Neon EVM solutions.*
-
-Using the original `ETH` token in Neon EVM can create additional difficulties when calculating payment of rewards to transaction participants. Therefore, the *Value token* has been introduced to circulate inside Neon EVM. This token is analogous to ETH, coming from the Ethereum network through one of the bridges, [Wormhole](https://solana.com/wormhole) or [Sollet](https://solana.com/ecosystem/sollet). Each of these bridges transfers funds (assets) from ETH-token to SPL-token and back.
-
-The transfer of funds using bridges is automated, so the converted tokens are directly transferred to Neon EVM. The token conversion scheme is implemented in such a way that it allows transactions to be executed in parallel. Unlike the method of conversion used in Ethereum through ERC-20 tokens, where a map is used with accounts inside a contract, this scheme does not allow transactions to line up in one queue.
-
-
-
-
-
-
-
-## Storing Balances Inside Neon EVM
-Inside the Neon EVM is the Ethereum account. For each user, the Ethereum account contains two fields for storing two types of coins:
- * `ETH` (or `USDT`) - a coin identifier, which is a *Value token*
- * `PAYMENT` - a token to pay for transactions. Each user can create a token, which they will pay the operator with for transactions.
-
-Part of the Ethereum account code should work with `ETH` and the other part with `PAYMENT`.
-
-The Solana account is outside the Neon EVM and is built as a program address of the Ethereum account. Therefore, only the Ethereum account can access the Solana account. The Solana account contains a balance in SPL tokens. All operations with a *Value token* are performed through an appeal to the SPL token. This balance is built in a certain fixed way according to the Ethereum account address and the Neon EVM program address. Therefore, only the Solana account can access this balance.
-
-Since only a specific Ethereum account can access the Solana account, only this Ethereum account can access the Solana account balance as well.
-
-When funds are transferred between users, an `SPL` token is requested, and it transfers funds from one balance to another. Users' balances are stored in their accounts. This balance placement eliminates queues for processing transactions.
-
-The Neon EVM contains the ERC-20 contract. This contract works with the balances of Solana's accounts. (The ERC-20 contract is called from inside the Solidity contract.)
-
-## Creating an Ethereum Account
-As soon as an Ethereum account is created, an `SPL` token balance is automatically built for a specific user. This operation can only be done by Neon EVM since only it has authorization to perform an operation from the program-account address (Solana account).
-
-After the Ethereum account is created, it becomes possible to send a *Value token* to the contract to a user's balance to process transfers made from the contract code.
-
-## Payment for the Execution of a Transaction
-
-A user has the ability to choose the token in which they will pay an operator for completing a transaction.
-To do this, the user creates an account in Neon EVM where they can transfer `ETH` tokens through a bridge to pay for transactions. They automatically get a balance in the SPL token.
-> *Transferring `ETH` (or `USDT`) tokens through one bridge (for example, through [Wormhole](https://solana.com/wormhole)) will not be equivalent to transferring the same tokens through another bridge (for example, through [Sollet](https://solana.com/ecosystem/sollet)). This means that the user cannot withdraw `ETH` tokens from their balance through one bridge ([Wormhole](https://solana.com/wormhole)), if these tokens were transferred to this balance through another bridge ([Sollet](https://solana.com/ecosystem/sollet))*.
-
-Since a coroutine address is linked to the user's balance, no one except this coroutine address can use this token.
-
-### Token Circulation
-Depending on the number of operations in a transaction, it can be performed in one or several iterations. When a user creates a transaction, they specify the cost of its execution, taking into account gas price. For each iteration performed separately, funds are transferred to an operator from the specified total transaction cost. Neon EVM acts as a guarantor in payment of funds to the operator for each iteration performed by them in accordance with the gas price.
-
-#### Token Circulation for Transaction Execution in One Iteration
-Before executing a transaction, an operator transfers funds to the Neon token collateral pool. At the same time, they pay a fee to the validator for checking signatures, and pay rent for storing data on the balance of the account.
-
-After the transaction is completed, `PAYMENT` tokens are transferred from the user's balance to the operator's balance to cover the costs.
-
-#### Token Circulation for Transaction Execution in Multiple Iterations
-Unlike a non-iterative transaction, the payment of funds to operators is added to make them more interested in facilitating faster transaction execution. This is done so that the accounts involved in the process are not blocked for an extended period of time.
-
-At the start of an iterative transaction, an operator transfers a fee to the collateral pool, as well as funds (`SOL` tokens) to a special deposit account. The funds in this account will be paid to the operator who completes the transaction. The fee will be paid for execution costs over multiple iterations.
-
-The priority to receive funds from a deposit is given to the operator who sent the transaction for execution.
-
-A transaction contains the name of the operator that is executing it. Also, the transaction indicates the block number when the last activity of this operator occurred. If fewer blocks have passed than the hardcoded value of the blocks, then this operator can continue the transaction. Only the operator specified in the transaction can cancel it. If more blocks have passed, then any operator can continue the transaction. The right to execute the transaction passes to the operator that intercepts this execution; that is, who is ahead of the others.
-
-The right to withdraw funds from a deposit is granted to the operator who performs the final step. At this step, the user's funds are transferred to the deposit.
-
-If for some reason a transaction is canceled (using the "Cancel" operation), the blocked funds of a user are returned to them. The deposit that was frozen is burned. No payout is made to operators. This is done so that operators are motivated to complete the transaction.
diff --git a/docs/clusters/neon_proxy_rpc_endpoints.md b/docs/clusters/neon_proxy_rpc_endpoints.md
deleted file mode 100644
index 4846ba97..00000000
--- a/docs/clusters/neon_proxy_rpc_endpoints.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Neon Proxy RPC Endpoints
----
-
-*The lookup table containing the URLs of all available proxies in the Neon EVM.*
-
-
-
-
-Semantic meaning of table columns:
- * `Network (Chain ID)` — Solana network and its identifier; the network determines what RPC URL proxy can be used.
- * `Operator name` — operator name providing the proxy.
- * `RPC URL` — address for interacting with the required proxy.
- * `Public key` — public key granting access to a network; this is either a public key of an authorized Neon EVM operator, or a developer key used to access only the Testnet or Devnet.
diff --git a/docs/clusters/solana_cluster.md b/docs/clusters/solana_cluster.md
index 81902700..843797d4 100644
--- a/docs/clusters/solana_cluster.md
+++ b/docs/clusters/solana_cluster.md
@@ -1,8 +1,13 @@
---
title: Solana Clusters
+proofedDate: na
+iterationBy: na
+includedInSite: false
+approvedBy: na
+comment: todo find out whether this page should be included in site -- no sidebar for this
---
-A Solana cluster is a set of independently owned computers working together to verify the output of user-submitted programs. A Solana cluster can be utilized any time a user wants to preserve an immutable record of events in time or programmatic interpretations of those events.
+A Solana cluster is a set of independently owned computers working together to verify the output of user-submitted programs. A Solana cluster can be utilized any time a user wants to preserve an immutable record of events in time or programmatic interpretations of those events.
It can also be argued that a Solana cluster is a set of validators that serve client transactions and maintain the integrity of the registry. Solana maintains several different clusters with different purposes.
@@ -23,8 +28,8 @@ This is a permissionless, persistent cluster for early token holders and launch
### Synchronization
Fast, reliable synchronization is one of the main challenges for achieving high throughput. Traditional blockchains synchronize on large chunks of transactions called blocks. As a consensus algorithm, they use *[Proof-of-Work](https://en.wikipedia.org/wiki/Proof_of_work)* or *[Proof-of-Stake](https://en.wikipedia.org/wiki/Proof_of_stake)*.
-Unlike traditional synchronization methods, Solana takes a complete approach, which it calls *[Proof-of-History](https://docs.neon-labs.org/docs/about/terminology/#proof-of-history-poh)*. Solana uses an optimistic method of processing blocks. (It was introduced in 1981 and is called [Optimistic Concurrency Control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control).)
-The peculiarity of this method is that Solana technically never sends a *[block](about/terminology.md#block)*, but uses the term to describe the sequence of entries that validators vote on to achieve *confirmation*. By processing the transactions optimistically, there is effectively no delay between the time the last entry is received and the time when the node can vote. In the event consensus is not achieved, a node simply rolls back its state.
+Unlike traditional synchronization methods, Solana takes a complete approach, which it calls *[Proof-of-History](https://docs.solana.com/cluster/synchronization)*. Solana uses an optimistic method of processing blocks. (It was introduced in 1981 and is called [Optimistic Concurrency Control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control).)
+The peculiarity of this method is that Solana technically never sends a *block*, but uses the term to describe the sequence of entries that validators vote on to achieve *confirmation*. By processing the transactions optimistically, there is effectively no delay between the time the last entry is received and the time when the node can vote. In the event consensus is not achieved, a node simply rolls back its state.
> **More details**
diff --git a/docs/code-samples/chainlink-btc-usd-pricefeed.sol b/docs/code-samples/chainlink-btc-usd-pricefeed.sol
new file mode 100644
index 00000000..0633e117
--- /dev/null
+++ b/docs/code-samples/chainlink-btc-usd-pricefeed.sol
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.7;
+
+import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";
+
+contract PriceConsumerV3 {
+ AggregatorV3Interface internal priceFeed;
+
+ /**
+ * Network: NeonEVM Devnet
+ * Aggregator: BTC/USD
+ * Address: 0x878738FdbCC9Aa39Ce68Fa3B0B0B93426EcB6417
+ */
+ constructor() {
+ priceFeed = AggregatorV3Interface(
+ 0x878738FdbCC9Aa39Ce68Fa3B0B0B93426EcB6417
+ );
+ }
+
+ /**
+ * Returns the latest price.
+ */
+ function getLatestPrice() public view returns (int) {
+ // prettier-ignore
+ (
+ /* uint80 roundID */,
+ int price,
+ /*uint startedAt*/,
+ /*uint timeStamp*/,
+ /*uint80 answeredInRound*/
+ ) = priceFeed.latestRoundData();
+ return price;
+ }
+}
\ No newline at end of file
diff --git a/docs/code-samples/factory.sol b/docs/code-samples/factory.sol
new file mode 100644
index 00000000..b11d627b
--- /dev/null
+++ b/docs/code-samples/factory.sol
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: MIT
+
+pragma solidity >= 0.7.0;
+pragma abicoder v2;
+
+interface SPLToken {
+
+ enum AccountState {
+ Uninitialized,
+ Initialized,
+ Frozen
+ }
+
+ struct Account {
+ bytes32 mint;
+ bytes32 owner;
+ uint64 amount;
+ bytes32 delegate;
+ uint64 delegated_amount;
+ bytes32 close_authority;
+ AccountState state;
+ }
+
+ struct Mint {
+ uint64 supply;
+ uint8 decimals;
+ bool isInitialized;
+ bytes32 freezeAuthority;
+ bytes32 mintAuthority;
+ }
+
+ function findAccount(bytes32 salt) external pure returns(bytes32);
+
+ function isSystemAccount(bytes32 account) external view returns(bool);
+
+ // Return spl_token account data. This function checks the account is owned by correct spl_token.
+ // Return default not initialized spl_token account data if corresponded Solana account doesn't exist.
+ function getAccount(bytes32 account) external view returns(Account memory);
+
+ // Return spl_token mint data. This function checks the mint is owned by correct spl_token.
+ // Return default not initialized spl_token mint data if corresponded Solana account doesn't exist.
+ function getMint(bytes32 account) external view returns(Mint memory);
+
+ function initializeMint(bytes32 salt, uint8 decimals) external returns(bytes32);
+ function initializeMint(bytes32 salt, uint8 decimals, bytes32 mint_authority, bytes32 freeze_authority) external returns(bytes32);
+
+ function initializeAccount(bytes32 salt, bytes32 mint) external returns(bytes32);
+ function initializeAccount(bytes32 salt, bytes32 mint, bytes32 owner) external returns(bytes32);
+
+ function closeAccount(bytes32 account) external;
+
+ function mintTo(bytes32 mint, bytes32 account, uint64 amount) external;
+ function burn(bytes32 mint, bytes32 account, uint64 amount) external;
+
+ function approve(bytes32 source, bytes32 target, uint64 amount) external;
+ function revoke(bytes32 source) external;
+
+ function transfer(bytes32 source, bytes32 target, uint64 amount) external;
+
+ // transfer funds from spl-token accounts owned by Solana user.
+ // This method uses PDA[ACCOUNT_SEED_VERSION, b"AUTH", msg.sender, seed] to authorize transfer
+ function transferWithSeed(bytes32 seed, bytes32 source, bytes32 target, uint64 amount) external;
+
+ function freeze(bytes32 mint, bytes32 account) external;
+ function thaw(bytes32 mint, bytes32 account) external;
+}
+
+interface Metaplex {
+ function createMetadata(bytes32 _mint, string memory _name, string memory _symbol, string memory _uri) external returns(bytes32);
+ function createMasterEdition(bytes32 mint, uint64 maxSupply) external returns(bytes32);
+
+ function isInitialized(bytes32 mint) external view returns(bool);
+ function isNFT(bytes32 mint) external view returns(bool);
+ function uri(bytes32 mint) external view returns(string memory);
+ function name(bytes32 mint) external view returns(string memory);
+ function symbol(bytes32 mint) external view returns(string memory);
+}
+
+SPLToken constant _splToken = SPLToken(0xFf00000000000000000000000000000000000004);
+Metaplex constant _metaplex = Metaplex(0xff00000000000000000000000000000000000005);
+
+contract ERC20ForSpl {
+
+ bytes32 immutable public tokenMint;
+
+ mapping(address => mapping(address => uint256)) private _allowances;
+
+ event Transfer(address indexed from, address indexed to, uint256 amount);
+ event Approval(address indexed owner, address indexed spender, uint256 amount);
+
+ event ApprovalSolana(address indexed owner, bytes32 indexed spender, uint64 amount);
+ event TransferSolana(address indexed from, bytes32 indexed to, uint64 amount);
+
+ constructor(bytes32 _tokenMint) {
+ require(_splToken.getMint(_tokenMint).isInitialized, "ERC20: invalid token mint");
+ require(_metaplex.isInitialized(_tokenMint), "ERC20: missing MetaPlex metadata");
+
+ tokenMint = _tokenMint;
+ }
+
+ function name() public view returns (string memory) {
+ return _metaplex.name(tokenMint);
+ }
+
+ function symbol() public view returns (string memory) {
+ return _metaplex.symbol(tokenMint);
+ }
+
+ function decimals() public view returns (uint8) {
+ return _splToken.getMint(tokenMint).decimals;
+ }
+
+ function totalSupply() public view returns (uint256) {
+ return _splToken.getMint(tokenMint).supply;
+ }
+
+ function balanceOf(address who) public view returns (uint256) {
+ bytes32 account = _solanaAccount(who);
+ return _splToken.getAccount(account).amount;
+ }
+
+ function allowance(address owner, address spender) public view returns (uint256) {
+ return _allowances[owner][spender];
+ }
+
+ function approve(address spender, uint256 amount) public returns (bool) {
+ address owner = msg.sender;
+
+ _approve(owner, spender, amount);
+
+ return true;
+ }
+
+ function transfer(address to, uint256 amount) public returns (bool) {
+ address from = msg.sender;
+
+ _transfer(from, to, amount);
+
+ return true;
+ }
+
+
+ function transferFrom(address from, address to, uint256 amount) public returns (bool) {
+ address spender = msg.sender;
+
+ _spendAllowance(from, spender, amount);
+ _transfer(from, to, amount);
+
+ return true;
+ }
+
+ function burn(uint256 amount) public returns (bool) {
+ address from = msg.sender;
+
+ _burn(from, amount);
+
+ return true;
+ }
+
+
+ function burnFrom(address from, uint256 amount) public returns (bool) {
+ address spender = msg.sender;
+
+ _spendAllowance(from, spender, amount);
+ _burn(from, amount);
+
+ return true;
+ }
+
+
+ function approveSolana(bytes32 spender, uint64 amount) public returns (bool) {
+ address from = msg.sender;
+ bytes32 fromSolana = _solanaAccount(from);
+
+ if (amount > 0) {
+ _splToken.approve(fromSolana, spender, amount);
+ } else {
+ _splToken.revoke(fromSolana);
+ }
+
+ emit Approval(from, address(0), amount);
+ emit ApprovalSolana(from, spender, amount);
+
+ return true;
+ }
+
+ function transferSolana(bytes32 to, uint64 amount) public returns (bool) {
+ address from = msg.sender;
+ bytes32 fromSolana = _solanaAccount(from);
+
+ _splToken.transfer(fromSolana, to, uint64(amount));
+
+ emit Transfer(from, address(0), amount);
+ emit TransferSolana(from, to, amount);
+
+ return true;
+ }
+
+ function claim(bytes32 from, uint64 amount) external returns (bool) {
+ return claimTo(from, msg.sender, amount);
+ }
+
+ function claimTo(bytes32 from, address to, uint64 amount) public returns (bool) {
+ bytes32 toSolana = _solanaAccount(to);
+
+ if (_splToken.isSystemAccount(toSolana)) {
+ _splToken.initializeAccount(_salt(to), tokenMint);
+ }
+
+ _splToken.transferWithSeed(_salt(msg.sender), from, toSolana, amount);
+
+ emit Transfer(address(0), to, amount);
+
+ return true;
+ }
+
+ function _approve(address owner, address spender, uint256 amount) internal {
+ require(owner != address(0), "ERC20: approve from the zero address");
+ require(spender != address(0), "ERC20: approve to the zero address");
+
+ _allowances[owner][spender] = amount;
+ emit Approval(owner, spender, amount);
+ }
+
+ function _spendAllowance(address owner, address spender, uint256 amount) internal {
+ uint256 currentAllowance = allowance(owner, spender);
+ if (currentAllowance != type(uint256).max) {
+ require(currentAllowance >= amount, "ERC20: insufficient allowance");
+ _approve(owner, spender, currentAllowance - amount);
+ }
+ }
+
+ function _burn(address from, uint256 amount) internal {
+ require(from != address(0), "ERC20: burn from the zero address");
+ require(amount <= type(uint64).max, "ERC20: burn amount exceeds uint64 max");
+
+ bytes32 fromSolana = _solanaAccount(from);
+
+ require(_splToken.getAccount(fromSolana).amount >= amount, "ERC20: burn amount exceeds balance");
+ _splToken.burn(tokenMint, fromSolana, uint64(amount));
+
+ emit Transfer(from, address(0), amount);
+ }
+
+ function _transfer(address from, address to, uint256 amount) internal {
+ require(from != address(0), "ERC20: transfer from the zero address");
+ require(to != address(0), "ERC20: transfer to the zero address");
+
+ bytes32 fromSolana = _solanaAccount(from);
+ bytes32 toSolana = _solanaAccount(to);
+
+ require(amount <= type(uint64).max, "ERC20: transfer amount exceeds uint64 max");
+ require(_splToken.getAccount(fromSolana).amount >= amount, "ERC20: transfer amount exceeds balance");
+
+ if (_splToken.isSystemAccount(toSolana)) {
+ _splToken.initializeAccount(_salt(to), tokenMint);
+ }
+
+ _splToken.transfer(fromSolana, toSolana, uint64(amount));
+
+ emit Transfer(from, to, amount);
+ }
+
+ function _salt(address account) internal pure returns (bytes32) {
+ return bytes32(uint256(uint160(account)));
+ }
+
+ function _solanaAccount(address account) internal pure returns (bytes32) {
+ return _splToken.findAccount(_salt(account));
+ }
+}
+
+contract ERC20ForSplMintable is ERC20ForSpl {
+ address immutable _admin;
+
+ constructor(
+ string memory _name,
+ string memory _symbol,
+ uint8 _decimals,
+ address _mint_authority
+ ) ERC20ForSpl(_initialize(_name, _symbol, _decimals)) {
+ _admin = _mint_authority;
+ }
+
+ function findMintAccount() public pure returns (bytes32) {
+ return _splToken.findAccount(bytes32(0));
+ }
+
+ function mint(address to, uint256 amount) public {
+ require(msg.sender == _admin, "ERC20: must have minter role to mint");
+ require(to != address(0), "ERC20: mint to the zero address");
+ require(amount <= type(uint64).max, "ERC20: mint amount exceeds uint64 max");
+ require(totalSupply() + amount <= type(uint64).max, "ERC20: total mint amount exceeds uint64 max");
+
+ bytes32 toSolana = _solanaAccount(to);
+ if (_splToken.isSystemAccount(toSolana)) {
+ _splToken.initializeAccount(_salt(to), tokenMint);
+ }
+
+ _splToken.mintTo(tokenMint, toSolana, uint64(amount));
+
+ emit Transfer(address(0), to, amount);
+ }
+
+ function _initialize(
+ string memory _name,
+ string memory _symbol,
+ uint8 _decimals
+ ) private returns (bytes32) {
+ bytes32 mintAddress = _splToken.initializeMint(bytes32(0), _decimals);
+ _metaplex.createMetadata(mintAddress, _name, _symbol, "");
+ return mintAddress;
+ }
+}
+
+contract ERC20ForSplFactory {
+
+ mapping(bytes32 => address) public getErc20ForSpl;
+ address[] public allErc20ForSpl;
+
+ event ERC20ForSplCreated(bytes32 _mint, address pair, uint);
+
+ function allErc20ForSplLength() external view returns (uint) {
+ return allErc20ForSpl.length;
+ }
+
+ function createErc20ForSpl(bytes32 _mint) public returns (address erc20spl) {
+
+ require(getErc20ForSpl[_mint] == address(0), 'ERC20 SPL Factory: ERC20_SPL_EXISTS');
+
+ bytes memory bytecode = type(ERC20ForSpl).creationCode;
+ bytecode = abi.encodePacked(bytecode, abi.encode(_mint));
+ bytes32 salt = keccak256(abi.encodePacked(_mint));
+ assembly {
+ erc20spl := create2(0, add(bytecode, 32), mload(bytecode), salt)
+ }
+ require(erc20spl != address(0), 'ERC20 SPL Factory: SPL TOKEN IS NOT CREATED');
+
+ getErc20ForSpl[_mint] = erc20spl;
+ allErc20ForSpl.push(erc20spl);
+
+ emit ERC20ForSplCreated(_mint, erc20spl, allErc20ForSpl.length);
+ }
+
+ function createErc20ForSplMintable(string memory _name, string memory _symbol, uint8 _decimals, address _mint_authority) public returns (address erc20spl) {
+
+ bytes memory bytecode = type(ERC20ForSplMintable).creationCode;
+ bytecode = abi.encodePacked(bytecode, abi.encode(_name, _symbol, _decimals, _mint_authority));
+ bytes32 salt = keccak256(abi.encodePacked(bytes32(0)));
+ assembly {
+ erc20spl := create2(0, add(bytecode, 32), mload(bytecode), salt)
+ }
+ require(erc20spl != address(0), 'ERC20 SPL Factory: SPL TOKEN MINTABLE IS NOT CREATED');
+
+ bytes32 _mint = ERC20ForSplMintable(erc20spl).findMintAccount();
+ getErc20ForSpl[_mint] = erc20spl;
+ allErc20ForSpl.push(erc20spl);
+
+ emit ERC20ForSplCreated(_mint, erc20spl, allErc20ForSpl.length);
+ }
+}
\ No newline at end of file
diff --git a/docs/composability/call_solana_interface.md b/docs/composability/call_solana_interface.md
new file mode 100644
index 00000000..1b619625
--- /dev/null
+++ b/docs/composability/call_solana_interface.md
@@ -0,0 +1,70 @@
+---
+title: 'ICallSolana Interface'
+proofedDate: 20240627
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+## Introduction
+
+To use the **Composability** feature of Solana, let us learn about the interface and the functions included in the interface that will be used to interact with the Solana programs via the precompile `0xFF00000000000000000000000000000000000006`.
+
+The interface contract `ICallSolana.sol` can be found in this [Github Repository](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/contracts/TestCallSolana/interfaces/ICallSolana.sol).
+
+## Struct Variables
+
+1. `AccountMeta` : For each account needed by an instruction, the following details must be provided -
+ - **account:** The account's on-chain address in bytes32.
+ - **is_writable:** Indicates if the account's data will be modified in boolean.
+ - **is_signer:** Indicates if the account needs to sign the transaction in boolean.
+2. `Instruction` : Instruction struct variable includes the following -
+ - **program_id:** The address of the program that contains the execution logic for the invoked instruction.
+ - **accounts:** Contains the AccountMeta for each account required by an instruction.
+ - **instruction_data:** The instruction data as a buffer of bytes.
+
+## Functions
+
+| getNeonAddress(address) -> bytes32 |
+| :--------------------------------------------------------------------------------- |
+| This function returns the Solana address in bytes32 format for a Neon EVM address. |
+
+| getResourceAddress(bytes32 salt) -> bytes32 |
+| :-------------------------------------------------------------------------------------------------------------- |
+| This function returns the Solana address in bytes32 format of a resource represented by the salt for contracts. |
+
+| createResource(bytes32 salt, uint64 space, uint64 lamports, bytes32 owner) -> bytes32 |
+| :--------------------------------------------------------------------------------------------------------------------------------- |
+| This function creates a resource with the specified salt and returns the Solana address of the created resource in bytes32 format. |
+
+| getSolanaPDA(bytes32 program_id, bytes memory seeds) -> bytes32 |
+| :------------------------------------------------------------------------------------------------------------ |
+| This function returns the Solana PDA in bytes32 format generated from the specified `program_id` and `seeds`. |
+
+| getExtAuthority(bytes32 salt) -> bytes32 |
+| :------------------------------------------------------------------------------------------------------------ |
+| This function returns the Solana address in bytes32 format of the external authority represented by the salt. |
+
+| getPayer() -> bytes32 |
+| :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| This function returns the Solana address of the payer account in bytes32 format. Payer account is required if an instruction needs an account to fund newly created accounts. |
+
+| execute(uint64 lamports, Instruction memory instruction) -> bytes |
+| :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| This function executes the instruction with a call to the Solana program and returns the data of the executed instruction in bytes format. The `lamports` parameter specifies the amount of lamports that will be required to create new accounts during execution. These lamports are transferred to the `payer` account. The `instruction` parameter is the struct variable with the values of program_id, accounts and instruction_data. |
+
+| executeWithSeed(uint64 lamports, bytes32 salt, Instruction memory instruction) -> bytes |
+| :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| This function executes the instruction with a call to the Solana program and returns the data of the executed instruction in bytes format. The `lamports` parameter specifies the amount of lamports that will be required to create new accounts during execution. These lamports are transferred to the `payer` account. The `salt` parameter is to generate an address of external authority. The `instruction` parameter is the struct variable with the values of program_id, accounts and instruction_data. |
+
+| execute(uint64 lamports, bytes memory instruction) -> bytes |
+| :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| This function executes the instruction with a call to the Solana program and returns the data of the executed instruction in bytes format. The `lamports` parameter specifies the amount of lamports that will be required to create new accounts during execution. These lamports are transferred to the `payer` account. The `instruction` is the bincode serialized instruction which needs to be executed. This method uses PDA of the sender to authorize the operation. |
+
+| executeWithSeed(uint64 lamports, bytes32 salt, bytes memory instruction) -> bytes |
+| :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| This function executes the instruction with a call to the Solana program and returns the data of the executed instruction in bytes format. The `lamports` parameter specifies the amount of lamports that will be required to create new accounts during execution. These lamports are transferred to the `payer` account. The `salt` parameter is to generate an address of external authority. The `instruction` is the bincode serialized instruction which needs to be executed. This method uses external authority to authorize the operation. |
+
+| getReturnData() -> bytes32, bytes |
+| :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| This function returns the `program_id` and returned data of the last executed instruction. Note: This method should be called after `execute` / `executeWithSeed` methods. |
diff --git a/docs/composability/common_solana_terminology.md b/docs/composability/common_solana_terminology.md
new file mode 100644
index 00000000..be7e8ebc
--- /dev/null
+++ b/docs/composability/common_solana_terminology.md
@@ -0,0 +1,90 @@
+---
+title: 'Common Solana Terminology'
+proofedDate: 20240627
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+## Introduction
+
+To learn about Solana's Composability feature, we first need to understand Solana’s core concepts and features that differentiates it from other blockchains.
+
+## What is Solana?
+
+Solana is a blockchain designed for widespread adoption, offering a high-performance network suited for various applications such as finance, NFTs, payments, and gaming. It functions as a single global state machine, ensuring openness, interoperability, and decentralization.
+
+Solana's parallel processing architecture marks a major breakthrough in blockchain technology, delivering exceptional scalability, throughput, and low-latency transaction confirmations. By utilizing parallelism across various levels of its framework, Solana attains high performance while maintaining decentralization and security.
+
+## Core concepts of Solana
+
+### Accounts
+
+Since Solana programs are stateless, hence the data on Solana is stored in what are known as "accounts". Each account is uniquely identified by a 32-byte address formatted as an Ed25519 PublicKey. This address acts as the account's unique identifier. Some of the key characteristic of accounts are -
+
+1. Accounts can store up to 10MB of data, which may include executable program code or program state.
+2. Accounts require a rent deposit in SOL, proportional to the amount of data stored. This deposit is fully refundable when the account is closed.
+3. Each account has a program "owner". Only the owning program can modify the account's data or reduce its lamport balance, but anyone can increase the balance.
+
+Every account in Solana has the structure called `AccountInfo` which includes the following fields -
+
+- `data`: A byte array that holds the state of an account. If the account is a program (smart contract), it contains the executable program code. This field is commonly known as "account data".
+- `executable`: A boolean flag indicating whether the account is a program.
+- `lamports`: A numerical representation of the account's balance in lamports, the smallest unit of SOL (1 SOL = 1 billion lamports).
+- `owner`: Indicates the public key (program ID) of the program that owns the account.
+
+Solana account types can be divided into two broad categories - Executable and non-executable programs.
+
+1. **Executable Programs**: Executable programs consist of immutable code that can own and create other accounts to store state. This code is written in a language such as Rust and then compiled into eBPF, a form of bytecode.
+
+ The following are the two types of executable accounts -
+
+ - `Native Programs`: Executable native programs are integral to the Solana ecosystem, handling tasks such as maintaining and operating validator nodes. The most notable example is the **System Program**, responsible for creating new system accounts (commonly referred to as "wallets") and transferring SOL. Other examples of native programs include the **Stake Program**, which manages the staking mechanism, and the BPF Loader, which functions similarly to Ethereum’s EVM.
+ - `SPL Programs`: SPL Programs facilitate numerous on-chain activities, including token creation, swapping, and lending, as well as the establishment of stake pools and the management of an on-chain name service. While the **SPL Token Program** can be accessed directly through the CLI, others, such as the **Associated Token Account Program**, are often utilized in conjunction with custom programs.
+ - `Custom Programs`: Custom programs on Solana are developer-created smart contracts tailored to specific use cases and functionalities beyond what is provided by native and SPL (Solana Program Library) programs. These programs allow developers to create a wide range of decentralized applications (dApps) like Orca DEX, and services that leverage the high performance and scalability of the Solana blockchain. A perfect example of this type of programs is the **Neon EVM Program**, which comprises of the EVM converted to BPF bytecode.
+
+2. **Non-executable Accounts**: Non-executable accounts are "storage" or "data" accounts that hold various types of data, such as program variables, token balances, NFTs, and fungible currencies. These accounts reflect state changes that occur after each transaction within the protocol.
+
+ This type of accounts can be further divided into -
+
+ - `System Accounts` : System accounts are essential for the network's functionality and manage the basic aspects of account creation and transaction processing. They are managed by the Solana runtime and are necessary for performing fundamental actions like creating, funding, and managing accounts.
+ - `Token Accounts` : Token accounts are owned by the Token Program and tracks the number of units of a specific type of token (mint account) owned by a particular address. Token accounts are specialized accounts used to manage and interact with tokens that adhere to the Solana Token Program (often referred to as SPL Token Program). These accounts facilitate the creation, transfer, and management of SPL tokens.
+
+ - An `Associated Token Account` is a token account with an address deterministically derived from the owner's address and the mint account's address. These accounts store the SPL token balances for each individual user.
+
+ - `Program Derived Address (PDA)` : A Program Derived Address (PDA) is a special type of account address that is derived from a program ID and some seed data. PDAs are used to create deterministic and secure addresses for program-owned accounts. These addresses are not directly controlled by any private key, but are instead controlled by the program itself, which can authorize transactions on behalf of the PDA.
+ - `Data Accounts` : Data accounts are specialized accounts that store data associated with Solana programs (smart contracts). These accounts are crucial for maintaining the state and data of decentralized applications running on the Solana blockchain.
+
+Please refer to the accounts types in details on [Solana Account Model](https://solana.com/docs/core/accounts).
+
+### Transactions and Instructions:
+
+1. `Transactions`**:** On Solana, transactions are sent to interact with the network. Each transaction consists of one or more instructions, each representing a specific operation to be executed. The execution logic for these instructions resides in programs deployed on the Solana network, with each program containing its own set of instructions.
+
+ Couple of key points about transaction execution -
+
+ - **Execution Order:** multiple instructions in a transaction are processed in the order they appear in the transaction.
+ - **Atomicity:** A transaction either fully completes with all instructions successfully processed, or it fails entirely. If any instruction within the transaction fails, none of the instructions are executed.
+
+2. `Instructions`: An instruction is a request to perform a specific action on-chain and represents the smallest unit of execution logic within a program.
+
+ An instruction must include the following information -
+
+ - **Program Address:** It specifies the program being called.
+ - **Accounts:** Lists all accounts that the instruction will read from or write to, including other programs, using the AccountMeta struct.
+ - **Instruction Data:** A byte array that indicates which instruction handler on the program to invoke, along with any additional data required by the instruction handler (function arguments).
+
+Please refer to transactions and instructions details on [Transactions and Instructions](https://solana.com/docs/core/transactions).
+
+### Cross Program Invocation (CPI):
+
+A Cross Program Invocation (CPI) occurs when one program calls the instructions of another program. This mechanism enables the **_Composability_** of Solana programs.
+
+Some important points to note about CPI -
+
+1. CPIs allow Solana program instructions to directly call instructions on another program.
+2. Signer privileges from the calling program are extended to the called program.
+3. When performing a CPI, programs can "sign" on behalf of PDAs derived from their own program ID.
+4. The called program can make additional CPIs to other programs, with a maximum depth of 4.
+
+Please refer to the details about CPI on [Cross Program Invocation](https://solana.com/docs/core/cpi).
diff --git a/docs/composability/using_composability/setup_configure.md b/docs/composability/using_composability/setup_configure.md
new file mode 100644
index 00000000..f68d03eb
--- /dev/null
+++ b/docs/composability/using_composability/setup_configure.md
@@ -0,0 +1,82 @@
+---
+title: 'Setup and Configure'
+proofedDate: 20240627
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+import mm_p_key from '@site/static/img/doc-images/developing/deploy_facilities/foundry-metamask.png';
+
+## Introduction
+
+The tutorials on the next pages are based on the [Github example](https://github.com/neonlabsorg/neon-tutorials/tree/main/hardhat) and will walk you through them to test different Composability features on Neon EVM Devnet and Solana Devnet.
+
+- [TestCallSolana.sol](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/contracts/TestCallSolana/TestCallSolana.sol) - This is a solidity smart contract which interacts with the precompile `0xFF00000000000000000000000000000000000006` via the `ICallSolana.sol` interface contract described in details [here](docs/composability/call_solana_interface.md).
+- [config.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/config.js) - This is a script which includes the contract address of the deployed `TestCallSolana.sol` and the helper functions required to execute the instructions on Solana via the deployed smart contract.
+
+### Step 1: Installation
+
+> **Note:** 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 tutorials. These packages include the `Hardhat` library and most importantly `@solana/web3.js` .
+
+If the above command results in an error, run:
+
+```sh
+npm cache clear --force
+npm install
+```
+
+**About `@solana/web3.js` library:**
+
+In our tutorials, we use the @solana/web3.js library because it's an invaluable tool for preparing and passing Solana instructions to on-chain requests. This library supports a comprehensive set of instructions essential for the development cycle. We strongly recommend using it as it formats the instructions in the exact way that the Composability precompile expects.
+
+### 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 will 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:
+
+```sh
+PRIVATE_KEY_OWNER=`YOUR_PRIVATE_KEY`
+USER1_KEY=`2ND_PRIVATE_KEY`
+```
+
+:::important
+Replace `OWNER_PRIVATE_KEY` and `2ND_PRIVATE_KEY` with the private keys of your wallet.
+:::
+
+### 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
+```
diff --git a/docs/composability/using_composability/swap_on_orca.md b/docs/composability/using_composability/swap_on_orca.md
new file mode 100644
index 00000000..16c07151
--- /dev/null
+++ b/docs/composability/using_composability/swap_on_orca.md
@@ -0,0 +1,310 @@
+---
+title: 'Swap on Orca DEX'
+proofedDate: 20240627
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+## Introduction
+
+This tutorial will walk you through the steps of performing a swap on The Orca DEX where the input swap token is **devUSDC** and the output swap token is **devSAMO.**
+
+:::info
+You can request devUSDCs and devSAMO from https://everlastingsong.github.io/nebula/
+:::
+
+This example code is based on the script [OrcaSwap.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/OrcaSwap.js). This script is designed to perform a token swap on the [Orca decentralized exchange (DEX)](https://www.orca.so/) on the Solana blockchain. It uses the Anchor SDK to interact with the blockchain and requires specific environment variables to be set for execution.
+
+## How the script works
+
+Let us breakdown the main components of the script `OrcaSwap.js` to get into more depth of the process of swapping tokens on Orca DEX.
+
+### Initial Checks and Imports
+
+```jsx
+if (process.env.ANCHOR_PROVIDER_URL == undefined || process.env.ANCHOR_WALLET == undefined) {
+ return console.log(
+ "This script uses the @coral-xyz/anchor library which requires the variables ANCHOR_PROVIDER_URL and ANCHOR_WALLET to be set. Please create id.json in the root of the hardhat project with your Solana's private key and run the following command in the terminal in order to proceed with the script execution - export ANCHOR_PROVIDER_URL=https://api.devnet.solana.com && export ANCHOR_WALLET=./id.json"
+ );
+}
+
+const { ethers } = require('hardhat');
+const web3 = require('@solana/web3.js');
+const { getAssociatedTokenAddress, getAccount } = require('@solana/spl-token');
+const { config } = require('./config');
+const { AnchorProvider } = require('@coral-xyz/anchor');
+const {
+ WhirlpoolContext,
+ buildWhirlpoolClient,
+ ORCA_WHIRLPOOL_PROGRAM_ID,
+ PDAUtil,
+ swapQuoteByInputToken,
+ IGNORE_CACHE,
+ getAllWhirlpoolAccountsForConfig,
+ WhirlpoolIx,
+ SwapUtils
+} = require('@orca-so/whirlpools-sdk');
+const { DecimalUtil, Percentage } = require('@orca-so/common-sdk');
+const { Decimal } = require('decimal.js');
+```
+
+This code block checks if the required environment variables `ANCHOR_PROVIDER_URL` and `ANCHOR_WALLET` are set. It then imports necessary libraries and modules. `ANCHOR_PROVIDER_URL` is Solana's RPC URL and `ANCHOR_WALLET` is Solana's private key in json byte array format.
+
+- Store your Solana’s private key in the file `id.json` and place it in the root of your hardhat project folder. This key will be used only for the Anchor SDK initialization, and not for signing or submitting any transactions.
+- Run this in your terminal -
+ ```bash
+ export ANCHOR_PROVIDER_URL=https://api.devnet.solana.com
+ export ANCHOR_WALLET=./id.json
+ ```
+
+### Setup and Initialization
+
+```jsx
+async function main() {
+ const [user1] = await ethers.getSigners();
+ const connection = new web3.Connection(config.SOLANA_NODE, "processed");
+ const provider = AnchorProvider.env();
+ const ctx = WhirlpoolContext.withProvider(provider, ORCA_WHIRLPOOL_PROGRAM_ID);
+ const client = buildWhirlpoolClient(ctx);
+ const DEVNET_WHIRLPOOLS_CONFIG = new web3.PublicKey("FcrweFY1G9HJAHG5inkGB6pKg1HZ6x9UC2WioAfWrGkR");
+
+ const TestCallSolanaFactory = await ethers.getContractFactory("TestCallSolana");
+ let TestCallSolanaAddress = config.CALL_SOLANA_SAMPLE_CONTRACT;
+ let TestCallSolana;
+ let solanaTx;
+ let tx;
+ let receipt;
+
+ if (ethers.isAddress(TestCallSolanaAddress)) {
+ TestCallSolana = TestCallSolanaFactory.attach(TestCallSolanaAddress);
+ } else {
+ TestCallSolana = await ethers.deployContract("TestCallSolana");
+ await TestCallSolana.waitForDeployment();
+
+ TestCallSolanaAddress = TestCallSolana.target;
+ console.log(`TestCallSolana deployed to ${TestCallSolana.target}`);
+ }
+```
+
+This block of code sets up the connection to the Solana blockchain and initializes the Anchor provider. It also creates or attaches to the already deployed `TestCallSolana` smart contract. It also defines the public key of the Orca pool contract account on Solana `DEVNET_WHIRLPOOLS_CONFIG` .
+
+### Retrieving Contract Public Key and Token Mints
+
+```jsx
+const contractPublicKeyInBytes = await TestCallSolana.getNeonAddress(TestCallSolanaAddress);
+const contractPublicKey = ethers.encodeBase58(contractPublicKeyInBytes);
+console.log(contractPublicKey, 'contractPublicKey');
+
+const TokenA = {
+ mint: new web3.PublicKey('Jd4M8bfJG3sAkd82RsGWyEXoaBXQP7njFzBwEaCTuDa'),
+ decimals: 9
+}; // devSAMO
+const TokenB = {
+ mint: new web3.PublicKey('BRjpCHtyQLNCo8gqRUr8jtdAj5AjPYQaoqbvcZiHok1k'),
+ decimals: 6
+}; // devUSDC
+```
+
+This code block retrieves the public key for the `TestCallSolana` contract and sets up the token mint addresses for devSAMO and devUSDC.
+
+### Whirlpool Configuration
+
+```jsx
+const whirlpool_pubkey = PDAUtil.getWhirlpool(
+ ORCA_WHIRLPOOL_PROGRAM_ID,
+ DEVNET_WHIRLPOOLS_CONFIG,
+ TokenA.mint, // devSAMO
+ TokenB.mint, // devUSDC
+ 64 // tick spacing
+).publicKey;
+const whirlpool = await client.getPool(whirlpool_pubkey);
+```
+
+This section configures the Whirlpool for the specified tokens and retrieves the Whirlpool client.
+
+### Checking and Initializing Token Accounts
+
+```jsx
+const amountIn = new Decimal('0.1'); // 0.1 devUSDC
+
+const ataContractTokenA = await getAssociatedTokenAddress(
+ TokenA.mint,
+ new web3.PublicKey(contractPublicKey),
+ true
+);
+let ataContractTokenAInfo = await connection.getAccountInfo(ataContractTokenA);
+
+const ataContractTokenB = await getAssociatedTokenAddress(
+ TokenB.mint,
+ new web3.PublicKey(contractPublicKey),
+ true
+);
+
+let ataContractTokenBInfo = await connection.getAccountInfo(ataContractTokenB);
+if (!ataContractTokenAInfo || !ataContractTokenBInfo) {
+ if (!ataContractTokenAInfo) {
+ console.log(
+ 'Account ' + contractPublicKey + ' does not have initialized ATA account for TokenA.'
+ );
+ }
+ if (!ataContractTokenBInfo) {
+ console.log(
+ 'Account ' + contractPublicKey + ' does not have initialized ATA account for TokenB.'
+ );
+ }
+ return;
+} else if (
+ Number((await getAccount(connection, ataContractTokenB)).amount) <
+ Number(DecimalUtil.toBN(amountIn, TokenB.decimals))
+) {
+ console.log(
+ 'Account ' +
+ contractPublicKey +
+ ' does not have enough TokenB amount to proceed with the swap execution.'
+ );
+ return;
+}
+```
+
+This section computes the contract’s Associated Token Addresses (ATAs) for devSAMO and devUSDC and checks if they are initialized. It also ensures the contract's account has enough devUSDC balance for the swap.
+
+If the contract’s ATA’s are not initialized for both the tokens devSAMO and devUSDC, then follow the steps below -
+
+- Open `CreateATA.js` file and add devSAMO account address `Jd4M8bfJG3sAkd82RsGWyEXoaBXQP7njFzBwEaCTuDa` to this variable -
+ ```jsx
+ const tokenMintPublicKey = '';
+ ```
+ Run `npx hardhat run scripts/TestCallSolana/CreateATA.js --network neondevnet` and this will create an ATA for the contract for devSAMO.
+- Repeat the previous step for devUSDC account address `BRjpCHtyQLNCo8gqRUr8jtdAj5AjPYQaoqbvcZiHok1k` to create an ATA for the contract for devUSDC.
+
+### Swap Estimation and Execution
+
+```jsx
+ const quote = await swapQuoteByInputToken(
+ whirlpool,
+ TokenB.mint, // devUSDC
+ DecimalUtil.toBN(amountIn, TokenB.decimals), // Input Token Mint amount
+ Percentage.fromFraction(10, 1000), // Acceptable slippage (10/1000 = 1%)
+ ctx.program.programId,
+ ctx.fetcher,
+ IGNORE_CACHE
+ );
+ console.log(quote, 'quote');
+
+ console.log("estimatedAmountIn:", DecimalUtil.fromBN(quote.estimatedAmountIn, TokenB.decimals).toString(), "TokenB");
+ console.log("estimatedAmountOut:", DecimalUtil.fromBN(quote.estimatedAmountOut, TokenA.decimals).toString(), "TokenA");
+ console.log("otherAmountThreshold:", DecimalUtil.fromBN(quote.otherAmountThreshold, TokenA.decimals).toString(), "TokenA");
+
+ console.log('Executing executeComposabilityMethod with Orca\'s swap instruction ...');
+ solanaTx = new web3.Transaction();
+ solanaTx.add(
+ WhirlpoolIx.swapIx(
+ ctx.program,
+ SwapUtils.getSwapParamsFromQuote(
+ quote,
+ ctx,
+ whirlpool,
+ ataContractTokenB,
+ ataContractTokenA,
+ new web3.PublicKey(contractPublicKey)
+ )
+ )
+ );
+
+ [tx, receipt] = await config.utils.executeComposabilityMethod(
+ solanaTx.instructions[0],
+ 0,
+ TestCallSolana,
+ undefined,
+ user1
+ );
+ console.log(tx, 'tx');
+ console.log(receipt.logs[0].args, 'receipt args');
+}
+```
+
+This code block obtains a swap quote for the input amount, logs the estimation details, prepares the swap instruction, and executes the transaction.
+
+## How to run the script
+
+To test the example script `OrcaSwap.js` , run this command in the terminal -
+
+```bash
+npx hardhat run scripts/TestCallSolana/OrcaSwap.js --network neondevnet
+```
+
+After running the above command successfully, you should get the output similar to this -
+
+```bash
+54Mfrfbv16neQhrP7o29FnsAfEtmLitTDG7fuP71YKYL contractPublicKey
+{
+ estimatedAmountIn: ,
+ estimatedAmountOut: ,
+ estimatedEndTickIndex: -115126,
+ estimatedEndSqrtPrice: ,
+ estimatedFeeAmount: ,
+ amount: ,
+ amountSpecifiedIsInput: true,
+ aToB: false,
+ otherAmountThreshold: ,
+ sqrtPriceLimit: ,
+ tickArray0: PublicKey [PublicKey(9H4aVdyXbnnmbSJLjYahvZzrgdHyWVMq8i1v1fD7jqBt)] {
+ _bn:
+ },
+ tickArray1: PublicKey [PublicKey(9H4aVdyXbnnmbSJLjYahvZzrgdHyWVMq8i1v1fD7jqBt)] {
+ _bn:
+ },
+ tickArray2: PublicKey [PublicKey(9H4aVdyXbnnmbSJLjYahvZzrgdHyWVMq8i1v1fD7jqBt)] {
+ _bn:
+ }
+} quote
+estimatedAmountIn: 0.1 TokenB
+estimatedAmountOut: 9.970350988 TokenA
+otherAmountThreshold: 9.871634641 TokenA
+Executing executeComposabilityMethod with Orca's swap instruction ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0x8c546929ba84ac22b38c310c2f670696a02c5594d9d006698e7c1c20d07e41b0',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23142,
+ gasLimit: 165000n,
+ gasPrice: 256947462431n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x121f31510e03685f8e909053e458121c66f5a76aedc7706aa11c82f8aa952a8f2b7879a900000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000004e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b900000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000cb644ca2669849d7472e9b7f94dcbe8368a8a265c3d2af8a922c7bb242d5dc2f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017e232db5b493652f09b55c17fb53aab8443178034742f1526722752d6a9ecfd400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001e88322e785613ef2c35786bf91d8006a035fb7312bc3a6684bffbda93b1ad6f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000179698dd5a7e6625086e3be1203de392b1a65a23a5d1099ec5a28318e2a4e88b800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001313e1c144a550aeaa99a29830910036800efbb8af592a87d705fe7938698f1c5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017afad55b43064520bec49256da6fc91853aa00fe5a354d830b032b08f3817427000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017afad55b43064520bec49256da6fc91853aa00fe5a354d830b032b08f3817427000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017afad55b43064520bec49256da6fc91853aa00fe5a354d830b032b08f38174270000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000127116a2b94f55339f566164cb265fd3ab70d4b91e594e8c555a3be76d69e9ecb00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002af8c69e91e17587c8a086010000000000d130654c02000000af331ba8327fbb35b1c4feff00000000010000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0xfb762b500e4a7551102f7cebfe17d207317496853240ded7283f2851c07d41f2", s: "0x6adcaeb774f416206b4b2f6970b32a7d0573d3cc74a5465865040ef86f48ffe6", yParity: 1, networkV: 490045888 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+```
+
+:::important
+The full code of the script can be viewed here [OrcaSwap.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/OrcaSwap.js).
+:::
diff --git a/docs/composability/using_composability/swap_on_raydium.md b/docs/composability/using_composability/swap_on_raydium.md
new file mode 100644
index 00000000..6a0ab9a2
--- /dev/null
+++ b/docs/composability/using_composability/swap_on_raydium.md
@@ -0,0 +1,219 @@
+---
+title: 'Swap on Raydium DEX'
+proofedDate: 20240801
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+## Introduction
+
+This tutorial will walk you through the steps of performing a swap on The Raydium DEX where the input swap token is **wSOL** and the output swap token is **USDC**.
+
+This example code is based on the script [RaydiumSwap.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/RaydiumSwap.js). This script is designed to perform a token swap on the [Raydium decentralized exchange (DEX)](https://raydium.io/) on the Solana blockchain. It uses the Raydium SDK to interact with the blockchain.
+
+:::important
+**Raydium** doesn't support Solana's Devnet environment to test, so we will be using Solana's Mainnet environment for the following tutorial.
+:::
+
+## How the script works
+
+Let us breakdown the main components of the script `RaydiumSwap.js` to get into more depth of the process of swapping tokens on Raydium DEX.
+
+### Initial Checks and Imports
+
+```jsx
+const { ethers } = require('hardhat');
+const web3 = require('@solana/web3.js');
+const { getAssociatedTokenAddress, getAccount } = require('@solana/spl-token');
+const { Liquidity } = require('@raydium-io/raydium-sdk');
+const { config } = require('./config');
+```
+
+This code block imports necessary libraries like `ethers` for interacting with Ethereum-based contracts, `@solana/web3.js` for Solana interactions, and `@raydium-io/raydium-sdk` for Raydium DEX functionality.
+
+### Swap configuration
+
+```jsx
+const swapConfig = {
+ tokenAAmount: 0.0001, // Amount of WSOL to swap
+ TokenA: 'So11111111111111111111111111111111111111112', // WSOL address
+ TokenB: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', // USDC address
+ direction: 'in', // Direction of swap
+ liquidityFile: 'https://api.raydium.io/v2/sdk/liquidity/mainnet.json',
+ slippage: 5 // Slippage tolerance in percentage
+};
+```
+
+This code block Defines the parameters for the swap, including the amount to swap, token addresses, and the liquidity pool configuration.
+
+### Setup and Initialization
+
+```jsx
+const TestCallSolanaFactory = await ethers.getContractFactory('TestCallSolana');
+let TestCallSolanaAddress = config.CALL_SOLANA_SAMPLE_CONTRACT_MAINNET;
+let TestCallSolana;
+
+if (ethers.isAddress(TestCallSolanaAddress)) {
+ TestCallSolana = TestCallSolanaFactory.attach(TestCallSolanaAddress);
+} else {
+ TestCallSolana = await ethers.deployContract('TestCallSolana');
+ await TestCallSolana.waitForDeployment();
+ TestCallSolanaAddress = TestCallSolana.target;
+ console.log(`TestCallSolana deployed to ${TestCallSolana.target}`);
+}
+```
+
+This block of code creates or attaches to the already deployed `TestCallSolana` smart contract.
+
+### Retrieving Contract Public Key
+
+```jsx
+const contractPublicKeyInBytes = await TestCallSolana.getNeonAddress(TestCallSolanaAddress);
+const contractPublicKey = ethers.encodeBase58(contractPublicKeyInBytes);
+console.log(contractPublicKey, 'contractPublicKey');
+```
+
+This code block retrieves the public key for the `TestCallSolana` contract.
+
+### Finding Pool Information
+
+```jsx
+const poolKeys = await config.raydiumHelper.findPoolInfoForTokens(
+ swapConfig.liquidityFile,
+ swapConfig.TokenA,
+ swapConfig.TokenB
+);
+if (!poolKeys) {
+ console.error('Pool info not found');
+ return 'Pool info not found';
+} else {
+ console.log('Found pool info');
+}
+```
+
+This code block fetches the necessary pool information for the tokens involved in the swap from Raydium's API.
+
+### Token Account Checks
+
+```jsx
+const ataContractTokenA = await getAssociatedTokenAddress(
+ new web3.PublicKey(swapConfig.TokenA),
+ new web3.PublicKey(contractPublicKey),
+ true
+);
+const ataContractTokenAInfo = await connection.getAccountInfo(ataContractTokenA);
+const ataContractTokenB = await getAssociatedTokenAddress(
+ new web3.PublicKey(swapConfig.TokenB),
+ new web3.PublicKey(contractPublicKey),
+ true
+);
+const ataContractTokenBInfo = await connection.getAccountInfo(ataContractTokenB);
+
+if (!ataContractTokenAInfo || !ataContractTokenBInfo) {
+ if (!ataContractTokenAInfo) console.log('Account does not have initialized ATA for TokenA.');
+ if (!ataContractTokenBInfo) console.log('Account does not have initialized ATA for TokenB.');
+ return;
+} else if (
+ Number((await getAccount(connection, ataContractTokenA)).amount) <
+ swapConfig.tokenAAmount * 10 ** amountIn.currency.decimals
+) {
+ console.log('Not enough TokenA amount to proceed with the swap.');
+ return;
+}
+```
+
+This block of code checks if the contract’s account has Associated Token Accounts (ATAs) for both WSOL and USDC, which are necessary for the swap. It also verifies if the account holds enough WSOL for the swap.
+
+### Creating and Executing the Swap Instruction
+
+```jsx
+const ins = await Liquidity.makeSwapInstruction({
+ poolKeys: poolKeys,
+ userKeys: {
+ tokenAccountIn: ataContractTokenA,
+ tokenAccountOut: ataContractTokenB,
+ owner: new web3.PublicKey(contractPublicKey)
+ },
+ amountIn: amountIn.raw,
+ amountOut: minAmountOut.raw,
+ fixedSide: 'in'
+});
+
+console.log("Executing executeComposabilityMethod with Raydium's swap instruction ...");
+solanaTx = new web3.Transaction();
+solanaTx.add(ins.innerTransaction.instructions[0]);
+
+[tx, receipt] = await config.utils.executeComposabilityMethod(
+ solanaTx.instructions[0],
+ 0,
+ TestCallSolana,
+ undefined,
+ user1
+);
+console.log(tx, 'tx');
+console.log(receipt.logs[0].args, 'receipt args');
+```
+
+This block of code creates a swap instruction using Raydium's `Liquidity` module. The instruction is then added to a Solana transaction, which is then executed via a composability method.
+
+## How to run the script
+
+To test the example script `RaydiumSwap.js` , run this command in the terminal -
+
+```bash
+npx hardhat run scripts/TestCallSolana/RaydiumSwap.js --network neonmainnet
+```
+
+After running the above command successfully, you should get the output similar to this -
+
+```bash
+EPE8HRAM9d3N5xHeQnYzESVgKNSvbyP5JEfMAgXUHsS3 contractPublicKey
+Found pool info
+Executing executeComposabilityMethod with Raydium's swap instruction ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neonmainnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0xd166fcd39bc6cd93a75d14d39694fbfe33641ba134c15966dc0b851641d28c86',
+ type: 0,
+ to: '0xEf7b3ed123d2c51c780F8684B0DD7c0b4bd89190',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 340,
+ gasLimit: 300000n,
+ gasPrice: 598145095750n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x121f31514bd949c43602c33f207790ed16a3524ca1b9975cf121a2a90cffec7df8b68acd00000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000078000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001206ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003d6e472e67a46ea6b4bd0bab9dfd35e2b4c72f1d6d59c2eab95c942573ad22f1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014157b0580f31c5fce44a62582dbcf9d78ee75943a084a393b350368d2289930800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f92f390ff9609e8ad437bb8e4c1f1aa43ac05d24308cca77de8512c5509292d300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001abe43c7c1e21eaa6f97c8bd355e21bd1279674756c1c8e106c6e712ba116d97000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001b870e12dd379891561d2e9fa8f26431834eb736f2f24fc2a2a4dff1fd5dca4df00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f2cbb9b760eddb185706303063ad33d7b57296ea02d4e0335e31ceafa4cc42dd000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010d0751a8282da61305fe299c37b998e58471db1135037310f8be1045a60af6ee000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006ac4c3cefa9f19bf54c8dc0f5e4d1ceee5327d26482b29d2b13cbaa43447218d0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000146527949e0a7a659f8aadc86bc53cc7c42469a17765a9bad62b1b05bc868b5ee00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001c9beb9b16d18a8273976ef89b7fde84aec9baaca0db173db8fda4ae0de478a34000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000016b103231c975050cec8da6de40357c9bca60ef9e8f33165a255665652a82533b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a84bb6466246781d7a9adab8588ba86b2acce51358c844f5444e40640875fd5a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014c9d997d2ec43bdc0d236269cfb0d08391afd103fd8fbd63453ff58b6e23a92000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001aa5a31cb020bb002985ca929908171940fe635cb76e99ce4fb8805428bb8254a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000095b12c2855d4bce649b9fd852608e747f546f049d78a2beff1600295f3f3c772000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014f3c9bd3d0fd35e6dfb74137337d2f72e81721438d527b147e9a32949a59172a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001c6d98c89611168a9961be2aa24bedbac9fd195d6337013a8a9cd74e3993040e400000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001109a0860100000000008336000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022934n,
+ signature: Signature { r: "0x210b95035a1228647cd21e686ff577b0861da3a900f90e7b349bd005dc9b2ea6", s: "0x0c0609fdfb647e8db94beb9f07a38b73ba7fcdd2e5ca040c9951abf61724622f", yParity: 0, networkV: 490045903 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+
+```
+
+:::important
+The full code of the script can be viewed here [RaydiumSwap.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/RaydiumSwap.js).
+:::
diff --git a/docs/composability/using_composability/transfer_sols.md b/docs/composability/using_composability/transfer_sols.md
new file mode 100644
index 00000000..357d4dd2
--- /dev/null
+++ b/docs/composability/using_composability/transfer_sols.md
@@ -0,0 +1,383 @@
+---
+title: 'Transfer SOLs between accounts'
+proofedDate: 20240627
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+## Introduction
+
+This tutorial will walk you through the steps of creating two accounts on Solana using the `createAccountWithSeed` instruction and then transferring 1 SOL from one account to the other using a solidity smart contract on Neon EVM Devnet.
+
+This example code is based on the script [TransferSOLsBetweenAccounts.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/TransferSOLsBetweenAccounts.js). This script is designed to demonstrate the creation of two accounts (SenderAccount and ReceiverAccount) on the Solana blockchain and perform a couple of SOL transfer transactions involving these accounts.
+
+## How the script works
+
+Let us breakdown the main components of the script `TransferSOLsBetweenAccounts.js` to get into more depth of the process of transferring of SOLs from one account to another.
+
+### Importing Dependencies
+
+```jsx
+const { ethers } = require('hardhat');
+const web3 = require('@solana/web3.js');
+const { config } = require('./config');
+```
+
+These lines import the necessary libraries: `ethers` for Ethereum-related operations, `@solana/web3.js` for Solana operations, and the configuration file.
+
+### Establishing Connection
+
+```jsx
+const connection = new web3.Connection(config.SOLANA_NODE, 'processed');
+```
+
+This establishes a connection to the Solana node specified in the configuration file.
+
+### Getting Signers and Contract Factory
+
+```jsx
+const [user1] = await ethers.getSigners();
+const TestCallSolanaFactory = await ethers.getContractFactory('TestCallSolana');
+```
+
+This gets the signer from the `ethers` library and retrieves the contract factory for deploying or interacting with the `TestCallSolana.sol` contract.
+
+### Deploying or Attaching to the Contract
+
+```jsx
+let TestCallSolanaAddress = config.CALL_SOLANA_SAMPLE_CONTRACT;
+let TestCallSolana;
+
+if (ethers.isAddress(TestCallSolanaAddress)) {
+ TestCallSolana = TestCallSolanaFactory.attach(TestCallSolanaAddress);
+} else {
+ TestCallSolana = await ethers.deployContract('TestCallSolana');
+ await TestCallSolana.waitForDeployment();
+ TestCallSolanaAddress = TestCallSolana.target;
+ console.log(`TestCallSolana deployed to ${TestCallSolana.target}`);
+}
+```
+
+This block of code either attaches to an existing contract or deploys a new one if the address is not valid.
+
+### Getting Payer and Contract Public Key
+
+```jsx
+const payer = ethers.encodeBase58(await TestCallSolana.getPayer());
+const contractPublicKeyInBytes = await TestCallSolana.getNeonAddress(TestCallSolanaAddress);
+const contractPublicKey = ethers.encodeBase58(contractPublicKeyInBytes);
+```
+
+This retrieves the payer address and the public key of the contract in base58 encoding.
+
+### Calculating Minimum Balance for Rent Exemption
+
+```jsx
+const minBalance = await connection.getMinimumBalanceForRentExemption(0);
+```
+
+This gets the minimum balance required for an account to be rent-exempt on Solana.
+
+### Creating Accounts with Seed
+
+```jsx
+const seedSender = 'salt' + Date.now().toString();
+const seedReceiver = seedSender + '1';
+
+const SenderAccount = await web3.PublicKey.createWithSeed(
+ new web3.PublicKey(contractPublicKey),
+ seedSender,
+ web3.SystemProgram.programId
+);
+const ReceiverAccount = await web3.PublicKey.createWithSeed(
+ new web3.PublicKey(contractPublicKey),
+ seedReceiver,
+ web3.SystemProgram.programId
+);
+```
+
+These lines generate unique seeds, `seedSender` and `seedReceiver` , for the sender and receiver accounts and create the public keys for these accounts using the seeds.
+
+### Checking and Creating Accounts if Necessary
+
+```jsx
+const senderAccountData = await connection.getAccountInfo(SenderAccount);
+const receiverAccountData = await connection.getAccountInfo(ReceiverAccount);
+
+// if sender's account has not been created yet
+if (senderAccountData == null) {
+ console.log('Creating SenderAccount through createAccountWithSeed instruction ...');
+ solanaTx = new web3.Transaction();
+ solanaTx.add(
+ web3.SystemProgram.createAccountWithSeed({
+ fromPubkey: new web3.PublicKey(payer),
+ basePubkey: new web3.PublicKey(contractPublicKey),
+ newAccountPubkey: SenderAccount,
+ seed: seedSender,
+ lamports: minBalance, // rent exempt
+ space: 0,
+ programId: web3.SystemProgram.programId
+ })
+ );
+ [tx, receipt] = await config.utils.executeComposabilityMethod(
+ solanaTx.instructions[0],
+ minBalance,
+ TestCallSolana,
+ undefined,
+ owner
+ );
+ console.log(tx, 'tx');
+ console.log(receipt.logs[0].args, 'receipt args');
+}
+
+// if receiver's account has not been created yet
+if (receiverAccountData == null) {
+ console.log('Creating ReceiverAccount through createAccountWithSeed instruction ...');
+ solanaTx = new web3.Transaction();
+ solanaTx.add(
+ web3.SystemProgram.createAccountWithSeed({
+ fromPubkey: new web3.PublicKey(payer),
+ basePubkey: new web3.PublicKey(contractPublicKey),
+ newAccountPubkey: ReceiverAccount,
+ seed: seedReceiver,
+ lamports: minBalance, // rent exempt
+ space: 0,
+ programId: web3.SystemProgram.programId
+ })
+ );
+ [tx, receipt] = await config.utils.executeComposabilityMethod(
+ solanaTx.instructions[0],
+ minBalance,
+ TestCallSolana,
+ undefined,
+ owner
+ );
+ console.log(tx, 'tx');
+ console.log(receipt.logs[0].args, 'receipt args');
+}
+```
+
+This checks if the accounts already exist. If not, it creates them using the `createAccountWithSeed` instruction.
+
+### Funding Sender Account with SOL
+
+```jsx
+const amount = 1000000000; // 1 SOL
+solanaTx = new web3.Transaction();
+solanaTx.add(
+ web3.SystemProgram.transfer({
+ fromPubkey: new web3.PublicKey(payer),
+ toPubkey: new web3.PublicKey(SenderAccount),
+ lamports: amount
+ })
+);
+```
+
+This funds the `SenderAccount` with 1 SOL from the payer.
+
+### Transferring SOL from Sender to Receiver
+
+```jsx
+solanaTx.add(
+ web3.SystemProgram.transfer({
+ fromPubkey: SenderAccount,
+ basePubkey: new web3.PublicKey(contractPublicKey),
+ toPubkey: ReceiverAccount,
+ lamports: amount,
+ seed: seedSender,
+ programId: web3.SystemProgram.programId
+ })
+);
+```
+
+This adds an instruction to transfer 1 SOL from the `SenderAccount` to the `ReceiverAccount`.
+
+### Executing Transactions
+
+```jsx
+console.log('Executing batchExecuteComposabilityMethod with all instructions ...');
+[tx, receipt] = await config.utils.batchExecuteComposabilityMethod(
+ solanaTx.instructions,
+ [amount, 0],
+ TestCallSolana,
+ undefined,
+ owner
+);
+```
+
+This executes the batch of transactions, including funding the `SenderAccount` and transferring SOL to the `ReceiverAccount`.
+
+## How to run the script
+
+To test the example script `TransferSOLsBetweenAccounts.js` , run this command in the terminal -
+
+```bash
+npx hardhat run scripts/TestCallSolana/TransferSOLsBetweenAccounts.js --network neondevnet
+```
+
+After running the above command successfully, you should get the output similar to this -
+
+```bash
+4FiNE9Rj3nKCBWmJgQVte7hRoSt2TeMNFe8FzZpsgnDD payer
+54Mfrfbv16neQhrP7o29FnsAfEtmLitTDG7fuP71YKYL contractPublicKey
+890880 minBalance
+PublicKey [PublicKey(5YqXxPNAy8kd2WZRR3mPsE6iUbX7uiFo7oDtzWfKkh8r)] {
+ _bn:
+} SenderAccount
+PublicKey [PublicKey(7EhujXfAQ16KAoyLBtHyukkWTf6m9v1Hx9Jix1DSP1qB)] {
+ _bn:
+} ReceiverAccount
+Creating SenderAccount through createAccountWithSeed instruction ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0xf13646a5ee2131f34bfa4c56774c6a2d5ef372036a74af53bcae1096466e819f',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23127,
+ gasLimit: 980880n,
+ gasPrice: 240531817980n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x121f3151000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000d9800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000033057f6fad62a3ecae4e8d197bc418c4c578bca456ebeeaff45778fd91964ea30000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000014396a149293487b0ac9142284b9d73c18be3cf3ac873be72ae4f338f66fa93bf000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b900000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006d030000003c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b9110000000000000073616c743137313932333237343230303500980d00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0x57a11b47d638cdae7d67e747548a501dd4ea5e8605ca11f80cfdf0f621d5792e", s: "0x677db2cb039f71ca3f1dcc058d1c71484d3ebf05df03ceb93794b7542d43217b", yParity: 1, networkV: 490045888 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+Creating ReceiverAccount through createAccountWithSeed instruction ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0x293eeda18afee57a5f23aa61f2f52ea3e7f2680719fcbec0dc4d384e009cf660',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23128,
+ gasLimit: 980880n,
+ gasPrice: 240433899348n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x121f3151000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000d9800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000033057f6fad62a3ecae4e8d197bc418c4c578bca456ebeeaff45778fd91964ea30000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000015ca8eda1bd5f2405805847cbecab552247f8cfb6ae4ac9862bf67477d9a670ea000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b900000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006e030000003c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b9120000000000000073616c74313731393233323734323030353100980d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0xabd472ac74b40a5431e3c526bc5cee9346ece8b5b1050b55275a97e89e55a5e4", s: "0x41602c22715ea1987526419f22ca42ae3ada06e80bcd262c63689292cb07f8df", yParity: 1, networkV: 490045888 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+{
+ data: ,
+ executable: false,
+ lamports: 890880,
+ owner: PublicKey [PublicKey(11111111111111111111111111111111)] {
+ _bn:
+ },
+ rentEpoch: 18446744073709552000,
+ space: 0
+} getAccountInfo SenderAccount
+{
+ data: ,
+ executable: false,
+ lamports: 890880,
+ owner: PublicKey [PublicKey(11111111111111111111111111111111)] {
+ _bn:
+ },
+ rentEpoch: 18446744073709552000,
+ space: 0
+} getAccountInfo SenderAccount
+Executing batchExecuteComposabilityMethod with all instructions ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0x266e43f084a81bba13d7da77d808029d3502acd6edcc333453733f862cf89daf',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23129,
+ gasLimit: 1000185000n,
+ gasPrice: 240400985720n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x59cfc5e400000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000038000000000000000000000000000000000000000000000000000000000000004a0000000000000000000000000000000000000000000000000000000000000050000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000012000000000000000000000000000000000000000000000000000000000000000023057f6fad62a3ecae4e8d197bc418c4c578bca456ebeeaff45778fd91964ea30000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000014396a149293487b0ac9142284b9d73c18be3cf3ac873be72ae4f338f66fa93bf0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000034396a149293487b0ac9142284b9d73c18be3cf3ac873be72ae4f338f66fa93bf000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b9000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000005ca8eda1bd5f2405805847cbecab552247f8cfb6ae4ac9862bf67477d9a670ea00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000c0200000000ca9a3b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000450b00000000ca9a3b00000000110000000000000073616c743137313932333237343230303500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0x2b3a2fba9eeed450aefd68097add3a0aba34b6a8b7d67c327bf627253ec2c2aa", s: "0x6ae14fe47acf41ffb71d01eb0cafc70f0fd2657fcfd41629f09ef8f71d85090b", yParity: 1, networkV: 490045888 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args instruction # 0
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args instruction # 1
+```
+
+:::important
+The full code of the script can be viewed here [TransferSOLsBetweenAccounts.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/TransferSOLsBetweenAccounts.js).
+:::
diff --git a/docs/composability/using_composability/transfer_spl_token.md b/docs/composability/using_composability/transfer_spl_token.md
new file mode 100644
index 00000000..9bb84858
--- /dev/null
+++ b/docs/composability/using_composability/transfer_spl_token.md
@@ -0,0 +1,432 @@
+---
+title: 'Transfer SPL Token between accounts'
+proofedDate: 20240627
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+## Introduction
+
+This tutorial will walk you through the steps of creating two accounts on Solana using the `createAccountWithSeed` instruction, minting an SPL token to one account and then transferring the SPL token from that account to another using a solidity smart contract on Neon EVM Devnet.
+
+This example code is based on the script [TransferSPLTokenBetweenAccounts.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/TransferSPLTokenBetweenAccounts.js). This script demonstrates creating two accounts on Solana using the `createAccountWithSeed` instruction, minting tokens to one account, and transferring those tokens to another account. It illustrates the process of handling SPL Token transfers between accounts. For this example, we are using an SPL Token with account address `8LkbY4Q1jGEF1BwedHz1ALM3q4zZRhZpCMWRe6SbrbKj` on Solana Devnet.
+
+## How the script works
+
+Let us breakdown the main components of the script `TransferSPLTokenBetweenAccounts.js` to get into more depth of the process of minting and transferring of an SPL Token from one account to another.
+
+### Importing Dependencies
+
+```jsx
+const { ethers } = require('hardhat');
+const web3 = require('@solana/web3.js');
+const { config } = require('./config');
+const {
+ ACCOUNT_SIZE,
+ TOKEN_PROGRAM_ID,
+ createMintToInstruction,
+ createTransferInstruction,
+ createInitializeAccount2Instruction
+} = require('@solana/spl-token');
+```
+
+These lines import the necessary libraries: `ethers` for Ethereum-related operations, `@solana/web3.js` and `@solana/spl-token` for Solana operations, and the configuration file.
+
+### Establishing Connection
+
+```jsx
+const connection = new web3.Connection(config.SOLANA_NODE, 'processed');
+```
+
+This establishes a connection to the Solana node specified in the configuration file.
+
+### Getting Signers, Contract Factory and the SPL Token account
+
+```jsx
+const [user1, user2] = await ethers.getSigners();
+const tokenMintPublicKey = '8LkbY4Q1jGEF1BwedHz1ALM3q4zZRhZpCMWRe6SbrbKj';
+if (tokenMintPublicKey == '') {
+ return console.error(
+ 'Before proceeding with instructions execution please set value for the tokenMintPublicKey variable.'
+ );
+}
+const token = new web3.PublicKey(tokenMintPublicKey);
+
+const TestCallSolanaFactory = await ethers.getContractFactory('TestCallSolana');
+```
+
+This gets the signers from the `ethers` library, retrieves the contract factory for deploying or interacting with the `TestCallSolana.sol` contract and also retrieves the SPL Token account public key.
+
+### Deploying or Attaching to the Contract
+
+```jsx
+let TestCallSolanaAddress = config.CALL_SOLANA_SAMPLE_CONTRACT;
+let TestCallSolana;
+let solanaTx;
+let tx;
+let receipt;
+
+if (ethers.isAddress(TestCallSolanaAddress)) {
+ TestCallSolana = TestCallSolanaFactory.attach(TestCallSolanaAddress);
+} else {
+ TestCallSolana = await ethers.deployContract('TestCallSolana');
+ await TestCallSolana.waitForDeployment();
+
+ TestCallSolanaAddress = TestCallSolana.target;
+ console.log(`TestCallSolana deployed to ${TestCallSolana.target}`);
+}
+```
+
+This block of code either attaches to an existing contract or deploys a new one if the address is not valid.
+
+### Getting Payer and Contract Public Key
+
+```jsx
+const payer = ethers.encodeBase58(await TestCallSolana.getPayer());
+const contractPublicKeyInBytes = await TestCallSolana.getNeonAddress(TestCallSolanaAddress);
+const contractPublicKey = ethers.encodeBase58(contractPublicKeyInBytes);
+```
+
+This retrieves the payer address and the public key of the contract in base58 encoding.
+
+### Calculating Minimum Balance for Rent Exemption
+
+```jsx
+const minBalance = await connection.getMinimumBalanceForRentExemption(0);
+```
+
+This gets the minimum balance required for an account to be rent-exempt on Solana.
+
+### Creating Accounts with Seed
+
+```jsx
+const seedSender = 'salt' + Date.now().toString();
+const seedReceiver = seedSender + '1';
+
+const SenderAccount = await web3.PublicKey.createWithSeed(
+ new web3.PublicKey(contractPublicKey),
+ seedSender,
+ web3.SystemProgram.programId
+);
+const ReceiverAccount = await web3.PublicKey.createWithSeed(
+ new web3.PublicKey(contractPublicKey),
+ seedReceiver,
+ web3.SystemProgram.programId
+);
+```
+
+These lines generate unique seeds, `seedSender` and `seedReceiver` , for the sender and receiver accounts and create the public keys for these accounts using the seeds.
+
+### Checking and Creating Accounts (ATAs and Token Accounts) if Necessary
+
+```jsx
+const senderAccountData = await connection.getAccountInfo(SenderAccount);
+const receiverAccountData = await connection.getAccountInfo(ReceiverAccount);
+
+// if sender's account has not been created yet
+if (senderAccountData == null) {
+ console.log('Creating SenderAccount through createAccountWithSeed instruction ...');
+ solanaTx = new web3.Transaction();
+ solanaTx.add(
+ web3.SystemProgram.createAccountWithSeed({
+ fromPubkey: new web3.PublicKey(payer),
+ basePubkey: new web3.PublicKey(contractPublicKey),
+ newAccountPubkey: SenderAccount,
+ seed: seedSender,
+ lamports: minBalance,
+ space: ACCOUNT_SIZE,
+ programId: TOKEN_PROGRAM_ID
+ })
+ );
+
+ solanaTx.add(
+ createInitializeAccount2Instruction(SenderAccount, token, new web3.PublicKey(contractPublicKey))
+ );
+
+ [tx, receipt] = await config.utils.batchExecuteComposabilityMethod(
+ solanaTx.instructions,
+ [minBalance, 0],
+ TestCallSolana,
+ undefined,
+ user1
+ );
+ console.log(tx, 'tx');
+ console.log(receipt.logs[0].args, 'receipt args');
+ console.log(receipt.logs[1].args, 'receipt args');
+}
+
+// if receiver's account has not been created yet
+if (receiverAccountData == null) {
+ console.log('Creating ReceiverAccount through createAccountWithSeed instruction ...');
+ solanaTx = new web3.Transaction();
+ solanaTx.add(
+ web3.SystemProgram.createAccountWithSeed({
+ fromPubkey: new web3.PublicKey(payer),
+ basePubkey: new web3.PublicKey(contractPublicKey),
+ newAccountPubkey: ReceiverAccount,
+ seed: seedReceiver,
+ lamports: minBalance,
+ space: ACCOUNT_SIZE,
+ programId: TOKEN_PROGRAM_ID
+ })
+ );
+
+ solanaTx.add(
+ createInitializeAccount2Instruction(
+ ReceiverAccount,
+ token,
+ new web3.PublicKey(contractPublicKey)
+ )
+ );
+
+ [tx, receipt] = await config.utils.batchExecuteComposabilityMethod(
+ solanaTx.instructions,
+ [minBalance, 0],
+ TestCallSolana,
+ undefined,
+ user1
+ );
+ console.log(tx, 'tx');
+ console.log(receipt.logs[0].args, 'receipt args');
+ console.log(receipt.logs[1].args, 'receipt args');
+}
+
+console.log(await connection.getAccountInfo(SenderAccount), 'getAccountInfo SenderAccount');
+console.log(await connection.getAccountInfo(ReceiverAccount), 'getAccountInfo SenderAccount');
+```
+
+This checks if the accounts already exist. If not, it creates them using the `createAccountWithSeed` instruction. This also creates a Token Account for the `SenderAccount` and `ReceiverAccount` for the SPL Token with respect to the contract.
+
+### Minting Tokens to the SenderAccount
+
+```jsx
+console.log('Minting SPL Tokens to SenderAccount and transferring them to ReceiverAccount...');
+solanaTx = new web3.Transaction();
+solanaTx.add(
+ createMintToInstruction(
+ token,
+ SenderAccount,
+ new web3.PublicKey(contractPublicKey),
+ 1000 * 10 ** 9 // mint 1000 tokens
+ )
+);
+```
+
+This block of code mints 1000 tokens to `SenderAccount`.
+
+### Transferring Tokens from SenderAccount to ReceiverAccount
+
+```jsx
+solanaTx.add(
+ createTransferInstruction(
+ SenderAccount,
+ ReceiverAccount,
+ contractPublicKey,
+ 10 * 10 ** 9, // transfers 10 tokens
+ []
+ )
+);
+```
+
+This code block transfers 10 tokens from `SenderAccount` to `ReceiverAccount`.
+
+### Executing Transactions
+
+```jsx
+console.log('Executing batchExecuteComposabilityMethod ...');
+[tx, receipt] = await config.utils.batchExecuteComposabilityMethod(
+ solanaTx.instructions,
+ [0, 0, 0, 0, 0],
+ TestCallSolana,
+ undefined,
+ user1
+);
+```
+
+This executes the batch of transactions, including minting SPL Token to the `SenderAccount` and transferring SPL Token from `SenderAccount` to the `ReceiverAccount`.
+
+## How to run the script
+
+To test the example script `TransferSPLTokenBetweenAccounts.js` , run this command in the terminal -
+
+```bash
+npx hardhat run scripts/TestCallSolana/TransferSPLTokenBetweenAccounts.js --network neondevnet
+```
+
+After running the above command successfully, you should get the output similar to this -
+
+```bash
+4FiNE9Rj3nKCBWmJgQVte7hRoSt2TeMNFe8FzZpsgnDD payer
+54Mfrfbv16neQhrP7o29FnsAfEtmLitTDG7fuP71YKYL contractPublicKey
+2039280 minBalance
+PublicKey [PublicKey(5FhKDhKNZWtYq2mRUEm6FgwrFTMdu52bRqXss31wykw5)] {
+ _bn:
+} SenderAccount
+PublicKey [PublicKey(GJxCHgh814MgbzztZzzWNzHuS22PqvM8wW2Z3mNJMdib)] {
+ _bn:
+} ReceiverAccount
+Creating SenderAccount through createAccountWithSeed instruction ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0xb091f3a5c3d4e000d95bd149c7f98ce518b60262311be5b490523a2d693a8dcb',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23139,
+ gasLimit: 2234280n,
+ gasPrice: 255970522754n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x59cfc5e400000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000003e0000000000000000000000000000000000000000000000000000000000000054000000000000000000000000000000000000000000000000000000000000005a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000006ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a900000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000000033057f6fad62a3ecae4e8d197bc418c4c578bca456ebeeaff45778fd91964ea30000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000013f32765caee0fe06ea9c34fc0fa68ef11468029c0a1e5b1b64b242eebeb012ec000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b90000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000033f32765caee0fe06ea9c34fc0fa68ef11468029c0a1e5b1b64b242eebeb012ec000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000016d11232b2c3c728347030537ca3de7dbce997aed3dec98b863b180ab1192a32e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006a7d517192c5c51218cc94c3d4af17f58daee089ba1fd44e3dbd98a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000006d030000003c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b9110000000000000073616c7431373139343333383135363431f01d1f0000000000a50000000000000006ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021103c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000001f1df00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0x3e25ceffc80be57819cd45f98e2ebabb94ed77f00581caa9cccc92d55b52e211", s: "0x25f0f27067d0516e035057d6629a7c9c77ae285d281c1cb7180a7a9172fb1273", yParity: 0, networkV: 490045887 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+Creating ReceiverAccount through createAccountWithSeed instruction ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0x175650f95f0fcb89a5ff1792720474053672519ca6c8e7a375ecb26073112e55',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23140,
+ gasLimit: 2234280n,
+ gasPrice: 256208913865n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x59cfc5e400000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000003e0000000000000000000000000000000000000000000000000000000000000054000000000000000000000000000000000000000000000000000000000000005a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000006ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a900000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000000033057f6fad62a3ecae4e8d197bc418c4c578bca456ebeeaff45778fd91964ea3000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e378961e4791977a2a9307ad30e8aae05652bbb1f46a3173c0970e8b709607cc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b9000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003e378961e4791977a2a9307ad30e8aae05652bbb1f46a3173c0970e8b709607cc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000016d11232b2c3c728347030537ca3de7dbce997aed3dec98b863b180ab1192a32e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006a7d517192c5c51218cc94c3d4af17f58daee089ba1fd44e3dbd98a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000006e030000003c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b9120000000000000073616c743137313934333338313536343131f01d1f0000000000a50000000000000006ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021103c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000001f1df00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0xc3169850f21b5fa07a73db2357a74447cfe22f8386c4e4c47655e3f01194fef4", s: "0x20f8cfe17aa2e415d3ba96c8fc1fcd821c0679499ca9dca099b81dd68d110f80", yParity: 1, networkV: 490045888 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+{
+ data: ,
+ executable: false,
+ lamports: 2039280,
+ owner: PublicKey [PublicKey(TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA)] {
+ _bn:
+ },
+ rentEpoch: 18446744073709552000,
+ space: 165
+} getAccountInfo SenderAccount
+{
+ data: ,
+ executable: false,
+ lamports: 2039280,
+ owner: PublicKey [PublicKey(TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA)] {
+ _bn:
+ },
+ rentEpoch: 18446744073709552000,
+ space: 165
+} getAccountInfo SenderAccount
+Minting SPLTokens to SenderAccount and transferring them to ReceiverAccount ...
+Executing batchExecuteComposabilityMethod ...
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0x4f7b817631fcd27067c2d4aca5aa01ea2a77f8b198934b557d4e2a547bf1ccd2',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23141,
+ gasLimit: 195000n,
+ gasPrice: 256301137725n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x59cfc5e400000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000003e000000000000000000000000000000000000000000000000000000000000004c00000000000000000000000000000000000000000000000000000000000000580000000000000000000000000000000000000000000000000000000000000000206ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a906ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a900000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000000036d11232b2c3c728347030537ca3de7dbce997aed3dec98b863b180ab1192a32e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013f32765caee0fe06ea9c34fc0fa68ef11468029c0a1e5b1b64b242eebeb012ec000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b90000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000033f32765caee0fe06ea9c34fc0fa68ef11468029c0a1e5b1b64b242eebeb012ec00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001e378961e4791977a2a9307ad30e8aae05652bbb1f46a3173c0970e8b709607cc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013c4adc98a3372450da1f1000ba8ec47c94f9533127f4b2589a40ebe7424de9b9000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000009070010a5d4e8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090300e40b54020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0xb50acd94d4c01c27a738206a37763f7cc45ee52b2f4c82975145603dbdfd9eb7", s: "0x7cef71ea1e788239c18ecc20becd6a651af87447f81b24bd7f171f79efe52917", yParity: 0, networkV: 490045887 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args instruction # 0
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args instruction # 1
+```
+
+:::important
+The full code of the script can be viewed here [TransferSPLTokenBetweenAccounts.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/TransferSPLTokenBetweenAccounts.js).
+:::
diff --git a/docs/composability/using_composability/using_vrf.md b/docs/composability/using_composability/using_vrf.md
new file mode 100644
index 00000000..7f142a2c
--- /dev/null
+++ b/docs/composability/using_composability/using_vrf.md
@@ -0,0 +1,202 @@
+---
+title: 'Using Verifiable Random Function (VRF)'
+proofedDate: 20240627
+iterationBy: na
+includedInSite: false
+approvedBy: na
+---
+
+## Introduction
+
+This tutorial will walk you through the steps of requesting on-chain randomness on Solana using ORAO VRF (Verifiable Random Function) program.
+
+This example code is based on the script [OraoNetworkVRF.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/OraoNetworkVRF.js). This script is designed to submit a VRF request to the ORAO VRF network program. You can generate on-chain randomness on Solana with ORAO's Verifiable Random Function. This tool offers unbiased, fast, and affordable randomness for your Solana programs. You can use it to create unique NFT characteristics, generate random levels for games and weapons, randomize airdrops, and provide secure, verifiable lotteries. It is built using the Anchor framework.
+
+## How the script works
+
+Let us breakdown the main components of the script `OraoNetworkVRF.js` to get into more depth of the process of generating randomness on Solana using ORAO’s VRF.
+
+### Initial Checks and Imports
+
+```jsx
+if (process.env.ANCHOR_PROVIDER_URL == undefined || process.env.ANCHOR_WALLET == undefined) {
+ return console.log(
+ "This script uses the @coral-xyz/anchor library which requires the variables ANCHOR_PROVIDER_URL and ANCHOR_WALLET to be set. Please create id.json in the root of the hardhat project with your Solana's private key and run the following command in the terminal in order to proceed with the script execution - export ANCHOR_PROVIDER_URL=https://api.devnet.solana.com && export ANCHOR_WALLET=./id.json"
+ );
+}
+
+const { ethers } = require('hardhat');
+const web3 = require('@solana/web3.js');
+const { config } = require('./config');
+const { AnchorProvider } = require('@coral-xyz/anchor');
+const { Orao } = require('@orao-network/solana-vrf');
+```
+
+This code block checks if the required environment variables `ANCHOR_PROVIDER_URL` and `ANCHOR_WALLET` are set. It then imports necessary libraries and modules. `ANCHOR_PROVIDER_URL` is Solana's RPC URL and `ANCHOR_WALLET` is Solana's private key in json byte array format.
+
+- Store your Solana’s private key in the file `id.json` and place it in the root of your hardhat project folder. This key will be used only for the Anchor SDK initialization, and not for signing or submitting any transactions.
+- Run this in your terminal -
+ ```bash
+ export ANCHOR_PROVIDER_URL=https://api.devnet.solana.com
+ export ANCHOR_WALLET=./id.json
+ ```
+
+### Setup and Initialization
+
+```jsx
+async function main() {
+ const [user1] = await ethers.getSigners();
+ const provider = AnchorProvider.env();
+ const vrf = new Orao(provider);
+
+ const TestCallSolanaFactory = await ethers.getContractFactory("TestCallSolana");
+ let TestCallSolanaAddress = config.CALL_SOLANA_SAMPLE_CONTRACT;
+ let TestCallSolana;
+ let solanaTx;
+ let tx;
+ let receipt;
+
+ if (ethers.isAddress(TestCallSolanaAddress)) {
+ TestCallSolana = TestCallSolanaFactory.attach(TestCallSolanaAddress);
+ } else {
+ TestCallSolana = await ethers.deployContract("TestCallSolana");
+ await TestCallSolana.waitForDeployment();
+
+ TestCallSolanaAddress = TestCallSolana.target;
+ console.log(
+ `TestCallSolana deployed to ${TestCallSolana.target}`
+ );
+ }
+```
+
+This block of code sets up the connection to the Solana blockchain and initializes the Anchor provider and an Orao VRF instance. It also creates or attaches to the already deployed `TestCallSolana` smart contract.
+
+### Getting Payer and Contract Public Key
+
+```jsx
+const payer = ethers.encodeBase58(await TestCallSolana.getPayer());
+console.log(payer, 'payer');
+
+const contractPublicKeyInBytes = await TestCallSolana.getNeonAddress(TestCallSolanaAddress);
+const contractPublicKey = ethers.encodeBase58(contractPublicKeyInBytes);
+console.log(contractPublicKey, 'contractPublicKey');
+```
+
+This block of code retrieves the payer and contract public key from the `TestCallSolana` contract.
+
+### Generating VRF Seed and Building Request
+
+```jsx
+const randomKeypair = web3.Keypair.generate();
+const seed = randomKeypair._keypair.publicKey; // use new generated keypair publicKey as VRF seed
+
+let req = await vrf.request(seed);
+let instruction = await req.build();
+```
+
+This code block generates a random keypair, and its public key is used as the VRF seed. A VRF request is then built using this seed.
+
+### Preparing and Submitting the Transaction
+
+```jsx
+const data = vrf.coder.instruction.encode('requestV2', { seed: instruction._args[0] });
+const programId = vrf.programId;
+const keys = [
+ { pubkey: new web3.PublicKey(payer), isSigner: true, isWritable: true },
+ { pubkey: instruction._accounts.networkState, isSigner: false, isWritable: true },
+ { pubkey: instruction._accounts.treasury, isSigner: false, isWritable: true },
+ { pubkey: instruction._accounts.request, isSigner: false, isWritable: true },
+ { pubkey: web3.SystemProgram.programId, isSigner: false, isWritable: false }
+];
+
+solanaTx = new web3.Transaction();
+solanaTx.add(
+ new web3.TransactionInstruction({
+ keys: keys,
+ programId: programId,
+ data: data
+ })
+);
+
+[tx, receipt] = await config.utils.executeComposabilityMethod(
+ solanaTx.instructions[0],
+ 7103920,
+ TestCallSolana,
+ undefined,
+ user1
+);
+console.log(tx, 'tx');
+console.log(receipt.logs[0].args, 'receipt args');
+```
+
+This section of code encodes the VRF request and prepares a transaction instruction, including the necessary keys and program ID. It then submits the transaction.
+
+### Waiting for Randomness and Outputting the Result
+
+```jsx
+ const randomness = await vrf.waitFulfilled(seed);
+ console.log(Buffer.from(randomness.randomness).readBigUInt64LE(), 'randomness');
+}
+```
+
+This section of code waits for the VRF request to be fulfilled and then outputs the generated randomness.
+
+## How to run the script
+
+To test the example script `OraoNetworkVRF.js` , run this command in the terminal -
+
+```bash
+npx hardhat run scripts/TestCallSolana/OraoNetworkVRF.js --network neondevnet
+```
+
+After running the above command successfully, you should get the output similar to this -
+
+```bash
+4FiNE9Rj3nKCBWmJgQVte7hRoSt2TeMNFe8FzZpsgnDD payer
+54Mfrfbv16neQhrP7o29FnsAfEtmLitTDG7fuP71YKYL contractPublicKey
+ContractTransactionResponse {
+ provider: HardhatEthersProvider {
+ _hardhatProvider: LazyInitializationProviderAdapter {
+ _providerFactory: [AsyncFunction (anonymous)],
+ _emitter: [EventEmitter],
+ _initializingPromise: [Promise],
+ provider: [BackwardsCompatibilityProviderAdapter]
+ },
+ _networkName: 'neondevnet',
+ _blockListeners: [],
+ _transactionHashListeners: Map(0) {},
+ _eventListeners: [],
+ _isHardhatNetworkCached: false,
+ _transactionHashPollingTimeout: undefined
+ },
+ blockNumber: null,
+ blockHash: null,
+ index: undefined,
+ hash: '0x9ddfafcab442ba954b8ff5100187c8f78c727f75a852c3605d86e9c050370552',
+ type: 0,
+ to: '0x004FB641e6C998Fc7dbdfB595F723727c8d07535',
+ from: '0x9CE2A03A7a258fB96d04Afb8Dd84b69A748B5959',
+ nonce: 23138,
+ gasLimit: 7213920n,
+ gasPrice: 253928464918n,
+ maxPriorityFeePerGas: null,
+ maxFeePerGas: null,
+ maxFeePerBlobGas: null,
+ data: '0x121f31510747b11afa91b4d1f922f27b0ebac1dab23b2129a4bef34f32a47b58f5cefc7800000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000002a000000000000000000000000000000000000000000000000000000000006c65b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000053057f6fad62a3ecae4e8d197bc418c4c578bca456ebeeaff45778fd91964ea30000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000013ede735db98b5ca2accac3bc1269e54b5409e5ea2c2bf6b2be0d80db10ee8f8c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017f2dcd2aa425a24abf0d8fe12b60aa8f4768370d0fd99c738aefe6f2150f03b800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001b245c746e0e26b8dc90f054fc08abda07b00ef400837ba3a9cd018f7825a02500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000282697d106c3661cd9809d438e6a37aa86282621e719d1722e68e08dcf77f8fbc2df49bf340145006b000000000000000000000000000000000000000000000000',
+ value: 0n,
+ chainId: 245022926n,
+ signature: Signature { r: "0xb53f1976bcf6795a7c5468045782747995acc6e099c2acc77ad97793712fcd15", s: "0x78bcbc24ae253083588e6624725ed2000e580bcd7f81eadb04e7a127effcf43a", yParity: 0, networkV: 490045887 },
+ accessList: null,
+ blobVersionedHashes: null
+} tx
+Result(3) [
+ '0x',
+ '0x0000000000000000000000000000000000000000000000000000000000000000',
+ '0x'
+] receipt args
+17369911603807770235n randomness
+```
+
+:::important
+The full code of the script can be viewed here [OraoNetworkVRF.js](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/scripts/TestCallSolana/OraoNetworkVRF.js).
+:::
diff --git a/docs/contributing/bpf_trace.md b/docs/contributing/bpf_trace.md
deleted file mode 100644
index 75e5e317..00000000
--- a/docs/contributing/bpf_trace.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: BPF Trace
----
-
-*During the runtime, the BPF interpreter can be configured to log a trace message for each BPF instruction executed. This can be very helpful for things like pinpointing the runtime context leading up to a memory access violation.*
-
-The trace logs together with the ELF dump can provide a lot of insight.
-
-To turn on BPF interpreter trace messages in a local cluster, specify the value `solana_rbpf` in `RUST_LOG` to trace. For example:
-```sh
-$ export RUST_LOG=solana_bpf_loader_program=trace
-```
-
-There is an additional level of control over this feature. To enable it, a local Solana cluster must be built with a specific `with-bpf-trace-control` feature:
-```sh
-$ cargo build --release --features with-bpf-trace-control
-```
-
-To turn it on, create another environment variable `SOLANA_BPF_TRACE_CONTROL`, which should contain a TCP port. For example:
-```sh
-$ export SOLANA_BPF_TRACE_CONTROL="8888"
-```
-
-The control config contains several settings to change the BPF tracing behavior without restarting a local cluster. Here is the default configuration as viewed with the `solana-bpf-trace-control` utility:
-```
-enable = true
-filter =
-output = /tmp/trace
-binary = false
-multiple_files = true
-max_threads = 2
-min_length = 1000000
-```
-This enables tracing without filtering, and redirects the output of each execution into a different file.
-
-The following are examples of settings:
-
-### Enable or Disable BPF Tracing Altogether
-For example:
-```
-enable = true
-```
-
-### Filter BPF Tracing of a Certain Program
-For example:
-```
-filter = evm_loader:3CMCRJieHS3sWWeovyFyH4iRyX4rHf3u2zbC5RCFrRex
-```
-The first part of the `filter` setting is an arbitrary string to be included in the trace file name. The second part is a program ID of interest. An empty `filter` setting passes any program.
-
-> Irrelevant information in the `filter` blocks any tracing.
-
-### Redirect BPF Tracing into a File
-For example:
-```
-output = /tmp/trace
-```
-An empty `output` setting means the tracing will be dumped to the standard output.
-
-### Force Writing Binary Files
-For example:
-```
-binary = true
-```
-Skips disassembling and formatting traces on write; write the raw binary data.
-
-### Separate BPF Traces of Different Runs
-For example:
-```
-multuple_files = true
-```
-
-Each new BPF trace will be written into a separate file. The names of these files will contain timestamps. Otherwise, the `multiple_files` setting causes all new traces to be added to a single file (if a `trace-file` is present).
-
-### Limit Writing Threads
-For example:
-```
-max_threads = 2
-```
-Allows you to run no more than two writing streams at the same time. If `multuple_files = false`, setting `max_threads` has no effect.
-
-### Limit Program Trace Length
-For example:
-```
-min_length = 1000000
-```
-Filters out too short (so less interesting) traces.
-
-### The Control Tool: solana-bpf-trace-control
-There is a special tool for viewing (a command without arguments) or changing (a command with arguments) settings. It can be found in the [temporary repo](https://github.com/vakond/solana-bpf-trace-control). Below are some usage examples of the tool.
-```
-solana-bpf-trace-control
-```
-Without arguments the current configuration is shown.
-
-```
-solana-bpf-trace-control enable
-```
-
-```
-solana-bpf-trace-control enable false
-```
-
-```
-solana-bpf-trace-control filter 'evm_loader:3CMCRJieHS3sWWeovyFyH4iRyX4rHf3u2zbC5RCFrRex'
-```
-
-```
-solana-bpf-trace-control trace-file ''
-```
-
-```
-solana-bpf-trace-control multiple-files false
-```
-
-> To clear a string setting just pass an empty quoted string as the argument.
-
-### Performance Considerations
-
-Writing a large trace file could be a substantially heavy task for the system, which can affect the overall performance. You should tweak `max-threads` and `min-length` settings to limit the number of writes. Increasing available RAM size and using SSD are also of great help.
-
-The BPF Trace Monitoring service of the local cluster starts the OS thread and binds the socket. To minimize possible performance impact the service will actually start only after the first BPF execution. At the first execution, the default settings will be taken into account. You should run a small program like `memo` or `token` first to make sure the controlling service is up and running.
diff --git a/docs/contributing/maintain_docs.md b/docs/contributing/maintain_docs.md
deleted file mode 100644
index f1e4faa2..00000000
--- a/docs/contributing/maintain_docs.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Maintaining Docs
----
-
-## Summary of Neon EVM Documentation
-This documentation is an open-source community effort, so feel free to suggest new topics or add new content wherever you think it might be helpful. All documentation is available for editing via GitHub.
-
-# How to Maintain Docs
-
-In this section, you will learn about making changes to the Neon documentation.
-
-## Before You Begin
- * Understand the following:
- * What is [Docusaurus](https://docusaurus.io/docs)
- * What is [Markdown](https://www.markdownguide.org/basic-syntax/)
- * Make sure [node.js](https://nodejs.org/en/download/) is installed on the device you are using (desktop or remote server). Version 12.13.0 or higher is recommended (which can be checked by running `node -v`)
-
-
-## Steps
-
-#### Step 1
-Create a workspace on your device by downloading the docs repository:
-
-```sh
-$ git clone https://github.com/neonlabsorg/neon-evm.docs/
-
-```
-
-It is strongly recommended to use a local branch for work. Let it be `` branch.
-
-```sh
-$ cd
-$ git branch
-$ git checkout
-```
-
-#### Step 2
-
-Make the necessary changes in the docs content. The sections with the source files are located in `/docs`.
-
-> If you make changes to the structure of the documentation (adding, deleteting, moving a file or section), you also have to fix the file `/sidebars.js`.
-
-#### Step 3
-
-It is strongly recommended to test your build locally before pushing changes to the main repository and deploying to production.
-
-Generate content with your changes (you can use `npm`, `npx`, `yarn`).
-```sh
-$ npm run build
-```
-The html files will be generated within the `/build` directory. Control content will be deployed locally at http://localhost:3000/. You can serve your built website locally.
-
-```sh
-$ npm run serve
-```
-
-#### Step 4
-
-After making all the necessary changes to the content, you can push it to your remote repository.
-
-```sh
-$ git status
-$ git commit -m "any comment"
-$ git push origin
-```
-
-Before making changes to the [main](https://github.com/neonlabsorg/neon-evm.docs/) remote repository, you need to create a "pull request" and get approvals from third parties by following the standard procedures.
-
-> The contents of the `/build` directory are not pushed to the remote repository.
-
-#### Step 5
-
-To simplify the deployment to production, you should use a script that will automatically run after making changes to the master branch.
-This script should perform the following operations:
- * Automatically building html files after making changes to https://github.com/neonlabsorg/neon-evm.docs/
- * Pushing the built html files to the html-repository https://github.com/neonlabsorg/neonlabsorg.github.io
- * Deploying the built html files to the website https://docs.neon-labs.org/
-
-Unfortunately, at the moment, this script is under development, and therefore you need to perform further actions in manual mode.
-
-To do this, you need to:
- * Clone the [html-repository](https://github.com/neonlabsorg/neonlabsorg.github.io) to your device and create ``
- * Write the html files taken from `/build` into ``
- * Push the `` changes to the [html-repository](https://github.com/neonlabsorg/neonlabsorg.github.io) by following the standard procedure.
-
-If all the actions are performed correctly, the changes you have made in Docs will be displayed at https://docs.neon-labs.org/.
diff --git a/docs/design_proposals/accepted/accepted_proposals.md b/docs/design_proposals/accepted/accepted_proposals.md
deleted file mode 100644
index 151c098b..00000000
--- a/docs/design_proposals/accepted/accepted_proposals.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Accepted Design Proposals
----
-
-The following design proposals have been accepted by the Neon team. They will be investigated more thoroughly before they are implemented, and may be implemented differently or not implemented at all. If implemented, the proposal will be moved to [Implemented Proposals](https://docs.neon-labs.org/docs/design_proposals/implemented/implemented_proposals), and the details will be added to the relevant sections of the documentation.
-
-
-1. [Restriction on Iterative Transactions](evm_compatibility/architectural_limitations/restriction_on_iterative_trx.md)
-1. [Unsupported Tokens in Neon EVM](evm_compatibility/architectural_limitations/erc721_tokens.md)
-1. [Precompiled Contracts that can not be used in Solana](evm_compatibility/architectural_limitations/precompiled_contracts.md)
-1. [Neon and Ethereum Gas Calculators give different Results](evm_compatibility/architectural_limitations/gas_calculator.md)
-1. [Unsupported Functions in Neon EVM](evm_compatibility/architectural_limitations/unsupported_functions.md)
-1. [Storage size limit for an account](evm_compatibility/architectural_limitations/storage_size_for_account.md)
diff --git a/docs/design_proposals/accepted_proposals.md b/docs/design_proposals/accepted_proposals.md
deleted file mode 100644
index 99b99618..00000000
--- a/docs/design_proposals/accepted_proposals.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Accepted Design Proposals
-
-The following design proposals have been accepted by the Neon team. They will be investigated more thoroughly before they are implemented, and may be implemented differently or not implemented at all. If implemented, the proposal will be moved to [Implemented Proposals](https://docs.neon-labs.org/docs/design_proposals/implemented/implemented_proposals), and the details will be added to the relevant sections of the documentation.
-
-
-1. [Restriction on Iterative Transactions](evm_compatibility/architectural_limitations/restriction_on_iterative_trx.md)
-1. [Unsupported Tokens in the Neon EVM](evm_compatibility/architectural_limitations/erc721_tokens.md)
-1. [Precompiled Contracts That Can't Be Used in Solana](evm_compatibility/architectural_limitations/precompiled_contracts.md)
-1. [Neon and Ethereum Gas Calculators Give Different Results](evm_compatibility/architectural_limitations/gas_calculator.md)
-1. [Unsupported Functions in the Neon EVM](evm_compatibility/architectural_limitations/unsupported_functions.md)
-1. [Storage Size Limit for an Account](evm_compatibility/architectural_limitations/storage_size_for_account.md)
diff --git a/docs/design_proposals/implemented_proposals.md b/docs/design_proposals/implemented_proposals.md
deleted file mode 100644
index 6ea219ea..00000000
--- a/docs/design_proposals/implemented_proposals.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Implemented Design Proposals
----
-
-The following design proposals have been accepted and implemented by the Neon team. Any design that may be changed in the future is marked on the specific proposal page. Design proposals that have been accepted but not yet implemented are located in [Accepted Proposals](accepted/accepted_proposals).
diff --git a/docs/developing/connect_rpc.md b/docs/developing/connect_rpc.md
index a39d79b6..9351d58f 100644
--- a/docs/developing/connect_rpc.md
+++ b/docs/developing/connect_rpc.md
@@ -1,57 +1,74 @@
---
title: Connect to Neon RPC
+proofedDate: 20231101
+iterationBy: na
+includedInSite: true
+approvedBy: na
+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
---
-This tutorial will give an overview of how to connect to a Neon RPC, resulting in a network confirguation where Neon is connected to a remote Neon Proxy and to remote Solana.
-
-## Connecting MetaMask to Neon EVM
-Go to [Chainlist](https://chainlist.org/) and type `Neon` in the search bar. You should see `Neon EVM Devnet` and `Neon EVM MainNet`.
-
-Select, for instance, `Neon EVM Devnet` and click `Connect Wallet`. A MetaMask pop-up window will show. Click `Next` and then `Connect`. You can now access the [Solana cluster](https://docs.solana.com/clusters) and carry out transactions.
-
-## Choosing a Remote Proxy
-Before sending a transaction to the Neon EVM, users should choose the operator that is optimal for them to perform the transaction. The operator is not chosen directly, but through the proxies they serve.
-
-A table of RPC proxies operated by Neon Labs, shown below, has the following columns:
- * `Network (Chain ID)` — the Solana network and its identifier; the network determines what RPC URL proxy can be used.
- * `Operator name` — the name of the operator providing the proxy.
- * `RPC URL` — the address for interacting with the required proxy.
-
-
-
-The proxy interacts with one EVM loader, which can be deployed in different Solana chains. This interaction allows the proxy to be used on different networks (Testnet, Devnet, Mainnet Beta).
-
-For a complete table of the RPC go to [Chainlist](https://chainlist.org/) and type `Neon` in the search bar.
-
-## Connecting Dev tools to Neon EVM
-
-To connect to a proxy using Remix, Truffle, or Hardhat, check out the following resources:
+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
+
+RPC endpoints are available on [Chainlist](https://chainlist.org/?chain=245022926&testnets=true&search=Neon+EVM).
+
+## Introduction
+
+This tutorial explains how to connect to a Neon RPC via Chainlist. You may connect an EVM-compatible wallet to a network and accept the default Proxy. Alternatively, you can manually set up your Proxy Operator.
+
+> The [Proxy Operator you choose](#choose-a-remote-proxy) is responsible for settling your Neon transactions on Solana. Chainlist will assign a default, but you can edit this later.
+
+## Connect via Chainlist
+
+To connect an EVM-compatible wallet such as MetaMask to Neon EVM:
+
+1.1 Visit [Neon's Chainlist](https://chainlist.org/?chain=245022926&testnets=true&search=Neon+EVM) page.
+
+1.2 Click "Connect Wallet"
+
+With most wallets, simply click "Approve" to connect your wallet.
+
+> Chainlist assigns their default Proxy; you can reconfigure this.
+
+## Choose a remote Proxy
+
+Before sending a transaction to the Neon EVM, users should choose the Operator that's optimal for them to perform transactions.
+
+> Selecting the RPC address an Operator provides assigns your transactions to that Operator.
+
+One Proxy may be available on different networks (i.e. Devnet and Mainnet). The Proxy interacts with one EVM loader, which can be deployed in different Solana chains.
+
+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.
+
+If your chosen Proxy Operator isn't the default provided during the wallet connection step, you will need to [connect manually](#connect-manually).
+
+## Connect manually
+
+The preceding steps demonstrate how to connect to a Solana cluster via Chainlist. Alternatively, you can connect to the Neon EVM manually or edit your choice of Proxy. While steps may differ slightly according to your EVM-compatible wallet, the principles will closely match the tutorial on connecting [manually via MetaMask](wallet/metamask_setup.md#option-b-manual-configuration).
+
+## Connect dev tools to Neon EVM
+
+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)
-* [Using Hardhat](developing/deploy_facilities/using_hardhat.md)
-Please note that, for Truffle and Hardhat, you need to configure the configuration file by setting the either the `HDWalletProvider` provider (for Truffle) or the URL and the `network_id`/`chainId` to the RPC URL (and ID) selected from the table above. This is described in detail in the relevant tutorial sections.
+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 checkout the [supported RPC API methods](/docs/evm_compatibility/json_rpc_api_methods).
-## Connecting Manually with MetaMask
-The above steps demonstrate how to connect to the Solana Devnet cluster via Chainlist. Alternatively, you can connect to the Neon EVM Devnet [manually via MetaMask](wallet/metamask_setup.md#setting-up-an-rpc-network).
diff --git a/docs/developing/contract_testing/img/neonswap-tests-1.png b/docs/developing/contract_testing/img/neonswap-tests-1.png
deleted file mode 100644
index 46b4124c..00000000
Binary files a/docs/developing/contract_testing/img/neonswap-tests-1.png and /dev/null differ
diff --git a/docs/developing/contract_testing/img/neonswap-tests-2.png b/docs/developing/contract_testing/img/neonswap-tests-2.png
deleted file mode 100644
index b84cf555..00000000
Binary files a/docs/developing/contract_testing/img/neonswap-tests-2.png and /dev/null differ
diff --git a/docs/developing/contract_testing/neonswap_tests.md b/docs/developing/contract_testing/neonswap_tests.md
deleted file mode 100644
index 564ef7db..00000000
--- a/docs/developing/contract_testing/neonswap_tests.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: Testing Contracts
----
-
-*This guide describes how to build and configure the Neon EVM to run integration tests on it.*
-
-> We want to demonstrate to Ethereum users that the NeonSwap infrastructure deployed on our Neon EVM ensures a passage of the *Uniswap-V2* integration test suite. This means Ethereum users can successfully run their applications on Neon EVM.
-
-## Prerequisites
-
-It is assumed:
-
-* You are already familiar with the document [Local Solana Cluster: Installation, Setup and Tests](clusters/solana_cluster.md).
-* Integration tests are performed on *NodeJS* (*v12* or higher), which should be installed in the system.
-* The local development *Solana* cluster should be up and active.
-
-## Prepare solana-program-library
-
-Clone the project `https://github.com/neonlabsorg/solana-program-library`. Don't forget to clone the dependent project (EVM): `git submodule update --remote --init --recursive`.
-
-## Deploy the EVM Loader
-
-Build the EVM Loader:
-```sh
-$ ./do.sh update
-$ ./do.sh build evm_loader
-```
-Directory `target/bpfel-unknown-unknown/release` should contain the resulting `evm_loader.so` file. Deploy it to the Solana cluster (which should be ready at this moment):
-```sh
-$ solana deploy evm_loader.so
-```
-
-## Prepare the Proxy
-
-Clone the project `https://github.com/neonlabsorg/proxy-model.py`.
-
-## Launch the Proxy
-
-Export the EVM Loader program id before starting the proxy (replace the example address with the actual):
-```sh
-$ export EVM_LOADER="Hqg8EZdZZdXr5so55b9zpTUz1g68haMx44sgjqNLP1cK"
-```
-Start the proxy:
-```sh
-$ python3 -m proxy --hostname 127.0.0.1 --port 9090 --enable-web-server --plugins proxy.plugin.SolanaProxyPlugin --num-workers=1
-```
-
-## Prepare the Integration Tests Suite
-
-Clone the project `https://github.com/neonlabsorg/uniswap-v2-core`. Build the tests (ignoring messages like "gyp ERR!"):
-```sh
-$ yarn install
-```
-
-## Run the Tests
-
-Now everything should be ready to run the integration tests of **Uniswap V2**:
-```sh
-$ yarn test
-```
-Individual test suites can be run with following command (replace the example test suite name with needed):
-```sh
-$ node node_modules/mocha/bin/mocha --grep "^UniswapV2Pair"
-```
-
-Results of the first test suite:
-
-
-
-
-Results of the second test suite:
-
-
-
-
-The absence of error messages indicates the successful completion of integration tests.
diff --git a/docs/developing/deploy_facilities/configure_brownie.md b/docs/developing/deploy_facilities/configure_brownie.md
deleted file mode 100644
index 9e3ae332..00000000
--- a/docs/developing/deploy_facilities/configure_brownie.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: "Configure Brownie"
----
-
-[Brownie](https://eth-brownie.readthedocs.io/en/stable/) is a Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine.
-
-With [Brownie](https://eth-brownie.readthedocs.io/en/stable/#features), you get:
-* Full support for Solidity and Vyper
-* Contract testing via pytest, including trace-based coverage evaluation
-* Property-based and stateful testing via hypothesis
-* Powerful debugging tools, including python-style tracebacks and custom error strings
-* Built-in console for quick project interaction
-* Support for ethPM packages
-
-For a tutorial on how to use Brownie to deploy on the Neon EVM, see [here](/docs/developing/deploy_facilities/using_brownie).
-
-## Prerequisites
-Before you start, make sure the following software is installed on your device:
- * [`eth-brownie`](https://eth-brownie.readthedocs.io/en/stable/install.html)
-
-Also make sure that the following is true:
- * MetaMask is installed on your device. To install MetaMask, follow [this guide](wallet/metamask_setup.md#installing-metamask).
- * MetaMask is configured for the Neon EVM.
-
-## Network Configurations
- * [Solana cluster](https://docs.solana.com/clusters) is accessed via a proxy.
- * Solana works in test mode and the proxy interacts with it through Neon EVM.
-
-## The Brownie Configuration File
-
-To deploy a contract to the Neon EVM with Brownie, some Neon-specific information must be specified in a configuration file. This configuration YAML file is called `brownie-config.yaml` and is located at the root of your project directory. Its file schema, variables, and other documentation can be found on the [official Brownie website](https://eth-brownie.readthedocs.io/en/stable/config.html). Please note that the deployer wallet address needs to have enough NEON tokens to cover the gas cost of the deployment. NEON tokens for Devnet can be obtained using the [NeonFaucet](developing/utilities/faucet.md).
-
-The following is a full example, configured for the example below, of the `brownie-config.yaml` configuration file for connecting Brownie to a devnet-proxy:
-
-```yaml
-dotenv: .env
-networks:
- default: neon-devnet
- neon-devnet:
- chainid: 245022926
- host: https://devnet.neonevm.org
- id: neon-devnet
- name: Devnet
- default_contract_owner: false
- gas_buffer: 1.1
- gas_limit: auto
- gas_price: auto
- max_fee: null
- priority_fee: null
- reverting_tx_gas_limit: false
-```
-
-## Importing a Network Separately
-
-Alternatively, it is possible to add networks to Brownie via the command line, without using the `brownie-config.yaml` configuration file. When adding a public network, Brownie requires at the very minimum `chainid`, `host`, and `id` (the network ID). To do so, create a configuration file (e.g., `network-config.yaml`) with the network information, and run
-```bash
-brownie networks import ./network-config.yaml
-```
diff --git a/docs/developing/deploy_facilities/configure_foundry.md b/docs/developing/deploy_facilities/configure_foundry.md
new file mode 100644
index 00000000..aca09fce
--- /dev/null
+++ b/docs/developing/deploy_facilities/configure_foundry.md
@@ -0,0 +1,79 @@
+---
+title: 'Configure Foundry'
+proofedDate: 20231116
+iterationBy: na
+includedInSite: true
+approvedBy: na
+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.
+
+## Introduction
+
+This page details several parameters required to configure Foundry. The Foundry framework isn't described here; find that in the [Foundry documentation](https://book.getfoundry.sh).
+
+## Prerequisites
+
+- cURL
+
+## Foundry configuration
+
+Unlike other toolkits, Foundry doesn't have a config file to hold the chain parameters, instead, parameters are passed into commands.
+
+1. The following command deploys a contract using a script:
+
+```
+forge script script/TestERC20/DeployTestERC20.s.sol:DeployTestERC20Script --broadcast --rpc-url $RPC_URL_DEVNET --legacy --skip-simulation
+```
+
+The parameters for `forge script` command include:
+
+- `--rpc-url`: RPC URL
+- `--skip-simulation`: This parameter skips the on-chain simulation which doesn't work on Neon EVM.
+- `--broadcast`: This parameter broadcasts the transaction.
+- `--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))_
+
+2. The following command deploys a contract directly without a script:
+
+```
+forge create --rpc-url $RPC_URL_DEVNET \
+--private-key $PRIVATE_KEY \
+--constructor-args "Test ERC20 Token" "TERC20" --legacy \
+src/TestERC20/TestERC20.sol:TestERC20
+```
+
+The parameters for `forge create` command include:
+
+- `--rpc-url`: RPC URL
+- `--private-key`: The private key of the transaction signer
+- `--constructor-args`: The constructor arguments to be passed to the contract that is being deployed
+- `--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))_
+
+3. The following command fetches the total supply of wNEON from Neon Mainnet contract:
+
+```
+$ cast call --rpc-url https://neon-proxy-mainnet.solana.p2p.org/ 0x202C35e517Fa803B537565c40F0a6965D7204609 "totalSupply()" --trace
+```
+
+This will output the result as:
+
+```
+Traces:
+ [327] 0x202C35e517Fa803B537565c40F0a6965D7204609::totalSupply()
+ └─ ← [Return] 0x000000000000000000000000000000000000000000007df4c0bc89d9a1ce65b6
+
+Transaction successfully executed.
+Gas used: 21391
+```
+
+The parameters for `forge create` command include:
+
+- `--rpc-url`: RPC URL
+- `--trace`: Flag used to display the stack trace of the function call
+
+:::important
+`--trace` flag is mandatory for the `cast call` command to get the result of the function call.
+:::
+
+### What next? See the [tutorial on how to use Foundry](/docs/developing/deploy_facilities/using_foundry) to deploy on Neon EVM.
diff --git a/docs/developing/deploy_facilities/configure_hardhat.md b/docs/developing/deploy_facilities/configure_hardhat.md
deleted file mode 100644
index 6cb6a381..00000000
--- a/docs/developing/deploy_facilities/configure_hardhat.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "Configure Hardhat"
----
-
-Hardhat is a development environment used to compile, deploy, test, and debug Ethereum software. It helps developers manage and automate the recurring tasks that are inherent to the process of building smart contracts and launching dApps, as well as supporting various add-on functionality and features in order to streamline this workflow.
-
-Details on how to use the Hardhat framework will not be described here. You can find all necessary information by reading the [Hardhat documentation](https://hardhat.org/getting-started/#overview).
-
-For a tutorial on how to use Hardhat to deploy on the Neon EVM, see [here](/docs/developing/deploy_facilities/using_hardhat).
-
-## Prerequisites
-Before you start, make sure the following software is installed on your device:
- * `NodeJS v8.9.4` or later
- * `Web3 v1.2.0` or later
-
-Also make sure that the following is true:
- * MetaMask is installed on your device. To install MetaMask, follow [this guide](wallet/metamask_setup.md#installing-metamask).
- * MetaMask is configured for the Neon EVM.
-
-## Network Configurations
- * [Solana cluster](https://docs.solana.com/clusters) is accessed via a proxy.
- * Solana works in test mode and the proxy interacts with it through Neon EVM.
-
-## The Hardhat Configuration File
-To deploy a contract to the Neon EVM with Hardhat, some Neon-specific information must be specified in a configuration file. This configuration file is called `hardhat.config.js` and is located at the root of your project directory. This file is a JavaScript file and can execute any code necessary to create your configuration. Its file schema, variables, and other documentation can be found on the [official Hardhat website](https://hardhat.org/hardhat-runner/docs/config). Please note that the deployer wallet address needs to have enough NEON tokens to cover the gas cost of the deployment. NEON tokens for Devnet can be obtained using the [NeonFaucet](developing/utilities/faucet.md).
-
-The following is a full example, configured for the example below, of the `hardhat.config.js` configuration file for connecting Hardhat to a devnet-proxy using the one-way library on Node.js:
-
-##### hardhat.config.js
-```js
-require("@nomiclabs/hardhat-waffle");
-
-const proxy_url = 'https://devnet.neonevm.org';
-const network_id = 245022926;
-
-// Private keys for test accounts
-// NOTE: Replace these placeholders with your own and make sure the accounts have non-zero NEON balances
-const privateKeys = [
- "0xPLACEHOLDER1",
- "0xPLACEHOLDER2"
-];
-
-module.exports = {
- solidity: "0.8.4",
- defaultNetwork: 'neonlabs',
- networks: {
- neonlabs: {
- url: proxy_url,
- accounts: privateKeys,
- network_id: network_id,
- chainId: network_id,
- allowUnlimitedContractSize: false,
- timeout: 1000000,
- isFork: true
- }
- }
-};
-```
-
-The parameters for `module.exports` include:
-* `solidity`: version of Solidity used
-* `defaultNetwork`: 'neonlabs'
-* `networks`:
- * `neonlabs`:
- * `url`: proxy URL
- * `accounts`: an array of deployer's private keys
- * `network_id`: the network's network ID
- * `chainId`: the network's chain ID
-
-Note that `proxy_url`, `network_id`, and `chainId` can be retrieved from the RPC endpoints table and/or [chainlist.org](https://chainlist.org/).
\ No newline at end of file
diff --git a/docs/developing/deploy_facilities/configure_hardhat.mdx b/docs/developing/deploy_facilities/configure_hardhat.mdx
new file mode 100644
index 00000000..7b4c8c09
--- /dev/null
+++ b/docs/developing/deploy_facilities/configure_hardhat.mdx
@@ -0,0 +1,99 @@
+---
+title: "Configure Hardhat"
+proofedDate: 20231116
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import WhatHardHat from '../../single-source-snippets/_hardhat.mdx'
+
+import ConfigHardHat from '../../single-source-snippets/_hardhat_config.mdx'
+
+
+## Introduction
+
+
+
+The Hardhat framework isn't described here; find that in the [Hardhat documentation](https://hardhat.org/getting-started/#overview).
+
+## Prerequisites
+- `NodeJS`
+
+## The Hardhat Configuration File
+
+
+
+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
+
+```js
+require("@nomicfoundation/hardhat-toolbox");
+require("dotenv").config();
+
+/** @type import('hardhat/config').HardhatUserConfig */
+module.exports = {
+ solidity: "0.8.21",
+ defaultNetwork: "neondevnet",
+ etherscan: {
+ apiKey: {
+ neonevm: "test"
+ },
+ customChains: [
+ {
+ network: "neonevm",
+ chainId: 245022926,
+ urls: {
+ apiURL: "https://devnet-api.neonscan.org/hardhat/verify",
+ browserURL: "https://devnet.neonscan.org"
+ }
+ },
+ {
+ network: "neonevm",
+ chainId: 245022934,
+ urls: {
+ apiURL: "https://api.neonscan.org/hardhat/verify",
+ browserURL: "https://neonscan.org"
+ }
+ }
+ ]
+ },
+ networks: {
+ neondevnet: {
+ url: "https://devnet.neonevm.org",
+ accounts: [process.env.PRIVATE_KEY_OWNER],
+ chainId: 245022926
+ },
+ neonmainnet: {
+ url: "https://neon-proxy-mainnet.solana.p2p.org",
+ accounts: [process.env.PRIVATE_KEY_OWNER],
+ chainId: 245022934
+ }
+ }
+};
+```
+
+The parameters for `module.exports` include:
+* `solidity`: version of Solidity used
+* `defaultNetwork`: default chain (for deploying or testing)
+* `etherscan`: settings used to verify contracts on-chain [read more here](https://hardhat.org/hardhat-runner/docs/guides/verifying)
+* `networks`: the list of the supported networks
+ * `neondevnet`:
+ * `url`: RPC URL
+ * `accounts`: an array of deployer's private keys; in the current example, PRIVATE_KEY_OWNER is stored inside .env file
+ * `chainId`: the network's chain ID
+
+Note that `url` and `chainId` can be retrieved from the RPC endpoints table and/or [Chainlist](https://chainlist.org/?search=Neon+EVM&testnets=true).
+
+## What next?
+
+See the [tutorial on how to use Hardhat to deploy to Neon EVM](/docs/developing/deploy_facilities/using_hardhat).
+
+## Gotchas
+
+:::info
+Remember, the deployer wallet address needs to have enough tokens to cover the gas cost of a deployment.
+> Get [NEON for Devnet](developing/utilities/faucet.md).
+:::
\ No newline at end of file
diff --git a/docs/developing/deploy_facilities/configure_truffle.md b/docs/developing/deploy_facilities/configure_truffle.md
index 3aaf0b9a..1b3fe5d8 100644
--- a/docs/developing/deploy_facilities/configure_truffle.md
+++ b/docs/developing/deploy_facilities/configure_truffle.md
@@ -1,5 +1,10 @@
---
title: "Configure Truffle"
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
The main goal in using Truffle is to make it easier for developers to deploy and debug contracts in Neon EVM.
@@ -67,7 +72,7 @@ module.exports = {
> **Note:** If both mnemonic and private keys are provided, the mnemonic takes precedence and is used instead.
-To connect Truffle to a proxy on `node.js`, the `eth_accounts` method from the [Ethereum JSON RPC API](https://eth.wiki/json-rpc/API) set is required. This method allows serving a list of *20* byte addresses owned by a client. Since the Neon EVM proxy does not support the `eth_accounts` method required to connect Truffle, the HDWalletProvider library is used to function as this method. The connection is configured in `truffle-config.js`.
+To connect Truffle to a proxy on `node.js`, the `eth_accounts` method from the [Ethereum JSON RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/) set is required. This method allows serving a list of *20* byte addresses owned by a client. Since the Neon EVM proxy does not support the `eth_accounts` method required to connect Truffle, the HDWalletProvider library is used to function as this method. The connection is configured in `truffle-config.js`.
The configuration file is publicly available, and therefore the `word mnemonic` and `private key` contained in the file are also publicly available. This makes it possible for the library to use this data. HDWalletProvider obtains the `word mnemonic` or `private key` from the configuration file and uses this data to sign transactions before sending them to the proxy. Due to this potential vulnerability, Truffle deployment should only be used with test wallets.
diff --git a/docs/developing/deploy_facilities/interacting_with_spl_tokens.md b/docs/developing/deploy_facilities/interacting_with_spl_tokens.md
index f6d19bc6..288e4a0c 100644
--- a/docs/developing/deploy_facilities/interacting_with_spl_tokens.md
+++ b/docs/developing/deploy_facilities/interacting_with_spl_tokens.md
@@ -1,98 +1,132 @@
---
title: ERC-20 for SPL Tokens
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comments:
+boilerPlatable: TODO we could have an item providing demo TODO see inline todos && this probably needs to become a folder with the subtopics
---
-The ERC-20 SPL wrapper contract provides access to native Solana tokens registered in the SPL token contract, through the ERC-20 interface.
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
-This allows Solana applications to interact with EVM (Solidity, Vyper, etc.) bytecode contracts. The ERC-20 SPL wrapper can also be used to transfer funds in Solana tokens using Ethereum wallets such as MetaMask.
+This page describes the ERC-20 SPL interface contract: the ERC-20 Factory Contract. This contract provides access to native Solana tokens, i.e. those registered in the SPL token contract, through the [ERC-20 standard interface](https://eips.ethereum.org/EIPS/eip-20).
-The contract is implemented in Rust as part of the Neon EVM program.
+
-Source code:
- * [Rust source code](https://github.com/neonlabsorg/neon-evm/blob/c43345d7abf7af14aa840e6b15c0fc64b084bb2c/evm_loader/program/src/precompile_contracts.rs#L106)
- * [Solidity wrapper source code](https://github.com/neonlabsorg/neon-evm/blob/develop/evm_loader/solidity/contracts/erc20_wrapper.sol)
+This allows Solana liquidity to be available to EVM bytecode contracts (Solidity, Vyper, etc.), i.e. this ERC-20 SPL interface allows Ethereum wallets such as MetaMask to transact with SPL tokens. The contract is deployed on Devnet and Mainnet:
-### Contract Interface
-```solidity
-interface IERC20 {
- function decimals() external view returns (uint8);
- function totalSupply() external view returns (uint256);
- function balanceOf(address who) external view returns (uint256);
- function allowance(address ow ERC-20 SPL-Wrapperer, address spender) external view returns (uint256);
- function transfer(address to, uint256 value) external returns (bool);
- function approve(address spender, uint256 value) external returns (bool);
- function transferFrom(address from, address to, uint256 value) external returns (bool);
+|Location|Factory Contract address|
+|:-------|:-------|
+|Devnet| 0xF6b17787154C418d5773Ea22Afc87A95CAA3e957|
+|Mainnet| 0x6B226a13F5FE3A5cC488084C08bB905533804720|
- event Transfer(address indexed from, address indexed to, uint256 value);
- event Approval(address indexed owner, address indexed spender, uint256 value);
+:::info
+To be able to use an SPL token from a Solana account balance, it must be transferred to a Neon EVM account via [NeonPass](/docs/developing/integrate/neon_transfer).
+:::
- function approveSolana(bytes32 spender, uint64 value) external returns (bool);
- event ApprovalSolana(address indexed owner, bytes32 indexed spender, uint64 value);
-}
-```
+## ERC-20 Factory Contract
-The purpose of each function in the IERC20 interface is detailed below:
- * `decimals()` — Returns the number of decimals used to get its user representation. For example, if `decimals` equals 2, a balance of 505 tokens should be displayed to a user as 5,05 (505 / 10 * 2).
+The [ERC-20-for-SPL Factory Contract](https://github.com/neonlabsorg/neon-evm/blob/4bcae0f476721e5396916c43396ec85e465f878f/evm_loader/solidity/erc20_for_spl_factory.sol) provides a method to access a list of deployed contracts on the Neon EVM and to issue and register a new ERC-20-for-SPL contract. Once registered, these contracts are then deployed to Neon EVM and are available on the system-wide registry.
- * `totalSupply()` — Returns the amount of tokens in existence.
+Depending on the method called and the arguments passed to this contract, two variants of the deployment may be created and registered:
- * `balanceOf(address account)` — Returns the amount of tokens owned by the `account`.
+### ERC-20-for-SPL
- * `allowance(address owner, address spender)` — Returns the remaining number of tokens that a `spender` will be allowed to spend on behalf of the `owner` through `transferFrom`. This is zero by default.
+The [ERC-20-for-SPL variant](https://github.com/neonlabsorg/neon-evm/blob/4bcae0f476721e5396916c43396ec85e465f878f/evm_loader/solidity/erc20_for_spl_factory.sol#L17) works with a precompiled contract within Neon EVM which can call the SPL token program. This enables you to utilize existing SPL tokens e.g. SOL or NEON, as wSOL or wNEON, respectively, via the ERC-20 interface, i.e. this contract assigns the to the token.
- * `transfer(address recipient, uint256 amount)` — Sends the specified `amount` of tokens from the caller's account balance to the `recipient's` account balance.
+:::info
+Note that before setting up the ERC-20 Factory Contract to construct an ERC-20-for-SPL, you must register the token's existing [Metaplex metadata](https://docs.metaplex.com/programs/token-metadata/overview).
+:::
- * `approve(address spender, uint256 amount)` — Sets an `amount` as the spender's allowance over the caller's tokens.
+### ERC-20-for-SPL-Mintable
- * `transferFrom(address sender, address recipient, uint256 amount)` — Transfers the `amount` of tokens from the `sender` to the `recipient`.
+The [ERC-20-for-SPL-Mintable variant](https://github.com/neonlabsorg/neon-evm/blob/4bcae0f476721e5396916c43396ec85e465f878f/evm_loader/solidity/erc20_for_spl_factory.sol#LL35C1-L35C1) has two additional methods that enable you to use the Neon EVM to mint a new SPL token and register it to the interface to be ERC-20-compatible. When the ERC-20 Factory Contract is constructed to this variant, it creates a new SPL token using Solana's Token Program and provides mint and freeze authority to the Neon account specified in the constructor.
- * `approveSolana(bytes32 spender, uint64 value)` — Allows ***Solana*** user `spender` to withdraw from the caller's account multiple times up to the `value` amount. Only one Solana `spender` can exists at the time. Translates into SPL token `Approve` instruction.
-### Restrictions
+## Contract signing
-According to the SPL token structure, an unsigned 64-bit floating point number is used to store the balance; in ERC-20, it's an unsigned 256-bit floating point number. Based on the unsigned 64-bit floating point standard, the maximum balance and transfer amount is (2^64-1)/(10^9), with 9 decimals of accuracy.
+Depending on which output you need to construct, you will sign with different accounts, as shown in the table:
-### Finding the Token Account Address
-The token account for a given wallet address is a program-derived account consisting of the following constants: the Ethereum wallet address itself, the ERC-20 contract address, and the token mint.
+| Contract | Usage | Requirements |tx signed by |
+| :-----:------------------- | ----------------------------------- | ------------------------------------------ | -------------------------------------------------------------------- |
+| ERC-20-For-Spl | Provide interface for Solana-minted token | 1\. Neon Account 2\. Existing SPL token | Signed by the Solana account private key (via linked Phantom wallet) 3\. Solana account & wallet|
+| ERC-20-ForSpl-Mintable | Mint a token on Solana & provide interface | 1\. Neon Account | Signed by the Neon account private key (via linked MetaMask wallet) |
-The account address can be derived in Rust with:
-```rust
-const ACCOUNT_SEED_VERSION: u8 = 1;
+## Restrictions
-fn token_address(owner: &H160, contract: &H160, mint: &Pubkey, neon_evm: &Pubkey) {
- let seeds: &[&[u8]] = &[&[ACCOUNT_SEED_VERSION], b"ERC20Balance", &mint.to_bytes(), contract.as_bytes(), owner.as_bytes()];
- Pubkey::find_program_address(seeds, neon_evm)
-}
-```
+According to the SPL token structure, an unsigned 64-bit floating point number is used to store the balance; in ERC-20, it's an unsigned 256-bit floating point number. Based on the unsigned 64-bit floating point standard, the maximum balance and transfer amount is (2^64-1)/(10^9), with 9 decimals of accuracy.
-### Creating the Token Account
-
-Accounts hold token balances and are created using the `ERC20CreateTokenAccount` instruction.
-
-This instruction can be created in Rust with:
-
-```rust
-fn create_token_account(funding: Pubkey, owner: H160, contract: H160, mint: Pubkey, neon_evm: Pubkey) {
- let (token_address, _) = token_address(&owner, &contract, &mint, &neon_evm);
- let (wallet_address, _) = Pubkey::find_program_address(&[&[ACCOUNT_SEED_VERSION], owner.as_bytes()], &neon_evm);
- let (contract_address, _) = Pubkey::find_program_address(&[&[ACCOUNT_SEED_VERSION], contract.as_bytes()], &neon_evm);
-
- Instruction::new_with_bincode(
- neon_evm,
- &(15_u8),
- vec![
- AccountMeta::new(funding, true),
- AccountMeta::new(token_address, false),
- AccountMeta::new_readonly(wallet_address, false),
- AccountMeta::new_readonly(contract_address, false),
- AccountMeta::new_readonly(mint, false),
- AccountMeta::new_readonly(system_program::id(), false),
- AccountMeta::new_readonly(spl_token::id(), false),
- AccountMeta::new_readonly(sysvar::rent::id(), false)
- ]
- )
-}
+## Notes on variants in outcome
+
+How you set up the ERC-20 Factory Contract will determine the contract deployed and the constructor's variables:
+
+
+
+
+```
+constructor(
+ bytes32 _tokenMint
+)
+Arguments:
+_tokenMint – address of SPL token account
+Constructor signature for Mintable token is:
+constructor(
+
+ uint8 _decimals,
+ address _mint_authority
+)
+Arguments:
+_name – string representing full name of the token
+_symbol – string representing shorten symbol of the token
+_decimals – decimals of new token
+_mint_authority – address of mint/freeze authority Neon account
```
+
+
+
+```
+constructor(
+ string memory _name,
+ string memory _symbol,
+ bytes32 _tokenMint
+)
+Arguments:
+_name – string representing full name of the token
+_symbol – string representing shorten symbol of the token
+_tokenMint – address of SPL token account
+Constructor signature for mintable token is:
+constructor(
+ string memory _name,
+ string memory _symbol,
+ uint8 _decimals,
+ address _mint_authority
+)
+Arguments:
+_name – string representing full name of the token
+_symbol – string representing shorten symbol of the token
+_decimals – decimals of new token
+_mint_authority – address of mint/freeze authority Neon account
+```
+
+
+
+## Notes on usage
+
+The ERC-20 Factory Contract is provided as a basic toolkit under the MIT (X11) license. You are invited to adapt this to your needs as required.
+
+
+
diff --git a/docs/developing/deploy_facilities/migrating_dapps.md b/docs/developing/deploy_facilities/migrating_dapps.md
deleted file mode 100644
index 2a477b55..00000000
--- a/docs/developing/deploy_facilities/migrating_dapps.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: Migrating dApps to the Neon EVM
----
-
-*The purpose of this document is to demonstrate to Ethereum users how easily their dApps can be ported to the Neon EVM. Using [Neon Swap](about/terminology.md#neonswap) as an example, we wil show you how to run dApps on [Solana](https://docs.solana.com/introduction) without any software code changes.*
-
-Every dApp includes a contract and software supporting that contract. In the Neon EVM, all dApps are deployed via Neon proxies. To deploy a dApp, it needs to send a request to a proxy, after which the proxy will automatically deploy contracts of the dApp in the Neon EVM environment. Contracts are loaded into a chain, and the software is deployed on a separate server for providing users interaction with these contracts.
-
-In this tutorial, you will learn how to port Uniswap services to the Neon EVM environment. Since we do not have native keys to Uniswap, we will use a fork of Uniswap-V2 called [NeonSwap](about/terminology.md#neonswap).
-
-Migrating dApps to the Neon EVM is done in three stages:
-
-**Stage 1** - Deploying contracts in a Neon EVM environment
-**Stage 2** - Checking if the deployed contracts work correctly
-**Stage 3** - Deploying the interface of the contracts
-
-## Stage 1. Deploying Contracts in a Neon EVM Environment
-
-Using [NeonSwap](about/terminology.md#neonswap) as an example, we can demonstrate that no changes to software serving contracts are required to port dApps. Changes are made only to those components that are necessary for its operation on he Neon EVM.
-
-The contracts are built by a typical Solidity compiler used in Ethereum. After compilation, all the necessary contracts are deployed on the Neon EVM using a [Web3](about/terminology.md#web-3) proxy. This proxy provides a standard interface that Ethereum utilities and tools can use.
-
-For example, Uniswap includes the following list of contracts that need to be deployed:
- * Governance
- * Uniswap-v2-periphery
- * Multicall
-
-### Changes for Deploying Contracts
-
-When deploying Uniswap in Neon EVM contracts, the following changes were made:
- * The timeout value was increased.
- * The number of repeated requests for transaction recipes was increased:
-```js
-// The call
- wait factoryV1.createExchange(WETHPartner.address, overrides)
-// was replaced with
- let id = await factoryV1.createExchange(WETHPartner.address, overrides) let receipt = await provider.waitForTransaction(id.hash, 3)
-```
- * Added the `deploy contracts()` method.
-
-Due to the fact that we did not have native keys to Uniswap, we had to change the addresses of the following uploaded contracts:
- * UNI_ADDRESS
- * TIMELOCK_ADDRESS
- * GOVERNANCE_ADDRESS
- * MULTICALL_ADDRESS
- * MIGRATOR_ADDRESS
- * FACTORY_ADDRESS
- * ROUTER1_ADDRESS
- * ROUTER_ADDRESS
- * V1_FACTORY_ADDRESS
- * WETH_ADDRESS
-
-## Stage 2. Check if the Deployed Contracts Work Correctly
-
-Contract health checks are performed in a real blockchain, not in a test environment, which is fully managed.
-
-Unlike the test environment, in a real working blockchain the range of test operations cannot be performed in full. For example, operations such as generating a block with a specified number of transactions are excluded. In a blockchain, all operations are real-time, and a user checking the contracts cannot influence the block generation.
-
-To test [NeonSwap](about/terminology.md#neonswap), we use the entire set of Uniswap-v2-core tests available in their repository for testing on Ethereum. The method of running these tests has been changed. Before running the tests, it is indicated that the deployment of contracts, calls to their methods, as well as testing takes place not in the test framework, but in the real blockchain.
-
-> For testing, we use an unmanaged environment. However, in Uniswap-v2-core tests (in contracts), there are sections of program code that contain environment management. In these pieces, we were able to successfully replace the environment management to expectation for a reaction from a chain. That is, where the block is to be generated, a delay is set. Then an action is performed and the reaction of the contract is evaluated; namely, whether it meets the expectation or not. At the same time, we believe that the number of blocks produced may be different.
-
-The need to adapt tests is because tests must issue correct results regardless of the run conditions.
-
-### Changes for Running the Uniswap-v2-core Test Suite
- The following changes were made to run the Uniswap-v2-core test suite in the Neon EVM:
- * Increased timeouts when expanding contracts
- * Changed ChainId
- * Replaced the rcp-request libraries, including the following: `Web3Provider` and `MockProvider` replaced with `JsonRpcProvider`
- * Changed the test using the `mineBlock()` method
- * Increased the number of re-requests in the `ethereum-waffle` library for receiving transaction receipts, including the following:
-```js
-// In the file
-uniswap-v2-core/node_modules/@ethereum-waffle/chai/dist/cjs/matchers/emit.js
-// the line
-const derivedPromise = promise.then((tx) => contract.provider.getTransactionReceipt(tx.hash) ).then((receipt) => {
-// was replaced with
-const derivedPromise = promise.then((tx) => contract.provider.waitForTransaction(tx.hash, 3) ).then((receipt) => {
-```
- * Increased the value of `gasLimit` in the `ethereum-waffle` library.
-
-## Stage 3. Deploying the Uniswap Interface
-After the addresses of the contracts have been loaded into the Neon EVM, we can start deploying the Uniswap interface. It is necessary to recall that we are using a real blockchain, and our contracts are located in this blockchain.
-
-### Changes for the NeonSwap Interface
-For the [NeonSwap](about/terminology.md#neonswap) interface to function successfully in the Neon EVM, the following were made:
- * Added a new testnet to the adapted NeonSwap interface code. The name of the new network with the new chain-ID is registered in all places where it was used:
- * Added `ChainId LOCAL` to dependent libraries and sources.
- * ChainID, url was specified in the .env file.
- * For the new network, a set of the loaded contracts was registered. In the `node_modules` directory, the addresses of contracts in the sources and dependent libraries were replaced.
-
-****
-
-> **More details**
-> A quick guide to using NeonSwap can be found in [How to Swap ERC-20 Tokens](developing/utilities/neonswap.md).
->
-> All changes we made for porting the Uniswap service to the Neon EVM can be found in the [Uniswap-v2-core Repository](https://github.com/neonlabsorg/uniswap-v2-core).
diff --git a/docs/developing/deploy_facilities/using_brownie.md b/docs/developing/deploy_facilities/using_brownie.md
deleted file mode 100644
index d13ebc0a..00000000
--- a/docs/developing/deploy_facilities/using_brownie.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Deploy with Brownie
----
-
-*This page outlines the steps for deploying and testing contracts in the Neon EVM using [Brownie](https://eth-brownie.readthedocs.io/en/stable/).*
-
-Before beginning the tutorial below, make sure that you have [Brownie](https://eth-brownie.readthedocs.io/en/stable/install.html) installed. To check, simply run in your command-line tool
-
-```bash
-$ brownie
-Brownie - Python development framework for Ethereum
-
-Usage: brownie [...] [options ]
-```
-
-## How to Use Brownie: A Tutorial
-The example this tutorial is based on is located in [this repository](https://github.com/neonlabsorg/examples/tree/main/simple-spl-erc20-brownie).
-
-By the end of this tutorial, you will deploy a contract describing an SPL token and ERC-20 version of it to the Neon Devnet.
-
-### Step 1: Cloning the Repository
-> **Note:** For more details on working with Brownie, refer to *[Brownie Quickstart](https://eth-brownie.readthedocs.io/en/stable/quickstart.html)*.
-
-Using Git, clone the example Brownie project from the remote repository and navigate to it:
-```bash
-git clone https://github.com/neonlabsorg/examples.git
-cd examples/simple-spl-erc20-brownie
-```
-
-### Step 2: Configuration
-
-[`brownie-config.yaml`](https://github.com/neonlabsorg/examples/blob/main/simple-spl-erc20-brownie/brownie-config.yaml) is Brownie's configuration file. You can learn more about how to configure Brownie [here](/docs/developing/deploy_facilities/configure_brownie).
-
-This first line in `brownie-config.yaml` means that the `.env` file, if it exists, will be loaded by Brownie.
-```bash
-dotenv: .env # top-level key
-```
-
-`.env` specifies environment variables that will be used by Brownie. Let's create this file and edit it with your favorite text editor
-```bash
-touch .env
-subl .env # or any editor of choice
-```
-
-#### Accounts
-Add your sender and recipient accounts to the `.env` file
-```bash
-export ACC1=0x......... # sender account address
-export ACC2=0x......... # recipient account address
-```
-
-#### Faucet
-Add your faucet URL to the `.env` file. This is the URL from which the contract code will request NEON tokens. You can use the [official Neon faucet URL](https://neonfaucet.org/), or your own faucet URL if you have one
-```bash
-export FAUCET_URL=https://neonfaucet.org/ # or a URL to your own faucet
-```
-
-### Step 3: Compilation and Deployment
-
-Compile the contract source files by running
-```bash
-brownie compile
-```
-
-Deploy the ERC contracts by running
-```bash
-brownie run scripts/deploy.py
-```
-
-### Step 4: Testing
-Run tests if needed
-```bash
-brownie test
-```
\ No newline at end of file
diff --git a/docs/developing/deploy_facilities/using_foundry.md b/docs/developing/deploy_facilities/using_foundry.md
new file mode 100644
index 00000000..c2574719
--- /dev/null
+++ b/docs/developing/deploy_facilities/using_foundry.md
@@ -0,0 +1,312 @@
+---
+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=`YOUR_PRIVATE_KEY`
+VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api
+```
+
+:::important
+Replace `YOUR_PRIVATE_KEY` 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.1 To deploy the project's contracts using scripts, run:
+
+```sh
+forge script script/TestERC20/DeployTestERC20.s.sol:DeployTestERC20Script --broadcast --rpc-url $RPC_URL_DEVNET --legacy --skip-simulation
+```
+
+On running this step, you should get console output similar to:
+
+```sh
+[⠢] Compiling...
+[⠒] Compiling 2 files with 0.8.21
+[⠢] Solc 0.8.21 finished in 842.35ms
+Compiler run successful!
+Script ran successfully.
+
+SKIPPING ON CHAIN SIMULATION.
+
+###
+Finding wallets for all the necessary addresses...
+##
+Sending transactions [0 - 0].
+⠁ [00:00:00] [######################################################################################################################################] 1/1 txes (0.0s)
+
+##
+Waiting for receipts.
+⠉ [00:00:04] [##################################################################################################################################] 1/1 receipts (0.0s)
+##### 245022926
+✅ [Success]Hash: 0x93b3a7f39f9bb5e6326d73b8f1c77ffe90a79390c784f1ece1ba74d6da356e31
+Contract Address: 0x853dA9a815c817866848Aff7fE43e4a74b8FF282
+Block: 278115244
+Paid: 5.7943561133217 ETH (33229200 gas * 174.37543225 gwei)
+
+==========================
+
+ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.
+Total Paid: 5.7943561133217 ETH (33229200 gas * avg 174.37543225 gwei)
+```
+
+To run the script for minting tokens, define the contract address displayed in the terminal after deploying the contract in script/TestERC20/MintTestERC20.s.sol and run:
+
+```sh
+forge script script/TestERC20/MintTestERC20.s.sol:MintTestERC20Script --broadcast --rpc-url $RPC_URL_DEVNET --legacy --skip-simulation
+```
+
+On running this step, you should get console output similar to:
+
+```sh
+[⠢] Compiling...
+No files changed, compilation skipped
+Script ran successfully.
+
+== Logs ==
+ The initial balance of the deployer account is:
+ 99000000000000
+ The new balance of the deployer account is:
+ 199000000000000
+ The initial balance of the receiver account before the transfer is:
+ 1000000000000
+ The new balance of the deployer account after the transfer is:
+ 198000000000000
+ The new balance of the receiver account after the transfer is:
+ 2000000000000
+
+SKIPPING ON CHAIN SIMULATION.
+
+###
+Finding wallets for all the necessary addresses...
+##
+Sending transactions [0 - 1].
+⠉ [00:00:01] [######################################################################################################################################] 2/2 txes (0.0s)
+
+##
+Waiting for receipts.
+⠙ [00:00:06] [##################################################################################################################################] 2/2 receipts (0.0s)
+##### 245022926
+✅ [Success]Hash: 0x2b4e080fef106d489fbb986fe517f8ce393ba593019939b2c591ec37035126fc
+Block: 278118078
+Paid: 0.0017438435201 ETH (10000 gas * 174.38435201 gwei)
+
+
+##### 245022926
+✅ [Success]Hash: 0x7975d08e3cf9413670ede44ee9cc2f5d69c0d375530948453585b5195c5ca472
+Block: 278118084
+Paid: 0.0017438435201 ETH (10000 gas * 174.38435201 gwei)
+
+==========================
+
+ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.
+Total Paid: 0.0034876870402 ETH (20000 gas * avg 174.38435201 gwei)
+```
+
+:::important
+`--skip-simulation` parameter skips the on-chain simulation which doesn't work on Neon EVM.
+
+The native token displayed above should be NEON instead of ETH and the unit should be Galan instead of gwei (It is not possible to customize the display).
+:::
+
+4.2 To deploy the project's contracts without scripts, 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
+```
+
+To mint tokens to the deployer address, run:
+
+```sh
+cast send --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY "mint(address,uint256)" 20000000000000000000 --legacy
+```
+
+On running this step, you should get console output similar to:
+
+```sh
+blockHash 0x60c530c2a73f48d9d7dea410d6a314f951e4120fa57a5472c1baf91fc50c6622
+blockNumber 252337066
+contractAddress
+cumulativeGasUsed 1527280
+effectiveGasPrice
+gasUsed 1527280
+logs [{"address":"0x5537599aa2f97dd60a66342522a465a7f2e40ff9","topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef","0x0000000000000000000000000000000000000000000000000000000000000000","0x0000000000000000000000004455e84eaa56a01676365d4f86348b311969a4f4"],"data":"0x000000000000000000000000000000000000000000000001158e460913d00000","blockHash":"0x60c530c2a73f48d9d7dea410d6a314f951e4120fa57a5472c1baf91fc50c6622","blockNumber":"0xf0a5baa","transactionHash":"0x6a0aafa041c4e27abdf55abb430c5ff9da5606af466b7beff4f4e8da3e7829ae","transactionIndex":"0x0","logIndex":"0x0","transactionLogIndex":"0x0","removed":false}]
+logsBloom 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
+root
+status 1
+transactionHash 0x6a0aafa041c4e27abdf55abb430c5ff9da5606af466b7beff4f4e8da3e7829ae
+transactionIndex 0
+type 0
+```
+
+:::important
+Replace `` and `` with your smart contract address and deployer address respectively.
+:::
+
+### Step 5: Call contract functions without publishing a transaction
+
+To perform a call on a deployed contract without publishing a transaction, you can use `cast call` command. For example, to fetch the total supply of the deployed TestERC20 token in the previous step, you can use:
+
+```sh
+$ cast call --rpc-url $RPC_URL_DEVNET 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9 "totalSupply()" --trace
+```
+
+On running this step, you should get console output similar to:
+
+```
+Traces:
+ [2326] 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9::totalSupply()
+ └─ ← [Return] 0x000000000000000000000000000000000000000000000001158e460913d00000
+
+Transaction successfully executed.
+Gas used: 23390
+```
+
+:::important
+`--trace` flag is mandatory for the `cast call` command to get the result of the function call.
+:::
+
+### Step 6: Contract verification
+
+6.1 Verify the deployment of your 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
+```
+
+6.2 Copy/paste this link in your browser, remembering to replace `contract_address` with your freshly deployed contract address:
+
+```sh
+https://neon-devnet.blockscout.com/address/
+```
diff --git a/docs/developing/deploy_facilities/using_goethereum.md b/docs/developing/deploy_facilities/using_goethereum.md
new file mode 100644
index 00000000..3c3fe348
--- /dev/null
+++ b/docs/developing/deploy_facilities/using_goethereum.md
@@ -0,0 +1,260 @@
+---
+title: Deploy with Go-ethereum
+proofedDate: 20240502
+iterationBy: na
+includedInSite: false
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+import mm_p_key from '@site/static/img/doc-images/developing/deploy_facilities/foundry-metamask.png';
+
+## Introduction
+
+Go-ethereum (Geth) is indeed the official implementation of the Ethereum protocol in Go. Its popularity stems from its robustness, performance, and active development community. Geth provides a comprehensive set of functionalities for interacting with the Ethereum blockchain, including creating and managing accounts, sending transactions, deploying and interacting with smart contracts, querying blockchain data, and more.
+
+Developers often choose Geth for Ethereum-based application development in Go due to its efficiency and the familiarity of the Go programming language. Its extensive API allows developers to build complex decentralized applications (dApps) and blockchain-based solutions easily.
+
+Overall, Geth is a powerful tool for developers building applications on the EVM based blockchains using the Go programming language.
+
+:::info
+For more details, please refer to these documentations https://goethereumbook.org/en/ and https://geth.ethereum.org/docs/developers/dapp-developer/native-bindings.
+:::
+
+## 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/)
+- NodeJS 16.x or newer
+- The latest Go version
+- [Solidity compiler](https://docs.soliditylang.org/en/latest/installing-solidity.html) **less than or equal to v0.8.24** (Neon EVM supports solidity versions less than or equal to v0.8.24)
+
+## Go installation
+
+:::important
+If your machine already has Go installed, then please proceed to the next step.
+:::
+
+1. Download the latest Go version from https://go.dev/doc/install.
+2. Create a directory `GoProjects` for your Go project development on your machine. Please run `pwd` inside `GoProjects` directory to get the full path. This will be used in Step 4 to set the $GOPATH env variable.
+3. Create 3 directories `/GoProjects/src`, `/GoProjects/pkg` and `/GoProjects/bin`.
+4. Set up the $GOPATH env variable on your machine -
+
+- Run `nano ~/.zshrc` on Mac machines.
+- Run `nano ~/.bash_profile` on Linux machines.
+- Paste the following lines -
+
+```sh
+export GOPATH=
+export PATH=$GOPATH/bin:$PATH
+```
+
+5. Save your ~/.bash_profile or ~/.zshrc file.
+
+- Run `source ~/.zshrc` on Mac machines.
+- Run `source ~/.bash_profile` on Linux machines.
+
+6. Run `echo $GOPATH` to check if the GOPATH is set correctly in the machine.
+
+## How to deploy contracts using go-ethereum
+
+This tutorial is based on the [Github example](https://github.com/neonlabsorg/go-ethereum-tutorial) and walks you through the steps of deploying the following smart contracts on Neon EVM Devnet-
+
+- Simple storage contract.
+- ERC20 token contract.
+
+### Step 1: Installation
+
+:::info
+Neon EVM doesn't support the latest JSON-RPC specifications. Therefore Neon EVM only supports go-ethereum versions **less than or equal to 1.12.2**.
+:::
+
+1.1 Navigate to the src directory of your `$GOPATH`:
+
+```sh
+cd $GOPATH/src
+```
+
+1.2 Clone the example go-ethereum project from the remote repository and navigate to it:
+
+```sh
+git clone https://github.com/neonlabsorg/go-ethereum-tutorial.git
+cd go-ethereum-tutorial
+```
+
+**Note:** All the following commands should be executed inside `go-ethereum-tutorial` folder.
+
+1.3 Install the required libraries:
+
+```sh
+npm install
+```
+
+```sh
+go install github.com/ethereum/go-ethereum/cmd/abigen@latest
+```
+
+```sh
+go mod tidy
+```
+
+### 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 Rename `.env.example` to `.env` and place your private key inside it:
+
+```sh
+PRIVATE_KEY=YOUR_PRIVATE_KEY
+NEON_RPC_DEVNET=https://devnet.neonevm.org
+NEON_RPC_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
+```
+
+:::important
+Replace `YOUR_PRIVATE_KEY` with your data.
+:::
+
+2.3 Run:
+
+```
+source .env
+```
+
+### Step 3: Generate the Go bindings for the smart contracts
+
+
+
+
+3.1 Run the following commands to generate the smart contract ABI and bytecode:
+
+```sh
+solc --abi ./contracts/Storage.sol -o build
+```
+
+```sh
+solc --bin ./contracts/Storage.sol -o build
+```
+
+3.2 Run the following command to generate the smart contract go binding inside `contractsgo` folder:
+
+```sh
+abigen --abi ./build/Storage.abi --pkg contractsgo --type Storage --out ./contractsgo/Storage.go --bin ./build/Storage.bin
+```
+
+
+
+
+
+3.1 Run the following commands to generate the smart contract ABI and bytecode:
+
+```sh
+solc --abi ./contracts/TestERC20.sol -o build
+```
+
+```sh
+solc --bin ./contracts/TestERC20.sol -o build
+```
+
+3.2 Run the following command to generate the smart contract go binding inside `contractsgo` folder:
+
+```sh
+abigen --abi ./build/TestERC20.abi --pkg contractsgo --type TestERC20 --out ./contractsgo/TestERC20.go --bin ./build/TestERC20.bin
+```
+
+
+
+
+### Step 4: Deploy and run smart contract functions
+
+
+
+
+:::important
+Go applications can only have one `main.go` file which is the entry point to execute the functions from the .go files in other packages. To run only the Storage contract, please comment out `deploy.RunTestERC20Contract()` in `main.go`.
+:::
+
+4.1 Run the following command to deploy the Storage contract, store a value in the deployed smart contract and reading the stored value from the deployed smart contract:
+
+```sh
+go run main.go
+```
+
+4.2 After successfully running this step you should get console output similar to:
+
+```
+You are now connected to Neon EVM Devnet
+The NEON balance of the account is: 310387553758242748088682
+------------------------------------------------------------------------
+Deploying Storage contract...
+The contract is deployed at address: 0x6b6Ba862e2bBc0C1305DF681d45f16a1D6F57baf
+Transaction hash: 0xf84667ce0bd5d2da4dfcf81fe9c72bdc81c207a41a3c9baa4c43e9ebb6ae1b6e
+
+You are now connected to Neon EVM Devnet
+The NEON balance of the account is: 310383249542814769793482
+------------------------------------------------------------------------
+Storing value in the Storage contract...
+Estimated gas: 25000
+Transaction hash: 0x24e5af83df1e9f1536d684c08e903d1285f1f5e484df43d4616c925bb25ec9a9
+
+You are now connected to Neon EVM Devnet
+The NEON balance of the account is: 310383247282862115123482
+------------------------------------------------------------------------
+Reading value from the Storage contract...
+Returned value: 45
+```
+
+
+
+
+
+:::important
+Go applications can only have one `main.go` file which is the entry point to execute the functions from the .go files in other packages. To run only the TestERC20 contract, please comment out `deploy.RunStorageContract()` in `main.go`.
+:::
+
+4.1 Run the following command to deploy the TestERC20 contract and transfer some TestERC20 tokens from the deployer address to a randomly created address:
+
+```sh
+go run main.go
+```
+
+4.2 After successfully running this step you should get console output similar to:
+
+```
+You are now connected to Neon EVM Devnet
+The NEON balance of the account is: 310383247282862115123482
+------------------------------------------------------------------------
+Deploying TestERC20 contract...
+The contract is deployed at address: 0x7BeE8180c4f35744C9cC811e540252ECcD8AcEb4
+Transaction hash: 0xf8af65bcb8187bcdcc8c7a5a7106f242c941d6506201497f31f46099d891bcc6
+
+You are now connected to Neon EVM Devnet
+The NEON balance of the account is: 310373551028315738437922
+------------------------------------------------------------------------
+Transferring TestERC20 tokens...
+Estimated gas: 1422000
+Sender balance before transfer: 1000000000000000000000
+Receiver balance before transfer: 0
+Transaction hash: 0x8d2ff2a94f836b25e3ae9cc2f9b95ca73e3b3c1e4a6bf7725890eddd915029ab
+
+Sender balance after transfer: 999999999999999999990
+Receiver balance after transfer: 10
+```
+
+
+
diff --git a/docs/developing/deploy_facilities/using_hardhat.md b/docs/developing/deploy_facilities/using_hardhat.md
deleted file mode 100644
index f221f655..00000000
--- a/docs/developing/deploy_facilities/using_hardhat.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: Deploy with Hardhat
----
-
-*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://metamask.zendesk.com/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..ff432db2
--- /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 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=`YOUR_PRIVATE_KEY`
+```
+:::important
+Replace `YOUR_PRIVATE_KEY` 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 output 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 `CONTRACT_ADDRESS`
+```
+
+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 `CONTRACT_ADDRESS` with your smart contract address.
+:::
diff --git a/docs/developing/deploy_facilities/using_remix.md b/docs/developing/deploy_facilities/using_remix.md
index bbd62100..b946c2ea 100644
--- a/docs/developing/deploy_facilities/using_remix.md
+++ b/docs/developing/deploy_facilities/using_remix.md
@@ -1,8 +1,13 @@
---
title: Deploy with Remix
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
-*This tutorial will show you step by step how to use [Remix](about/terminology.md#remix) and [MetaMask](about/terminology.md#metamask) to create and deploy a simple smart contract on Solana. Although the instructions use Solana's [Devnet](https://docs.solana.com/clusters#devnet), they may also be applicable to Solana's [Testnet](https://docs.solana.com/clusters#testnet) or Solana's [Mainnet Beta](https://docs.solana.com/clusters#mainnet-beta).*
+*This tutorial demonstrates step by step how to use Remix and MetaMask to create and deploy a simple smart contract on Solana. Although the instructions use Solana's [Devnet](https://docs.solana.com/clusters#devnet), they may also be applicable to Solana's [Testnet](https://docs.solana.com/clusters#testnet) or Solana's [Mainnet Beta](https://docs.solana.com/clusters#mainnet-beta).*
## Requirements
Before you start, make sure that the following is true:
diff --git a/docs/developing/deploy_facilities/using_truffle.md b/docs/developing/deploy_facilities/using_truffle.md
index 77c1bbcf..fa1e7daf 100644
--- a/docs/developing/deploy_facilities/using_truffle.md
+++ b/docs/developing/deploy_facilities/using_truffle.md
@@ -1,5 +1,10 @@
---
title: Deploy with Truffle
+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 Truffle tool. Truffle can be useful for those involved in the development and maintenance of the Neon EVM.*
@@ -140,6 +145,6 @@ Summary
```
### Step 6: Connect Project to MetaMask
-To import your project as an asset in MetaMask, follow the instructions [here](https://metamask.zendesk.com/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.
+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/dev_environment/faucet_and_test_suite_services.md b/docs/developing/dev_environment/faucet_and_test_suite_services.md
deleted file mode 100644
index 69a8608c..00000000
--- a/docs/developing/dev_environment/faucet_and_test_suite_services.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: (Optional) Setting up Faucet and Full Test Suite Services
----
-
-*This **optional** step-by-step guide describes how to set up faucet and full test suite services. It assumes that a proxy and a connection to a Solana cluster have already been established, either locally or remotely.*
-
-## Faucet Service
-The Faucet service provides liquidity to all the accounts that are mentioned in the incoming requests.
-
-#### docker-compose.yml
-
- version: "3"
-
- services:
-
- faucet:
- container_name: faucet
- image: neonlabsorg/faucet:latest
- environment:
- - FAUCET_RPC_BIND=0.0.0.0
- - FAUCET_RPC_PORT=3333
- - SOLANA_URL=http://solana:8899
- - NEON_ETH_MAX_AMOUNT=50000
- - EVM_LOADER=53DfF883gyixYNXnM7s5xhdeyV8mVk9T4i2hGV9vG9io
- - FAUCET_RPC_ALLOWED_ORIGINS=["https://neonswap.live"]
- - FAUCET_WEB3_ENABLE=false
- - FAUCET_SOLANA_ENABLE=true
- - NEON_OPERATOR_KEYFILE=/opt/faucet/id.json
- - SOLANA_COMMITMENT=confirmed
- entrypoint: /opt/faucet/faucet --config /opt/proxy/faucet.conf run
- ports:
- - 3333:3333
- expose:
- - "3333"
- networks:
- - net
-
- networks:
- net:
- external: yes
- # name: local
-
-Save the above content in faucet/docker-compose.yml.
-
-##### How to Run it in Bash
-```bash
-docker-compose -f faucet/docker-compose.yml up -d --quiet-pull
-```
-The output should look like this:
-```console
-Creating faucet ... done
-```
-
-## Full Test Suite Service
-
-The full test suite, generally speaking, provides the [OpenZeppelin tests](https://docs.openzeppelin.com/learn/writing-automated-tests) to make sure the infrastructure deployed by this guide works properly. At the end, the `full test suite` outputs the result in the following form:
-```console
- Full test passing - 1743
- Full test threshold - 1700
- Check if 1743 is greater or equal 1700
-```
-#### full_test_suite/docker-compose.yml
-
- version: "3"
-
- services:
-
- full_test_suite:
- container_name: ${FTS_CONTAINER_NAME:-full_test_suite}
- image: ${FTS_IMAGE:-neonlabsorg/full_test_suite:develop}
- entrypoint: ./run-full-test-suite.sh 2>/dev/null
- environment:
- - NETWORK_NAME=${NETWORK_NAME}
- - PROXY_URL=${PROXY_URL}
- - NETWORK_ID=${NETWORK_ID}
- - REQUEST_AMOUNT=${REQUEST_AMOUNT}
- - FAUCET_URL=${FAUCET_URL}
- - USE_FAUCET=${USE_FAUCET}
- - SOLANA_URL=${SOLANA_URL}
- - FTS_USERS_NUMBER=${FTS_USERS_NUMBER}
- - FTS_JOBS_NUMBER=${FTS_JOBS_NUMBER}
-
- networks:
- - net
-
- networks:
- net:
- external: yes
- # name: local
-
-#### full_test_suite/local.env
-
- NETWORK_NAME=local
- PROXY_URL=http://proxy:9090/solana
- NETWORK_ID=111
- REQUEST_AMOUNT=20000
- FAUCET_URL=http://faucet:3333/request_neon
- USE_FAUCET=true
- SOLANA_URL=http://solana:8899
- FTS_USERS_NUMBER=15
- FTS_JOBS_NUMBER=8
-
-#### How to Run it in Bash
-```bash
-docker-compose -f full_test_suite/docker-compose.yml --env-file full_test_suite/local.env up
-```
-The outpur should show a summary of the test results at the end.
diff --git a/docs/developing/dev_environment/local_proxy_remote_solana.md b/docs/developing/dev_environment/local_proxy_remote_solana.md
new file mode 100644
index 00000000..6ba1e2d1
--- /dev/null
+++ b/docs/developing/dev_environment/local_proxy_remote_solana.md
@@ -0,0 +1,143 @@
+---
+title: "Local Proxy to Remote Solana"
+proofedDate: 20230828
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+:::info
+The [Proxy local testing tutorial](/docs/operating/basic) describes how to perform testing with a local Proxy to a local Solana node. This option can be useful for developers who want to debug their Solidity contracts by hosting both Proxy and Solana nodes locally. This page provides a tutorial that demonstrates how to transact from a local Proxy to a public, remote Solana.
+:::
+
+
+## Prerequisites
+- [Docker](https://docs.docker.com/get-docker/); `docker-compose` v1.29 is recommended.
+- Operator keys. Test [public keys are available](https://github.com/neonlabsorg/proxy-model.py/tree/develop/proxy/operator-keypairs).
+
+
+## Network configuration
+ * The target Solana cluster is accessed via the locally-hosted Proxy.
+ * Solana [Testnet](https://docs.solana.com/clusters#testnet)/[Devnet](https://docs.solana.com/clusters#devnet)/[Mainnet](https://docs.solana.com/clusters#mainnet-beta) is used, and the Proxy interacts with it through Neon EVM.
+
+## Set up a local Proxy
+First, set up and host a Proxy locally as per the following steps. After executing these commands, the Proxy is available at `http://localhost:9090/solana`. This address and port are set by default.
+
+### Step 1: Docker
+Docker images themselves are never "started" and never "running". The `docker run` command takes the Docker image as a template and produces a container from it. Before starting your Proxy container, you need to start service containers.
+
+Make sure that you have a daemon running by executing the following command:
+```bash
+docker info
+```
+
+:::tip
+If you see something like this:
+```console
+Can't connect to the Docker daemon at . Is the docker daemon running?
+```
+run the daemon first:
+```bash
+sudo systemctl start docker
+```
+:::
+
+### Step 2: Run the Database, Indexer, and Proxy services
+In this step, you will create the services necessary for the function of the Proxy (including Database and Indexer services), as well as the Proxy service itself. These services, whose functions follow, are controlled by a docker-compose.yml file.
+
+#### Database Services
+This container aims to handle the database that stores all the relevant Ethereum processing metadata linked to each other: **`transactions`**, **`blocks`**, **`receipts`**, **`accounts`**, etc. This data is consumed by the **Indexer** service.
+
+Currently, Neon EVM proxies are hard coded to work with PostgreSQL. To connect the Proxy to a database, you need to start a PostgreSQL container. The default settings are hard coded in the following docker-compose.yml file. If you want to use your Proxy with other settings, you need to register as an Operator so that Neon EVM can recognize your keys.
+
+> Only authorized Operators can change the settings of these parameters. Learn more about [operating a Neon Proxy](/docs/operating/operator-introduction.md)
+
+#### Indexer service
+The Indexer service indexes all the relevant Ethereum processing metadata consisting of **`signatures`**, **`transactions`**, **`blocks`**, **`receipts`**, **`accounts`**, etc. It gathers all this data from the Solana blockchain, filtering them by the EVM contract address. It enables us to provide our users with the Ethereum API.
+
+#### Proxy service
+The Proxy service is a core service that allows Ethereum-like transactions to be processed on Solana, taking full advantage of Solana-native functionality, including the ability to execute transactions in parallel.
+
+The Neon EVM address is registered inside `neonlabsorg/proxy`, so the Proxy knows which Neon EVM is running in the Solana cluster. After executing this command, the Proxy will be available at `http://localhost:9090/solana`. This address and port are set by default.
+
+#### Create and run services with Docker Compose
+In order to create and run these services:
+
+1. Create a file `id.json` for storing an Operator key.
+ Put Solana private key to the `id.json`.
+
+2. Set the following environment variables
+ - `EVM_LOADER`, i.e. the contract address for Neon EVM
+ - For Devnet/Testnet, use: `eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU`
+ - For Mainnet, use: `NeonVMyRX5GbCrsAHnUwx1nYYoJAtskU1bWUo6JGNyG`
+ - `SOLANA_URL`
+ - Refer to the [RPC Endpoints table](#rpc-endpoints)
+ - `VERSION` - neon proxy revision
+ - `SOLANA_KEY_FOR_EVM_CONFIG` - operator key, should be a valid solana public key with SOLs on it
+
+Example for devnet configuration:
+```bash
+export EVM_LOADER=eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU
+export VERSION=v1.13.20
+export SOLANA_URL=
+export SOLANA_KEY_FOR_EVM_CONFIG=
+```
+Please note that public Solana nodes have [rate limits](https://solana.com/docs/core/clusters) and they may not work with the local Neon Proxy.
+If you want to host the local instance on your end you need a Solana node with no rate limits. You can set up your own node or just request one from a provider like P2P, Everstake or QuickNode.
+
+3. Download the files needed to run services:
+```bash
+# docker-compose file
+wget https://raw.githubusercontent.com/neonlabsorg/neon-proxy.py/develop/docker-compose/docker-compose-ro.yml
+
+# directory to store the data in case you want to rerun indexer service
+mkdir indexer_db
+
+# db scheme
+mkdir db
+cd db
+wget https://raw.githubusercontent.com/neonlabsorg/neon-proxy.py/develop/db/scheme.sql
+cd ..
+```
+
+4. Start the local environment.
+```bash
+docker-compose -f docker-compose-ro.yml up -d
+```
+
+5. Check the local environment.
+You can ensure that start is succesful by service statuses:
+```console
+dbcreation - Exited
+indexer - Up
+postgres, proxy - Up (healthy)
+```
+If proxy works, the request
+```bash
+curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"eth_blockNumber","id":1}' http://127.0.0.1:9090/solana
+```
+will return current block as in the example:
+```JSON
+{"jsonrpc":"2.0","id":1,"result":"0x12b23ae0"}
+```
+
+6. Destroy the local environment.
+If you want to destroy the local environment, run the following command:
+```bash
+docker-compose down
+```
+
+## Connect to a Solana cluster RPC endpoint
+
+**RPC endpoints**
+
+To use a Solana RPC endpoint, you need to specify the variable `-e SOLANA_URL='http://'` on the command line.
+
+When a Proxy is deployed, it generates a wallet containing a key pair. If you don't need the new wallet and want to use the keys you already have, you need to specify the path to your wallet on the command line.
+
+**Command Line Options**
+ * `~/.config/solana/id.json` — absolute path to your key pair file stored locally
+ * `--name proxy` — specifies the Proxy name
+
+
diff --git a/docs/developing/dev_environment/local_solana.md b/docs/developing/dev_environment/local_solana.md
deleted file mode 100644
index 27be8643..00000000
--- a/docs/developing/dev_environment/local_solana.md
+++ /dev/null
@@ -1,245 +0,0 @@
----
-title: Setting up a Local Solana Cluster
----
-
-*This step-by-step guide describes how to install, configure, and test the local Solana cluster with Neon EVM onboard. It will help new developers create their own environment and run Ethereum programs wrapped into the Neon EVM.*
-
-The [Neon EVM](https://neon-labs.org/) is a solution that performs transaction execution outside layer 1. The development process can be run on any modern Linux or Mac system, though this document is based on an Ubuntu 20.04 experience.
-
-All the services in the **`Neon EVM environment`** presented by the docker-compose configuration files can be interchangeably substituted with their experimental versions in order to develop and test each service independently. To resolve issues, the Neon engineer has to be able to replace any service with a customized one according to the current requirements. You are welcome to change the following `docker-compose` configuration files based on your needs. You can also combine them in a single docker-compose file, though it is important to provide dependencies according to the following sequence.
-
-Before you start to build your local environment, make sure you have all the [prerequisites](#prerequisites).
-
-## Prerequisites
-
-- **Docker** — for docker installation, please follow instructions at: https://docs.docker.com/engine/install/ubuntu/
-- **Docker Compose** — Docker Compose is required to start up containers at: https://docs.docker.com/compose/install/
-- **Solana Tool Suite** — for interaction with Solana, we need to install Solana CLI Tools: https://docs.solana.com/ru/cli/install-solana-cli-tools
-- A Chromium-based **browser** — for [MetaMask](https://metamask.io/) and [Remix](https://remix.ethereum.org/)
-* **Node package manager** — [Node.js/npm](https://www.w3schools.com/nodejs/nodejs_npm.asp) to interact with he Neon EVM with [Web3](https://www.npmjs.com/package/web3) and [Eth](https://www.npmjs.com/package/web3-eth) modules.
-
-## Setting up the Neon Local Workspace Environment
-
-Currently, the most flexible way to setup the environment is to use the set of independent docker containers sharing the common external network. To create the network called **`local`** that will be used over the docker containers, just input the following command:
-
-```bash
-docker network create local
-```
-
-If you want to bind some ports from the service to the host machine to be able to connect them and work with a service independently, just extend a `docker-compose.yml` configuration with the `ports` instruction. For example, you can bind the Solana (8899, 8900)- or Proxy (9090)-related ports to the host machine this way.
-
-After setting up the local network, it is time to start the Solana validator service and EVM loader service containers.
-
-### Step 1: Solana Validator Service
-
-This service presents the Solana validator running inside the container.
-
-Once you deploy the environment, you will have the Solana RPC endpoint working from the docker container at port `8899`. A folder named `solana_state` will be created also and it contains the Solana ledger to keep the state over restarts. If you need to reset the ledger, just remove this folder and it will be recreated the next time you run `docker-compose`.
-
-#### docker-compose.yml
-
- version: "3"
-
- services:
- solana:
- container_name: solana
- image: neonlabsorg/solana:${SOLANA_REVISION:-v1.9.12-testnet}
- environment:
- SOLANA_URL: http://solana:8899
- RUST_LOG: solana_runtime::system_instruction_processor=trace,solana_runtime::message_processor=debug,solana_bpf_loader=debug,solana_rbpf=debug
- expose:
- - 8899
- - 8900
- networks:
- - net
- healthcheck:
- test: [ CMD-SHELL, "solana cluster-version -u http://solana:8899" ]
- interval: 5s
- timeout: 10s
- retries: 10
- start_period: 10s
- volumes:
- - "./solana_state:/opt/solana/config/"
-
- networks:
- net:
- external: yes
- name: local
-
-#### How to Run it in Bash
-
- docker-compose -f solana/docker-compose.yml pull
- docker-compose -f solana/docker-compose.yml up -d
-
-### Step 2: EVM Loader Service
-
-This container helps deploy onto Solana the Neon EVM base contract, which listens for incoming connections on the port `8899`. It is important to note that this container does **not** work as a daemon, it simply uploads the Neon EVM contract and finishes with a return code of `0`.
-
-#### docker-compose.yml
-
- version: "3"
-
- services:
- evm_loader:
- container_name: evm_loader
- image: neonlabsorg/evm_loader:latest
- environment:
- - SOLANA_URL=http://solana:8899
- networks:
- - net
- command: bash -c "create-test-accounts.sh 1 && deploy-evm.sh && /opt/spl-token create-account HPsV9Deocecw3GeZv1FkAPNCBRfuVyfw9MMwjwRe1xaU && /opt/spl-token mint HPsV9Deocecw3GeZv1FkAPNCBRfuVyfw9MMwjwRe1xaU 1000000000 --owner /opt/evm_loader-keypair.json -- HX14J4Pp9CgSbWP13Dtpm8VLJpNxMYffLtRCRGsx7Edv"
-
- networks:
- net:
- external: yes
- name: local
-
-#### How to Run it in Bash
-
- docker-compose -f evm-loader/docker-compose.yml pull
- docker-compose -f evm-loader/docker-compose.yml up
-
-## Logs
-
-After following the previous steps, you will have four running containers for the Neon EVM local environment: **`solana`**, **`postgres`**, **`proxy`**, **`indexer`**:
-
-```
-49c864f47ccd neonlabsorg/solana:v1.9.12-testnet "./run.sh" About an hour ago Up About an hour (healthy) 8003/udp, 0.0.0.0:8899-8900->8899-8900/tcp, :::8899-8900->8899-8900/tcp, 9900/tcp solana
-92f6b4492894 neonlabsorg/proxy:latest "./proxy/run-proxy.sh" 46 hours ago Up About an hour 0.0.0.0:9090->9090/tcp, :::9090->9090/tcp proxy
-932d4d860629 neonlabsorg/proxy:latest "proxy/run-indexer.sh" 46 hours ago Up About an hour 9090/tcp indexer
-5a7df37069fc postgres:14.0 "docker-entrypoint.s…" 47 hours ago Up About an hour (healthy) 127.0.0.1:5432->5432/tcp postgres
-```
-
-To look for events or errors, just run the `docker logs` for either the `solana` or `proxy` container:
-
-```sh
-docker logs -f solana 2>&1 | grep -v "Program Vote111111111111111111111111111111111111111"
-docker logs -f proxy
-```
-
-## Remix and MetaMask with the Neon EVM
-
-Set up the "MetaMask" Chromium extension to connect to the proxy via Custom RPC at `http://localhost:9090/solana`. The following image describes how to set up the local Solana connection:
-
-
-
-
-
-
-
-Note: Once you create or import a new account in MetaMask, some NEON tokens will be airdropped into it.
-
-Open Remix (also in Chromium) and select `Injected Web3` environment. You can deploy EVM-wrapped smart contracts on Solana and input these instructions:
-
-
-
-
-
-
-
-## Truffle Suite with Neon EVM
-
-Truffle is a popular platform to deploy and test Solidity programs. This section shows you how to check the compatibility of the Neon EVM and the Truffle suite.
-
-In the new terminal, create a Truffle project and deploy contracts into the EVM:
-
-```sh
-sudo npm install -g truffle
-mkdir myproject && cd myproject
-truffle init
-npm install web3 @truffle/hdwallet-provider
-```
-
-### Common Truffle Settings
-
-Put your `truffle-config.js` into the Truffle root:
-
-```sh
-echo 'const Web3 = require("web3");
-
-const Web3eth = require("web3-eth");
-const HDWalletProvider = require("@truffle/hdwallet-provider");
-
-const web3eth = new Web3eth();
-const accs = Array.from(Array(10), (_, x) => web3eth.accounts.create());
-const privateKeys = accs.map((account) => account.privateKey);
-
-module.exports = {
- networks: {
- solana: {
- provider: new HDWalletProvider(privateKeys, "http://127.0.0.1:9090/solana"),
- from: accs[0].publicKey,
- network_id: "111",
- }
- },
-
- compilers: {
- solc: {
- version: "0.8.9"
- }
- }
-};' > truffle-config.js
-```
-
-### Contract Creation
-
-Create a trivial contract at `contracts/Storage.sol`:
-
-```sh
-echo '// SPDX-License-Identifier: GPL-3.0
-
-pragma solidity >=0.7.0 <0.9.0;
-
-contract Storage {
- uint256 number;
-
- function put(uint256 num) public {
- number = num;
- }
-
- function get() public view returns (uint256) {
- return number;
- }
-}' > contracts/Storage.sol
-```
-
-### Testing
-
-You can now start testing `Storage` invocations with Truffley:
-
-```sh
-echo 'const Storage = artifacts.require("Storage");
-
-contract("Storage", (accounts) => {
- let storage;
-
- beforeEach(async () => {
- storage = await Storage.new();
- });
-
- it("should store a value", async () => {
- const setResult = await storage.put(248);
- assert.equal(setResult.receipt.status, true);
- const value = await storage.get();
- assert.equal(value, 248);
- })
-})' > test/Storage.test.js
-
-truffle test test/Storage.test.js --network solana
-```
-
-### Possible Problems
-
-If, for some reason, you remove the Solana container and run it again, then all related accounts stored in foreign systems become invalid from that moment on. To avoid this, re-run the proxy container and reset the state of MetaMask and Truffle as well, to make all relations consistent.
-
-To reset the MetaMask state, follow the steps at `Settings`, `Advanced`, `Reset Account`.
-
-The Truffle state can be reset by redeploying it in the following way:
-
-```sh
-truffle compile --network solana --reset
-```
-
----
-
-*Deploy your Solidity programs on the [Solana](https://solana.com)-driven [Neon EVM](https://neon-labs.org/)*.
diff --git a/docs/developing/dev_environment/op1_remote_proxy_remote_solana.md b/docs/developing/dev_environment/op1_remote_proxy_remote_solana.md
deleted file mode 100644
index 9561a972..00000000
--- a/docs/developing/dev_environment/op1_remote_proxy_remote_solana.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: "Option 1: Remote Proxy to Remote Solana"
----
-
-## Prerequisites
-
-[MetaMask wallet](https://metamask.io/) must be already installed on your device.
-
-> Although this tutorial uses the *Ubuntu* operating system, these instructions can be applied to other UNIX distros as well.
-
-## Network Configuration
-At the end of this section, your network configuration should permit the following:
- * The [Solana cluster](https://docs.solana.com/cluster/overview) being accessible via a proxy hosted on a remote virtual server.
- * Solana working in test mode (recommended) and the proxy interacting with it through the Neon EVM.
-
-### Choosing a Remote Proxy
-Before sending a transaction to the Neon EVM, users should choose the operator that is optimal for them to perform the transaction. The operator is not chosen directly, but through the proxies they serve.
-
-The Neon EVM provides users with a [table](clusters/neon_proxy_rpc_endpoints.md) containing the [RPC](about/terminology.md#remote-procedure-call-rpc) URLs of all available proxies, each served by a separate operator. Each URL corresponds to the operator's public key, which it uses to sign and send a transaction to the Neon EVM.
-
-The proxy interacts with one EVM loader, which can be deployed in different Solana chains. This interaction allows the proxy to be used on different networks (Testnet, Devnet, Mainnet Beta).
-
-> **Note:**
-> Currently, the table contains only a list of URLs of proxies using the [MVP](about/terminology.md#minimum-viable-product-mvp) on Mainnet. With the development of the Neon EVM, this table will be supplemented with statistical indicators evaluating the operator's service and the capabilities of their proxy. A user will choose an operator based on these indicators. Depending on the resources (proxy capabilities) provided by operators, the "gas price" will be different for each operator. Hence, the transaction cost will also be different and will depend on the RPC URL selected from this [table](clusters/neon_proxy_rpc_endpoints.md).
->
-> *For instance,* if a transaction does not require huge resources, a user can choose the URL with the lowest "gas price", that is, choose a proxy with limited resources. To perform important operations, it will make sense for the user to choose the URL with the highest "gas price", that is, to choose the operator providing the highest quality service.
->
-> The table data will be provided to users in real time.
-
-### Connecting to a Proxy
-
-To connect to a proxy using Remix/Truffle/Hardhat, follow the instructions below.
-
-#### Connecting to a Proxy Using Remix
-
-To connect to a proxy using Remix, follow the instruction [Using Remix](developing/deploy_facilities/using_remix.md).
-
-#### Connecting to a Proxy Using Truffle
-
-To connect to a proxy using Truffle or to deploy dApps using Truffle, follow the instructions [Using Truffle](developing/deploy_facilities/using_truffle.md). Please note that you need to configure the `truffle-config.js` file by setting the [`HDWalletProvider` library](developing/deploy_facilities/using_truffle.md#installation-of-the-hdwalletprovider-library) to the RPC URL selected from the [table](clusters/neon_proxy_rpc_endpoints.md).
-
-#### Connecting to a Proxy using Hardhat
-
-To connect to a proxy using Hardhat or to deploy dApps using Hardhat, follow the instructions [Using Hardhat](developing/deploy_facilities/using_hardhat.md). Please note that you need to configure the `hardhat.config.js` file by setting the URL and the `network_id`/`chainId` to the RPC URL selected from the [table](clusters/neon_proxy_rpc_endpoints.md).
-
-## Connecting MetaMask to the Neon EVM
-To connect MetaMask to the Neon EVM, follow the instructions on the [Getting Started](developing/getting_started.md#step-2-connect-metamask-to-the-neon-evm-devnet) page. The instructions on this page are mainly for connecting to the devnet, so if you want to connect to the mainnet or testnet, make sure to modify the instructions as described there.
\ No newline at end of file
diff --git a/docs/developing/dev_environment/op2_local_proxy_local_solana.md b/docs/developing/dev_environment/op2_local_proxy_local_solana.md
deleted file mode 100644
index 9a75cb08..00000000
--- a/docs/developing/dev_environment/op2_local_proxy_local_solana.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: "Local Proxy to Local Solana"
----
-
-This option will let you connect to Solana via a proxy, when **both** are hosted locally. This option can be useful for developers that want to debug their Solidity contracts by hosting a proxy and a Solana node locally.
-
-## Prerequisites
-[Docker](https://docs.docker.com/get-docker/) must be already installed on your device. `docker-compose` v1.29 is recommended.
-
-## Network Configuration
- * Both the Solana node and the proxy are hosted locally.
- * The proxy interacts with the Solana node through the Neon EVM.
-
-## Setting up Local Proxy and Local Solana Node
-
-Download the `docker-compose-test.yml` file to your currently directory using the following command:
-```bash
-wget https://raw.githubusercontent.com/neonlabsorg/proxy-model.py/master/proxy/docker-compose-test.yml
-```
-
-Execute the command:
-```bash
-sudo REVISION=stable docker-compose -f docker-compose-test.yml up -d --quiet-pull
-```
-
-The output should look like this:
-```console
-Creating solana ... done
-Creating evm_loader ... done
-Creating postgres ... done
-Creating proxy ... done
-Creating indexer ... done
-```
-As soon as the latest command is completed, the proxy will start to deploy the Neon EVM in a local Solana node. After that, the proxy and Solana will be available at the URLs `http://localhost:9090/solana` and `http://localhost:8899`, respectively. The Neon faucet will also be available at `http://localhost:3333`.
-
----
-
-> **Note:**
-> For your proxy, you can use the dedicated Neon server, or a separate server that you will need to deploy and log into.
->
-> For the Solana endpoint, you can use a separate node hosted on Devnet or Testnet.
->
-You can also use a Solana node that is not hosted on any network. In this case, you will need to configure this node and synchronize it with the Devnet or Testnet network. Then you will need to deploy the local proxy and configure it to work with this node. In addition, you will also need to connect to the EVM loader deployed within Devnet or Testnet.
diff --git a/docs/developing/dev_environment/op3_local_proxy_remote_solana.md b/docs/developing/dev_environment/op3_local_proxy_remote_solana.md
deleted file mode 100644
index 367ac056..00000000
--- a/docs/developing/dev_environment/op3_local_proxy_remote_solana.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: "Local Proxy to Remote Solana"
----
-
-## Prerequisites
-[Docker](https://docs.docker.com/get-docker/) must be already installed on your device. `docker-compose` v1.29 is recommended.
-
-## Network Configuration
- * The target Solana cluster is accessed via the locally-hosted proxy.
- * Solana [Testnet](https://docs.solana.com/clusters#testnet)/[Devnet](https://docs.solana.com/clusters#devnet)/[Mainnet](https://docs.solana.com/clusters#mainnet-beta) is used, and the proxy interacts with it through the Neon EVM.
-
-## Setting up a Local Proxy
-First, set up and host a proxy locally as per the following steps. After executing these commands, the proxy will be available at `http://localhost:9090/solana`. This address and port are set by default.
-
-### Step 1: Docker
-Docker images themselves are never "started" and never "running". The `docker run` command takes the Docker image as a template and produces a container from it. Before starting your proxy container, you need to start service containers.
-
-Make sure that you have a daemon running by executing the following command:
-```bash
-docker info
-```
-If you see something like this:
-```console
-Cannot connect to the Docker daemon at . Is the docker daemon running?
-```
-you need to run the daemon first:
-```bash
-sudo systemctl start docker
-```
-
-### Step 2: Run the Database, Indexer, and Proxy Services
-In this step, you will create the services necessary for the function of the proxy (including database and indexer services), as well as the proxy service itself. These services, the functions of which are described below, will be created from a docker-compose.yml file.
-
-#### Database Services
-This container aims to handle the database that stores all the relevant Ethereum processing metadata linked to each other: **`transactions`**, **`blocks`**, **`receipts`**, **`accounts`** etc. This data is consumed by the **Indexer** service.
-
-Currently, Neon EVM proxies are hardcoded to work with PostgreSQL. To connect the proxy to a database, you need to start a PostgreSQL container. The default settings are hardcoded in the following docker-compose.yml file. If you want to use your proxy with other settings, you need to register as an operator so that the Neon EVM can recognize your keys.
-
-> Only authorized operators can change the settings of these parameters.
-
-#### Indexer Service
-The indexer service indexes all the relevant Ethereum processing metadata consisting of **`signatures`**, **`transactions`**, **`blocks`**, **`receipts`**, **`accounts`**, etc. It gathers all this data from the Solana blockchain, filtering them by the EVM contract address. It also makes it possible to provide our users with the Ethereum API according to the data provided by the whole known operators.
-
-#### Proxy Service
-The Proxy service is a core service that allows Ethereum-like transactions to be processed on Solana, taking full advantage of Solana-native functionality, including the ability to execute transactions in parallel.
-
-The Neon EVM address is registered inside `neonlabsorg/proxy`, so the proxy knows which Neon EVM is running in the Solana cluster. After executing this command, the proxy will be available at `http://localhost:9090/solana`. This address and port are set by default.
-
-#### Create and Run Services with Docker Compose
-In order to create and run these abovementioned services,
-
-1. Create "keys" folder and put your whitelisted key into it. Note that the file with operator key should be named `id.json`.
-```bash
-mkdir keys
-mv {PATH_TO_WHITELISTED_KEYS} keys/
-```
-
-2. Set the following environment variables
- - `EVM_LOADER`
- - For devnet/testnet, it should be `eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU`
- - `SOLANA_URL`
- - Refer to the [RPC Endpoints table](#rpc-endpoints)
- - `PROXY_VERSION`
-
-For example,
-```bash
-export EVM_LOADER=eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU
-export SOLANA_URL=http://api.devnet.solana.com/
-export PROXY_VERSION=latest
-```
-
-3. Download the `docker-compose` [file](https://raw.githubusercontent.com/neonlabsorg/proxy-model.py/develop/proxy/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
-```
-
-4. Start the local environment.
-```bash
-docker-compose -f docker-compose-remote-solana.yml up -d
-```
-
-If you want to destroy the local environment, run the following command:
-```bash
-docker-compose -f docker-compose-remote-solana.yml down
-```
-
-The console output should look like this:
-```console
-Creating postgres ... done
-Creating dbcreation ... done
-Creating indexer ... done
-Creating proxy ... done
-```
-
-## Connecting to Solana Cluster RPC Endpoints
-
-A proxy connects to a public [Solana cluster RPC endpoint](https://docs.solana.com/cluster/rpc-endpoints) depending on the `SOLANA_URL` value set. The table below shows the *endpoint* value that is set automatically based on the value of the `CONFIG` flag.
-
-### RPC Endpoints
-CONFIG | RPC Endpoint
-:-|:-
-devnet | `https://api.devnet.solana.com`
-testnet | `https://api.testnet.solana.com`
-mainnet | `https://api.mainnet-beta.solana.com`
-
-To use a different endpoint, you need to specify the variable `-e SOLANA_URL='http://'` on the command line. For example, in order to use devnet, add the flag `-e SOLANA_URL='https://api.devnet.solana.com'`.
-
-When a proxy is deployed, it generates a wallet containing a key pair. If you do not need the new wallet and want to use the keys you already have, you need to specify the path to your wallet on the command line.
-
-**Command Line Options**
- * `~/.config/solana/id.json` — absolute path to your key pair file stored locally
- * `--name proxy` — specifies the proxy name
-
-If you are not registered as an operator, you can only use test public keys. A list of available public keys is accessible in the [Neon Proxy RPC Endpoints](clusters/neon_proxy_rpc_endpoints.md) section. You do not need to specify the key using the `-v` flag, since it is already hard-coded into the Devnet/Testnet containers.
diff --git a/docs/developing/dev_environment/setting_up_the_dev_environment.md b/docs/developing/dev_environment/setting_up_the_dev_environment.md
deleted file mode 100644
index 1c4c0fc0..00000000
--- a/docs/developing/dev_environment/setting_up_the_dev_environment.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Setting up the Development Environment
----
-
-As a new, aspiring Neon developer, your first step of exploring the Neon EVM framework is to set up your development environment. As mentioned in the Introduction, you need to have a [**proxy**](architecture/neon_evm_arch.md/#neon-web3-proxy-proxy), which wraps Ethereum-like transactions into Solana transactions and sends them, and a **Solana cluster**, where the resulting transactions are executed.
-
-There are several ways to do set up proxy and Solana cluster:
- * [Option 1:](developing/dev_environment/op1_remote_proxy_remote_solana.md) The proxy is hosted on a remote virtual server. Solana [Testnet](https://docs.solana.com/clusters#testnet)/[Devnet](https://docs.solana.com/clusters#devnet)/[Mainnet](https://docs.solana.com/clusters#mainnet-beta) is used.
- * [Option 2:](developing/dev_environment/op2_local_proxy_local_solana.md) The proxy is hosted locally. Solana [Testnet](https://docs.solana.com/clusters#testnet)/[Devnet](https://docs.solana.com/clusters#devnet)/[Mainnet](https://docs.solana.com/clusters#mainnet-beta) is used.
- * [Option 3:](developing/dev_environment/op3_local_proxy_remote_solana.md) Both the proxy and Solana are hosted locally. (Debug mode, which allows you to configure your node locally.)
-
-> **Note:** It is important to set up the most appropriate development environment for your purposes and use cases. Refer to the [Neon Proxy RPC Endpoints](clusters/neon_proxy_rpc_endpoints.md) section to learn more about which Neon proxy to connect to.
-
-[Testnet](https://docs.solana.com/clusters#testnet), like [Devnet](https://docs.solana.com/clusters#devnet), is an alternative cryptocurrency chain exclusively for developers. It allows developers to run their node on a test blockchain and experiment and develop without losing real currency to gas fees and other endeavors. The Mainnet, Testnet, and Devnet tokens are incompatible with each other. Testnet and Devnet tokens have no value, and developers cannot transfer Mainnet tokens to Testnet/Devnet. Conversely, Testnet/Devnet tokens cannot be transfered to Mainnet. It is recommended for developers to use the Devnet rather than the Testnet when testing their code.
\ No newline at end of file
diff --git a/docs/developing/dev_recommendations/global_variables.md b/docs/developing/dev_recommendations/global_variables.md
new file mode 100644
index 00000000..efd64836
--- /dev/null
+++ b/docs/developing/dev_recommendations/global_variables.md
@@ -0,0 +1,122 @@
+---
+title: Global Variables & Oracle Integration Optimizations
+proofedDate: 20240708
+iterationBy: AI
+includedInSite: true
+approvedBy: TBD
+comment: Formatted based on template, updated with 'important' boxes
+---
+
+## TL;DR
+
+- Global variables in Neon EVM can cause issues with transaction processing
+- Oracle price feeds from Pyth and Chainlink are particularly affected
+- Developers should follow best practices to optimize for parallel execution
+
+## Overview
+
+This document discusses global variables issues in the Neon EVM ecosystem — specifically price feeds from Oracles and transaction processing. Most of these insights were derived from root-cause analysis of specific problems protocols like LendOS and Lumen encountered after the Mainnet upgrade.
+
+## Background
+
+After a recent Mainnet upgrade, reports emerged of transaction error processing in protocols using Oracle price feeds — notably Pyth and Chainlink. For most, the underlying issue was how global variables are updated in the new optimistic transaction processing model.
+
+## The Problem of Updating Global Variables and Restarting Transactions
+
+In simple terms, the problem lies in how changes to global variables are processed during the execution of a transaction in the Neon EVM. When a contract reads in an external variable, for instance, an oracle price feed, at the beginning of its execution, the EVM would recheck if this variable changed at the beginning of each subsequent iteration. If this occurs, it is considered to start over the transaction.
+
+This is a serious issue, particularly when it comes to oracles, as their price updates are by nature quite dynamic. For instance:
+
+- Pyth oracles updates NEON/ USD price feed once a minute..
+- Chainlink price feeds on Solana are updated around 5 times/ minute..
+
+This means any transaction that relies on these frequently updating price feeds will likely reset due to a failed or stuck transaction.
+
+:::important
+Frequent updates to global variables like oracle price feeds can cause transaction restarts and performance issues in the Neon EVM.
+:::
+
+## Protocol Impact
+
+- **LendOS**: Experienced issues for both USDC and wSOL borrows, which were dependent on the Chainlink oracle.
+- **Lumen**: Faced similar problems due to heavy reliance on Chainlink oracles.
+
+## Technical Analysis
+
+### EVM Behavior
+
+The Neon EVM computes the account hashes from the other programs and is not owned directly by the Neon EVM. This means that external changes to these accounts can provoke a restart of transactions.
+
+```rust
+// From neon-evm/evm_loader/program/src/account/state.rs
+pub fn hash(&self) -> [u8; 32] {
+ let mut hasher = Sha256::new();
+ hasher.update(&self.lamports.to_le_bytes());
+ hasher.update(&self.data);
+ hasher.update(&self.owner.to_bytes());
+ hasher.update(&[self.executable as u8]);
+ hasher.update(&self.rent_epoch.to_le_bytes());
+ hasher.finalize().into()
+}
+```
+
+This hashing scheme propagates to accounts owned by other programs and results in potential problems. Directly reading from the Pyth contract, which added 20+ Solana accounts to transactions, caused choke-ups during testnet.
+
+## Oracle Integration Challenges
+
+### Pyth Oracle
+
+- Direct reading from the Pyth contract added 20+ Solana accounts on transactions, which caused blockages during testnet.
+- A caching mechanism was implemented in LendOS (PythAggregator contract) to avoid frequent price updates.
+
+### Chainlink Oracle
+
+- Frequent updates (~ 5 times/minute) result in transaction restarts in the new optimistic processing model.
+
+:::tip
+Implementing caching mechanisms for oracle data can help mitigate frequent transaction restarts.
+:::
+
+## Best Practices for Developers
+
+When working in parallel execution environments like Neon EVM, developers should adopt the following best practices to fully benefit from parallel processing:
+
+### Good Practices
+
+- **Avoid Shared Resources**: Implement practices that use shared account data very little.
+- **User-Specific Data Structures**: Implement isolating user data structures. For example, in ERC20 tokens:
+ - Use mappings: `user_address → user_metadata`. This way, the transaction for a particular user may change only its specific data without interfering with transactions of other users.
+
+### Practices to Avoid
+
+- **Global Smart Contract Variables**: When data is stored as global variables for the smart contract, it results in performance issues.
+- **Frequent Global Updates**: Updating global variables (such as price feeds) with every user transaction entails that all user transactions are queued and executed serially. This kills parallel execution.
+
+:::info
+Adopting user-specific data structures and minimizing global variables can significantly improve parallel execution performance.
+:::
+
+### Recommendations
+
+- **Minimize Global Variables**: Avoid global smart contract variables, especially for write operations.
+- **Read-Only Operations**: The above recommendations are primarily valid for write operations and are less critical for read-only operations.
+
+## Proposed Solutions
+
+1. **Disable Specific Account Type Checks**: Disable the change check for accounts of the particular type. For instance, in the case of SPL Token accounts owned by Neon EVM, turn off change checking. This may be inappropriate if Neon EVM does not own an account.
+
+2. **Selective Account Checking**: Modify the EVM to omit read-only accounts for selective checks and only check accounts the action interacts with. This can potentially avoid unnecessary restarts for read-only data like price feeds.
+
+3. **Implement a Particular Account Type**: Define a new type of NeonEVM account that can only be used for holding data, such as prices, where change checking does not make sense. This solution requires careful design and auditing.
+
+4. **Optimize Oracle Integration**:
+ - **For Pyth**: Directly read from the Solana account, potentially without a middle caching layer.
+ - **For Chainlink**: Explore optimizations on how frequently it checks against the quickly updating price feeds.
+
+5. **Refactor Existing Contracts**:
+ - Examine and modify current smart contracts to bring them into compliance with the previously mentioned best practices.
+ - When feasible, employ user-specific data structures in place of global variables.
+
+:::tip
+Implementing these solutions can help optimize transaction processing and reduce issues related to global variables in the Neon EVM ecosystem.
+:::
\ No newline at end of file
diff --git a/docs/developing/get-started.md b/docs/developing/get-started.md
new file mode 100644
index 00000000..6ab2a727
--- /dev/null
+++ b/docs/developing/get-started.md
@@ -0,0 +1,172 @@
+---
+title: Get Started on Neon EVM
+proofedDate: 20231101
+iterationBy: HB
+includedInSite: true
+approvedBy: na
+comment: todo -- link to internal Foundry tutorial once its PR is in
+---
+
+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.
+:::
+
+
+## Get test NEON for Neon Devnet
+
+To populate the accounts with test NEON, visit [the faucet](https://neonfaucet.org), where you will be issued up to 100 NEON.
+
+## Configure Neon network credentials in your framework's config file
+
+
+
+
+The network credentials are configured under the “networks” property in the `hardhat.config.js`.
+
+
+
+
+```jsx
+neondevnet: {
+ url: "https://devnet.neonevm.org",
+ accounts: [Array_of_accounts_private_keys],
+ chainId: 245022926,
+ allowUnlimitedContractSize: false,
+ gas: "auto",
+ gasPrice: "auto",
+ isFork: true,
+},
+```
+
+
+
+
+
+```jsx
+neonmainnet: {
+ url: "https://neon-proxy-mainnet.solana.p2p.org",
+ accounts: [Array_of_accounts_private_keys],
+ chainId: 245022934,
+ allowUnlimitedContractSize: false,
+ gas: "auto",
+ gasPrice: "auto",
+ isFork: true,
+},
+```
+
+
+
+
+See the [Hardhat tutorial](/docs/developing/deploy_facilities/configure_hardhat)
+
+
+
+
+
+
+
+Foundry doesn’t have a configuration file like Hardhat or Truffle to configure the network settings. Rather, the RPC endpoint and the private key are specified in the command line when passing foundry commands.
+
+See the [Foundry tutorial](https://github.com/neonlabsorg/neon-tutorials/tree/main/foundry).
+
+
+
+
+
+The network credentials can be configured under the “networks” property in the `truffle-config.js`.
+
+
+
+
+```jsx
+neondevnet: {
+ provider: () => {
+ return new HDWalletProvider(
+ [Array_of_accounts_private_keys],
+ "https://devnet.neonevm.org",
+ );
+ },
+ network_id: 245022926
+},
+```
+
+
+
+
+```jsx
+neondevnet: {
+ provider: () => {
+ return new HDWalletProvider(
+ [Array_of_accounts_private_keys],
+ "https://neon-proxy-mainnet.solana.p2p.org",
+ );
+ },
+ network_id: 245022934
+},
+```
+
+
+
+
+See the [Truffle tutorial](https://neonevm.org/docs/developing/deploy_facilities/using_truffle).
+
+
+
+
+
+
+## Verify contracts on Neon Devnet with Hardhat and NeonScan:
+
+To verify contracts on Neon Devnet with NeonScan, add this configuration to `hardhat.config.js`:
+
+```jsx
+etherscan: {
+ apiKey: {
+ neonevm: "test"
+ },
+ customChains: [
+ {
+ network: "neonevm",
+ chainId: 245022926,
+ urls: {
+ apiURL: "https://devnet-api.neonscan.org/hardhat/verify",
+ browserURL: "https://devnet.neonscan.org"
+ }
+ }
+ ]
+}
+```
+
+The command for verifying a deployed contract is:
+
+```jsx
+npx hardhat verify --network neondevnet
+```
+
+Follow this [GitHub tutorial](https://github.com/neonlabsorg/neon-tutorials/tree/main/hardhat) for Hardhat contract verification.
+
+## Gotchas
+
+### Reaching account limits
+
+You may encounter an error `The transaction requires too lot of accounts`, i.e. that the transaction has exceeded the account limit. This error refers to the fact that the transaction on Solana does not allow the number of accounts to be more than 64. If you do need more than 64 accounts, the smart contract function throwing the error needs to be optimized.
+
+### Basic optimization of smart contracts
+
+Consider applying the following optimization techniques:
+
+1. Reduce the contract binary size.
+2. Use indexed parameters for the events.
+3. Use custom errors instead of require statements whenever possible.
+4. Minimize function calls from within a function (this reduces the function call overload).
+5. Avoid using strings as storage values and, instead, use fixed-sized bytes32 whenever possible.
+6. Avoid loops through long arrays and use mappings instead of loops.
+7. Make revert and assert messages as short as possible.
+8. Write a library for all the reusable codes.
+9. Use memory locations wisely - calldata, memory, storage (order is cheapest to expensive).
+10. Variables should be declared in order so that they use fewer storage slots.
+
+Learn more about optimizations from the [EVM Compatibility Overview](/docs/evm_compatibility/overview).
diff --git a/docs/developing/getting_started.md b/docs/developing/getting_started.md
deleted file mode 100644
index 345f9f76..00000000
--- a/docs/developing/getting_started.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Getting Started
----
-
-*The purpose of this guide is to get you familiarized with the Neon EVM's high-level structure and to provide you with step-by-step instructions on how to set up your local Neon EVM development environment.*
-
-## Reference
-
-If you are already familiar with Neon, make sure to check out the following tools and tutorials that will enhance your Neon experience:
-
-* Receive free NEON test tokens with the [Neon Faucet](/docs/developing/utilities/faucet).
-* Browse Neon's blockchain transaction history with [NeonScan](https://neonscan.org/).
-* Transfer tokens to and from Neon using [NeonPass](/docs/developing/utilities/neonpass).
-* Set up a [Neon wallet](/docs/wallet/metamask_setup).
-
-For information on deploying dApps on Neon, check out the following resources:
-* [Using Remix](developing/deploy_facilities/using_remix.md)
-* [Using Hardhat](developing/deploy_facilities/using_hardhat.md)
-* [Using Truffle](developing/deploy_facilities/using_truffle.md)
-
-## Quick Start
-
-To get started quickly with Neon, follow the steps below.
-
-### Step 1: Install MetaMask
-Install MetaMask by following the setup instructions on the [Installing MetaMask](wallet/metamask_setup.md#installing-metamask) page.
-
-### Step 2: Connect MetaMask to the Neon EVM Devnet
-There are two ways to connect to the Solana [Devnet](https://docs.solana.com/clusters#devnet) cluster: using Chainlist.org or manually.
-
-#### Option A: Connect with Chainlist.org
-Go to [Chainlist](https://chainlist.org/) and type `Neon` in the search bar. You should see `Neon EVM Devnet` and `Neon EVM Mainnet`.
-
-
-
-Select `Neon EVM Devnet` and click `Connect Wallet`. A MetaMask pop-up window will show. Click `Next` and then `Connect`. You can now access the [Solana cluster](https://docs.solana.com/clusters) and carry out transactions.
-
-#### Option B: Connect Manually with MetaMask
-Alternatively, you can connect to the Neon EVM Devnet [manually via MetaMask](wallet/metamask_setup.md#option-b-manual-configuration).
-
-### Step 3: Get NEON Devnet Tokens from the NeonFaucet
-NEON tokens for Devnet can be obtained using the [NeonFaucet](developing/utilities/faucet.md).
-
-### Step 4: Deploying dApps
-
-Deploying dApps on Neon is easy and you can do so with [Remix](https://remix-project.org/), [Truffle](https://trufflesuite.com/), and [Hardhat](https://hardhat.org/).
-
-[🔘 Using Remix](developing/deploy_facilities/using_remix.md) — Example of deploying smart contracts using Remix.
-[🔘 Using Truffle](developing/deploy_facilities/using_truffle.md) — Example of deploying smart contracts using Truffle.
-[🔘 Using Hardhat](developing/deploy_facilities/using_hardhat.md) — Example of deploying smart contracts using Hardhat.
-
-## Fundamental Topics
-
-If you are new to Neon EVM development, we recommend starting from the very beginning and moving forward in order through each of the topics.
-
-[🔘 Web2 versus Web3](architecture/core_aspects/web3.md) — Describes the fundamental differences between Web2 and Web3.
-[🔘 Ethereum account](architecture/core_aspects/account.md) — An entity with an ETH balance that can send transactions on Ethereum.
-[🔘 Ethereum transaction](architecture/core_aspects/transaction.md) — A cryptographically signed instruction from an account.
-[🔘 Block](architecture/core_aspects/block.md) — A special structure for recording a group of transactions in blockchain systems.
-[🔘 Gas](architecture/core_aspects/gas.md) — Computational power represented in tokens. Required to process transactions.
-[🔘 Ethereum and Solana capabilities in a single solution](architecture/eth_sol_solution.md) — Describes a unique solution that allows Ethereum users to use the key features of Solana and vice versa.
-[🔘 Overview of Neon EVM architecture](architecture/neon_evm_arch.md) — Describes the architectural solutions built into Neon EVM that enable fast transaction processing for Ethereum users.
diff --git a/docs/developing/integrate/indexer/envio.md b/docs/developing/integrate/indexer/envio.md
new file mode 100644
index 00000000..07e1d364
--- /dev/null
+++ b/docs/developing/integrate/indexer/envio.md
@@ -0,0 +1,176 @@
+---
+title: "Envio"
+proofedDate: 20240405
+includedInSite: true
+approvedBy: na
+description: Feature-rich blockchain indexer and data infrastructure provider speed-optimized for querying real-time and historical data.
+---
+
+*This page provides an overview of Envio and a simple tutorial to get started on Neon EVM.*
+
+# Introduction
+
+[Envio](https://envio.dev/) is a feature-rich indexing solution that provides developers with a seamless and efficient way to index and aggregate real-time or historical blockchain data for any EVM. The indexed data is easily accessible through custom GraphQL queries, providing developers with the flexibility and power to retrieve specific information.
+
+Envio offers native support for Neon EVM (both devnet and mainnet) and has been designed to support high-throughput blockchain applications that rely on real-time data for their business requirements.
+
+Designed to optimize the user experience, Envio offers automatic code generation, flexible language support, quickstart templates, and a reliable cost-effective [hosted service](https://docs.envio.dev/docs/hosted-service).
+
+Indexers on Envio can be written in JavaScript, TypeScript, or ReScript.
+
+## Envio HyperSync
+
+Envio supports [HyperSync](https://docs.envio.dev/docs/hypersync) on Neon EVM mainnet.
+
+HyperSync is an accelerated data query layer for the Neon EVM blockchain, providing APIs that bypass JSON-RPC for 100x faster syncing of historical data. HyperSync is used by default in Envio's indexing framework, with the use of RPC for data retrieval being optional. Using HyperSync, application developers do not need to worry about RPC URLs, rate-limiting, or managing infrastructure - and can easily sync large datasets in a few minutes, something that would usually take hours or days using traditional indexing solutions.
+
+HyperSync is also available as a standalone API for data analytic use cases. Data analysts can interact with the HyperSync API using JavaScript, Python, or Rust clients and extract data in JSON, Arrow, or Parquet formats. For more information, visit the HyperSync documentation [here](https://docs.envio.dev/docs/overview-hypersync).
+
+
+## Key Features
+
+- Contract Import: Autogenerate the key boilerplate for an entire Indexer project off a single or multiple smart contracts. Deploy within minutes.
+
+- Multi-chain Support: Aggregate data across multiple networks into a single database. Query all your data with a unified GraphQL API.
+
+- Asynchronous Mode: Fetch data from off-chain storage such as IPFS, or contract state (e.g. smart contract view functions) to create a rich API.
+
+- Factory Contracts: Automatically process events emitted by all child contracts that are created by the specified factory.
+
+- Quickstart Templates: Use pre-defined indexing logic for popular contract standards (e.g. ERC-20).
+
+
+## Getting Started
+
+Developers can choose whether they want to start from a template (e.g. Blank, ERC-20, etc.), or use the Contract Import feature.
+
+The following files are required from the user to run the Envio indexer:
+
+- Configuration (defaults to `config.yaml`)
+- GraphQL Schema (defaults to `schema.graphql`)
+- Event Handlers (defaults to `src/EventHandlers.*` depending on the language chosen)
+
+These files are auto-generated according to the template and language chosen by running the `envio init` command.
+
+## Contract Import Tutorial
+
+This walkthrough explains how to initialize an indexer using a single or multiple contracts that are already deployed on a blockchain. This process allows a user to quickly and easily start up a basic indexer and a queryable GraphQL API for their blockchain application within a few minutes.
+
+### Initialize your indexer
+
+`cd` into the folder of your choice and run
+
+```bash
+envio init
+```
+
+Name your indexer
+
+```bash
+? Name your indexer:
+```
+
+Choose the directory where you would like to setup your project (default is the current directory)
+
+```bash
+? Set the directory: (.) .
+```
+
+Select `Contract Import` as the initialization option.
+
+```bash
+? Choose an initialization option
+ Template
+> ContractImport
+[↑↓ to move, enter to select, type to filter]
+```
+
+```bash
+? Would you like to import from a block explorer or a local abi?
+ Block Explorer
+> Local ABI
+[↑↓ to move, enter to select, type to filter]
+```
+
+Block Explorer option only requires user to input the contracts address and chain of the contract. If the contract is verified and deployed on one of the supported chains, this is the quickest setup as it will retrieve all needed contract information from a block explorer.
+
+Please note: Block explorer option currently only supports networks with etherscan. If the network doesn't have etherscan, you can proceed using the Local ABI option.
+
+Choosing `Local ABI` option will allow you to point to a JSON file containing the smart contract ABI. The `Contract Import` process will then populate the required files from the ABI.
+
+#### Specify the directory of JSON file containing ABI
+
+```bash
+? What is the path to your json abi file?
+```
+
+#### Choose which events to include in the `config.yaml` file
+
+```bash
+? Which events would you like to index?
+> [x] ClaimRewards(address indexed from, address indexed reward, uint256 amount)
+ [x] Deposit(address indexed from, uint256 indexed tokenId, uint256 amount)
+ [x] NotifyReward(address indexed from, address indexed reward, uint256 indexed epoch, uint256 amount)
+ [x] Withdraw(address indexed from, uint256 indexed tokenId, uint256 amount)
+[↑↓ to move, space to select one, → to all, ← to none, type to filter]
+```
+
+#### Specify which chain the contract is deployed on
+
+```bash
+? Choose network:
+>
+ ethereum-mainnet
+ goerli
+ optimism
+ base
+ bsc
+ neon-evm
+v polygon
+[↑↓ to move, enter to select, type to filter]
+```
+
+#### Enter in the name for the contract
+
+```bash
+? What is the name of this contract?
+```
+
+#### Enter in the address of the contract
+
+```bash
+? What is the address of the contract?
+[Use the proxy address if your abi is a proxy implementation]
+```
+
+Note if you are using a proxy contract with an implementation, the address should be for the proxy.
+
+#### Select the continuation option
+
+```bash
+? Would you like to add another contract?
+> I'm finished
+ Add a new address for same contract on same network
+ Add a new network for same contract
+ Add a new contract (with a different ABI)
+[Current contract: BribeVotingReward, on network: neon-evm]
+```
+
+The `Contract Import` process will prompt the user whether they would like to finish the import process or continue adding more addresses for same contract on same network, addresses for same contract on different network or a different contract.
+
+For more information on contract import feature, visit the documentation [here](https://docs.envio.dev/docs/contract-import).
+
+
+## Envio Indexer Examples
+
+Click [here](https://docs.envio.dev/docs/example-uniswap-v3) for Envio Indexer Examples.
+
+## Getting Help
+
+Indexing can be a rollercoaster, especially for more complex use cases. Our engineers are available to help you with your data availability needs.
+
+Join our growing community of elite builders, and find peace of mind with Envio.
+
+* [Discord](https://discord.gg/mZHNWgNCAc)
+* Email: [hello@envio.dev](mailto:hello@envio.dev)
+
diff --git a/docs/developing/integrate/indexer/flair.md b/docs/developing/integrate/indexer/flair.md
new file mode 100644
index 00000000..bcbf8a4c
--- /dev/null
+++ b/docs/developing/integrate/indexer/flair.md
@@ -0,0 +1,128 @@
+---
+title: "Flair"
+proofedDate: 20231207
+includedInSite: true
+approvedBy: na
+description: Real-time and historical custom data indexing for any evm chain.
+---
+
+
+*This page provides a tutorial covering how to leverage Flair for data collection from Neon EVM*.
+
+
+# Introduction
+
+[Flair](https://flair.dev) supports real-time and historical custom data indexing for any EVM chain via an RPC URL.
+
+Flair offers reusable indexing primitives (such as fault-tolerant RPC ingestors, custom processors, re-org aware database integrations) to simplify how you receive, transform, store, and access on-chain data.
+
+[](https://docs.flair.dev/)
+
+Learn more about [Flair's features](#flair-features)
+
+## How to integrate with Flair
+
+### Step 1: clone the repo
+
+Clone the [starter boilerplate](https://github.com/flair-sdk/starter-boilerplate) template and follow the instructions in the README.md:
+
+
+```bash
+git clone https://github.com/flair-sdk/starter-boilerplate.git
+```
+:::info
+
+The boilerplate creates a **new cluster**, generates **an API Key**, and sets up a manifest.yml to index your **first contract** with **sample custom processor** scripts.
+
+Learn more about the [structure of manifest.yml](https://docs.flair.dev/reference/manifest.yml).
+
+:::
+
+### Step 2: configure Neon RPC nodes
+
+Set a **unique** namespace, Neon `chainId` and RPC endpoint in your configuration file. Remember that you can add up to 10 RPC endpoints for resiliency.
+
+```yaml
+{
+ "cluster": "dev",
+ "namespace": "my-awesome-neon-indexing-dev",
+ "indexers": [
+ {
+ "chainId": 245022934,
+ "enabled": true,
+ "ingestionFilterGroup": "default",
+ "processingFilterGroup": "default",
+ "sources": [
+ # Highly-recommended to have at least 1 websocket endpoint
+ "wss://XXX",
+ # You can put multiple endpoints for failover
+ "https://neon-mainnet.everstake.one"
+ ]
+ }
+ ]
+}
+```
+
+:::info
+
+Ensure that you apply a **unique** namespace value. A single namespace cannot be used for more than one Flair integration.
+
+:::
+
+### Step 3: Sync
+
+3. Sync some historical data using the [backfill command](https://docs.flair.dev/reference/backfilling). Remember that the `enabled: true` flag in your `config` enables your indexer to capture data in real-time.
+
+```bash
+# backfill certain contracts or block ranges
+pnpm flair backfill --chain 245022934 --address 0x6c2908088920d01adf4e17112d013e48f333164c -d backward --max-blocks 10000
+
+# backfill for a specific block number, if you have certain events you wanna test with
+pnpm flair backfill --chain 245022934 -b 219068525
+
+# backfill for the recent data in the last X minute
+pnpm flair backfill --chain 245022934 --min-timestamp="30 mins ago" -d backward
+```
+
+### Step 4: work with your data
+
+4.1 [Query](https://docs.flair.dev/#getting-started) your custom-indexed data.
+
+4.2 Stream the data to your [own database](https://docs.flair.dev/reference/database#your-own-database).
+
+## Examples
+
+Explore real-world usage of Flair indexing primitives for various use-cases.
+
+### DeFi
+
+* [Aggregate protocol fees in USD across multiple chains](https://github.com/flair-sdk/examples/tree/main/aggregate-protocol-fees-in-usd)
+* [Calculate "Health Factor" of positions with contract factory tracking](https://github.com/flair-sdk/examples/tree/main/health-factor-with-factory-tracking)
+* [Index Uniswap v2 swaps with USD price for all addresses](https://github.com/flair-sdk/examples/tree/main/uniswap-v2-events-from-all-contracts-with-usd-price)
+
+### NFT
+
+* [Index ERC-721 and ERC-1155 NFTs on any EVM chain with an RPC URL](https://github.com/flair-sdk/examples/tree/main/erc721-and-erc1155-nft-indexing)
+
+## Flair features
+
+Flair offers:
+
+* A **parallel and distributed processing** paradigm means high scalability and resiliency for your indexing stack. Instead of constrained sequential processing (e.g Subgraph).
+* A focus on **primitives**, which means on the left, you plug-in an RPC, and on the right, you output the data to any destination database.
+* Native **real-time stream processing** for certain data workload (such as aggregations or rollups) for properties such as total volume per pool, or total portfolio per user wallet.
+* **Managed** cloud services avoid DevOps and irrelevant engineering costs for dApp developers.
+* Avoids decentralization **overhead** (consensus, network hops, etc.): simplifying data access.
+* Free managed RPC URLs for 8+ chains.
+* Works with both websocket and https-only RPCs.
+* Tracks and ingests **any contract** for **any event topic.**
+* Auto-tracks new contracts deployed from factory contracts.
+* **Custom processor scripts** with Javascript runtime (with **Typescript** support)
+* Makes external API or Webhook calls to third-party or your backend.
+* Gets current or historical USD value of any ERC20 token amount of any contract address on any chain.
+* Uses any external NPM library.
+* **Streams** stored data to your destination database (Postgres, MongoDB, MySQL, Kafka, Elasticsearch, Timescale, etc.).
+
+## Need help?
+
+[Flair engineers](https://docs.flair.dev/talk-to-an-engineer) provide product support.
\ No newline at end of file
diff --git a/docs/developing/integrate/indexer/subsquid.md b/docs/developing/integrate/indexer/subsquid.md
new file mode 100644
index 00000000..7809be63
--- /dev/null
+++ b/docs/developing/integrate/indexer/subsquid.md
@@ -0,0 +1,220 @@
+---
+title: 'Subsquid SDK Integration'
+proofedDate: N/A
+includedInSite: false
+approvedBy: na
+description: Serves historical on-chain data, including event logs, transaction receipts, traces and per-transaction state diffs.
+---
+
+_This page presents an example of how SDK packages can be combined into a working indexer (called squid) on Neon EVM Devnet. This squid example tracks transfers of WNEON on Neon EVM Devnet, then save the resulting data to PostgreSQL and serve it as a GraphQL API._
+
+# Introduction
+
+[Subsquid Network](https://docs.subsquid.io/) is a decentralized query engine optimized for batch extraction of large volumes of data. It currently serves historical on-chain data ingested from 100+ EVM and Substrate networks, including event logs, transaction receipts, traces and per-transaction state diffs.
+
+Here's an example of how SDK packages can be combined into a working indexer (called squid). This example uses [WNEON contract](https://devnet.neonscan.org/address/0x11adc2d986e334137b9ad0a0f290771f31e9517f).
+
+## Prerequisites
+
+- NodeJS 16.x or newer
+- Docker
+
+## How to run a squid on Neon EVM Devnet
+
+### Step 1: Initialize a node project
+
+Create an empty project directory and navigate to it and run:
+
+```sh
+npm init
+```
+
+### Step 2: Install dependencies
+
+```sh
+npm i @subsquid/evm-processor @subsquid/typeorm-store @subsquid/typeorm-migration @subsquid/graphql-server
+
+npm i typescript @subsquid/typeorm-codegen @subsquid/evm-typegen @@subsquid/util-internal-validation --save-dev
+```
+
+### Step 3: Add `tsconfig.json` to the project's root directory
+
+```sh
+{
+ "compilerOptions": {
+ "rootDir": "src",
+ "outDir": "lib",
+ "module": "commonjs",
+ "target": "es2020",
+ "esModuleInterop": true,
+ "skipLibCheck": true,
+ "experimentalDecorators": true,
+ "emitDecoratorMetadata": true
+ }
+}
+```
+
+### Step 4: Define the schema for both the database and the core GraphQL API in `schema.graphql` in the project's root directory
+
+```sh
+type Transfer @entity {
+ id: ID!
+ src: String! @index
+ dst: String! @index
+ wad: BigInt!
+}
+```
+
+### Step 5: Generate TypeORM classes based on the schema
+
+```sh
+npx squid-typeorm-codegen
+```
+
+The TypeORM classes will be available at `src/model/index.ts`.
+
+### Step 6: Prepare the database
+
+6.1 Create `.env` file in the project's root directory and paste the following lines -
+
+```sh
+DB_NAME=squid
+DB_PORT=23798
+RPC_NEON_HTTP=https://devnet.neonevm.org
+GQL_PORT=4350
+```
+
+6.2 Create `docker-compose.yaml` file in the project's root directory and paste the following lines -
+
+```sh
+version: "3"
+services:
+ db:
+ image: postgres:15
+ environment:
+ POSTGRES_DB: "${DB_NAME}"
+ POSTGRES_PASSWORD: postgres
+ ports:
+ - "${DB_PORT}:5432"
+```
+
+6.3 Start the database container -
+
+```sh
+docker compose up -d
+```
+
+6.4 Compile the TypeORM classes -
+
+```sh
+npx tsc
+```
+
+6.5 Generate the migration file -
+
+```sh
+npx squid-typeorm-migration generate
+```
+
+6.6 Apply the migration with -
+
+```sh
+npx squid-typeorm-migration apply
+```
+
+### Step 7: Generate utility classes for decoding WNEON contract data based on its ABI
+
+7.1 Create a folder named `abi` under `src` (`src/abi`).
+
+7.2 Create `wneon.json` file under `src/abi` (`src/abi/wneon.json`) and paste the contracts's ABI (https://devnet.neonscan.org/address/0x11adc2d986e334137b9ad0a0f290771f31e9517f#contract) into it.
+
+7.3 Run -
+
+```sh
+npx squid-evm-typegen src/abi ./src/abi/wneon.json
+```
+
+The utility classes will be available at src/abi/wneon.ts.
+
+### Step 8: Create an executable file `main.ts` under `src` folder (`src/main.ts`)
+
+Paste the following lines of code into `main.ts` -
+
+```sh
+import { EvmBatchProcessor } from "@subsquid/evm-processor";
+import { TypeormDatabase } from "@subsquid/typeorm-store";
+import * as wneonAbi from "./abi/wneon";
+import { Transfer } from "./model";
+
+const processor = new EvmBatchProcessor()
+ .setGateway("https://v2.archive.subsquid.io/network/neon-devnet")
+ .setRpcEndpoint({
+ // set RPC endpoint in .env
+ url: process.env.RPC_NEON_HTTP,
+ //rateLimit: 10,
+ })
+ .setBlockRange({ from: 177455580 }) // Neon EVM Devnet genesis block
+ .setFinalityConfirmation(75) // 15 mins to finality
+ .addLog({
+ address: ["0x11adC2d986E334137b9ad0a0F290771F31e9517F"], // WNEON contract address on Neon EVM Devnet
+ topic0: [wneonAbi.events.Transfer.topic],
+ });
+
+const db = new TypeormDatabase();
+
+processor.run(db, async (ctx) => {
+ const transfers: Transfer[] = [];
+ for (let block of ctx.blocks) {
+ for (let log of block.logs) {
+ let { src, dst, wad } = wneonAbi.events.Transfer.decode(log);
+ transfers.push(
+ new Transfer({
+ id: log.id,
+ src,
+ dst,
+ wad,
+ })
+ );
+ }
+ }
+ await ctx.store.insert(transfers);
+});
+```
+
+### Step 9: Compile the project and start the processor process
+
+```sh
+npx tsc
+```
+
+```sh
+node -r dotenv/config lib/main.js
+```
+
+### Step 10: Start the GraphQL server
+
+In a separate terminal, run the graphql server -
+
+```sh
+npx squid-graphql-server
+```
+
+The finished GraphQL API with GraphiQL will be available at localhost:4350/graphql.
+
+:::info
+Please follow the quick start github tutorial _[Subsquid SDK Example](https://github.com/neonlabsorg/neon-tutorials/tree/main/subsquid)_.
+:::
+
+## Changes needed to run a squid on Neon EVM Mainnet
+
+To run a squid on Neon EVM Mainnet, there needs to be some changes to some of the above mentioned steps.
+
+1. Replace `RPC_NEON_HTTP=https://devnet.neonevm.org` to `RPC_NEON_HTTP=https://neon-proxy-mainnet.solana.p2p.org` in the `.env` file in **Step 6.1**
+
+2. Get the WNEON contract's ABI from the mainnet (https://neonscan.org/address/0x202c35e517fa803b537565c40f0a6965d7204609#contract) in **Step 7.2**
+
+3. In **Step 8**, change to the following in the `src/main.ts` file:
+
+- `setGateway("https://v2.archive.subsquid.io/network/neon-mainnet")`
+- `setBlockRange({ from: 195350522 })` (Neon EVM Mainnet genesis block)
+- `address: ["0x202c35e517fa803b537565c40f0a6965d7204609"]` (WNEON contract address on Neon EVM Mainnet)
diff --git a/docs/developing/integrate/indexers.md b/docs/developing/integrate/indexers.md
deleted file mode 100644
index a7a12609..00000000
--- a/docs/developing/integrate/indexers.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Indexers
----
-
-Indexers are tools that perform the task of indexing, which refers to the processing and organizing of data in order for applications to search and query it faster and more efficiently.
-
diff --git a/docs/developing/integrate/middleware/the-graph.md b/docs/developing/integrate/middleware/the-graph.md
new file mode 100644
index 00000000..61316fda
--- /dev/null
+++ b/docs/developing/integrate/middleware/the-graph.md
@@ -0,0 +1,252 @@
+---
+title: The Graph
+proofedDate: 20230728
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: original item https://medium.com/neon-labs/the-graph-on-neon-evm-enabling-efficient-on-chain-dapp-data-querying-d5c73e3c6bb1 the examples repo has (out of date) full proxy local/Solana/Tracer/Indexer for Graph here https://github.com/neonlabsorg/examples/blob/main/the-graph-integration/README.md For the graph we will have separate RPC Endpoint not public
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+
+*This page presents a high-level overview of how to create a subgraph for The Graph and the endpoint services provided by Neon EVM.*
+
+## TL;DR
+
+- Work from The Graph CLI
+
+```bash
+yarn global add @graphprotocol/graph-cli
+# or
+npm install -g @graphprotocol/graph-cli
+```
+
+- Send a request to info@neonevm.org to be added to the allowlist for The Graph [endpoints](#the-graph-endpoints).
+
+## Prerequisites for standard flow
+
+:::info
+
+The standard flow is where the end user deploys and collects data from their own contract. In the standard flow you:
+
+1. Deploy a contract to Neon EVM
+2. Collect the contract's address and block number
+3. [Configure your subgraph.yaml](#subgraph-overview) to collect data on events emitted by contract with value and block number from previous step
+4. [Deploy your subgraph](#deploy-your-subgraph)
+
+The Graph is highly customizable and supports other flows; for example, it allows you to monitor [public contracts](#public-contracts) too.
+
+:::
+
+- Smart contract address on Neon EVM
+- ABI file for the deployed contract
+- Graph CLI: see [The Graph docs](https://thegraph.com/docs/en/cookbook/quick-start)
+
+## Neon EVM-specific deviations
+
+On the Solana blockchain, data accounts are used to temporarily store data with a history of days. While on the Ethereum blockchain, data is stored within smart contracts. Neon EVM offers an intermediate approach by storing Solana account data for an extended period to support tracing services.
+
+This means that The Graph may not be able to acquire all data according to the block number assigned. It is important that end users consider what data they wish to extract and store from the API service provided by their subgraph for future use.
+
+:::important
+Neon subgraph supports specVersion: 0.0.4 inside the subgraph.yaml file.
+:::
+
+## Introduction
+
+To extract, process, and store data from a dApp contract on Neon EVM using The Graph protocol, you must deploy a dedicated subgraph to a Graph node.
+
+:::info
+
+Subgraphs map 1:1 with a dApp to provide Graph nodes with the information and logic needed to:
+- Observe the blockchain for log events of smart contacts
+- Translate the events into entities for storage
+
+:::
+
+
+### Subgraph overview
+
+We need to create a subgraph to source data from the contract/s of interest that will constantly observe the blockchain using [your chosen Neon RPC](https://chainlist.org/?chain=245022926&testnets=true&search=Neon+EVM) for your events of interest. When one of these events is detected, the Graph node will extract the event log data and begin to process the information using a WebAssembly script defined in the subgraph.
+
+The script uses a GraphQL schema file in the subgraph to produce records, called entities, that represent metadata related to your query. These entities are stored on a database, so they may be queried by API requests.
+
+A subgraph is created using three main components:
+- Subgraph manifest
+- GraphQL schema
+- AssemblyScript mapping file
+
+:::info
+
+Learn more from [The Graph documentation](https://thegraph.com/docs/en/developing/creating-a-subgraph).
+
+:::
+
+### Subgraph manifest: important considerations
+
+The subgraph manifest is defined by the subgraph.yaml file. The manifest defines the smart contract(s) the subgraph will index, what type of events the target smart contract(s) will emit, and how to convert event data into entities that the Graph Node processes and stores for querying.
+
+The following subgraph manifest items deserve particular attention:
+
+- `dataSources.source`
+- `dataSources.network`
+- `dataSources.source.address`
+
+#### `dataSources.source`
+
+`dataSources.source` provides both the (optional) address of the smart contract to watch and the ABI of the smart contract to use
+
+> Omitting address allows you to index matching events from all contracts.
+
+The ABI file is a JSON file created when a Solidity contract is compiled. It contains information on functions in the smart contract and types of events that will be emitted.
+
+Contracts fall into two broad types: personal, i.e. a contract that you have developed and deployed, and private. Let's consider how you collect ABI files for each.
+
+##### Personal contracts
+
+If you’re developing a subgraph for your own project, you generate the ABI files when you compile your smart contract.
+
+##### Public contracts
+
+If you’re developing a subgraph for an existing public project, you will need to download the project’s smart contract(s) and compile them, e.g. with truffle, to retrieve the ABI files.
+
+#### `dataSources.networking`
+
+`dataSources.networking` is important for deploying subgraphs on Neon EVM. The property maps to the network configuration provided in your project’s truffle.js file.
+
+:::tip
+
+If you set `dataSources.networking` to `neonlabs.`, then the manifest file will pull the corresponding “neonlabs” network configurations as setup in your project’s truffle.js file.
+
+:::
+
+#### `dataSources.source.address`
+
+The address of the contract deployed to the `dataSources.network` in the subgraph.yaml manifest file.
+
+## The Graph endpoints
+
+
+
+
+- IPFS: https://ipfs.neonevm.org
+- Graph UI: https://thegraph.neonevm.org
+- Deployment: https://thegraph.neonevm.org/deploy
+- GraphQL: https://thegraph.neonevm.org/subgraphs/name/YOUR_SUBGRAPH_SLUG/graphql
+
+> Replace `YOUR_SUBGRAPH_SLUG` with your slug.
+
+
+
+
+- IPFS: https://ch-ipfs.neontest.xyz
+- Graph UI: https://ch2-graph.neontest.xyz/
+- Deployment: https://ch2-graph.neontest.xyz/deploy/
+- GraphQL: https://ch2-graph.neontest.xyz/subgraphs/name/YOUR_SUBGRAPH_SLUG/graphql
+
+> Replace `YOUR_SUBGRAPH_SLUG` with your slug.
+
+
+
+
+
+
+## Deploy your subgraph
+
+When you have finished creating the subgraph manifest, the subgraph’s GraphQL schema, and the AssemblyScript Mapping file, you’re ready to deploy the subgraph.
+
+### Step 1: request access
+
+Request access to the allowlist for The Graph endpoints at info@neonevm.org. You will be added to the allowlist for the endpoint of the [network/s](#the-graph-endpoints) you request.
+
+
+### Step 2: set up
+
+2.1 Get The Graph's CLI with:
+
+
+
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+
+
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+
+
+2.2 Initiate a project:
+
+
+
+
+Neon EVM provides an example of how to integrate The Graph on Neon [on GitHub](https://github.com/neonlabsorg/neon-tutorials/tree/main/the-graph-test). This project includes example of how to fetch data for the USDC token deployed on Neon Mainnet.
+
+
+
+
+Start a fresh Graph project with
+
+```bash
+graph init --studio {YOUR_SUBGRAPH_SLUG}
+```
+> Remember to define your custom network to `neonlabs` in the subgraph.yaml and again in truffle-config.js to define the neonlabs network.
+
+
+
+
+
+### Step 3: create
+
+For example, let's create a subgraph called `test-subgraph` on Neon EVM. From The Graph CLI, run:
+
+```bash
+graph create neonlabs/test-subgraph --node https://thegraph.neonevm.org/deploy/
+```
+
+### Step 4: instantiate
+
+In the CLI, instantiate `test-subgraph` with:
+
+2.1
+
+```bash
+graph codegen
+```
+
+2.2
+
+```bash
+graph build
+```
+
+### Step 5: deploy
+
+Deploy to the Graph node with:
+
+```bash
+graph deploy neonlabs/test-subgraph --ipfs https://ipfs.neonevm.org/ --node https://thegraph.neonevm.org/deploy/ --version-label="v0.0.1"
+```
+
+### Step 6: record
+
+Finally, record the output of the previous command: the URL at which your subgraph provides the API service feed for your data.
+
+## Gotchas
+
+Remember:
+
+- Neon subgraph supports specVersion: 0.0.4 inside the subgraph.yaml file.
+- Due to the different memory models of Solana and the EVM, there are [Neon-specific deviations](#neon-evm-specific-deviations).
+
+## What next?
+
+If you are new to The Graph and need further support, consider trying our [full walk-through](https://medium.com/neon-labs/the-graph-on-neon-evm-enabling-efficient-on-chain-dapp-data-querying-d5c73e3c6bb1) for setting up and deploying a subgraph on Neon EVM.
+
diff --git a/docs/developing/integrate/neon_transfer.mdx b/docs/developing/integrate/neon_transfer.mdx
new file mode 100644
index 00000000..4c1e24da
--- /dev/null
+++ b/docs/developing/integrate/neon_transfer.mdx
@@ -0,0 +1,322 @@
+---
+title: Neon Transfer Client
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: Vale not setup for mdx on this branch -- needs merge of branch with fix to do full proof. Grammarly proofing done
+---
+
+import { DemoFrame } from '@site/src/components/DemoFrame';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+This page explains how to pass tokens between Solana and Neon EVM programmatically.
+
+## TL;DR
+
+- [Neon Token Transfer](https://www.npmjs.com/package/@neonevm/token-transfer-core) is available as an npm package.
+- [Github repo](https://github.com/neonlabsorg/neon-client-transfer) available.
+- [React demo](https://codesandbox.io/s/neon-token-transfer-demo-2x5gdt) available.
+
+## Introduction
+
+This page describes how to use the Neon token pass tool: providing the same functionality as the [NeonPass UI](https://devnet.neonpass.live).
+The tool is an npm package that supports the transfer of SPL or ERC-20 tokens between Solana and Neon EVM.
+
+## Prerequisites
+
+- You need to integrate Solana-compatible and EVM-compatible wallet providers from supported official libraries such as `@solana/web3.js` or `web3.js`, `ether.js` and `WalletConnect`.
+- Supported browser plugins (e.g. Phantom or MetaMask wallets).
+
+## Step 1: Install and setup
+
+### 1.1 Install the package
+
+
+
+
+```sh
+yarn add @neonevm/token-transfer-core
+yarn add @neonevm/token-transfer-web3
+```
+
+
+
+
+```sh
+npm install @neonevm/token-transfer-core --save
+npm install @neonevm/token-transfer-web3 --save
+```
+
+
+
+
+### 1.2 Enable access to wallets
+
+Now you need to create a connection to the Solana and NeonEVM devnet, and connect the appropriate wallets to perform transfers between them.
+
+In this example we use `web3.js`, but you can also use `ethers.js` as an alternative, by setting `@neonevem/token-transfer-ethers` instead of `@neonevem/token-transfer-web3`.
+
+```javascript
+import { Connection, Keypair, PublicKey } from '@solana/web3.js';
+import { HttpProvider } from 'web3-providers-http';
+import { Web3 } from 'web3';
+import { decode } from 'bs58';
+
+const proxyUrl = `https://devnet.neonevm.org`;
+const solanaUrl = `https://api.devnet.solana.com`;
+
+const connection = new Connection(solanaUrl, 'confirmed');
+const web3 = new Web3(new HttpProvider(proxyUrl));
+
+const neonWallet = web3.eth.accounts.privateKeyToAccount(``);
+const solanaWallet = Keypair.fromSecretKey(decode(``)); // private key in base58 format string
+```
+
+### 1.3 Configure parameters
+
+We employ the `evmParams` method from Neon EVM to obtain specific addresses and constants required for seamless operations.
+
+Also the `nativeTokenList` method contains a list of tokens that are native to Neon EVM and can be used as token gas fee.
+
+```javascript
+import { PublicKey } from '@solana/web3.js';
+
+const neonProxyRpcApi = new NeonProxyRpcApi(proxyUrl);
+const evmParams = await neonProxyRpcApi.evmParams();
+const nativeTokenList = await neonProxyRpcApi.nativeTokenList();
+
+const id = nativeTokenList.findIndex(i => i.token_name === 'NEON');
+const gasToken = nativeTokenList[id];
+
+const neonEvmProgram = new PublicKey(evmParams.NEON_EVM_ID);
+const neonTokenMint = new PublicKey(gasToken.token_mint);
+const chainId = parseInt(gasToken.token_chain_id, 16);
+```
+
+## Step 2: Transfer tokens
+
+### 2.1 Transfer NEON
+
+
+
+
+This example will generate a transaction to transfer NEON from Solana to Neon EVM.
+
+```javascript
+import {
+ NEON_TOKEN_MINT_DECIMALS,
+ solanaNEONTransferTransaction,
+ SPLToken
+} from '@neonevm/token-transfer-core';
+
+const neonToken: SPLToken = {
+ chainId,
+ address_spl: '89dre8rZjLNft7HoupGiyxu3MNftR577ZYu8bHe2kK7g',
+ address: '',
+ decimals: NEON_TOKEN_MINT_DECIMALS,
+ name: 'Neon',
+ symbol: 'NEON',
+ logoURI: 'https://raw.githubusercontent.com/neonlabsorg/token-list/main/neon_token_md.png'
+};
+
+const transaction = await solanaNEONTransferTransaction(solanaWallet.publicKey, neonWallet.address, neonEvmProgram, neonTokenMint, neonToken, amount, chainId);
+const signature = await sendSolanaTransaction(connection, transaction, [toSigner(solanaWallet)]);
+console.log(signature);
+```
+
+
+
+
+Similarly, to transfer NEON from Neon EVM to Solana, use this pattern:
+
+```javascript
+import {
+ NEON_TRANSFER_CONTRACT_DEVNET,
+ NEON_TOKEN_MINT_DECIMALS
+} from '@neonevm/token-transfer-core';
+
+const neonToken: SPLToken = {
+ chainId,
+ address_spl: '89dre8rZjLNft7HoupGiyxu3MNftR577ZYu8bHe2kK7g',
+ address: '',
+ decimals: NEON_TOKEN_MINT_DECIMALS,
+ name: 'Neon',
+ symbol: 'NEON',
+ logoURI: 'https://raw.githubusercontent.com/neonlabsorg/token-list/main/neon_token_md.png'
+};
+
+const transaction = await neonNeonTransactionWeb3(proxyUrl, neonWallet.address, NEON_TRANSFER_CONTRACT_DEVNET, solanaWallet.publicKey, amount);
+const signature = await sendNeonTransaction(web3, transaction, neonWallet);
+console.log(signature);
+```
+
+
+
+
+> Note: You can find more examples in our [repository](https://github.com/neonlabsorg/neon-client-transfer) in the `examples` folder.
+
+### 2.2 Transfer ERC-20 tokens
+
+When working with Devnet, Testnet, or Mainnet, different ERC-20 tokens are utilized. We maintain a JSON [list of supported tokens](https://github.com/neonlabsorg/token-list). Alternatively, please refer to the [token list](/docs/tokens/token_list.md).
+
+For install `token-list` to your project, use this pattern:
+
+```shell
+yarn add token-list@https://github.com/neonlabsorg/token-list.git
+# or
+npm install token-list@https://github.com/neonlabsorg/token-list.git --save
+```
+
+
+
+
+To transfer ERC-20 tokens from Solana to Neon EVM, use the following patterns:
+
+```javascript
+import { neonTransferMintTransactionWeb3 } from '@neonevm/token-transfer-web3';
+import { keccak256 } from 'web3-utils';
+
+const tokenList = require('token-list/tokenlist.json');
+const tokens = (tokensData?.tokens as SPLToken[] ?? []).filter(t => t.chainId === chainId);
+const token = tokens.find(i => i.symbol === 'USDT');
+const amount = '1';
+
+const signer = web3.eth.accounts.privateKeyToAccount(keccak256(solanaWallet.publicKey.toBase58() + neonWallet.address));
+const transaction = await neonTransferMintTransactionWeb3(connection, proxyUrl, neonProxyRpcApi, neonEvmProgram, solanaWallet.publicKey, neonWallet.address, signer, token, amount, chainId);
+const signature = await sendSolanaTransaction(connection, transaction, [toSigner(solanaWallet)]);
+console.log(signature);
+```
+
+
+
+
+Similarly, to transfer ERC-20 tokens from Neon EVM to Solana:
+
+```javascript
+import { Connection, Keypair, PublicKey } from '@solana/web3.js';
+import { getAccount, getAssociatedTokenAddressSync } from '@solana/spl-token';
+import { createMintNeonTransactionWeb3 } from '@neonevm/token-transfer-web3';
+
+const tokenList = require('token-list/tokenlist.json');
+const tokens = (tokensData?.tokens as SPLToken[] ?? []).filter(t => t.chainId === chainId);
+const token = tokens.find(i => i.symbol === 'USDT');
+const amount = '1';
+
+const mint = new PublicKey(token.address_spl);
+const associatedToken = getAssociatedTokenAddressSync(mint, solanaWallet.publicKey);
+try {
+ await getAccount(connection, associatedToken);
+} catch (e) {
+ const solanaTransaction = createAssociatedTokenAccountTransaction(solanaWallet.publicKey, mint, associatedToken);
+ const signature = await sendSolanaTransaction(connection, solanaTransaction, [toSigner(solanaWallet)]);
+ console.log(`Associated token account`, signature);
+}
+const transaction = await createMintNeonTransactionWeb3(proxyUrl, neonWallet.address, associatedToken, token, amount);
+const signature = await sendNeonTransaction(web3, transaction, neonWallet);
+console.log(signature);
+```
+
+
+
+
+### 2.3 Multi-token gas fee
+
+A new feature that Neon EVM supports is multi-token gas fee. So far this feature is implemented in NeonEVM Devnet, but it is already integrated in Token transfer and is available for testing.
+
+Now gas fee is available for two tokens: NEON and SOL. NEON was described above in this documentation, SOL we will now consider.
+
+For transfer SOL as a native token, it is necessary to change the configuration of Neon EVM.
+
+```javascript
+// Neon EVM Devnet for SOL fee configuration
+const proxyUrl = `https://devnet.neonevm.org/solana/sol`;
+const solProxyRpcApi = new NeonProxyRpcApi(proxyUrl);
+const solProxyStatus = await solProxyRpcApi.evmParams();
+const gasTokens = await solProxyRpcApi.nativeTokenList();
+
+const id = gasTokens.findIndex(i => i.token_name === 'SOL');
+const gasToken = gasTokens[id];
+
+const neonEvmProgram = new PublicKey(solProxyStatus.NEON_EVM_ID);
+const solTokenMint = new PublicKey(gasToken.token_mint);
+const chainId = parseInt(gasToken.token_chain_id, 16);
+const web3 = new Web3(new HttpProvider(proxyUrl));
+```
+
+
+
+
+To transfer SOL token as native token from Solana to Neon EVM, use the following patterns:
+
+```javascript
+import { solanaSOLTransferTransaction, SPLToken } from '@neonevm/token-transfer-core';
+
+const solToken: SPLToken = {
+ chainId,
+ address_spl: 'So11111111111111111111111111111111111111112',
+ address: '0xc7Fc9b46e479c5Cb42f6C458D1881e55E6B7986c',
+ decimals: 9,
+ name: 'SOL',
+ symbol: 'SOL',
+ logoURI: 'https://raw.githubusercontent.com/neonlabsorg/token-list/master/assets/solana-wsol-logo.svg'
+};
+const amount = '1';
+
+const transaction = await solanaSOLTransferTransaction(connection, solanaWallet.publicKey, neonWallet.address, neonEvmProgram, solTokenMint, solToken, amount, chainId);
+const signature = await sendSolanaTransaction(connection, transaction, [toSigner(solanaWallet)]);
+console.log(signature);
+```
+
+
+
+
+Similarly, to transfer SOL tokens from Neon EVM to Solana:
+
+```javascript
+import { neonNeonTransactionWeb3 } from '@neonevm/token-transfer-web3';
+import { SOL_TRANSFER_CONTRACT_DEVNET, SPLToken } from '@neonevm/token-transfer-core';
+
+const solToken: SPLToken = {
+ chainId,
+ address_spl: 'So11111111111111111111111111111111111111112',
+ address: '0xc7Fc9b46e479c5Cb42f6C458D1881e55E6B7986c',
+ decimals: 9,
+ name: 'SOL',
+ symbol: 'SOL',
+ logoURI: 'https://raw.githubusercontent.com/neonlabsorg/token-list/master/assets/solana-wsol-logo.svg'
+};
+const amount = '1';
+
+const transaction = await neonNeonTransactionWeb3(proxyUrl, neonWallet.address, SOL_TRANSFER_CONTRACT_DEVNET, solanaWallet.publicKey, amount);
+const signature = await sendNeonTransaction(web3, transaction, neonWallet);
+console.log(signature);
+```
+
+
+
+
+An ERC20 transfer using SOL gas fee is similar to a transfer with NEON gas fee and has been described earlier in this documentation.
+
+## Alternative libraries
+
+As mentioned above, the examples in this documentation are presented using the [web3.js](https://web3js.org/) library, but we have added support for [ethers.js](https://docs.ethers.org/) as an alternative and put it in a separate package `@neonevm/token-transfer-ethers`.
+
+```shell
+yarn add @neonevm/token-transfer-ethers
+# or
+npm install @neonevm/token-transfer-ethers --save
+```
+
+More examples with using `ethers.js` can be found in the `examples` folder of our [Github repo](https://github.com/neonlabsorg/neon-client-transfer).
+
+## React Demo App
+
+The following [live demo with an open codebase](https://github.com/neonlabsorg/neon-client-transfer/tree/develop/examples/neon-transfer-react) supports the tooling via React App.
+
+
diff --git a/docs/developing/integrate/neon_transfer_sdk.md b/docs/developing/integrate/neon_transfer_sdk.md
deleted file mode 100644
index 07b83182..00000000
--- a/docs/developing/integrate/neon_transfer_sdk.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: Neon Transfer SDK
----
-
----
-**NOTE**
-
-The package is tested on [NeonPass](https://neonpass.live/) codebase, which use react hooks arch.
-You can use clean core, but all important requirements you need to provide as params and see how it goes by yourself.
-
----
-
-Module was used by the react wrapper `import {useNeonTransfer} from "neon-portal/src/react"`
-For clean working configuration example we have to rebuild connect status buttons, their transfer callbacks and error handling.
-
-## Installation and setup
-
-Firstly, install the package:
-
-```sh
-npm install neon-portal --save
-```
-
-### For native
-
-After installing you need to pass some required properties, when calling new instance, for properly working. Neon wallet interface based on Metamask. Module checks, is wallet objects - window.solana and window.ehtereum - really exists. If not - module will throw an error for you. So, besides Solana Phantom wallet you need to connect Metamask wallet and get both user addresses, which you need to pass as properties.
-
-```javascript
-import { NeonPortal } from "neon-portal"
-//for transfer ERC20 tokens use:
-import { MintPortal } from "neon-portal"
-
-const eventParams = {
- onBeforeSignTransaction: () => {
- /* Your state changes here */
- },
- /* ... */
-};
-const portal = new NeonPortal({
- solanaWalletAddress: publicKey,
- neonWalletAddress: account,
- customConnection: connection,
- /*
- You can pass events as properties,
- but this functions will be call at portal context.
- */
- ...eventParams,
-});
-button.addEventListener("onClick", (e) => {
- /*
- If you want to save context of event function - pass it as first argument
- Else first argument should be undefined
- */
- portal.createNeonTransfer(eventParams, amount, splToken);
-});
-```
-
-| Property name | Type | Description | is required |
-|-------------------------------:| :------: |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|------------:|
-| solanaWalletAddress | String | Address from solana wallet | true |
-| neonWalletAddress | String | Address of preconfigured for neon network metamask wallet | true |
-| web3 | Object | Connection module of ethereum web3 framework. It needs for use Neon SDK network connection. | true |
-| connection | Object | connection module of solana web3 framework. You have to provide your own connection, if it exists. Cause of context, if you won't, it should start working for other solana networks. | true |
-| onBeforeCreateInstructions | function | Function, which calls on start of init transfer functions. It uses in both transfer functions | false |
-| onCreateNeonAccountInstruction | function | Function, which calls on instructions building, if neon account didn't find. It uses in transfer to neon from solana. | false |
-| onBeforeSignTransaction | function | Function, which calls before transaction will be sign by solana wallet. It uses in both transfers | false |
-| onBeforeNeonSign | function | Function, which calls before metamask will approve transfer. It uses when you transfer from neon to solana. | false |
-| onSuccessSign | function | Function, which calls after sign the transfer. When you use it on transfer to neon, function get one argument - solana transaction sign. On transfer to solana it provides two arguments. Solana and Neon signatures. | false |
-| onErrorSign | function | Function, which calls, if wallet throw an error after try to sign | false |
-
-
-### For React
-
-You can use hook from package. This hook apply event parameters as object for argument. For clean code You should create your own hook and manipulate your states here.
-
-
-Here is an example:
-
-
-``` javascript
-export const useTransfering = () => {
- const { setPending, setSign, setError } = useStates()
- const { publicKey } = useWallet()
- const { account, library } = useWeb3React();
- // please, add your own custom solana connection, if you use it in the context of your app. Pass it as second argument at neon transfer hook.
- const connection = useConnection()
- const { createNeonTransfer, createSolanaTransfer } = useNeonTransfer(
- {
- onBeforeCreateInstruction: () => {
- setPending(true)
- },
- onBeforeSignTransaction: () => {
- setPending(false)
- setTransfering(true)
- },
- /*
- sig - phantom signature (solana)
- txHash - neon approve signature when transfer to solana
- */
- onSuccessSign: (sig, txHash) => {
- setSign(sig, txHash)
- setTransfering(false)
- },
- onErrorSign: (e) => {
- setError(e.message)
- setPending(false)
- },
- // yes, there
- },
- connection,
- library, // Web3 Library instance
- publicKey, // you Phantom wallet public key
- account // you Metamask wallet public key
- )
- return { createNeonTransfer, createSolanaTransfer }
-}
-```
diff --git a/docs/developing/integrate/oracles/integrating_api3.md b/docs/developing/integrate/oracles/integrating_api3.md
new file mode 100644
index 00000000..551046ea
--- /dev/null
+++ b/docs/developing/integrate/oracles/integrating_api3.md
@@ -0,0 +1,196 @@
+---
+title: API3
+proofedDate: 20240717
+iterationBy: na
+includedInSite: false
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import mm_p_key from '@site/static/img/doc-images/developing/deploy_facilities/foundry-metamask.png';
+
+## Introduction
+
+API3 dAPIs (decentralized APIs) offer a state-of-the-art solution for connecting off-chain data sources with on-chain applications. They use first-party oracles managed directly by API providers, ensuring reliable and continuously updated data feeds. These oracles provide cryptographically signed data, which is then aggregated on-chain into a secure and tamper-proof data feed known as a beacon set.
+
+Developers can easily integrate dAPIs into their decentralized applications (dApps), enabling real-time access to off-chain data, such as price feeds, without requiring extensive technical implementation. The integration process is simplified through a proxy address that represents the dAPI requester, facilitating the interaction between the dApp and the data feed. API3 has made it straightforward for dApp owners to read on-chain values from these beacons, enhancing the functionality and reliability of their applications.
+
+Each API3 data feed is available via its own proxy contract. To use a feed, you create a "hybrid" smart contract, i.e. you build the integration with the feed proxy contract into your own smart contract and deploy that. Learn more from [API3's documentation](https://docs.api3.org/explore/dapis/what-are-dapis.html), or examine the [boilerplate provided](#boilerplate-contract).
+
+## Deployed feeds
+
+:::important
+Activation of API3 price feeds is permissionless and anyone can activate the price feeds with a transaction on Neon EVM Mainnet and Devnet.
+:::
+
+The proxy contract addresses of the price feeds are available both on Neon EVM Mainnet and Devnet.
+
+
+
+
+
+| Currency pair | API3 proxy contract feed address |
+| :-----------: | :----------------------------------------: |
+| USDT/USD | 0xF00249f594f11c3F98F2D73433274D10098906B6 |
+
+
+
+
+
+| Currency pair | API3 proxy contract feed address |
+| :-----------: | :----------------------------------------: |
+| BTC/USD | 0x81A64473D102b38eDcf35A7675654768D11d7e24 |
+| ETH/USD | 0xa47Fd122b11CdD7aad7c3e8B740FB91D83Ce43D1 |
+| SOL/USD | 0xCa81409D8dF6d34a21d93B5c0EF79557Bc5fb4be |
+| USDC/USD | 0xa790a882bB695D0286C391C0935a05c347290bdB |
+| USDT/USD | 0xF00249f594f11c3F98F2D73433274D10098906B6 |
+| NEON/USD | 0x383CC331Cd5669b7B6460a24b1B45cD9220B28a8 |
+| LINK/USD | 0xB102ec41347F26E8493B8C98cA1c10b69903Dc57 |
+
+
+
+
+
+## Boilerplate contract
+
+[View GitHub example](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/contracts/TestAPI3/TestAPI3.sol)
+
+```
+// SPDX-License-Identifier: MIT
+pragma solidity 0.8.21;
+
+import "@api3/contracts/api3-server-v1/proxies/interfaces/IProxy.sol";
+
+contract TestAPI3 {
+ // Use your proxy address as the argument
+ function readDataFeed(address proxy) public view returns (int224 value, uint32 timestamp) {
+ (value, timestamp) = IProxy(proxy).read();
+ // If you have any assumptions about `value` and `timestamp`, make sure
+ // to validate them right after reading from the proxy. For example,
+ // if the value you are reading is the spot price of an asset, you may
+ // want to reject non-positive values...
+ require(value > 0, "Value not positive");
+ // ...and if the data feed is being updated with a one day-heartbeat
+ // interval, you may want to check for that.
+ require(
+ timestamp + 1 days > block.timestamp,
+ "Timestamp older than one day"
+ );
+ }
+}
+```
+
+## How to integrate with the API3 contract
+
+:::important
+Before trying out the tutorial in the next steps, please make sure that the price feeds are activated for **[Neon EVM Mainnet](https://market.api3.org/neon-evm)** and **[Neon EVM Devnet](https://market.api3.org/neon-evm-testnet)**.
+:::
+
+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 which reads API3 price feeds.
+
+### 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=`YOUR_PRIVATE_KEY`
+```
+
+:::important
+Replace `YOUR_PRIVATE_KEY` with your data.
+:::
+
+### 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 Contract
+
+`NEON_CONFIG` contains the proxy price feed addresses on Neon EVM Mainnet and Devnet for reading API3 price feeds.
+
+To deploy the project's hybrid contract, simply run the command below to run the deployment script in the `scripts/` directory:
+
+```sh
+npx hardhat run scripts/TestAPI3/deploy.js --network neondevnet
+```
+
+The output should look like:
+
+```
+TestAPI3 deployed to 0xB8747279e8029108720BcB5386511D70B9129D68
+BTC_USD Result(2) [ 64547812100000000000000n, 1721241637n ]
+ETH_USD Result(2) [ 3431460000000000000000n, 1721274476n ]
+SOL_USD Result(2) [ 159776804400000000000n, 1721284955n ]
+USDC_USD Result(2) [ 999900024820969500n, 1721220644n ]
+USDT_USD Result(2) [ 1000188700000000000n, 1721220738n ]
+NEON_USD Result(2) [ 392570000000000000n, 1721270758n ]
+LINK_USD Result(2) [ 13807707000000000000n, 1721291017n ]
+```
+
+> The result represents an array with the following parameters:
+>
+> - 1st parameter - Price
+> - 2nd parameter - Timestamp of the last price push
+
+:::info
+To deploy on Neon EVM Mainnet, change `--network neondevnet` to `--network neonmainnet` in the command line.
+:::
+
+:::important
+If a dApp wants to recapture OEV (https://api3.org/oev/), they can contact us, and API3 will assist them in obtaining a unique proxy for their dApp. You can join their [Discord](https://discord.com/invite/qnRrcfnm5W) and reach out to the API3 team in the OEV section.
+:::
diff --git a/docs/developing/integrate/oracles/integrating_chainlink.md b/docs/developing/integrate/oracles/integrating_chainlink.md
index 60e7f081..49bae724 100644
--- a/docs/developing/integrate/oracles/integrating_chainlink.md
+++ b/docs/developing/integrate/oracles/integrating_chainlink.md
@@ -1,13 +1,107 @@
---
-title: Integrate Chainlink
+title: Chainlink
+proofedDate: 20231124
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Introduction
-[Chainlink Data Feeds](https://data.chain.link/) are the quickest way to connect your smart contracts to real-world data, such as asset prices. It supports Neon EVM and is implemented as a smart contract making Chainlink Data Feeds from Solana network available on Neon EVM. You can learn more from the [hoodieshq/chainlink-neon](https://github.com/hoodieshq/chainlink-neon) repo.
+[Chainlink data feeds](https://data.chain.link/) are the quickest way to connect your smart contracts to oracle data, such as asset prices.
+
+Chainlink is implemented as a smart contract on Neon EVM, making Chainlink data feeds from the Solana network available for smart contracts to consume.
+
+Each Chainlink feed is available via its own contract. To use a feed, you create a "hybrid" smart contract, i.e. you build the integration with the feed contract into your own smart contract and deploy that. Learn more from [Chainlink's documentation](https://docs.chain.link/data-feeds/solana), or examine the [boilerplate provided](#boilerplate-contract).
+
+
+## Deployed feeds
+
+The Chainlink controller contract is deployed on Devnet. This contract implements the [`AggregatorV3Interface`](https://docs.chain.link/docs/price-feeds-api-reference/#aggregatorv3interface) to support the following feeds:
+
+
+
+
+
+|Currency pair|Chainlink contract feed address|
+|:----:|:-----:|
+|AVAX/USD|0x1d6E632542B7E405FAA8D26C4805C981260A9e70|
+|BTC/USD|0x002A8368a4fd76C1809765ea66a9AFa3D424d8e0|
+|BNB/USD|0x3c864365f961f1fb31a6682EB388E84832fd159C|
+|DAI/USD|0xa13Cbd21e5De770Bb9104B951B0b0a876c46ef85|
+|ETH/USD|0xC55B1E0c36A69e2b40BD16759434B071F4bBe8df|
+|LINK/USD|0x22eE81bFA94049c9d880e81c5d40b12423307DFb|
+|MATIC/USD|0x5864ccda29c78845460639021287c3f192350816|
+|OP/USD|0x996c00D1E9DDA20a6d0B7dd516394D5978AC0B92|
+|SOL/USD|0x76721563EC3CF5fB94737Eb583F38f3cD166C7Bb|
+|SRM/USD|0xd010175e4eA718569A105FCbeAa8db44c590730E|
+|USDC/USD|0x8cb22a71AD5ef0384B85FF08Ba1343ec71880C35|
+|USDT/USD|0xba92eACD3fb46661E130577cD03fa32E6D4D757a|
+
+
+
+
+
+|Currency pair|Chainlink contract feed address|
+|:----:|:-----:|
+|BTC/USD|0x878738FdbCC9Aa39Ce68Fa3B0B0B93426EcB6417|
+|ETH/USD|0x7235B04963600fA184f6023696870F49d014416d|
+|LINK/USD|0xc75E93c4593c23A50cff935F8916774e02c506C7|
+|SOL/USD|0xec852B2A009f49E4eE4ffEddeDcF81a1AD1bbD6d|
+|USDC/USD|0xedc0d80E85292fEf5B0946DEc957563Ceb7C8e6c|
+|USDT/USD|0xE69C1E63ef3E95bE56A50f326aC97Bb7994890aD|
+
+
+
+
+## Boilerplate contract
+
+[View GitHub example](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/contracts/TestChainlink/TestChainlink.sol)
+
+[View in Remix](https://remix.ethereum.org/#url=https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/contracts/TestChainlink/TestChainlink.sol&lang=en&optimize=false&runs=200&evmVersion=null&version=soljson-v0.8.21+commit.d9974bed.js)
+
+```Solidity
+SPDX-License-Identifier: MIT
+pragma solidity 0.8.21;
+
+import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";
+
+
+contract TestChainlink {
+ /**
+ * Returns the latest price for specific price feed
+ */
+ function getLatestPrice(address _priceFeed) external view returns (int) {
+ (
+ /* uint80 roundID */,
+ int price,
+ /*uint startedAt*/,
+ /*uint timeStamp*/,
+ /*uint80 answeredInRound*/
+ ) = AggregatorV3Interface(_priceFeed).latestRoundData();
+ return price;
+ }
+
+ /**
+ * Returns the decimals for specific price feed
+ */
+ function getDecimals(address _priceFeed) external view returns (uint8) {
+ return AggregatorV3Interface(_priceFeed).decimals();
+ }
+}
+```
+
+
\ No newline at end of file
diff --git a/docs/developing/integrate/oracles/integrating_pyth.md b/docs/developing/integrate/oracles/integrating_pyth.md
index 5222132f..963f5405 100644
--- a/docs/developing/integrate/oracles/integrating_pyth.md
+++ b/docs/developing/integrate/oracles/integrating_pyth.md
@@ -1,42 +1,187 @@
---
-title: Integrate Pyth
+title: Pyth
+proofedDate: 20240502
+iterationBy: HB
+includedInSite: true
+approvedBy: na
+comment:
---
+import mm_p_key from '@site/static/img/doc-images/developing/deploy_facilities/foundry-metamask.png';
+
## Introduction
-[Pyth](https://pyth.network/) is an open-source real-time on-chain market data feed. It supports Neon EVM and its repo is maintained by Pyth on GitHub at [pyth-network/pyth-neon](https://github.com/pyth-network/pyth-neon).
+[Pyth](https://pyth.network/) is an open-source real-time on-chain market data feed. Neon EVM can read Pyth Solana Mainnet and Devnet price feeds natively with precompiles.
-This guide contains a smart contract making Pyth price feeds available on Neon EVM.
+Next, your contract should query the Solana Pyth Contract that holds this updated data for the token prices you require. The price feed IDs are available for -
-It is **strongly recommended** to follow the [consumer best practices](https://docs.pyth.network/consumers/best-practices) when consuming Pyth data.
+- [Solana Mainnet Beta](https://pyth.network/developers/price-feed-ids#solana-mainnet-beta)
+- [Solana Devnet](https://pyth.network/developers/price-feed-ids#solana-devnet)
-## How to Use
+## Boilerplate contract
-To consume prices, you need to look up the price feed ID for the token symbol you are interested in.
-The Pyth Network website lists the NEON price feed IDs for [devnet](https://pyth.network/developers/price-feed-ids/#neon-evm-devnet) and [mainnet](https://pyth.network/developers/price-feed-ids/#neon-evm-mainnet).
+[View GitHub example](https://github.com/neonlabsorg/neon-tutorials/blob/main/hardhat/contracts/TestReadSolanaData/TestReadPythPriceFeed.sol)
-```javascript
-// SPDX-License-Identifier: Apache-2.0
-pragma solidity ^0.8.0;
+```
+// SPDX-License-Identifier: MIT
+pragma solidity 0.8.21;
-import "@pythnetwork/pyth-sdk-solidity/PythStructs.sol";
+import "./SolanaDataConverterLib.sol";
+import "./QueryAccount.sol";
-contract ExampleContract {
- function getBTCUSDPrice() public returns (PythStructs.Price memory) {
+contract TestReadPythPriceFeed {
+ using SolanaDataConverterLib for bytes;
+ using SolanaDataConverterLib for uint64;
+ using SolanaDataConverterLib for uint32;
- // The NEON Devnet price feed ID of BTC/USD
- bytes32 priceID = 0xf9c0172ba10dfa4d19088d94f5bf61d3b54d5bd7483a322a982e1373ee8ea31b;
+ /// @notice This method serves to read the bytes length of a Solana data account
+ /// @param solanaAddress The Solana data account address of the price feed
+ function readSolanaDataAccountLen(bytes32 solanaAddress) public view returns(uint256) {
+ (bool success, uint256 data) = QueryAccount.length(uint256(solanaAddress));
+ require(success, "failed to query account data");
- return pyth.getCurrentPrice(priceID);
+ return data;
}
+ /// @notice This method serves to read the raw data of a Solana data account
+ /// @param solanaAddress The Solana data account address of the price feed
+ /// @param offset The offset in bytes, starting to read from the byte
+ /// @param len The length of the Solana data account
+ function readSolanaDataAccountRaw(bytes32 solanaAddress, uint64 offset, uint64 len) public view returns(bytes memory) {
+ (bool success, bytes memory data) = QueryAccount.data(uint256(solanaAddress), offset, len);
+ require(success, "failed to query account data");
+
+ return data;
+ }
+
+ /// @notice This method serves to read from Pyth price feeds price, prevPublishTimestamp and status
+ /// @param solanaAddress The Solana data account address of the price feed
+ /// @param offset The offset in bytes, starting to read from the byte
+ /// @param len The length of the Solana data account
+ /// @return Price
+ /// @return Timestamp
+ /// @return Status - could be UNKNOWN, TRADING, HALTED, AUCTION
+ function readSolanaPythPriceFeed(bytes32 solanaAddress, uint64 offset, uint64 len) public view returns(int64, uint64, uint32) {
+ (bool success, bytes memory data) = QueryAccount.data(uint256(solanaAddress), offset, len);
+ require(success, "failed to query account data");
+
+ return (
+ (data.toUint64(208)).readLittleEndianSigned64(),
+ (data.toUint64(200)).readLittleEndianUnsigned64(),
+ (data.toUint32(224)).readLittleEndianUnsigned32()
+ );
+ }
}
```
-### How to Deploy
+:::important
+`TestReadPythPriceFeed.sol` contract imports `QueryAccount.sol` and `SolanaDataConverterLib.sol` which are the required libraries to read data from Solana accounts natively.
+:::
+
+## How to integrate with the Pyth contract
+
+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 which reads Pyth Solana price feeds.
+
+### 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=`YOUR_PRIVATE_KEY`
+```
+
+:::important
+Replace `YOUR_PRIVATE_KEY` with your data.
+:::
+
+### 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 Contract
+
+`NEON_CONFIG` contains the proxy contract addresses on Devnet and Mainnet, and the price ids for reading Pyth prices.
+
+To deploy the project's contract for Solana Pyth price, simply run the command below to run the deployment script in the `scripts/` directory:
+
+```sh
+npx hardhat run scripts/TestReadSolanaData/TestReadPythPriceFeed.js --network neondevnet
+```
+
+The output should look like:
+
+```
+TestReadPythPriceFeed deployed to 0x7068EbfED06C7a87ba23e339199FACeF76515Df2
+Result(3) [ 102486086n, 1714670447n, 1n ] neonPrice
+Result(3) [ 13932481388n, 1714670448n, 1n ] solPrice
+Result(3) [ 299735750000n, 1714670448n, 1n ] ethPrice
+Result(3) [ 5919709374999n, 1714670448n, 1n ] btcPrice
+```
+
+> The result represents an array with the following parameters:
+>
+> - 1st parameter - Price
+> - 2nd parameter - Timestamp of the last price push
+> - 3rd parameter - Status (0 = UNKNOWN, 1 = TRADING, 2 = HALTED, 3 = AUCTION)
+>
+> For validating the correct price, a check for the timestamp or status can be implemented in the code.
+
+:::info
+To deploy on Neon EVM Mainnet, change `--network neondevnet` to `--network neonmainnet` in the command line.
+:::
-1. Create a `.secret` file containing the private key or mnemonic of the account you want to use to deploy the
- contracts.
-2. (Optional) Edit `truffle-config.js` to add the NEON network you want to deploy to.
-3. Run `truffle migrate --network neon_devnet`
+It's **strongly recommended** that you follow the [consumer best practices](https://docs.pyth.network/documentation/pythnet-price-feeds/best-practices) when consuming Pyth data.
diff --git a/docs/developing/integrate/wallets/img/cli1.png b/docs/developing/integrate/wallets/img/cli1.png
new file mode 100644
index 00000000..649a4be4
Binary files /dev/null and b/docs/developing/integrate/wallets/img/cli1.png differ
diff --git a/docs/developing/integrate/wallets/img/cli2.png b/docs/developing/integrate/wallets/img/cli2.png
new file mode 100644
index 00000000..8361b494
Binary files /dev/null and b/docs/developing/integrate/wallets/img/cli2.png differ
diff --git a/docs/developing/integrate/wallets/img/cli3.png b/docs/developing/integrate/wallets/img/cli3.png
new file mode 100644
index 00000000..178b8895
Binary files /dev/null and b/docs/developing/integrate/wallets/img/cli3.png differ
diff --git a/docs/developing/integrate/wallets/img/cli4.png b/docs/developing/integrate/wallets/img/cli4.png
new file mode 100644
index 00000000..f4a7fb53
Binary files /dev/null and b/docs/developing/integrate/wallets/img/cli4.png differ
diff --git a/docs/developing/integrate/wallets/img/cli5.png b/docs/developing/integrate/wallets/img/cli5.png
new file mode 100644
index 00000000..ec521c9a
Binary files /dev/null and b/docs/developing/integrate/wallets/img/cli5.png differ
diff --git a/docs/developing/integrate/wallets/img/cli6.png b/docs/developing/integrate/wallets/img/cli6.png
new file mode 100644
index 00000000..73fa0f12
Binary files /dev/null and b/docs/developing/integrate/wallets/img/cli6.png differ
diff --git a/docs/developing/integrate/wallets/img/safe1.png b/docs/developing/integrate/wallets/img/safe1.png
new file mode 100644
index 00000000..cad9ab4d
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe1.png differ
diff --git a/docs/developing/integrate/wallets/img/safe2.png b/docs/developing/integrate/wallets/img/safe2.png
new file mode 100644
index 00000000..96f30a94
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe2.png differ
diff --git a/docs/developing/integrate/wallets/img/safe3.png b/docs/developing/integrate/wallets/img/safe3.png
new file mode 100644
index 00000000..278edc31
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe3.png differ
diff --git a/docs/developing/integrate/wallets/img/safe4.png b/docs/developing/integrate/wallets/img/safe4.png
new file mode 100644
index 00000000..ce71f821
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe4.png differ
diff --git a/docs/developing/integrate/wallets/img/safe5.png b/docs/developing/integrate/wallets/img/safe5.png
new file mode 100644
index 00000000..1b6229bf
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe5.png differ
diff --git a/docs/developing/integrate/wallets/img/safe6.png b/docs/developing/integrate/wallets/img/safe6.png
new file mode 100644
index 00000000..a3b51a4d
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe6.png differ
diff --git a/docs/developing/integrate/wallets/img/safe7.png b/docs/developing/integrate/wallets/img/safe7.png
new file mode 100644
index 00000000..b29a6cdd
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe7.png differ
diff --git a/docs/developing/integrate/wallets/img/safe8.png b/docs/developing/integrate/wallets/img/safe8.png
new file mode 100644
index 00000000..c7406876
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe8.png differ
diff --git a/docs/developing/integrate/wallets/img/safe9.png b/docs/developing/integrate/wallets/img/safe9.png
new file mode 100644
index 00000000..95df0582
Binary files /dev/null and b/docs/developing/integrate/wallets/img/safe9.png differ
diff --git a/docs/developing/integrate/wallets/img/web3auth-1.png b/docs/developing/integrate/wallets/img/web3auth-1.png
new file mode 100644
index 00000000..6ee0c54e
Binary files /dev/null and b/docs/developing/integrate/wallets/img/web3auth-1.png differ
diff --git a/docs/developing/integrate/wallets/img/web3auth-2.png b/docs/developing/integrate/wallets/img/web3auth-2.png
new file mode 100644
index 00000000..86460178
Binary files /dev/null and b/docs/developing/integrate/wallets/img/web3auth-2.png differ
diff --git a/docs/developing/integrate/wallets/img/web3auth-3.png b/docs/developing/integrate/wallets/img/web3auth-3.png
new file mode 100644
index 00000000..8c3a0385
Binary files /dev/null and b/docs/developing/integrate/wallets/img/web3auth-3.png differ
diff --git a/docs/developing/integrate/wallets/img/web3auth-4.png b/docs/developing/integrate/wallets/img/web3auth-4.png
new file mode 100644
index 00000000..e85ede28
Binary files /dev/null and b/docs/developing/integrate/wallets/img/web3auth-4.png differ
diff --git a/docs/developing/integrate/wallets/img/web3auth-5.png b/docs/developing/integrate/wallets/img/web3auth-5.png
new file mode 100644
index 00000000..90af1ef5
Binary files /dev/null and b/docs/developing/integrate/wallets/img/web3auth-5.png differ
diff --git a/docs/developing/integrate/wallets/img/web3auth-6.png b/docs/developing/integrate/wallets/img/web3auth-6.png
new file mode 100644
index 00000000..0ba446c0
Binary files /dev/null and b/docs/developing/integrate/wallets/img/web3auth-6.png differ
diff --git a/docs/developing/integrate/wallets/integrating_metamask_into_your_dapp.md b/docs/developing/integrate/wallets/integrating_metamask_into_your_dapp.md
index 12a1510f..650fd565 100644
--- a/docs/developing/integrate/wallets/integrating_metamask_into_your_dapp.md
+++ b/docs/developing/integrate/wallets/integrating_metamask_into_your_dapp.md
@@ -1,18 +1,29 @@
---
-title: Integrate MetaMask into Your DApp
+title: MetaMask
+proofedDate: 20231117
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Introduction
-This guide goes through the process of integrating MetaMask into your dApp so that users of your dApp can click on a `Connect to Neon` button and be prompted to connect to your dApp via MetaMask in an intuitive and accessible manner.
+This guide goes through the process of integrating MetaMask into your dApp so that users of your dApp can click on a **Connect to Neon** button and be prompted to connect to your dApp via MetaMask in an intuitive and accessible manner.
This guide assumes proficiency in JavaScript.
-## Full JavaScript Code
+## Full JavaScript code
This code is also available on [CodeSandbox](https://codesandbox.io/s/autumn-sky-0gkxs4).
-```javascript
+
+
+
+```jsx
import detectEthereumProvider from "@metamask/detect-provider";
const configure = async () => {
@@ -24,14 +35,14 @@ const configure = async () => {
method: "wallet_addEthereumChain",
params: [
{
- chainId: "0x" + (245022926).toString(16),
- chainName: "Neon DevNet",
+ chainId: "0x" + (245022934).toString(16),
+ chainName: "Neon Mainnet",
nativeCurrency: {
name: "NEON",
symbol: "NEON",
- decimals: 9
+ decimals: 18
},
- rpcUrls: ["https://proxy.devnet.neonlabs.org/solana"],
+ rpcUrls: ["https://neon-proxy-mainnet.solana.p2p.org"],
blockExplorerUrls: ["https://neonscan.org/"]
}
]
@@ -52,3 +63,51 @@ export default function App() {
);
}
+```
+
+
+
+
+```jsx
+import detectEthereumProvider from "@metamask/detect-provider";
+
+const configure = async () => {
+ const provider = await detectEthereumProvider({ mustBeMetaMask: true });
+ if (provider) {
+ try {
+ await provider.request({ method: "eth_requestAccounts" });
+ await provider.request({
+ method: "wallet_addEthereumChain",
+ params: [
+ {
+ chainId: "0x" + (245022926).toString(16),
+ chainName: "Neon Devnet",
+ nativeCurrency: {
+ name: "NEON",
+ symbol: "NEON",
+ decimals: 18
+ },
+ rpcUrls: ["https://devnet.neonevm.org"],
+ blockExplorerUrls: ["https://devnet.neonscan.org"]
+ }
+ ]
+ });
+ } catch (e) {
+ alert("Error");
+ console.error("configure provider error", e);
+ }
+ } else {
+ alert("Please install MetaMask");
+ }
+};
+
+export default function App() {
+ return (
+
+
+
+ );
+}
+```
+
+
\ No newline at end of file
diff --git a/docs/developing/integrate/wallets/integrating_walletconnect.mdx b/docs/developing/integrate/wallets/integrating_walletconnect.mdx
new file mode 100644
index 00000000..0bfad9b7
--- /dev/null
+++ b/docs/developing/integrate/wallets/integrating_walletconnect.mdx
@@ -0,0 +1,152 @@
+---
+title: WalletConnect
+proofedDate: 20231117
+iterationBy: Miro
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import devnet from '@site/static/img/doc-images/developing/integrate/protocols/walletconnect/devnet.png';
+import projectid from '@site/static/img/doc-images/developing/integrate/protocols/walletconnect/projectid.png';
+import buttonclicked from '@site/static/img/doc-images/developing/integrate/protocols/walletconnect/button-clicked.png';
+import walletconnectqr from '@site/static/img/doc-images/developing/integrate/protocols/walletconnect/wallet-connect-qr.png';
+import mathwalletconnect from '@site/static/img/doc-images/developing/integrate/protocols/walletconnect/math-wallet-connect.jpeg';
+import walletconnectlogged from '@site/static/img/doc-images/developing/integrate/protocols/walletconnect/wallet-connect-logged.png';
+import walletconnectloggedoptions from '@site/static/img/doc-images/developing/integrate/protocols/walletconnect/wallet-connect-logged-options.png';
+
+## Introduction
+
+[WalletConnect](https://docs.walletconnect.com/2.0/) is a protocol providing a decentralized standard to connect Web3 wallets and dApps.
+
+This guide lays out a step-by-step process to configure a React or HTML dApp on Neon EVM using WalletConnect's [Web3Modal SDK](https://docs.walletconnect.com/web3modal/about).
+
+Web3Modal is a library that allows users to connect to any dApp via the WalletConnect interface.
+
+:::info
+
+Check out Web3Modal code on [GitHub](https://github.com/WalletConnect/web3modal).
+
+Web3Modal supports:
+
+- [React](https://docs.walletconnect.com/web3modal/react/about)
+- [HTML](https://docs.walletconnect.com/web3modal/html/about)
+:::
+
+
+## Prerequisites
+
+- EVM-compatible wallet (this tutorial uses MathWallet)
+- WalletConnect account
+
+## Tutorial
+
+### Step 1: Create a project
+
+Log into [WalletConnect Cloud](https://cloud.walletconnect.com/) to create a new project and copy the Project ID.
+
+>
+
+
+### Step 2: Configure your project's chain
+
+From WalletConnect's project page, click the **Explorer** tab and select the Neon chain you require from the **Chains** drop-down. For this guide, we will use the Neon EVM Devnet.
+
+>
+
+
+### Step 3: Configure your app
+
+For this guide, we are configuring an HTML Web App.
+
+
+
+3.1 Install the required packages into your app:
+
+
+
+
+```bash
+npm install @wagmi/core @web3modal/wagmi viem vite
+```
+
+
+
+
+```
+yarn add @wagmi/core @web3modal/wagmi viem vite
+```
+
+
+
+
+3.2 Inside `package.json` file, add the following code:
+
+> `vite` is a dependency that starts the server
+
+```json
+"scripts": {
+ "dev": "vite"
+}
+```
+
+3.3 Create `.env.local` file and place `VITE_PROJECT_ID="XYZ"` ( place your project ID key from [WalletConnect Cloud](https://cloud.walletconnect.com/) ).
+
+3.4 Create an `index.html` file and use the following code:
+
+```html
+
+
+
+
+ Neon WalletConnect Example
+
+
+
+
+
+
+```
+
+3.5 Create a `main.js` file and place the following code:
+
+```javascript
+import { createWeb3Modal, defaultWagmiConfig } from '@web3modal/wagmi';
+import { neonMainnet, neonDevnet } from '@wagmi/core/chains';
+
+const projectId = import.meta.env.VITE_PROJECT_ID;
+const metadata = {
+ name: 'Neon Example',
+ description: 'Neon Web3Modal Example',
+ url: 'https://neonevm.org',
+ icons: ['https://neonevm.org/favicons/android-chrome-512x512.png']
+};
+
+const chains = [neonMainnet, neonDevnet];
+const wagmiConfig = defaultWagmiConfig({chains, projectId, metadata});
+
+const modal = createWeb3Modal({wagmiConfig, projectId, chains});
+```
+
+3.6 Run `npm run dev` or `yarn run dev` to start your Web application, and you should see the Web3Modal button loaded in your Web app page.
+
+### Step 4: Connect your wallet
+
+For this example, we use [MathWallet](https://mathwallet.org/).
+
+4.1 You have several connecting options; select **WalletConnect**:
+
+
+4.2 The popup will load a WalletConnect QR code.
+
+
+4.3 Open your MathWallet mobile app and scan the QR code.
+
+
+4.4 After scanning the WalletConnect QR code, you should be able to see your NEON balance inside your Web app page:
+
+
+Now, if you click your NEON balance, you'll be able to see more options for your WalletConnect connection:
+
\ No newline at end of file
diff --git a/docs/developing/integrate/wallets/integrating_web3auth.md b/docs/developing/integrate/wallets/integrating_web3auth.md
new file mode 100644
index 00000000..23484e17
--- /dev/null
+++ b/docs/developing/integrate/wallets/integrating_web3auth.md
@@ -0,0 +1,174 @@
+---
+title: Web3Auth SDK
+proofedDate: 20240501
+iterationBy: na
+includedInSite: false
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+## Introduction
+
+This guide will walk you through the steps of a working example for integrating Web3Auth pluggable wallet infrastructure for Web3 wallets and applications using Web3Auth SDK and ReactJS.
+
+Integrating Web3Auth into your decentralized application (dApp) or blockchain wallet offers a means to greatly streamline the user onboarding process, ensuring a smooth and uncomplicated experience for your users. Concurrently, Web3Auth enables the preservation of your wallet management system's non-custodial nature. This ensures that users continue to possess complete control and ownership of their cryptographic wallets, thereby strengthening the foundational principles of privacy and security inherent in blockchain technology. To learn more, please follow the [Web3Auth documentation](https://web3auth.io/docs/what-is-web3auth).
+
+## Prerequisites
+
+- NodeJS 16.x or newer
+
+## How to integrate Web3Auth SDK
+
+This tutorial is based on the example located in [this repository](https://github.com/neonlabsorg/neon-tutorials/tree/main/web3auth).
+
+### Step 1: Create a Web3Auth project and get the Client ID from Web3Auth Dashboard
+
+1.1 Go to the [login](https://dashboard.web3auth.io/login) page and login with any of your social login credentials.
+
+
+
+
+
+
+
+1.2 Create a new project to get the Client ID for the project.
+
+
+
+
+
+
+
+1.3 Copy the Client ID.
+
+
+
+
+
+
+
+### Step 2: Installation
+
+> **Note:** This page is just a quickstart based on a specific example program.
+
+2.1 Using Git, clone the example project from the remote repository and navigate to it:
+
+```sh
+git clone https://github.com/neonlabsorg/neon-tutorials
+cd neon-tutorials/web3auth
+```
+
+2.2 Then, run the following command:
+
+```sh
+npm install
+```
+
+This will install all the necessary packages to continue with the example.
+
+### Step 3: Configure the project
+
+3.1 In the `src/App.tsx` file, replace this line with your own Client ID.
+
+```sh
+const clientId =
+ "BPi5PB_UiIZ-cPz1GtV5i1I2iOSOHuimiXBI0e-Oe_u6X3oVAbCiAZOTEBtTXw4tsluTITPqA8zMsfxIKMjiqNQ";
+```
+
+3.2 Add the chain configuration
+
+
+
+```sh
+// Neon EVM Devnet
+const chainConfig = {
+ chainId: "0xe9ac0ce",
+ rpcTarget: "https://devnet.neonevm.org",
+ chainNamespace: CHAIN_NAMESPACES.EIP155,
+ displayName: "Neon EVM Devnet",
+ blockExplorerUrl: "https://devnet.neonscan.org",
+ ticker: "NEON",
+ tickerName: "Neon",
+ logo: "",
+};
+```
+
+
+```sh
+// Neon EVM Mainnet
+const chainConfig = {
+ chainId: "0xe9ac0d6",
+ rpcTarget: "https://neon-proxy-mainnet.solana.p2p.org",
+ chainNamespace: CHAIN_NAMESPACES.EIP155,
+ displayName: "Neon EVM Mainnet",
+ blockExplorerUrl: "https://neonscan.org",
+ ticker: "NEON",
+ tickerName: "Neon",
+ logo: ""
+};
+```
+
+
+
+### Step 4: Run and interact with the application
+
+4.1 To start the application in your local machine, run -
+
+```sh
+npm run start
+```
+
+This will redirect to http://localhost:3000/ where you can interact with the application.
+
+
+
+
+
+
+
+4.2 Click on the login button to open the login modal.
+
+
+
+
+
+
+
+This Web3Auth example allows you to login via the following ways -
+
+ - Social logins like Google, Facebook, Reddit, Discord, Apple, Github, X, Linkedin and many more.
+ - Email or Phone number.
+ - Metamask wallet.
+
+4.3 After successfully signing in with any of the above mentioned ways of signing in, the following methods can be checked on Neon EVM -
+
+
+
+
+
+
+
+:::important
+By default, this example is configured to connect with **Neon EVM Devnet**. `readContract()` and `writeContract()` functions in the `src/web3RPC.ts` file includes a simple storage contract address `0x093451875d5A8D61bB90faA7A8645eB17c86b297` and its ABI deployed on Neon EVM Devnet.
+
+If you change the chain configuration to **Neon EVM Mainnet**, then please deploy the smart contract on Neon EVM Mainnet and replace the deployed address and the contract ABI in `readContract()` and `writeContract()` functions in the `src/web3RPC.ts` file.
+:::
+
+ - **Get Chain ID:** Displays the network chain ID to which the dApp is connected. This value is `245022926`, when the chain configuration is **Neon EVM Devnet** and `245022934` when the chain configuration is **Neon EVM Mainnet**.
+
+ - **Get Accounts:** Displays the wallet account on Neon EVM Devnet connected to the dApp.
+
+ - **Get Balance:** Displays the balance of NEONs for the wallet account that is connected to the dApp.
+
+ - **Sign Message:** Signs a message with the connected wallet account and returns the signed message.
+
+ - **Send Transaction:** Does a simple NEON transfer from account to another and returns the transaction receipt.
+
+ - **Read Contract:** Calls a read-only contract method and returns the result. In this example, it returns a message stored in the simple storage contract `0x093451875d5A8D61bB90faA7A8645eB17c86b297` deployed on Neon EVM Devnet.
+
+ - **Write Contract:** Sends a transaction to the smart contract method and returns the transaction receipt. In this example, the message is updated in the simple storage contract `0x093451875d5A8D61bB90faA7A8645eB17c86b297` deployed on Neon EVM Devnet.
+
+ - **Log Out:** Logs out of the account connected.
diff --git a/docs/developing/integrate/wallets/safe.md b/docs/developing/integrate/wallets/safe.md
new file mode 100644
index 00000000..0f4370dd
--- /dev/null
+++ b/docs/developing/integrate/wallets/safe.md
@@ -0,0 +1,90 @@
+---
+title: Safe
+proofedDate: 20240609
+iterationBy: na
+includedInSite: false
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+## Introduction
+
+What is Safe?
+
+The Safe Account functions as a proxy contract, which means it forwards requests to a singleton contract. This singleton contract holds all the essential logic required for the Safe to operate. Proxy contracts are advantageous because they are typically more cost-effective to deploy and manage on public blockchains and they allow for easier upgrades. The primary purpose of the Safe proxy contract is to oversee and maintain the Safe’s state.
+The term "contract state" refers to the variables (or values) associated with a specific contract. Functions and contract code are usually stored and executed as bytecode within the Neon EVM, while variables are managed separately. These variables are the values that functions change when they run. For the Safe, the singleton contract provides the functions that adjust the state variables in the proxy. This singleton contract is also called the master copy of the Safe.
+
+Purpose:
+The primary purpose of Safe Neon EVM is to facilitate the secure storage, management, and multi-signature capabilities for digital assets. By leveraging the features of the Neon EVM, it allows users to utilize Ethereum-compatible tools like Solidity and Vyper while benefiting from Solana’s low transaction fees, high speeds, and parallel processing capabilities.
+
+## How to create a Safe account on Neon EVM Mainnet
+
+### Step 1: Connect your wallet
+
+1.1 Go to the [login](https://safe.neonevm.org/welcome) page and connect your wallet.
+
+
+
+
+
+
+
+1.2 1.2 Select your wallet from the available options to get started
+
+
+
+
+
+
+
+1.3 Create new Safe account
+
+
+
+
+
+
+
+1.4 Set the signer wallets
+
+
+
+
+
+
+
+
+1.5 Review the filled information
+
+
+
+
+
+
+
+1.6 Wait for the transaction confirmation
+Accept the transaction in your initial wallet
+
+
+
+
+
+
+
+1.7 After the confirmation your account will be created
+
+
+
+
+
+
+
+1.8 Welcome page
+
+
+
+
+
diff --git a/docs/developing/integrate/wallets/safe_cli.md b/docs/developing/integrate/wallets/safe_cli.md
new file mode 100644
index 00000000..6074029f
--- /dev/null
+++ b/docs/developing/integrate/wallets/safe_cli.md
@@ -0,0 +1,93 @@
+---
+title: Safe CLI
+proofedDate: 20241909
+iterationBy: na
+includedInSite: false
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+## Introduction
+
+Get the Safe CLI
+Prerequisite: Install Docker Desktop (https://www.docker.com/products/docker-desktop/)
+
+Once Docker is installed on your system, create Safe account using the Safe guide
+
+Purpose:
+
+The primary purpose of the Neon CLI (Command Line Interface) for Neon EVM is to allow developers to manage, deploy, and operate Ethereum-compatible dApps on the Solana blockchain directly from the command line. This interface simplifies development tasks by enabling users to handle various functions, such as deploying smart contracts, configuring projects, managing databases, and setting up multi-signature accounts.
+
+
+## Interact with a Safe wallet using CLI
+
+### Step 1: Create 2 or more wallets
+
+1.1 Go to the [login](https://safe.neonevm.org/welcome) page and connect your wallet and create two or more wallets
+
+
+
+### Step 3: How to remove an owner
+
+3.1 Run
+For 2 wallets:
+```
+load_cli_owners
+```
+
+If you have more wallets then add more private keys
+
+
+
+
+
+
+
+3.2 Run
+```
+show_cli_owners
+```
+
+
+
+
+
+
+
+3.3 Run
+```
+remove_owner --threshold 3
+```
+
+Example for 2 wallets:
+```
+remove_owner 0x0x0000000000000000000000000000000000000000 --threshold 2
+```
+
+If you have more than two wallets then change the number of --threshold
+
+
+
+
+
+
diff --git a/docs/developing/utilities/faucet.md b/docs/developing/utilities/faucet.md
index 2ab11e8e..4a9f9fac 100644
--- a/docs/developing/utilities/faucet.md
+++ b/docs/developing/utilities/faucet.md
@@ -1,5 +1,10 @@
---
title: Request Test Tokens
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
You can request Test tokens on the Neon devnet using the Neon Faucet. There are two ways to use the Neon Faucet - on the Neon Faucet website, and using the Neon Faucet API.
diff --git a/docs/developing/utilities/neonpass.md b/docs/developing/utilities/neonpass.md
deleted file mode 100644
index 38521123..00000000
--- a/docs/developing/utilities/neonpass.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: NeonPass
----
-
-NeonPass is an open-source service designed to transfer tokens between Solana and the Neon EVM.
-
-Go to the [NeonPass](https://neonpass.live/) page to call the NeonPass application.
-
-Read more about NeonPass in the [Token Transferring](token_transferring/neonpass_usage.md) section.
diff --git a/docs/developing/utilities/neonswap.md b/docs/developing/utilities/neonswap.md
deleted file mode 100644
index 9350e112..00000000
--- a/docs/developing/utilities/neonswap.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: NeonSwap
----
-
-## The Goal
-The goal of this article is to show how to swap an ERC-20 token with another token of the same standard using the NeonSwap application.
-
-*Condition:* The ERC-20 token can be any [SPL token](about/terminology.md#spl-token) whose contract complies with the [ERC-20 standard](about/terminology.md#erc-20) and is deployed on the Neon EVM.
-
-## Before You Begin
- * Familiarize yourself with the following:
- * The [Solana network](https://docs.solana.com/clusters).
- * [MetaMask](about/terminology.md#metamask).
- * The [MetaMask](about/terminology.md#metamask) wallet must be installed on your device and can be accessed from the browser you are using.
- * Read the [How to Connect MetaMask to Solana's Network](wallet/metamask_setup.md) guide.
-
-## NeonSwap Overview
-
- *NeonSwap is an open-source service forked from [Uniswap v2](https://uniswap.org/blog/uniswap-v2) and modified in order for it to work with the Neon EVM.*
-
- NeonSwap is an open-source dApp whose main function is to provide the services required to deploy Ethereum contracts on the Neon EVM. In Ethereum, transactions such as exchanging one token for another, require the deployment of contracts. These contracts operate using their specific services and cannot be deployed outside of this environment.
-
- The Neon EVM product allows you to transfer applications from Ethereum to Solana while ensuring that they function reliably. The NeonSwap infrastructure provides full support for applications on the Neon EVM, as well as the swap interface on a separate server. No changes are required to port applications over to Neon using the NeonSwap service.
-
- > The **[NeonSwap](about/terminology.md#neonswap)** service provides an opportunity for Ethereum developers to migrate their applications to the Neon EVM without any difficulties.
-
-## Steps
-The NeonSwap application allows any user to swap one token for another. You just need to connect your wallet to the application following the step-by-step instructions. Swapping tokens will be carried out automatically without sending funds to the exchange. There are some gas transaction fees to pay with the application.
-
-As an example, this tutorial outlines an exchange of ETH tokens to USDT tokens.
-
-### Step 1: Open the NeonSwap application and connect your wallet
-Go to the [NeonSwap](https://neonswap.live/) page to call the NeonSwap application. Before you can make a swap, you need to connect your wallet. Click `Connect Wallet` on the swap screen.
-
-
-
-
-
-
-
-From the list appears in the dropdown, you must select your wallet. (In our case, this is MetaMask.) Select the account you want to connect to.
-
-### Step 2: Select a pair of tokens to be swapped
-
-After connecting your wallet, you can begin setting up the exchange. You need to select the token that will be swapping from. It will retrieve your balance from the connected wallet. In our case, it will be ETH.
-
-Click `Select a token` to open up a menu where you can select a token to exchange for.
-
-
-
-
-
-
-
-### Step 3: Add a new token to the list, if necessary
-The `Select a token` menu contains tokens deployed in the Neon EVM. If the token symbol you specified is not in the list, you can paste the token's address if you know what it is. Note: the token must first be deployed on the Neon EVM network.
-
-If you want to add a new token to the list, click `Manage` at the bottom of the box. The `Manage` tab will open on the screen. Add the address of the new token deployed in the Neon EVM network and click `Import`. (You can take a token's address from the [token-list](https://github.com/neonlabsorg/token-list/).)
-
-
-
-
-
-
-
-You will receive a warning message, "Trade at your own risk!" If you are confident in your actions, agree by choosing `I understand` then click `Import`.
-
-The symbol of the new token will appear in the list of tokens available for swapping.
-
-### Step 4: Enter the quantity you want to sell
-
-To check the balance of the token being sold, click `max` (next to the token symbol). Keep in mind that some amount of the token must be spent as a fee to pay for the gas required for a transaction to execute. If you specify the entire amount of funds for trade, the resulting exchanged amount will be reduced by the fee.
-
-If there are not enough tokens in the pool to exchange, NeonSwap will warn you by issuing the message "Insufficient liquidity for this trade".
-
-In our case, we want to exchange ETH tokens for USDT tokens. Let's specify the number of tokens to be exchanged as 10. Neon Swap will indicate the expected number of purchased USDT tokens, corresponding to 2.49176 at the exchange rate before our transaction.
-
-
-
-
-
-
-
-### Step 5: Perform the exchange
-Before you can submit this exchange, you need to understand the following:
- * `Price` — the price at which the exchange is possible
- * `Minimum received` — the minimum amount of tokens (in our case, USDT) you will receive if the trade goes through. The trade will fail if the price deviates too much during the transaction (also known as [slippage](about/terminology.md#slippage)).
- * `Price impact` — tells you how much your swap will affect this token's price. This value can be seen as a loss you will take on the swap. The closer this number is to zero, the better.
- * `Liquidity Provider Fee` — the fee you will pay for this transaction. NeonSwap charges a *0.03 %* fee of the total transaction amount. This fee is expressed in the token you are selling (in our case, ETH).
-
-Once you are ready to perform the exchange click `Swap`. A confirmation window will pop up with details of the exchange. If the conditions are accepted, click `Confirm Swap`. A request will be sent to MetaMask to confirm the transaction.
-
-### Step 6: Verify the result of the exchange
-
-The request will open up a MetaMask window where you can confirm the transaction. You can see an estimate of how much gas you will pay. Click `Confirm` to send the transaction.
-
-
-
-
-
-
-
-You can also check the result of the trade in the NeonSwap window. Click `Close` to complete the transaction.
-
-
-
-
-
-
-
-Now you can open MetaMask, as well as the list of tokens, by clicking `Select a token` to make sure that the balances of tokens have changed to the expected values.
-
-
-
-
-
-
-
-The transaction is complete, which means you have successfully swapped your ETH for USDT.
-
-### Step 7. Additional settings for trading
-
-Click the cogwheel icon. The window `Transaction Settings` will pop up on the screen to set up the advanced swap:
-
-
-
-
-
-
-
-Transaction settings:
- * `Slippage tolerance` — the allowable amount of price change. "Slippage" refers to when an order is fulfilled at a price different from what you expected. If this difference exceeds the tolerance level that is set, the transaction will not go through. If you are trading when markets are experiencing high volatility, you may want to increase this value. Increasing the transaction speed can help you to reduce the chances of high [slippage](about/terminology.md#slippage) as well.
- * `Transaction deadline` — allows the transaction to automatically cancel if it is taking too long to process.
- * `Toggle Expert Mode` — disables the confirmation screen and removes [slippage](about/terminology.md#slippage) limits. Enabling this mode is not recommended, unless you fully understand the associated risks.
- * `Disable Multihops` — disables complex conversion paths. For example, if there is not enough liquidity in the "A->B" token pair, then the algorithm can involve other tokens to find some "A->C->B" intermediate route and make the trade for you. This action requires more network fees, because multiple smart contracts would be called.
diff --git a/docs/developing/verify_facilities/img/blockscout-1.png b/docs/developing/verify_facilities/img/blockscout-1.png
new file mode 100644
index 00000000..0191d9e7
Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-1.png differ
diff --git a/docs/developing/verify_facilities/img/blockscout-2.png b/docs/developing/verify_facilities/img/blockscout-2.png
new file mode 100644
index 00000000..2f6133cc
Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-2.png differ
diff --git a/docs/developing/verify_facilities/img/blockscout-3.png b/docs/developing/verify_facilities/img/blockscout-3.png
new file mode 100644
index 00000000..a20618ab
Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-3.png differ
diff --git a/docs/developing/verify_facilities/img/blockscout-4.png b/docs/developing/verify_facilities/img/blockscout-4.png
new file mode 100644
index 00000000..b7de47ea
Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-4.png differ
diff --git a/docs/developing/verify_facilities/img/blockscout-5.png b/docs/developing/verify_facilities/img/blockscout-5.png
new file mode 100644
index 00000000..6cd96d9a
Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-5.png differ
diff --git a/docs/developing/verify_facilities/img/blockscout-6.png b/docs/developing/verify_facilities/img/blockscout-6.png
new file mode 100644
index 00000000..477b0f89
Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-6.png differ
diff --git a/docs/developing/verify_facilities/img/blockscout-7.png b/docs/developing/verify_facilities/img/blockscout-7.png
new file mode 100644
index 00000000..fce2fccf
Binary files /dev/null and b/docs/developing/verify_facilities/img/blockscout-7.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-1.png b/docs/developing/verify_facilities/img/neonscan-1.png
new file mode 100644
index 00000000..7155b5c7
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-1.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-2.png b/docs/developing/verify_facilities/img/neonscan-2.png
new file mode 100644
index 00000000..8dce7516
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-2.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-3.png b/docs/developing/verify_facilities/img/neonscan-3.png
new file mode 100644
index 00000000..90361829
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-3.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-4.png b/docs/developing/verify_facilities/img/neonscan-4.png
new file mode 100644
index 00000000..745b83fe
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-4.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-5.png b/docs/developing/verify_facilities/img/neonscan-5.png
new file mode 100644
index 00000000..fe5d432c
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-5.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-6.png b/docs/developing/verify_facilities/img/neonscan-6.png
new file mode 100644
index 00000000..ac0ae578
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-6.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-7.png b/docs/developing/verify_facilities/img/neonscan-7.png
new file mode 100644
index 00000000..d0628eda
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-7.png differ
diff --git a/docs/developing/verify_facilities/img/neonscan-8.png b/docs/developing/verify_facilities/img/neonscan-8.png
new file mode 100644
index 00000000..9d5538b1
Binary files /dev/null and b/docs/developing/verify_facilities/img/neonscan-8.png differ
diff --git a/docs/developing/verify_facilities/using_foundry.md b/docs/developing/verify_facilities/using_foundry.md
new file mode 100644
index 00000000..baf1fc75
--- /dev/null
+++ b/docs/developing/verify_facilities/using_foundry.md
@@ -0,0 +1,75 @@
+---
+title: Verify smart contracts with Foundry
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+_This page outlines the steps for verifying contracts on Neon EVM using the Foundry tool._
+
+This tutorial is based on the example located in [this repository](https://github.com/neonlabsorg/neon-tutorials/tree/main/foundry).
+
+:::info
+Foundry doesn't support custom explorers and only support Blockscout, Sourcify and Etherscan.
+:::
+
+By the end of this tutorial, you will learn to verify a contract that deploys an ERC-20 token to Neon EVM Devnet on Blockscout explorer.
+
+## Step 1: Configure `.env`
+
+Create a `.env` file in the project's root directory to feed in the required variables.
+
+```sh
+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
+```
+
+Run `source .env` to save the .env variables.
+
+## Step 2: Deploy the contract
+
+To deploy a contract, please follow this page describing [how to deploy contracts with Foundry](https://docs.neonevm.org/docs/developing/deploy_facilities/using_foundry).
+
+## Step 3: Verify the deployed contract
+
+To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0x93adb347065949a90a7f2e198f94c2fadeb7dbbd` on Neon EVM Devnet.
+
+After running the following command to verify -
+
+```sh
+forge verify-contract --chain-id $CHAIN_ID_DEVNET 0x93adb347065949a90a7f2e198f94c2fadeb7dbbd src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout
+```
+
+The output should look like this -
+
+```sh
+Start verifying contract `0x93Adb347065949a90a7f2e198F94c2FADeb7dBbd` deployed on 245022926
+
+Submitting verification for [src/TestERC20/TestERC20.sol:TestERC20] "0x93Adb347065949a90a7f2e198F94c2FADeb7dBbd".
+Submitted contract for verification:
+ Response: `OK`
+ GUID: `93adb347065949a90a7f2e198f94c2fadeb7dbbd661584d8`
+ URL:
+ https://neon-devnet.blockscout.com/api?/address/0x93adb347065949a90a7f2e198f94c2fadeb7dbbd
+```
+
+The verified contract source code can be found here https://neon-devnet.blockscout.com/address/0x93Adb347065949a90a7f2e198F94c2FADeb7dBbd?tab=contract.
+
+:::important
+If the deployed contract consists of constructor arguments to be passed, then the constructor arguments are ABI-encoded. For example -
+
+```sh
+forge verify-contract --chain-id $CHAIN_ID_DEVNET 0x93adb347065949a90a7f2e198f94c2fadeb7dbbd src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout --constructor-args $(cast abi-encode "constructor(string,string)" "TestToken" "TEST")
+```
+
+:::
+
+:::info
+If you want to verify on NeonScan, then please follow this page which describes the steps **[to verify smart contracts manually on NeonScan](verify_manually.md)**
+:::
diff --git a/docs/developing/verify_facilities/using_hardhat.md b/docs/developing/verify_facilities/using_hardhat.md
new file mode 100644
index 00000000..89db239d
--- /dev/null
+++ b/docs/developing/verify_facilities/using_hardhat.md
@@ -0,0 +1,140 @@
+---
+title: Verify smart contracts with Hardhat
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+_This page outlines the steps for verifying contracts on Neon EVM using the Hardhat tool._
+
+Before beginning the tutorial below, make sure that you have properly [configured Hardhat](/docs/developing/deploy_facilities/configure_hardhat) for Neon EVM.
+
+This tutorial is based on the example located in [this repository](https://github.com/neonlabsorg/neon-tutorials/tree/main/hardhat).
+
+By the end of this tutorial, you will learn to verify a contract that deploys an ERC-20 token to Neon EVM Devnet on Neonscan and Blockscout explorers.
+
+## Step 1: Deploy the contract
+
+To deploy a contract, please follow this page describing [how to deploy contracts with Hardhat](https://docs.neonevm.org/docs/developing/deploy_facilities/using_hardhat).
+
+## Step 2: Verify the deployed contract
+
+To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08` on Neon EVM Devnet.
+
+
+
+
+1. Add these lines to `hardhat.config.js` -
+
+```sh
+etherscan: {
+ apiKey: {
+ neonevm: "test",
+ },
+ customChains: [
+ {
+ network: "neonevm",
+ chainId: 245022926,
+ urls: {
+ apiURL: "https://devnet-api.neonscan.org/hardhat/verify",
+ browserURL: "https://devnet.neonscan.org",
+ },
+ },
+ {
+ network: "neonevm",
+ chainId: 245022934,
+ urls: {
+ apiURL: "https://api.neonscan.org/hardhat/verify",
+ browserURL: "https://neonscan.org",
+ },
+ },
+ ],
+},
+```
+
+2. After running the following command to verify -
+
+```sh
+npx hardhat verify --network neondevnet 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08
+```
+
+The output should look like this -
+
+```sh
+Successfully submitted source code for contract
+contracts/TestERC20/TestERC20.sol:TestERC20Hardhat at 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08
+for verification on the block explorer. Waiting for verification result...
+
+Successfully verified contract TestERC20Hardhat on the block explorer.
+https://devnet.neonscan.org/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08#code
+```
+
+The verified contract source code can be found here https://devnet.neonscan.org/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08#contract.
+
+
+
+
+
+1. Add these lines to `hardhat.config.js` -
+
+```sh
+etherscan: {
+ apiKey: {
+ neonevm: "test",
+ },
+ customChains: [
+ {
+ network: "neonevm",
+ chainId: 245022926,
+ urls: {
+ apiURL: "https://neon-devnet.blockscout.com/api",
+ browserURL: "https://neon-devnet.blockscout.com",
+ },
+ },
+ {
+ network: "neonevm",
+ chainId: 245022934,
+ urls: {
+ apiURL: "https://neon.blockscout.com/api",
+ browserURL: "https://neon.blockscout.com",
+ },
+ },
+ ],
+},
+```
+
+2. After running the following command to verify -
+
+```sh
+npx hardhat verify --network neondevnet 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08
+```
+
+The output should look like this -
+
+```sh
+Successfully submitted source code for contract
+contracts/TestERC20/TestERC20.sol:TestERC20Hardhat at 0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08
+for verification on the block explorer. Waiting for verification result...
+
+Successfully verified contract TestERC20Hardhat on the block explorer.
+https://neon-devnet.blockscout.com/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08#code
+```
+
+The verified contract source code can be found here https://neon-devnet.blockscout.com/address/0xf4f09428C61c5F91c6F6B9a1A422778F0473eA08?tab=contract.
+
+
+
+
+:::important
+If the deployed contract consists of constructor arguments to be passed, then the command for verification should be -
+
+```sh
+npx hardhat verify --network neondevnet
+```
+
+:::
diff --git a/docs/developing/verify_facilities/verify_manually.md b/docs/developing/verify_facilities/verify_manually.md
new file mode 100644
index 00000000..6543204c
--- /dev/null
+++ b/docs/developing/verify_facilities/verify_manually.md
@@ -0,0 +1,171 @@
+---
+title: Verify smart contracts manually
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+_This page outlines the steps for verifying contracts on Neon EVM manually on NeonScan and Blockscout._
+
+Before beginning the tutorial below, please follow this page which describes [how to deploy a smart contract on Neon EVM using Remix IDE](https://docs.neonevm.org/docs/developing/deploy_facilities/using_remix).
+
+If you are not using Hardhat or Foundry tools for deployment and using Remix for the smart contract development, then you can verify your smart contracts on NeonScan or Blockscout.
+
+## Step 1: Deploy the contract
+
+For this example, let us take a simple smart contract `TestERC20.sol` -
+
+```sh
+// SPDX-License-Identifier: MIT
+pragma solidity 0.8.24;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+
+contract TestERC20Manual is ERC20 {
+ constructor() ERC20("TestERC20", "TST") {
+ _mint(msg.sender, 1000 * 10 ** decimals());
+ }
+}
+```
+
+## Step 2: Verify the deployed contract
+
+If your smart contract references different solidity files in its imports, you can upload a flattened version of the smart contract or upload each solidity file your smart contract references.
+
+To flatten your contract, right-click the filename on your Remix.IDE file explorer, and choose flatten. Remix.IDE will generate a flattened version of your smart contract e.g., TestERC20_flattened.sol in this case, that you can paste into NeonScan or Blockscout.
+
+
+
+
+To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0x628C8F52De7C661AA703523eDD75539Dce8D7EBB` on Neon EVM Devnet.
+
+The deployed contract can be found here https://devnet.neonscan.org/address/0x628C8F52De7C661AA703523eDD75539Dce8D7EBB#contract.
+
+1. Click on the `Verify Contract Code` link to go the verification page.
+
+
+
+
+
+
+
+2. On the `Verify and Publish` page, the `Contract Address` field is auto-filled with the deployed contract address.
+
+
+
+
+
+
+
+3. Enter the name of the deployed contract in the `Contract Name` field. In this example, the name of the deployed contract is **TestERC20Manual**.
+
+
+
+
+
+
+
+4. Select the `Compiler Type` from the dropdown. In this example, this should be **Solidity**.
+
+
+
+
+
+
+
+5. Select the `Compiler Version` from the dropdown. In this example, the compiler version used is **v0.8.23+commit.f704f362**.
+
+
+
+
+
+
+
+6. Select `Optimization` from the dropdown and the `Run` value. In this example, optimization is **Yes** and the value is **200**.
+
+
+
+
+
+
+
+7. Enter the name of the flattened smart contract in the `File name` field and the flattened solidity source code in the `Code` field. The file name in this example is **TestERC2_flattened.sol**.
+
+
+
+
+
+
+
+8. After clicking on the `Submit` button, the verified contract source code can be seen on the contract page https://devnet.neonscan.org/address/0x628C8F52De7C661AA703523eDD75539Dce8D7EBB#contract.
+
+
+
+
+
+
+
+
+
+
+
+To verify the deployed contract from the above step, let's take an example of a deployed contract with address `0x00407307F5eb91dFCC406E88618dB8aAE7d715B8` on Neon EVM Devnet.
+
+The deployed contract can be found here https://neon-devnet.blockscout.com/address/0x00407307F5eb91dFCC406E88618dB8aAE7d715B8?tab=contract.
+
+1. Click on `Verify & publish`.
+
+
+
+
+
+
+
+2. On the `Verify & publish` page, choose Contract license from the dropdown. In this example, the license mentioned in the smart contract is MIT.
+
+
+
+
+
+
+
+3. Choose verification method or compiler type from the dropdown. In this example, we are using Solidity (Flattened source code).
+
+
+
+
+
+
+
+4. Choose compiler and the EVM version from the dropdowns. These fields should be entered as per the configuration in Remix IDE. In this example, we are using compiler **0.8.24+commit.e11b9ed9** and EVM version **default**.
+
+
+
+
+
+
+
+5. Click on the Optimization enabled if it is enabled in Remix IDE. Enter the flattened solidity code in the Contract code box.
+
+
+
+
+
+
+
+6. After clicking on the `Verify & publish` button, the verified contract source code can be seen on the contract page https://neon-devnet.blockscout.com/address/0x00407307F5eb91dFCC406E88618dB8aAE7d715B8?tab=contract.
+
+
+
+
+
diff --git a/docs/evm_compatibility/architectural_limitations/erc721_tokens.md b/docs/evm_compatibility/architectural_limitations/erc721_tokens.md
deleted file mode 100644
index 507067e7..00000000
--- a/docs/evm_compatibility/architectural_limitations/erc721_tokens.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Unsupported Tokens in the Neon EVM
----
-
-### Problem
-In Testnet and Devnet, the Neon EVM operates with tokens that comply with the [ERC-20](about/terminology.md#erc-20) standard. Non-fungible tokens (NFTs) generated in accordance with the [ERC-721](about/terminology.md#erc-721) standard are not processed by the Neon EVM.
-
-### Details
-To support the [ERC-20](about/terminology.md#erc-20) token type, a separate component is implemented in the form of a wrapper over the Solana system frame named *[SPL Token](about/terminology.md#spl-token)*. This wrapper uses the API to access the SPL-token methods to obtain the account balance data.
-
-To transfer tokens, the wrapper calls the corresponding instruction in *[SPL Token](about/terminology.md#spl-token)*, which transfers funds from one account balance to another. Currently the wrapper is implemented to support only the instruction set of the ERC-20 standard.
-
-### What happens if a user transfers NFT tokens from Ethereum to Solana?
-In this case, a contract will be created in Neon EVM to work with these types of tokens. Processing these tokens in *[SPL Token](about/terminology.md#spl-token)* will not comply with the standard adopted in Ethereum.
-
-If you use the [ERC-721](about/terminology.md#erc-721) contract implemented in Ethereum and compile and run it in the Neon EVM, then the tokens generated using this contract can only be liquid within the Neon EVM. These tokens cannot be transferred anywhere, including to the exchange, since there is no standard in Solana that supports this type of token. As a result, the tokens will not have any value.
-
-### Proposed Solution to Support Operations on Non-fungible Tokens in Neon EVM
-It is proposed to integrate the [ERC-721](about/terminology.md#erc-721) standard with the core of those programs that work inside Solana.
diff --git a/docs/evm_compatibility/architectural_limitations/gas_calculator.md b/docs/evm_compatibility/architectural_limitations/gas_calculator.md
deleted file mode 100644
index 547a43bd..00000000
--- a/docs/evm_compatibility/architectural_limitations/gas_calculator.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Neon and Ethereum Gas Calculators Give Different Results
----
-
-### Problem
-In Neon EVM, a calculator is implemented to account for the gas consumption.
-Despite the fact that this calculator is implemented in the same way as in Ethereum, sometimes it shows different results in gas calculations on tests.
-
-Since contracts for Neon EVM can be created using various languages (including *Solidity/Viper*), these contracts can implement their own gas counting method.
-
-Let's assume that the Ethereum network contract implements the following operations:
- * Calculation of gas consumption using their own methods.
- * Calculation of gas consumption using the EVM calculator.
- * Comparison of the results obtained.
-
-Since the results may be different, this method will not work.
-
-At the moment, the following is known about this bug:
- * The error is in the Neon EVM code.
- * The error does not affect the stability of the code.
- * The error appears if:
- * a contract independently calculates gas consumption.
- * in the contract, the calculation is checked with issuing a message like this: "the gas has been calculated correctly".
-
-Due to a bug in the Neon EVM code, the result of such checks may be incorrect.
-
-### When will the bug be fixed?
-Investigating and fixing the bug will start after MVP on Mainnet.
diff --git a/docs/evm_compatibility/architectural_limitations/precompiled_contracts.md b/docs/evm_compatibility/architectural_limitations/precompiled_contracts.md
deleted file mode 100644
index d4327000..00000000
--- a/docs/evm_compatibility/architectural_limitations/precompiled_contracts.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Precompiled Contracts That Can't Be Used in Solana
----
-
-### Problem
-Contracts written in the Solidity language cannot work in Solana if they contain calls to the following precompiled contracts:
- * *[bigModExp](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-198.md)* — Used for efficient [RSA](about/terminology.md#rivest-shamir-adleman-rsa) verification inside of EVM, as well as other forms of number theory-based cryptography.
- * *[bn256Add](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-196.md)* — Performs addition on the elliptic curve operations.
- * *[bn256ScalarMult](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-196.md)* — Performs scalar multiplication on the elliptic curve operations.
- * *[bn256Pairing](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-197.md)* — Elliptic curve pairing operations to perform [zkSTARKs](about/terminology.md#zk-stark) verification within the block gas limit.
-
-The Neon EVM requires the implementation of system calls in Solana for these contracts.
-
-### Details
-A Solidity contract can contain calls to functions supported by the EVM itself. For example, to perform operations such as addition, subtraction, obtaining a hash block, a contract can use methods implemented in the EVM. Each called function is an *operation-code*. The EVM contains some such codes (in a limited number).
-
-To increase the number of such functions, precompiled contracts implemented inside the blockchain core are used. Since these contracts are written in Solidity, their use requires an increased consumption of resources (i.e. gas). The Neon EVM contains several pieces of the program code where calls to these precompiled contracts can occur.
-
-If the program enters such places, the Neon EVM does not create a new contract, but calls an already-compiled contract from the blockchain core. Although these functions are called within the core, in the code it is like calling another contract. Since this code is executed directly in the core, it is resource-intensive.
-
-Currently there are several precompiled contracts implemented as *bpf-code*. When calling these contracts, a lot of *bpf-instructions* are used, and therefore the transaction size limit may be exceeded.
-
-### Solution
-In order for the precompiled contracts to be used in Solana, it is proposed to implement sys-calls inside the Solana core. That is, to perform an implementation similar to the *erc-recover* implementation.
-
-### Implementation Strategy
-1. Prepare the necessary changes to support precompiled contracts in the Solana core.
-2. Create *pull requests* for the Solana core to make these improvements.
-3. Test changes in Testnet.
-4. Test changes in Devnet.
-5. Test changes in Mainnet.
-6. Update the Neon EVM to support these precompiled contracts.
diff --git a/docs/evm_compatibility/architectural_limitations/restriction_on_iterative_trx.md b/docs/evm_compatibility/architectural_limitations/restriction_on_iterative_trx.md
deleted file mode 100644
index d689898a..00000000
--- a/docs/evm_compatibility/architectural_limitations/restriction_on_iterative_trx.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Restriction on Iterative Transactions
----
-
-Executing a transaction in iterative mode is a sequence of actions, each of which is performed by a separate account specified in it. The list of accounts is specified by the creator of the transaction.
-
-### Description of the Problem
-When executing a transaction in iterative mode via the Neon EVM, a user may receive the error with a message about a blocked account. In this case, further execution of the transaction is terminated. This can happen despite the fact that the execution of the same transaction on Ethereum completes successfully, which is confusing for users since they are sure of the correctness of the transaction they have created.
-
-### Details
-The error is not typical for Ethereum and only appears in the Neon EVM. The reason for the error with the message about blocked accounts lies in the processing of iterative transactions in the Neon EVM.
-
-Processing an iterative transaction in the Neon EVM:
- * The Neon EVM receives the transaction for iterative execution and first marks the accounts specified in it for blocking.
- * When the next transaction enters the Neon EVM, the list of accounts specified in it and involved in its execution is viewed. If at this moment any listed account is in a blocked state for iterative execution in another transaction, the Neon EVM returns the error.
- * The first transaction that blocked accounts will unblock the accounts only when it is completed.
-
-The point of this implementation for Mainnet is to have a consistent state for Solana accounts during the execution of the transaction until it is completed. Since the transaction is executed in iterative mode, there are time intervals between the steps being executed. Therefore, such a solution excludes the possibility of changing the data of Solana's accounts located in system state during these intervals.
-
-### Solution
-Issuing the error about blocked accounts when starting a transaction is a temporary workaround solution. The final decision will be made after MVP on Mainnet.
diff --git a/docs/evm_compatibility/architectural_limitations/storage_size_for_account.md b/docs/evm_compatibility/architectural_limitations/storage_size_for_account.md
deleted file mode 100644
index c9281c0f..00000000
--- a/docs/evm_compatibility/architectural_limitations/storage_size_for_account.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Storage Size Limit for an Account
----
-
-### Problem
-In Solana, the size of storage allocated for an account has a limit and it can not exceed *10 MB*. This means that the storage size of contracts placed on the account can also not exceed *10 MB*. This threshold value limits the amount of records in a contract and can be an inconvenience to users.
-
-### Suggested Solutions
-*Solution 1*. In Neon EVM storage, it is proposed to increase the amount of accounts by *1*. The implementation of this solution will be considered by the Neon EVM developers.
-
-*Solution 2*. In Solana storage, it is proposed to increase the threshold value of the account size to more than *10 MB*. The implementation of this solution will be proposed by the Solana developers.
-
-The *10 MB* limit means that about *100,000* records can be used by the contract for its data. This limitation is set directly in Solana. It is large enough and not critical. At the startup of the [MVP](about/terminology.md#minimum-viable-product-mvp) project, we do not expect contracts with sizes exceeding *10 MB* to appear.
-
-Therefore, in the first months of Neon EVM operation, the limit on the storage size allocated for one account will remain at *10 MB*.
diff --git a/docs/evm_compatibility/architectural_limitations/unsupported_functions.md b/docs/evm_compatibility/architectural_limitations/unsupported_functions.md
deleted file mode 100644
index 61ace482..00000000
--- a/docs/evm_compatibility/architectural_limitations/unsupported_functions.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Unsupported Functions in the Neon EVM
----
-
-The Neon EVM doesn't support the following functions:
- * `gas_price(&self)`
- * `block_hash(&self, number: U256)`
- * `block_coinbase(&self)`
- * `block_dificulty(&self)`
- * `block_gas_limit(&self)`
-
-### Why are these features temporarily not supported?
-Calling each of these functions mistakenly returns zero instead of the expected ones. The reason for the behavior of these functions is a bug in the Neon EVM program code.
-
-### When will these features be supported?
-Investigating and fixing the bug will start after MVP on Mainnet.
diff --git a/docs/evm_compatibility/code_compatibility_checklist.md b/docs/evm_compatibility/code_compatibility_checklist.md
new file mode 100644
index 00000000..082ac3b5
--- /dev/null
+++ b/docs/evm_compatibility/code_compatibility_checklist.md
@@ -0,0 +1,118 @@
+---
+title: 'Smart Contract Code Compatibility Checklist'
+proofedDate: na
+iterationBy: HB
+includedInSite: false
+approvedBy: na
+comments: na
+---
+
+## Introduction
+
+This page details the smart contract code compatibility factors that determine whether the smart contracts are fully compatible with Neon EVM or not.
+
+## Smart contract compatibility factors
+
+The following are the factors that determine the smart contract code compatibility with Neon EVM and the alternative solutions -
+
+### Solidity Compiler version
+
+If the contracts are not clean fork like Uniswap V2 or Aave V2 and the solidity compiler is very old i.e. < 0.8.x, it is always recommended to upgrade to the latest stable solidity compiler version and re-run the tests.
+:::info
+Solidity version ≥ 0.8.25 is not supported currently because of the need to implement EIP-5656 and EIP-1153. It will be supported on Devnet and Mainnet soon.
+:::
+
+### Usage of third-party protocols
+
+There shouldn't be any usage of third party protocols that are not currently supported on Neon EVM.
+
+### Usage of `block.number` and `block.timestamp`
+
+1. `block.timestamp` and `block.number` shouldn't be used as an array or mapping key. More details can be found [here](https://docs.neonevm.org/docs/evm_compatibility/overview#limitation-on-blocktimestamp--blocknumber-usage)
+
+2. `block.timestamp` and `block.number` shouldn't be used as an argument in `create2`(Deterministic deployments) since deterministic addresses are calculated based on the arguments provided.
+
+### Usage of non-reentrancy safe methods `transfer()` and `send()`
+
+`transfer()` and `send()` are not considered as reentrancy safe methods in Neon EVM. This is described [here](https://docs.neonevm.org/docs/evm_compatibility/overview#reentrancy-safe-approaches). It is recommended to use `call()` as an alternative for native token transfers.
+
+```sh
+contract Vulnerable {
+ function withdraw(uint256 amount) external {
+ // This forwards 2300 gas, which may not be enough if the recipient
+ // is a contract and gas costs change.
+ msg.sender.transfer(amount);
+ }
+}
+
+contract Fixed {
+ function withdraw(uint256 amount) external {
+ // This forwards all available gas. Be sure to check the return value!
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success, "Transfer failed.");
+ }
+}
+```
+
+### Usage of unsupported OpCodes
+
+There shouldn't be any usage of unsupported opcodes -
+
+1. `gasleft()` or `gas()`
+2. `block.coinbase`
+3. `block.difficulty` / `block.prevrandao`
+4. `block.gaslimit`
+5. `block.basefee`
+6. `selfdestruct` - The opCode behind this method will be deprecated soon. This can be mostly seen with the projects that uses [Seaport marketplace protocol](https://github.com/ProjectOpenSea/seaport/blob/main/contracts/zones/PausableZone.sol#L110). However, if `selfdestruct` is used only for tests/ mocks, this can be skipped.
+
+The details of the unsupported opcodes are described [here](https://docs.neonevm.org/docs/evm_compatibility/opcodes).
+
+### Usage of `multicall` methods
+
+The smart contracts having `multicall` methods that includes more than one address or migration methods to recreate state from another chain results in exceeding the 64 accounts limit. This situation can be avoided by calling these methods in batches.
+
+:::info
+The restriction of 64 accounts doesn't translate directly to 64 addresses in Solidity. The limit may further decrease if there are additional internal calls between contracts.
+:::
+
+### Emitting big events data
+
+Smart contracts shouldn't emit big data through events such as an array of bytes or strings or a single bytes or string variable through a `multicall` method, which eventually generates a big event log if there are a lot of multicall iterations.
+
+Every Solana transaction which corresponds to a particular Neon EVM transaction, subject to an event limit of 128K bytes. If the transaction execution is in iterative mode, each Solana transaction within this process maintains a 128K byte limit for event logs.
+
+If the data emitted by an event is more than 128K bytes, the transaction won't get reverted, but some of the event data won't be stored on-chain, causing some inconsistencies in the data stored.
+
+### Usage of dynamic sized variable types
+
+In Solidity versions before `0.8.15`, there is a limitation when using dynamic-sized variable types, such as `string` and `bytes`, as mapping values in functions invoked multiple times. This issue arises because reusing the same parameters of these types in transactions leads to increased consumption of Solana accounts.
+
+For example:
+
+```sh
+// SPDX-License-Identifier: MIT
+pragma solidity >=0.7.0 <0.9.0;
+
+contract MappingActions {
+ mapping(uint256 => string) public mapping1;
+ mapping(uint256 => bytes) public mapping2;
+
+ function testMapping1() external {
+ for (uint256 i = 0; i < 45; ++i) {
+ mapping1[i] = 'Test 123 Hello';
+ }
+ }
+
+ function testMapping2() external {
+ for (uint256 i = 0; i < 45; ++i) {
+ mapping2[i] = '0x1';
+ }
+ }
+}
+```
+
+The transaction will fail with the error `Too many accounts` if the functions `testMapping1()` and `testMapping2()` are invoked more than once.
+
+## Support
+
+Should you require further advice to help troubleshoot, create a ticket in the support-tickets channel in [Neon's Discord](https://discord.gg/neonevm).
diff --git a/docs/evm_compatibility/img/false-copy.png b/docs/evm_compatibility/img/false-copy.png
new file mode 100644
index 00000000..127535ac
Binary files /dev/null and b/docs/evm_compatibility/img/false-copy.png differ
diff --git a/docs/evm_compatibility/json_rpc_api_methods.md b/docs/evm_compatibility/json_rpc_api_methods.md
index bad5ba64..1afe0717 100644
--- a/docs/evm_compatibility/json_rpc_api_methods.md
+++ b/docs/evm_compatibility/json_rpc_api_methods.md
@@ -1,10 +1,19 @@
---
title: JSON-RPC API Methods
+proofedDate: na
+iterationBy: HB
+includedInSite: true
+approvedBy: na
+comments: TODOs inline
---
-*The following tables present the full list of JSON-RPC methods. Each of them is in one of the states:*
+This page presents the full list of JSON-RPC methods. Each of them is in one of three states:
-|| — done| | — in progress| | — to do|
+
+
+|| — done| | — in progress| | — not supported|
|--|--|--|--|--|--|
## JSON-RPC Methods According to [Ethereum Client API](https://ethereum.org/en/developers/docs/apis/json-rpc/)
@@ -16,30 +25,30 @@ title: JSON-RPC API Methods
| 2 | [eth_getBlockByNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber) | _Returns information about a block by number_ |  |
| 3 | [eth_getBlockTransactionCountByHash](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblocktransactioncountbyhash) | _Returns the number of transactions in a block from a block matching the given block hash_ |  |
| 4 | [eth_getBlockTransactionCountByNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblocktransactioncountbynumber) | _Returns the number of transactions in a block matching the given block number_ |  |
-| 5 | [eth_getUncleCountByBlockHash](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclecountbyblockhash) | _Returns the number of uncles in a block from a block matching the given block hash_ |  |
-| 6 | [eth_getUncleCountByBlockNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclecountbyblocknumber) | _Returns the number of uncles in a block from a block matching the given block number_ |  |
-| 7 | [eth_protocolVersion](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_protocolversion) | _Returns the current Ethereum protocol version_ |  |
+| 5 | [eth_getUncleCountByBlockHash](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclecountbyblockhash) | _Returns the number of uncles in a block from a block matching the given block hash_ |  |
+| 6 | [eth_getUncleCountByBlockNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getunclecountbyblocknumber) | _Returns the number of uncles in a block from a block matching the given block number_ | |
+| 7 | [eth_protocolVersion](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_protocolversion) | _Returns the current Ethereum protocol version_ |  |
| 8 | [eth_chainId](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_chainid) | _Returns the chain ID of the current network_ |  |
-| 9 | [eth_syncing](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_syncing) | _Returns an object with data about the sync status or false_ |  |
-| 10 | [eth_coinbase](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_coinbase) | _Returns the client coinbase address_ |  |
+| 9 | [eth_syncing](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_syncing) | _Returns an object with data about the sync status or false-copy_ |  |
+| 10 | [eth_coinbase](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_coinbase) | _Returns the client Coinbase address_ |  |
| 11 | [eth_accounts](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_accounts) | _Returns a list of addresses owned by client_ |  |
| 12 | [eth_blockNumber](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_blocknumber) | _Returns the number of most recent block._ |  |
-| 13 | [eth_call](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_call) | _Executes a new message call immediately without creating a transaction on the block chain_ |  |
+| 13 | [eth_call](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_call) | _Executes a new message call immediately without creating a transaction on the blockchain_ |  |
| 14 | [eth_estimateGas](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_estimategas) | _Generates and returns an estimate of how much gas is necessary to allow the transaction to complete._ |  |
| 15 | [eth_gasPrice](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gasprice) | _Returns the current price per gas in wei_ |  |
-| 16 | [eth_feeHistory](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_feehistory) | _Returns fee history_ |  |
-| 17 | [eth_newFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newfilter) | _Creates a filter object, based on filter options, to notify when the state changes (logs)_ |  |
-| 18 | [eth_newBlockFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newblockfilter) | _Creates a filter in the node, to notify when a new block arrives_ |  |
+| 16 | [eth_feeHistory](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_feehistory) | _Returns fee history_ |  |
+| 17 | [eth_newFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newfilter) | _Creates a filter object, based on filter options, to notify when the state changes (logs)_ |  |
+| 18 | [eth_newBlockFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newblockfilter) | _Creates a filter in the node, to notify when a new block arrives_ |  |
| 19 | [eth_newPendingTransactionFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_newpendingtransactionfilter) | _Creates a filter in the node, to notify when new pending transactions arrive_ |  |
| 20 | [eth_uninstallFilter](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_uninstallfilter) | _Uninstalls a filter with given id_ |  |
-| 21 | [eth_getFilterChanges](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterchanges) | _Polling method for a filter, which returns an array of logs which occurred since last poll_ |  |
-| 22 | [eth_getFilterLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterlogs) | _Returns an array of all logs matching filter with given id. Can compute the same results with an `eth_getLogs call`_ |  |
+| 21 | [eth_getFilterChanges](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterchanges) | _Polling method for a filter, which returns an array of logs which occurred since last poll_ |  |
+| 22 | [eth_getFilterLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterlogs) | _Returns an array of all logs matching filter with given id. Can compute the same results with an `eth_getLogs call`_ |  |
| 23 | [eth_getLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs) | _Anytime a transaction is mined, we can see event logs for that transaction by making a request to eth_getLogs and then take actions based off those results_ |  |
| 24 | [eth_mining](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_mining) | _Returns whether the client is actively mining new blocks_ |  |
| 25 | [eth_hashrate](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_hashrate) | _Returns the number of hashes per second that the node is mining with_ |  |
| 26 | [eth_getWork](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getwork) | _Returns the hash of the current block, the seedHash, and the boundary condition to be met ("target")_ |  |
-| 27 | [eth_submitWork](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_submitwork) | _Used for submitting a proof-of-work solution_ |  |
-| 28 | [eth_submitHashrate](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_submithashrate) | _Used for submitting mining hashrate_ |  |
+| 27 | [eth_submitWork](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_submitwork) | _Used for submitting a Proof-of-Work solution_ |  |
+| 28 | [eth_submitHashrate](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_submithashrate) | _Used for submitting mining hashrate_ |  |
| 29 | [eth_sign](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_sign) | _Returns an EIP-191 signature over the provided data._ |  |
| 30 | [eth_signTransaction](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_signtransaction) | _Signs and submits a transaction_ |  |
| 31 | [eth_getBalance](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getbalance) | _Returns the balance of the account of given address_ |  |
@@ -53,8 +62,9 @@ title: JSON-RPC API Methods
| 39 | [eth_getTransactionByBlockNumberAndIndex](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionbyblocknumberandindex) | _Returns information about a transaction by block number and transaction index position_ |  |
| 40 | [eth_getTransactionReceipt](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_gettransactionrecepit) | _Returns the receipt of a transaction by transaction hash_ |  |
+Methods `eth_getTransactionByHash`, `eth_getTransactionByBlockHashAndIndex`, `eth_getTransactionByBlockNumberAndIndex`, `eth_getBlockByHash` and `eth_getBlockByNumber` also return the `chainId` property in addition to the [specified](https://ethereum.org/en/developers/docs/apis/json-rpc) output.
-## JSON-RPC Methods According to [the Web3 Module API](https://openethereum.github.io/JSONRPC-web3-module)
+## JSON-RPC methods according to the [Web3 Module API](https://openethereum.github.io/JSONRPC-web3-module)
| Num | Method | Description | Status |
|-----|----------------------------------------------------------------------------------------------|------------------------------------------------------------------------|--------------------------------|
@@ -63,10 +73,10 @@ title: JSON-RPC API Methods
-## JSON-RPC Methods According to [the Net Module API](https://openethereum.github.io/JSONRPC-net-module)
+## JSON-RPC methods according to the [Net Module API](https://openethereum.github.io/JSONRPC-net-module)
| Num | Method | Description | Status |
|-----|----------------------------------------------------------------------------------|------------------------------------------------------------------------|--------------------------------|
| 1 | [net_listening](https://openethereum.github.io/JSONRPC-net-module#net_listening) | _Returns true if client is actively listening for network connections_ |  |
-| 2 | [net_peerCount](https://openethereum.github.io/JSONRPC-net-module#net_peercount) | _Returns number of peers currenly connected to the client_ |  |
-| 3 | [net_version](https://openethereum.github.io/JSONRPC-net-module#net_version) | _Returns the current network protocol version._ |  |
+| 2 | [net_peerCount](https://openethereum.github.io/JSONRPC-net-module#net_peercount) | _Returns number of peers currently connected to the client_ |  |
+| 3 | [net_version](https://openethereum.github.io/JSONRPC-net-module#net_version) | _Returns the current network protocol version_ |  |
diff --git a/docs/evm_compatibility/opcodes.md b/docs/evm_compatibility/opcodes.md
new file mode 100644
index 00000000..022e4d03
--- /dev/null
+++ b/docs/evm_compatibility/opcodes.md
@@ -0,0 +1,27 @@
+---
+title: OpCodes
+proofedDate: na
+iterationBy: HB
+includedInSite: true
+approvedBy: na
+comments:
+---
+
+Neon EVM supports the majority of the [Ethereum OpCodes](https://ethereum.org/en/developers/docs/evm/opcodes/) verbatim. This page presents those OpCodes that are *not* supported verbatim as they're adapted for use in the Neon EVM.
+
+
+|Stack|Name|Description|
+|--|--|--|
+|41|COINBASE|always returns zero|
+|44|PREVRANDAO (FKA DIFFICULTY)|always returns zero|
+|45|GASLIMIT|always returns U256::MAX|
+|48|BASEFEE|always returns zero|
+|5A|GAS|returns the gas limit in the transaction instead of remaining gas|
+
+
+
+
+
+
+
+
diff --git a/docs/evm_compatibility/overview.md b/docs/evm_compatibility/overview.md
index b4eed274..20e7c815 100644
--- a/docs/evm_compatibility/overview.md
+++ b/docs/evm_compatibility/overview.md
@@ -1,34 +1,166 @@
---
title: EVM Compatibility Overview
+proofedDate: na
+iterationBy: HB
+includedInSite: true
+approvedBy: na
+comments: Missing -- details of tracer for source of historical data. Where in docs can this live?
---
-Neon EVM is designed to be compatible with the [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/) to provide a as seamless of a developer experience as possible, with some notable differences and considerations.
+import heap from '@site/static/img/doc-images/evm-compat/heap-overflow-error.png';
-## Shared Features
-Coming from Ethereum, your Solidity smart contracts, development and deployment tools, and standard practices can be moved over to Neon EVM with almost no code changes. Neon EVM accounts follow [Ethereum's account standards](https://ethereum.org/en/developers/docs/accounts/). All [Ethereum opcodes](https://www.evm.codes/?fork=merge) are represented verbatim on Neon EVM.
-### JSON RPC API
-Neon EVM follows Ethereum's standard RPC API and a list of all the JSON RPC API methods that Neon EVM supports can be found [here](./json_rpc_api_methods). They are based on the Ethereum Client API, the Web3 Module API, and the Net Module API.
+## TL;DR
+
+- Apply (most of) Ethereum's standard [JSON RPC API methods](/docs/evm_compatibility/json_rpc_api_methods)
+- Direct the calls to a [Neon RPC](/docs/developing/connect_rpc) via a Proxy Operator
+- Solana and Ethereum differ: consider those differences and the limitations they enforce
+- EIP-1559 not supported
+
+## Introduction
+
+Interacting with Neon EVM is essentially the same as interacting with any [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/).
+
+Neon EVM provides a proxy service that accepts [Ethereum's standard RPC API methods](https://ethereum.github.io/execution-apis/api-documentation/).
+
+> Your dApp can apply familiar methods: with your calls directed to the [Neon Proxy](../about/neon_ecosystem.mdx#neon-proxy) rather than an Ethereum L1 node.
+
+In this way, Neon EVM provides a seamless developer experience. Note that there are some differences and considerations due to some signigicant differences between Solana transaction requirements and the equivalent in EVM.
+
+## Shared standards and features
+
+Solidity or Vyper smart contracts, standard development and deployment tools and practices can all be applied on Neon EVM with minimal reconfiguration of the code.
+
+- Neon EVM accounts follow [Ethereum's account standards](https://ethereum.org/en/developers/docs/accounts/)
+
+> Only a few [OpCodes](#opcodes) are not handled verbatim.
+
+- Neon EVM supports type 0 / legacy transaction requests
+
+> An Ethereum transaction request is either formed as an EIP-1559 transaction or a legacy transaction. For now, the Neon EVM accepts the legacy/type 0 and type 1 transaction formats.
+
+- Apply Ethereum's standard JSON RPC API based on the Ethereum Client API, the Web3 Module API, and the Net Module API
+
+> See the [supported JSON RPC API methods](./json_rpc_api_methods).
+
+## Notable differences
+
+Interoperability between Solana and Ethereum EVMs requires certain adaptations. In addition to Solana-specific restrictions, two major differences include:
### Precompiles
-Neon supports all precompiled contracts defined on [evm.code](https://www.evm.codes/precompiled?fork=merge) that provide more advanced functionalities, but there are [certain limitations](./precompiles#limitations) on some precompiled contracts on Neon EVM.
-## Gas Calculation
-The mechanism of gas consumption and calculation of gas fees on Neon EVM differ from Ethereum. Gas fees on Neon EVM are much cheaper than on Ethereum. You can learn more about the NEON token and how gas fees work on Neon EVM [here](../../docs/tokens/gas_fees.md).
+Neon supports all precompiled contracts defined on [evm.code](https://www.evm.codes/precompiled?fork=merge) that provide more advanced functionalities, with [certain limitations](./precompiles#limitations) on some precompiled contracts on Neon EVM.
+
+Neon also supports native precompiled contracts that are available to our users.
+
+
+
+### Opcodes
+
+While the majority of OpCodes are supported verbatim, there are some that are handled differently. Learn about those [variant OpCodes](opcodes).
+
+### Gas calculation
+
+The mechanism of gas consumption and calculation of gas fees on Neon EVM differ from Ethereum. Gas fees on Neon EVM are much cheaper than on Ethereum because Solana is the settlement layer.
+
+> Learn more about the [NEON token and how gas fees work on Neon EVM](../../docs/tokens/gas_fees).
+
+### Reentrancy-safe approaches
+
+:::caution
+
+Due to the difference in how gas is calculated in Neon EVM, Solidity's transfer() and send() are NOT reentrancy safe methods.
+:::
+
+Hardcoding gas is one method that programmers may apply to prevent reentrancy attacks. Within the Ethereum/Solidity ecosystem, it is possible to default gas to 2300 gwei by using `transfer()`and `send()`. However, since gas costs are now variable, these methods are [no longer advised](https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/).
+
+### Storage
+
+Several Solana-specific differences also impact smart contract development. In Ethereum EVMs, there are two types of accounts, both of which are associated with a storage map which can be used to read and write arbitrary data:
+
+- Basic accounts store an account balance
+- Code accounts store EVM code
+
+Solana’s Sealevel also provides two accounts which are assigned up to 256 consecutive storage slots; but they have different purposes:
-## Other Neon-Specific Limitations
+ - Executable
-### Number of Accounts
-Solana requires that all accounts used in a transaction be specified in order to ensure parallel execution of transactions. Using [Solana Transaction V2](https://docs.solana.com/proposals/transactions-v2), up to 64 accounts can be used in a single transaction. As Neon EVM uses Solana Transaction V2, it has the same limitation: the maximum number of accounts used in a single transaction is 64.
+ > Executable accounts provide immutable storage of executable byte code or an (immutable) proxy address of an account which stores mutable executable byte code.
-### Heap Size
-Ethereum-like transactions are executed by Neon EVM inside [Solana's Berkeley Packet Filter (BPF)](https://docs.solana.com/developing/on-chain-programs/overview#berkeley-packet-filter-bpf). The BPF has a limit on heap memory of 256 KB. Consequently, the size of the heap allocated to a contract call, is limited to the same 256 KB.
+ - Non-executable
-To avoid the occurrence of a heap overflow error, it is recommended that you:
-* Reduce the size of the call stack
-* Reduce the number of variables used
+> Since executable accounts are immutable, their application state is stored in non-executable accounts.
+
+The differences go deeper still. In an Ethereum EVM, contracts can only read and write their own storage. In Sealevel, any account’s data can be read or written to by a contract. However, the runtime enforces that only an account’s “owner” is allowed to modify it. Changes by any other programs will be reverted and cause the transaction to fail.
+
+
+### Upper limit on number of accounts
+
+When a contract requires storage slots within Solana, it may create Solana accounts and access these random addresses. However, this must be done with an awareness of the upper limit on the number of accounts.
+
+Neon EVM uses [Solana Transaction V0](https://docs.solana.com/developing/versioned-transactions): limiting the maximum number of accounts used in a single transaction to 64. Solana requires that all accounts used in a transaction be specified in order; to enable parallel execution of transactions.
+
+
+:::info
+Each Ethereum account involved in a transaction must be mapped to a corresponding Solana account. Any call made to the Ethereum account (e.g. to read balance, execute a transaction, etc.) requires that the Solana account is included to make use of the storage provided.
+
+:::
+
+
+
+By constructing the contract logic differently, fixed-sized values and arrays can fit into a significantly smaller number of accounts.
+
+```Solidity
+ /*1 account: */
+uint256[] list;
+...
+
+for (uint256 i = 0; i < 32; i++) {
+ list[i] = i;
+}
+```
+
+```Solidity
+/* 32 accounts: */
+mapping(uint256 => uint256) map;
+...
+
+for (uint256 i = 0; i < 32; i++) {
+ map[i] = i;
+}
+```
+
+
+
+### Heap size
+Ethereum-like transactions are executed by Neon EVM inside [Solana's Berkeley Packet Filter (BPF)](https://solana.com/docs/core/programs#berkeley-packet-filter-bpf). The BPF has heap memory limit of 256 KB, i.e. the size of the heap allocated to a contract call, is limited to 256 KB.
+
+:::info
+
+This [Neon transaction](https://neonscan.org/tx/0x6bdc50921eaa8981e2f534e09139840fd176bf092bd835393ee4bab998409c0a) failed due to a heap overflow error. By viewing the [transaction on Sol scan](https://solscan.io/tx/3fuTXn8SiAwTrpG96VmhvuHQe9tssFv7y2yHFynVpM4d51uBZerehxZebPTFvKLs8b2wmnXmhxu5yhAwWdnUJLVC?cluster=devnet) you can access the log for the final (failing) transactions and view the "out of memory" errors.
+
+
+
+:::
+
+Consider the following techniques if you need to troubleshoot a heap overflow error:
+
+- Transactions: reduce the calldata size
+- Deploying/calling contracts, reduce the:
+ - Call depth
+ - Contract binary size
+ - Size of the function/constructor arguments
+- Event emission
+ - Use indexed parameters
+ - Avoid strings, arrays, and mappings
+- Returning values from a function
+ - Don't return data you don't use!
+ - Avoid strings, arrays, and mappings
+- Local variables: avoid strings, arrays, and mappings
+
+
+### Limitation on `block.timestamp` / `block.number` usage
-### Limitation on `block.timestamp` / `block.number` Usage
Time-related methods in addresses for mapping indexes, namely `block.timestamp` and `block.number`, behave differently from Ethereum and developers are **strongly cautioned** against using them when developing on Neon EVM.
The following code snippet is correct on Ethereum, but is **not** correct on Neon, due to the usage of `block.timestamp`.
@@ -38,3 +170,7 @@ function create_new_element_timestamp() external {
test_mapping[block_timestamp] = 100;
}
```
+
+## Support
+
+Should you require further advice to help troubleshoot, create a ticket in the support-tickets channel in [Neon's Discord](https://discord.gg/neonevm).
diff --git a/docs/evm_compatibility/precompiles.md b/docs/evm_compatibility/precompiles.md
index 588b2236..00ca4be0 100644
--- a/docs/evm_compatibility/precompiles.md
+++ b/docs/evm_compatibility/precompiles.md
@@ -1,17 +1,25 @@
---
title: Precompiles
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: We need to get the custom precompile addresses
---
-## Precompiled Contracts Supported by Neon
-Currently, Neon supports a variety of precompiled contracts. These include:
+## Precompiled EVM contracts
-* https://www.evm.codes/precompiled?fork=merge
+Currently, Neon EVM supports the majority of [precompiled contracts](https://www.evm.codes/precompiled?fork=merge)
-## Limitations
-However, there are some precompiled contracts that Neon does not support. Contracts written in the Solidity language will not work on Solana if they contain calls to the following precompiled contracts:
-* bigModExp — Used for efficient RSA verification inside of EVM, as well as other forms of number theory-based cryptography.
-* bn256Add — Performs addition on the elliptic curve operations.
-* bn256ScalarMult — Performs scalar multiplication on the elliptic curve operations.
-* bn256Pairing — Elliptic curve pairing operations to perform zkSTARKs verification within the block gas limit.
-
-The Neon EVM requires the implementation of system calls in Solana for these contracts.
+| Address | Name | Compatibility |
+| ------- | ---------------- | ------------------------------------ |
+| 0x01 | ecRecover |  |
+| 0x02 | SHA2-256 |  |
+| 0x03 | RIPEMD-160 |  |
+| 0x04 | identity |  |
+| 0x05 | modexp |  |
+| 0x06 | ecAdd |  |
+| 0x07 | ecMul |  |
+| 0x08 | ecPairing |  |
+| 0x09 | blake2f |  |
+| 0x0a | point evaluation |  |
diff --git a/docs/faq/couldnt-find-answer.md b/docs/faq/couldnt-find-answer.md
deleted file mode 100644
index 153b135b..00000000
--- a/docs/faq/couldnt-find-answer.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: I couldn't find an answer to my question
----
-
-I have a question about the Neon EVM that is not answered in the FAQ. What do I do?
-
-Feel free to join our [Discord server](https://discord.gg/WafwJrwBvh). Our team will be glad to help you find the answer to your question.
diff --git a/docs/faq/how-does-neon-work.md b/docs/faq/how-does-neon-work.md
deleted file mode 100644
index a4cebc16..00000000
--- a/docs/faq/how-does-neon-work.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: How does Neon work?
----
-
-* [How does Neon the EVM interact with Solana?](#how-does-the-neon-evm-interact-with-solana)
-* [How does the Neon EVM contract work?](#how-does-the-neon-evm-contract-work)
-* [How does the Neon EVM enable the parallel execution of transactions?](#how-does-the-neon-evm-enable-the-parallel-execution-of-transactions)
-* [What types of transactions can be executed in parallel?](#what-types-of-transactions-can-be-executed-in-parallel)
-* [What types of transactions are executed iteratively the by Neon EVM, and why?](#what-types-of-transactions-are-executed-iteratively-by-the-neon-evm-and-why)
-* [How do you ensure that iterative transactions are finalized by the Neon EVM operator?](#how-do-you-ensure-that-iterative-transactions-are-finalized-by-the-neon-evm-operator)
-* [Why are Solana accounts "blocked" when iterative execution begins?](#why-are-solana-accounts-blocked-when-iterative-execution-begins)
-* [Is the Neon EVM compatible with native Solana contracts such as SPL tokens?](#is-the-neon-evm-compatible-with-native-solana-contracts-such-as-spl-tokens)
-* [Is it possible to call a function of a contract running on the Neon EVM from other Solana contracts?](#is-it-possible-to-call-a-function-of-a-contract-running-on-the-neon-evm-from-other-solana-contracts)
-* [How are Neon EVM gas fees calculated?](#how-are-neon-evm-gas-fees-calculated)
-* [How are gas costs paid on the Neon EVM?](#how-are-gas-costs-paid-on-the-neon-evm)
-* [What are NEON tokens used for?](#what-are-neon-tokens-used-for)
-* [Why do transactions go through the Neon Web3 Proxy before the Neon EVM by default?](#why-do-transactions-go-through-the-neon-web3-proxy-before-the-neon-evm-by-default)
-* [What does it mean to "send a Solana transaction directly to a Solana node without the Neon Web3 Proxy"?](#what-does-it-mean-to-send-a-solana-transaction-directly-to-a-solana-node-without-the-neon-web3-proxy)
-* [How can Neon transactions be performed without the Neon Web3 Proxy?](#how-can-neon-transactions-be-performed-without-the-neon-web3-proxy)
-* [I am a dApp developer and I don't want to use the Neon Web3 Proxy. How will this impact my project?](#i-am-a-dapp-developer-and-i-dont-want-to-use-the-neon-web3-proxy-how-will-this-impact-my-project)
-* [Are proxies custodial?](#are-proxies-custodial)
-* [How do accounts work in the Neon EVM?](#how-do-accounts-work-in-neon-evm)
-* [Is arbitrary data stored on a remote host and simply executed on Solana?](#is-arbitrary-data-stored-on-a-remote-host-and-simply-executed-on-solana)
-* [Does the Neon EVM add complex virtualization requiring Solana validators to cooperatively execute Neon transactions across multiple blocks?](#does-the-neon-evm-add-complex-virtualization-requiring-solana-validators-to-cooperatively-execute-neon-transactions-across-multiple-blocks)
-* [How does the transfer of funds from Ethereum to the Neon EVM occur?](#how-does-the-transfer-of-funds-from-ethereum-to-the-neon-evm-occur)
-* [What infrastructure is available (wallets, blockchain explorers, oracles, etc.) for Neon EVM users?](#what-infrastructure-is-available-wallets-blockchain-explorers-oracles-etc-for-neon-evm-users)
-
-### How does the Neon EVM interact with Solana?
-
-The Alpha version of the Neon EVM has an interface that can interact with [SPL token](about/terminology.md#spl-token) accounts.
-The Beta version of the Neon EVM will have an interface that can read data from Solana accounts and will facilitate the integration of Neon EVM contracts with Oracles on Solana.
-In upcoming versions, Neon Labs plans to implement an interface for writing data to Solana accounts, which will allow the integration of Neon EVM contracts with Solana programs.
-
-The Neon EVM works as a smart contract on the Solana blockchain. The contract can interact with and call other
-smart contracts on Solana — for example, [SPL tokens](about/terminology.md#spl-token). The Neon EVM is able to access data stored on Solana accounts. Furthermore, every Ethereum-like account within the Neon EVM is stored in a corresponding Solana account.
-
-### How does the Neon EVM contract work?
-
-The Neon EVM is a smart contract on Solana acting as the Ethereum Virtual Machine. It is compiled into [Berkeley Packet Filter](about/terminology.md#berkeley-packet-filter-bpf) bytecode, a format that can be executed on Solana. This allows the Neon EVM to receive Solana transactions with wrapped Ethereum-like transactions and process them on Solana according to Ethereum rules.
-
-### How does the Neon EVM enable the parallel execution of transactions?
-
-Solana can process tens of thousands of contracts in parallel using as many cores as are available to its validator. This functionality is known as Sealevel. Parallel processing is possible because Solana transactions describe all the accounts a transaction will read or write while executing. This prevents transactions from overlapping, and allows independent transactions and those that are reading the same account to be executed concurrently.
-
-Regarding parallel processing on the Neon EVM, Neon transactions are wrapped into Solana transactions by the Neon Web3 Proxy. The Neon EVM program is a smart contract on Solana, so Solana loads the Neon EVM program for each Neon transaction. This allows them to be executed in parallel by Solana.
-
-### What types of transactions can be executed in parallel?
-
-Transactions that do not change/write data to the same Solana accounts can be executed in parallel
-
-### What types of transactions are executed iteratively by the Neon EVM, and why?
-
-The Solana blockchain limits the resources (instructions) allocated to the execution of a single transaction to ensure optimal usage of hardware. Due to this restriction, Neon transactions that exceed Solana's resource limit are executed iteratively by the Neon EVM.
-
-### How do you ensure that iterative transactions are finalized by the Neon EVM operator?
-
-Neon EVM operators deposit their own funds at the start of the execution of iterative transactions. If the transaction isn't fully executed by the original operator, the deposit and the user's fee are granted to another operator who finalizes it.
-
-Each operator has a financial interest in executing an operation that was not finalized by the original operator. This eliminates the appearance of unfinalized transactions.
-
-### Why are Solana accounts "blocked" when iterative execution begins?
-
-The "blocking" of Solana accounts supports the atomicity of entire Neon transactions by preventing modifications to the targeted accounts through other Neon transactions.
-
-### Is the Neon EVM compatible with native Solana contracts such as SPL tokens?
-
-Yes, the Neon EVM has compatibility with native Solana tokens.
-
-### Is it possible to call a function of a contract running on the Neon EVM from other Solana contracts?
-
-No, this is not possible in the Alpha version of the Neon EVM. We are working on an architecture that will allow the integration of Neon EVM contracts and Solana programs.
-
-### How are Neon EVM gas fees calculated?
-
-Neon EVM gas fees include three main components:
- 1. The cost of executing a Solana transaction, which depends on the number of signatures specified in the
-transaction.
- 2. A fee paid to the Neon EVM governance body for using the Neon EVM.
- 3. A fee paid to the Neon EVM operator that executes the transaction.
-
-### How are gas costs paid on the Neon EVM?
-
-Gas costs on the Neon EVM will be initially paid in NEON tokens. Eventually, payment will be accepted in NEON/ETH/ERC-20 at the discretion of the Neon EVM operator.
-
-### What are NEON tokens used for?
-
-The Neon economy is fee-based. The NEON token is a utility token that is needed to pay for the execution of Neon transactions. At launch, Neon governance will be handled by a multisig account whose keys are held by reputable individuals and entities with a vested interest in the success of Neon. Additionally, there will be a clear and user-friendly process for proposing and voting for protocol improvements.
-
-Shortly after Mainnet launch, Neon governance will transition to a DAO, and the NEON token will be used for governance purposes as well.
-
-### Why do transactions go through the Neon Web3 Proxy before the Neon EVM by default?
-
-The Neon Web3 Proxy performs two main functions:
- * The first function is to enable interactions between Ethereum clients and a Solana cluster. An Ethereum client doesn’t know anything about the interaction protocol for the Solana node. The Solana node doesn't know anything about Ethereum-like transactions. The Neon Web3 Proxy provides an Ethereum-like RPC endpoint for Ethereum clients. When an Ethereum client sends a Neon transaction to the Neon Web3 Proxy, the Proxy packs the Neon transaction into a Solana transaction and sends the Solana transaction to the Solana cluster for on-chain execution.
- * The second function is to process big Ethereum-like transactions. Solana limits the amount of resources for the execution of a single Solana transaction. If an Ethereum-like transaction requires a lot of compute units, it cannot be performed within a single Solana transaction.
-
-Therefore, the Neon EVM program saves the EVM state to the Solana storage, and when the Neon Web3 Proxy sends a command to the Solana cluster, the execution of the stored Neon transaction is renewed. So the Neon EVM program restores the EVM state on demand and continues the Neon transaction execution from the stopping point. This process continues until the Neon transaction is completed.
-
-### What does it mean to "send a Solana transaction directly to a Solana node without the Neon Web3 Proxy"?
-
-It means that a Neon user makes the Solana transactions needed to execute their Ethereum-like
-transactions on their own. In this use case, the Neon operator is excluded from the process.
-
-All fees tied to the Solana transactions for this use case must be paid for directly by the Neon user in SOL.
-
-### How can Neon transactions be performed without the Neon Web3 Proxy?
-
-The Solana transaction needs to be built on the client side (web/mobile) with a Neon transaction packed
-within it. The Solana transaction can then be sent directly to a Solana node without the Neon Web3 Proxy.
-
-When using this method, it’s important to understand that the sender (Neon user) is responsible for the
-following items:
-
-1. In cases where the Neon transaction is too large, it has to be executed [iteratively](architecture/value_token.md#token-circulation).
-2. A list of all Neon accounts and contracts corresponding to the Neon transaction needs to be determined
-on the client side.
-
-
-### I am a dApp developer and I don't want to use the Neon Web3 Proxy. How will this impact my project?
-
-The Neon Web3 Proxy can be implemented as a library, but implementation isn't simple. The most complex part of Neon Web3 Proxy implementation is the iterative transaction execution. The Neon Web3 Proxy forms Solana transactions, marking the number of VM steps to be executed without exceeding the BPF instruction limit of the Solana VM. The Neon Web3 Proxy traces the process of the Neon transaction execution, sending transactions for the continuation of the suspended Neon transaction, awaiting its full execution. So if you don't want to use the Neon Web3 Proxy, you will still need to implement its functionality in your client.
-
-### Are proxies custodial?
-
-Proxy operators are not gatekeepers. The Neon EVM ensures the independence of its operations by providing open access to its infrastructure to anyone who is willing to run and capable of running the Neon Web3 Proxy. Moreover, the Neon Web3 Proxy can be replaced with a client library by any Neon EVM client. The transactions received by the Neon EVM cannot be discriminated against because they do not have any attributes that determine their priority. The unchangeable nonce and user signature fields verified by the Neon EVM program guarantee the consistency of execution of Neon transactions and protect from re-execution.
-
-### How do accounts work in the Neon EVM?
-
-The Ethereum-like accounts are saved in Solana storage by the Neon EVM (Solana is agnostic to such data), and therefore there is no need to redesign or even to recompile Ethereum smart contracts.
-
-### Is arbitrary data stored on a remote host and simply executed on Solana?
-
-The Neon EVM stores all data in the Solana state. In terms of execution, the Neon EVM smart contract on Solana
-handles and processes arbitrary data.
-
-### Does the Neon EVM add complex virtualization requiring Solana validators to cooperatively execute Neon transactions across multiple blocks?
-
-The Neon EVM Web3 Proxy handles all the transaction structuring and conversion work automatically.
-There is no need for Solana validators to treat transactions from Neon EVM any differently. Anyone,
-including Neon EVM clients or users, can launch and run the Neon Web3 Proxy.
-
-### How does the transfer of funds from Ethereum to the Neon EVM occur?
-
-This transfer is facilitated by the Wormhole bridge.
-
-When ERC-20 tokens on layer 1 (L1) are sent across the Wormhole bridge, SPL tokens representing the
-ERC-20 tokens are generated by an SPL token contract on Solana.
-
-To enable the interaction between SPL tokens and the Neon EVM interface (along with smart contracts on
-the Neon EVM), the original ERC-20 tokens are "wrapped" into SPL tokens. Once the ERC-20 tokens are
-wrapped, they're able to operate on the Solana network. This "wrapper" is also used to transfer SOL/SPL
-tokens to Ethereum wallets such as MetaMask.
-
-After these two steps, the funds are considered to be transferred from Ethereum to a Neon user's wallet.
-
-### What infrastructure is available (wallets, blockchain explorers, oracles, etc.) for Neon EVM users?
-
-Blockchain explorers and oracles will be available in the future.
diff --git a/docs/faq/how-run-neon-evm.md b/docs/faq/how-run-neon-evm.md
deleted file mode 100644
index 093e29a1..00000000
--- a/docs/faq/how-run-neon-evm.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: How can I run Neon EVM?
----
-
-* [Where can I find the Testnet RPC and ChainID?](#where-can-i-find-the-testnet-rpc-and-chainid)
-* [Will the Mainnet addresses for USDC/USDT/BTC/ETH be the same as they are in Testnet?](#will-the-mainnet-addresses-for-usdcusdtbtceth-be-the-same-as-they-are-in-testnet)
-* [Can I use the Solana Devnet proxy for the Neon EVM?](#can-i-use-the-solana-devnet-proxy-for-the-neon-evm)
-* [How much should a Neon operator deposit for executing a transaction?](#how-much-should-a-neon-operator-deposit-for-executing-a-transaction)
-* [Is there an explorer to view Neon transactions, or do I use Solana's explorer?](#is-there-an-explorer-to-view-neon-transactions-or-do-i-use-solanas-explorer)
-
-
-### Where can I find the Testnet RPC and ChainID?
-
-You can find the Testnet RPC and ChainID at [chainlist.org](http://chainlist.org/).
-
-### Will the Mainnet addresses for USDC/USDT/BTC/ETH be the same as they are in Testnet?
-
-No, the addresses for USDC/USDT/BTC/ETH won't be the same for Mainnet.
-
-### Can I use the Solana Devnet proxy for the Neon EVM?
-
-Yes, you can. Find the instructions on how to do so at [chainlist.org](http://chainlist.org/).
-
-### How much should a Neon operator deposit for executing a transaction?
-
-The deposit amount should be 5,000 lamports.
-
-### Is there an explorer to view Neon transactions, or do I use Solana's explorer?
-
-Currently you will be able to use Solscan explorer to view Neon transactions
diff --git a/docs/faq/how-use-neon.md b/docs/faq/how-use-neon.md
deleted file mode 100644
index 771be5ef..00000000
--- a/docs/faq/how-use-neon.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: How can I use Neon?
----
-
-* [How do I start using dApps deployed on the Neon EVM?](#how-do-i-start-using-dapps-deployed-on-the-neon-evm)
-* [What tools does a Neon EVM user need to start using the Neon EVM?](#what-tools-does-a-neon-evm-user-need-to-start-using-the-neon-evm)
-* [What tools does a Neon EVM operator need to run the Neon EVM?](#what-tools-does-a-neon-evm-operator-need-to-run-the-neon-evm)
-* [How do Neon EVM users pay for using dApps deployed on the Neon EVM?](#how-do-neon-evm-users-pay-for-using-dapps-deployed-on-the-neon-evm)
-* [What happens if no Neon EVM operators accept my requested Neon transaction?](#what-happens-if-no-neon-evm-operators-accept-my-requested-neon-transaction)
-* [How do I transfer the token contracts deployed on the proxy network to my Phantom wallet?](#how-do-i-transfer-the-token-contracts-deployed-on-the-proxy-network-to-my-phantom-wallet)
-
-### How do I start using dApps deployed on the Neon EVM?
-
-To start using a dApp deployed on the Neon EVM as a user, you should have an account within
-with a balance in NEON.
-
-### What tools does a Neon EVM user need to start using the Neon EVM?
-
-As a user, all you need is a MetaMask wallet pointed to the Neon network. For a description of how to set
-up this configuration, check out this [quick tutorial](https://www.youtube.com/watch?v=ry2yGhWmGRw).
-
-### What tools does a Neon EVM operator need to run the Neon EVM?
-
-A Neon EVM operator needs the following:
-
- 1. The Neon Web3 Proxy. A dedicated RPC Solana node for operators is highly desirable.
- 2. A Solana account (wallet) funded with SOL tokens.
-
-See details [here](operating/operator_guide.md).
-
-### How do Neon EVM users pay for using dApps deployed on the Neon EVM?
-
-A Neon EVM user would simply transfer funds to the address of the dApp (contract).
-
-### What happens if no Neon EVM operators accept my requested Neon transaction?
-
-In this scenario, a Neon EVM user will have two options:
-
- 1. Increase the fee to be paid for the successful execution of their transaction.
- 2. Perform the Neon transaction on their own.
-
-### How do I transfer the token contracts deployed on the proxy network to my Phantom wallet?
-
-Solana wallets do not work with the Neon EVM. You need to use MetaMask.
-In the future, SOL/SPL tokens will be available in MetaMask.
diff --git a/docs/faq/neon-brief-faq.md b/docs/faq/neon-brief-faq.md
index 7893a76f..fb3f6f0d 100644
--- a/docs/faq/neon-brief-faq.md
+++ b/docs/faq/neon-brief-faq.md
@@ -1,62 +1,74 @@
---
-title: FAQ
+title: Common Questions
+proofedDate: 20230919
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comments: todo Roadmap links to Neon Labs page -- should this be updated to EVM site (issue is that roadmap there is on landing page and has no unique URL to link user to). todo? core dev Anton has asked for BPF to be removed from articles in the past -- what is the status on this?
---
-*This section contains answers to frequently asked questions (FAQs). All questions are divided into groups based on category*
+
+This page answers frequently asked questions (FAQs).
## Technology
### What is Neon EVM?
-Neon EVM is an Ethereum Virtual Machine operating as a smart contract on Solana. It gives developers the power to directly deploy Ethereum dApps with no code change while benefiting from Solana's technical advantages, and is built with security, decentralization, and sustainability top of mind.
+Neon EVM is an Ethereum Virtual Machine operating as a smart contract on Solana. It gives developers the power to directly deploy Ethereum dApps with minimal code reconfiguration while benefiting from Solana's technical advantages. Neon EVM is built with security, decentralization, and sustainability in mind.
### How does Neon EVM Work?
-Neon EVM is a smart contract on Solana acting as the Ethereum Virtual Machine. It is compiled into Berkeley Packet Filter bytecode, a format that can be executed on Solana. This allows Neon EVM to receive Solana transactions that contain wrapped Ethereum-like transactions and process them on Solana according to Ethereum rules. Get more details [here](https://docs.neon-labs.org/docs/about/how_it_works).
+Neon EVM is a smart contract on Solana acting as the Ethereum Virtual Machine. It's compiled into Berkeley Packet Filter bytecode, a format that can be executed on Solana. This allows Neon EVM to receive Solana transactions that contain wrapped Ethereum-like transactions and process them on Solana according to Ethereum rules. Get more details [here](https://neonevm.org/docs/about/how_it_works).
### How can I start building on Neon?
-To begin building on Neon, follow our [Quick Start Guide](/docs/quick_start). Porting and deploying your existing EVM contracts onto Neon using Truffle, Remix, or Hardhat is also an easy and seamless process.
+To begin building on Neon, follow our [Quick Start Guide](/docs/quick_start). Porting and deploying your existing EVM contracts onto Neon using Foundry, Remix, or Hardhat is also an easy and seamless process.
+
### Why is Neon good for Ethereum dApps?
-As a smart contract on Solana, Neon EVM benefits from Solana’s low gas fees (no less than 0.000015 SOL per transaction) and high throughput (+2,000 TPS). This makes it the cheapest and most efficient way anywhere to run Ethereum dApps.
+As a smart contract on Solana, Neon EVM benefits from Solana’s low gas fees (no less than 0.000015 SOL per transaction) and high throughput (+2,000 TPS). This arguably makes it the cheapest and most efficient way to run Ethereum dApps.
-Neon EVM does not require any significant changes to run existing Ethereum smart contracts, with all the advantages and innovations of Solana. In addition, the Neon EVM provides access to many familiar Ethereum developer tools, including MetaMask, Remix, Hardhat, Truffle, and Brownie. Neon is the perfect platform for Ethereum dApps to tap into the Solana ecosystem.
+Neon EVM doesn't require any significant changes to run existing Ethereum smart contracts, with all the advantages and innovations of Solana. In addition, the Neon EVM provides access to many familiar Ethereum developer tools, including MetaMask, Remix, Hardhat, and Truffle. Neon is the perfect platform for Ethereum dApps to tap into the Solana ecosystem.
### What makes Neon EVM so special?
-Neon EVM is unique in combining the powerful technical advantages of Solana with the vibrant development community and expertise of Ethereum. In general, it is much easier to port over existing EVM smart contract code than to build natively on Solana from scratch.
+Neon EVM is unique in combining the powerful technical advantages of Solana with the vibrant development community and expertise of Ethereum. In general, it's much easier to port over existing EVM smart contract code than to build natively on Solana from scratch.
-### What tools are currently available on Neon?
+### What Neon-native tools are currently available?
The following tools are available on Neon:
-* [NeonScan](https://neonscan.org/) - Neon EVM’s block explorer
-* [NeonPass](https://neonpass.live/) - A utility for transferring SPL tokens between Solana and Neon
-* [Neon Faucet](https://neonfaucet.org/) - Where tokens for the Neon Devnet may be retrieved for testing and experimental purposes
-* [Neon Analytics](https://neon.aleph.cloud/) - A data-rich dashboard built on [Aleph](https://aleph.im/)
+
+* [NeonScan](https://neonscan.org/): Neon EVM’s block explorer
+* NeonPass: A tool for transferring tokens between Solana and Neon: available as an [App](https://neonpass.live/) and an [npm package](/docs/developing/integrate/neon_transfer)
+* [Neon Faucet](https://neonfaucet.org/): Provides NEON tokens on Devnet for testing purposes
+
### How do I transfer SPL tokens between Solana and Neon?
-[NeonPass](https://neonpass.live/) is an open-source service that facilitates token transfers between Solana and Neon EVM, including the NEON SPL token. To use NeonPass, you must have access to two wallets: a Solana wallet, such as [Phantom](https://phantom.app/), and an EVM wallet, such as [MetaMask](https://metamask.io/) for Neon.
+[NeonPass](/docs/token_transferring/neonpass_usage) is an open-source service that facilitates token transfers between Solana and Neon EVM, including the NEON SPL token. To use NeonPass, you must have access to two wallets: a Solana wallet, such as [Phantom](https://phantom.app/download), and an EVM wallet, such as [MetaMask](https://metamask.io/).
-### What is Neon's Roadmap?
+### What is Neon's roadmap?
-You can view our roadmap on our [Home Page](https://neon-labs.org/).
+You can view our roadmap on our [Home Page](https://neon-labs.org/).
## Community
### How can I join the Neon community?
-The Neon community is an exciting one to join! Check out our [community page](https://neon-labs.org/community) and join any platform that interest you.
-
-### How can I help support Neon?
-
-Feel free to reach out to us in our [Discord community](https://discord.com/invite/ApZRBDqYcN).
+Neon has an active community: check out our [community page](https://neonevm.org/community) and join any platform that interests you.
### Where can I see a list of projects in the ecosystem?
-You can see the list of projects that are being built in Neon [here](https://docs.neon-labs.org/docs/about/neon_ecosystem).
+You can see the list of projects building on Neon [here](https://neonevm.org/docs/about/neon_ecosystem).
### Where can I see a list of upcoming events involving Neon?
-Upcoming events in the Neon community are listed on our [events page](https://neon-labs.org/events). You can also sign up for Neon’s newsletter to stay in the loop. If an in-person Neon event is happening near you, why not come and say hello?
+Upcoming events in the Neon community are listed on our [events page](https://neonevm.org/events).
+
+
+
+## What next?
+
+If you still have a question about the Neon EVM that isn't answered in the following FAQ pages, please join us on our [Discord server](https://discord.gg/neonevm). Our AI support channel, `#ai-support`, will answer your questions day or night. If the AI is not smart enough, don't worry; our support team will be glad to help you.
+
+> Discord [invite link](https://discord.com/invite/ApZRBDqYcN)
diff --git a/docs/faq/neon-faq.md b/docs/faq/neon-faq.md
deleted file mode 100644
index 72d1630c..00000000
--- a/docs/faq/neon-faq.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: FAQ Categories
----
-
-*This section contains answers to frequently asked questions (FAQs). All questions are divided into groups based on their focus:*
-
- * [What is Neon?](/docs/faq/what-is-neon)
- * [How does Neon work?](/docs/faq/how-does-neon-work)
- * [How can I use Neon?](/docs/faq/how-use-neon)
- * [Why should I choose Neon?](/docs/faq/why-choose-neon)
- * [How can I run the Neon EVM?](/docs/faq/how-run-neon-evm)
- * [I could not find an answer to my issue](/docs/faq/couldnt-find-answer)
diff --git a/docs/faq/neonpass.md b/docs/faq/neonpass.md
new file mode 100644
index 00000000..4ed7c938
--- /dev/null
+++ b/docs/faq/neonpass.md
@@ -0,0 +1,35 @@
+---
+title: NeonPass FAQ
+proofedDate: 20230919
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comments: na
+---
+
+## NeonPass FAQ
+
+This page answers some of the most commonly asked questions about NeonPass.
+
+### How do I use NeonPass?
+
+The [NeonPass](/docs/token_transferring/neonpass_usage) tutorial details the steps to use the NeonPass app. Alternatively, you may use the [npm package](/docs/developing/integrate/neon_transfer).
+
+
+### Does NeonPass wrap my tokens?
+No. The term wrapped is associated with the common practice of locking assets on one chain to mint their equivalent, “synthetic” asset on another chain. We prefer to describe the “packaging” of SPL tokens via the interface contract to distinguish the approach of NeonPass from that of traditional wrapping. NeonPass [transfers assets between accounts](/docs/tokens/token-accounts); it doesn't lock or mint tokens.
+
+
+### What are the different account types in Solana and Neon EVM?
+Solana has Associated Token Accounts (not to be confused with Solana User Accounts), which manage tokens. These Token Accounts are owned by the Solana Token Program, the default program in the Solana Blockchain. This provides authority to the User Solana Account according to the relationship between tokens and user accounts defined by the Associated Token Program, one of Solana’s default programs.
+
+
+Neon EVM ERC-20 Token Accounts are not the same as Neon EVM’s User Accounts, i.e. those EVM-based wallet accounts. The former are created within the Neon EVM Ecosystem to store the assets associated with users’ Neon EVM-facing wallet accounts.
+
+
+### What accounts are created on my behalf?
+When you transfer an asset to a Neon EVM account from Solana that doesn’t have any existing balance of that asset, a new Neon EVM ERC-20 Token Account is created to store the balance. This account is linked to your associated Neon EVM User Account. If the Neon Account does contain that asset’s balance, then the incoming assets are transferred to the existing Neon EVM ERC-20 Token Account associated with your Neon EVM User Account.
+
+Similarly, if a Solana account doesn't have an existing asset balance for the incoming asset, a new Solana Associated Token Account is created to store the new asset balance on behalf of your associated Solana User Account. And, if the asset balance exists already, then the incoming assets are transferred to the existing Associated Token Account that is associated with your Solana account.
+
+
diff --git a/docs/faq/what-is-neon.md b/docs/faq/what-is-neon.md
deleted file mode 100644
index 53f69c05..00000000
--- a/docs/faq/what-is-neon.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: What is Neon?
----
-
-* [What is Neon?](#what-is-neon)
-* [What is the Neon Web3 Proxy?](#what-is-the-neon-web3-proxy)
-* [What are the main roles in Neon?](#what-are-the-main-roles-in-neon)
-* [What is the ERC-20/SPL wrapper?](#what-is-the-erc-20spl-wrapper)
-* [What about the NFT support (ERC-721 and ERC-1155)?](#what-about-the-nft-support-erc-721-and-erc-1155)
-* [What is the ERC-20/SPL bridge?](#what-is-the-erc-20spl-bridge)
-
-### What is Neon?
-
-Neon is a smart contract on Solana that was designed to bring EVM (Ethereum Virtual Machine) compatibility to Solana. Neon enables the use of Ethereum dApps and tools on Solana without any reconfiguration.
-
-### What is the Neon Web3 Proxy?
-
-The Neon Web3 Proxy allows users to access Solana via the existing Ethereum app front end. On the back end, it wraps a Neon transaction into a Solana transaction. Then the Proxy sends the Solana transaction to a Solana cluster and the Neon EVM program executes the Neon transaction on-chain.
-
-### What are the main roles in Neon?
-
-**Neon user**: Any account in Neon EVM with a non-zero balance in Neon tokens (later NEON/ETH/ERC-20).
-Neon users order Ethereum-like transactions that are executed via the Neon EVM program on Solana.
-
-**Neon client**: An application with EVM bytecode (Solidity, Vyper, etc.) loaded into Neon.
-The application generates a Neon transaction according to Ethereum rules and sends it to Neon EVM
-via the Web3 Proxy.
-
-**Neon operator**: Anyone who operates a Neon Web3 Proxy. Operators are compensated by users in
-Neon tokens (later NEON/ETH/ERC-20). Operators must maintain SOL tokens as payment to Neon EVM and
-Solana validators for the execution of Neon transactions. Operators receive a fee from Neon users for finalizing the executions of Neon transactions.
-
-### What is the ERC-20/SPL wrapper?
-
-The ERC-20/SPL wrapper is the implementation of the ERC-20 interface for SPL tokens. Its purpose is to ensure the interaction of Solana applications with Neon EVM contracts. The original ERC-20 tokens are "wrapped" in the SPL tokens so that they can operate with Solana. This wrapper can also be used to transfer SOL/SPL tokens using Ethereum wallets such as MetaMask.
-
-### What about the NFT support (ERC-721 and ERC-1155)?
-
-NFTs (ERC-721 and ERC-1155) aren't supported right now but will be supported in the future.
-
-### What is the ERC-20/SPL bridge?
-
-Say, for example, you have a dApp on Ethereum. This dApp has an ERC-20 contract with its own logic of token minting, and you want to deploy it on Neon EVM.
-
-The dApp tokens will be available to other Solidity contracts on Neon EVM, but they will not exist for Solana programs. The ERC-20/SPL bridge will allow you to transfer such tokens from an ERC-20 contract to SPL token accounts.
diff --git a/docs/faq/why-choose-neon.md b/docs/faq/why-choose-neon.md
deleted file mode 100644
index 7ba44982..00000000
--- a/docs/faq/why-choose-neon.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Why should I choose Neon?
----
-
-* [What are the main advantages of the Neon EVM?](#what-are-the-main-advantages-of-the-neon-evm)
-* [How are the costs of the Neon EVM so low while maintaining a high transaction throughput?](#how-are-the-costs-of-the-neon-evm-so-low-while-maintaining-a-high-transaction-throughput)
-* [Are there any dApps currently running on the Neon EVM?](#are-there-any-dapps-currently-running-on-the-neon-evm)
-
-### What are the main advantages of the Neon EVM?
-
-The Neon EVM is built as a smart contract on Solana. It benefits from low gas fees (at a cost of no less than
-0.000015 SOL per transaction) and high throughput (up to 4,500 Ethereum-like transactions per second).
-
-The advantages are all accomplished without significant changes to existing Ethereum smart contract code.
-In addition, the Neon EVM provides access to familiar Ethereum developer tools such as MetaMask, Remix, and Truffle.
-
-### How are the costs of the Neon EVM so low while maintaining a high transaction throughput?
-
-These two benefits are the result of the Neon EVM working on Solana.
-
-The main benefit of throughput comes from the parallel execution of transactions enabled by Solana.
-
-The low costs of Neon EVM transactions are attributed to the low costs of Solana transactions.
-
-### Are there any dApps currently running on the Neon EVM?
-
-The Neon Labs team has launched NeonSwap, a fork of Uniswap V2 with no code changes, on the Neon EVM Testnet.
diff --git a/docs/governance/command_line.md b/docs/governance/command_line.md
new file mode 100644
index 00000000..6bd29f16
--- /dev/null
+++ b/docs/governance/command_line.md
@@ -0,0 +1,69 @@
+---
+title: Command line utilities
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+---
+## Command line utilities
+
+### Get vesting information with `vesting-contract-cli`
+
+The main part of the NEON-tokens is in a locked state and will be issued in parts according
+to a certain schedule. For their storage and release at the required time, the vesting contract is used
+(https://github.com/neonlabsorg/neon-spl-governance/tree/main/addin-vesting, commit `1fc1ad6a21aebd13911db7f60ca7099a6ad61b92`).
+
+The vesting contract was audited by the next teams:
+
+* [Halborn at April 17th, 2022](https://github.com/neonlabsorg/neon-spl-governance/blob/main/audit/20220513-Halborn-Governance.pdf)
+* [Ackee Blockchain at Jule 22th, 2022](https://github.com/neonlabsorg/neon-spl-governance/blob/main/audit/20220906-AckeeBlockchain.pdf)
+* [Neodyme at June 7th, 2023](https://github.com/neonlabsorg/neon-spl-governance/blob/main/audit/20230607-Neodyme.pdf)
+
+This contract was deployed at address `919AnvG1Vi9ekoxQs6d6SYQiRmYMcinw4U6bzL2YNoFM` in Solana Mainnet
+(https://solscan.io/account/919AnvG1Vi9ekoxQs6d6SYQiRmYMcinw4U6bzL2YNoFM).
+
+To view information about vesting, its quantity and output schedule, you can use the vesting-contract-cli
+utility (its sources are located at https://github.com/neonlabsorg/neon-spl-governance/tree/main/addin-vesting/cli).
+```
+vesting-contract-cli --url https://api.mainnet-beta.solana.com info --governance_program_id DRJeCVsc33fDT2khezFiMQpQiuoucFrji1A62QfbxPPT --vesting_program_id 919AnvG1Vi9ekoxQs6d6SYQiRmYMcinw4U6bzL2YNoFM --vesting_address `VESTING_ADDRESS`
+```
+The `VESTING_ADDRESS` is taken from the `Address` column of the token holders page
+https://solscan.io/token/NeonTjSjsuo3rexg9o6vHuMXw62f9V7zvmu8M8Zut44#holders.
+Output example:
+```
+vesting-contract-cli --url https://api.mainnet-beta.solana.com info --governance_program_id DRJeCVsc33fDT2khezFiMQpQiuoucFrji1A62QfbxPPT --vesting_program_id 919AnvG1Vi9ekoxQs6d6SYQiRmYMcinw4U6bzL2YNoFM --vesting_address A5zrmTFMPpTWhSxay8gDr3rLr4WguCPYp8um5ywRFeCT
+
+---------------VESTING--CONTRACT--INFO-----------------
+
+Program ID: 919AnvG1Vi9ekoxQs6d6SYQiRmYMcinw4U6bzL2YNoFM
+Vesting Account Pubkey: FbVwXodUY8m4WrZDZCEDzUeHWLA7LuTpqqQLke1wngQf
+Vesting Token Account Pubkey: A5zrmTFMPpTWhSxay8gDr3rLr4WguCPYp8um5ywRFeCT
+Vesting Owner Address: DZ7GXB26tC6DmCNDEj9wd9qYg2NfnTmE1wjPBVE95buz
+Vesting Mint Address: NeonTjSjsuo3rexg9o6vHuMXw62f9V7zvmu8M8Zut44
+Vesting Token Address: A5zrmTFMPpTWhSxay8gDr3rLr4WguCPYp8um5ywRFeCT
+Vesting Realm: Some(9AQvVMCTEBqKFzPRG9inL9ssSVJeQhWQVARHBMy3Fo1V)
+Schedule:
+ 0: amount 3541666666666666, timestamp 1723053458 (2024-08-07 17:57:38)
+ 1: amount 3541666666666667, timestamp 1725731858 (2024-09-07 17:57:38)
+ 2: amount 3541666666666667, timestamp 1728323858 (2024-10-07 17:57:38)
+ 3: amount 3541666666666666, timestamp 1731002258 (2024-11-07 17:57:38)
+ 4: amount 3541666666666667, timestamp 1733594258 (2024-12-07 17:57:38)
+ 5: amount 3541666666666667, timestamp 1736272658 (2025-01-07 17:57:38)
+ 6: amount 3541666666666666, timestamp 1738951058 (2025-02-07 17:57:38)
+ 7: amount 3541666666666667, timestamp 1741370258 (2025-03-07 17:57:38)
+ 8: amount 3541666666666667, timestamp 1744048658 (2025-04-07 17:57:38)
+ 9: amount 3541666666666666, timestamp 1746640658 (2025-05-07 17:57:38)
+ 10: amount 3541666666666667, timestamp 1749319058 (2025-06-07 17:57:38)
+ 11: amount 3541666666666667, timestamp 1751911058 (2025-07-07 17:57:38)
+Total amount: 42500000000000000
+```
+To run vesting-contract-cli, you can use the ready-made docker image `neonlabsorg/launch-script:v1.0.0`. We suggest to run it with command:
+```
+docker run -ti --rm --network host neonlabsorg/launch-script:v1.0.0
+```
+Or you can build `vesting-contract-cli` utility from source:
+```
+git clone git@github.com:neonlabsorg/neon-spl-governance.git
+git submodule update --init
+cargo build --release --bin vesting-contract-cli
+```
diff --git a/docs/governance/neon_daos/neon_daos.md b/docs/governance/neon_daos.md
similarity index 90%
rename from docs/governance/neon_daos/neon_daos.md
rename to docs/governance/neon_daos.md
index 19cd5683..251fc849 100644
--- a/docs/governance/neon_daos/neon_daos.md
+++ b/docs/governance/neon_daos.md
@@ -1,6 +1,12 @@
---
title: Neon DAO Organization
+proofedDate: na sublime only
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: TODO requires overhaul
---
+import dao from '@site/static/img/doc-images/governance/dao_organization.png';
## Neon is Governed by the Community, For the Community
@@ -10,7 +16,7 @@ Since the results depend on Neon's stability, a high level of coordination must
## The Neon DAO Model
-The Neon DAO model is based on the interplay and synergy of several decentralized Assemblies, organized into three Focus Areas. In a nutshell, Assemblies are member-owned communities that serve as safe and effective venues for like-minded indivuals to constructively work together and engage in collective decision-making. While each Assembly has different criteria for submitting proposals, eligibility for voting, and the scope of influence its decisions can have, they all follow the same basic formula as described in the [Voting Process Overview](/docs/governance/overview/#voting-process-overview).
+The Neon DAO model is based on the interplay and synergy of several decentralized Assemblies, organized into three Focus Areas. In a nutshell, Assemblies are member-owned communities that serve as safe and effective venues for like-minded individuals to constructively work together and engage in collective decision-making. While each Assembly has different criteria for submitting proposals, eligibility for voting, and the scope of influence its decisions can have, they all follow the same basic formula as described in the [Voting Process Overview](/docs/governance/overview/#voting-process-overview).
* An idea for potential implementation is brought to an Assembly within a Focus Area.
* Assembly participants discuss, review, and revise the proposed idea off-chain.
@@ -28,7 +34,7 @@ The following is a diagram visualizing the relationships between the Neon DAO's
-
+
@@ -36,7 +42,7 @@ The parameters pertaining to the Neon DAO governance framework may be adjusted a
## Ecosystem
-The Ecosystem Focus Area is charged with the promotion of sustainable, long-term growth of the Neon ecosystem. As the collective owner of the Neon Treasury, its duties and responsibilties consist of distribution of funds for grants, security audits, bug bounties, and other ecosystem initiatives.
+The Ecosystem Focus Area is charged with the promotion of sustainable, long-term growth of the Neon ecosystem. As the collective owner of the Neon Treasury, its duties and responsibilities consist of distribution of funds for grants, security audits, bug bounties, and other ecosystem initiatives.
Within the Ecosystem Focus Area, the Ecosystem Assembly and Foundation work in collaboration to provide a frictionless experience for Ecosystem developers. The Ecosystem Assembly provides custodial services to the Foundation, informs the Foundation on decisions taken, and lets the Foundation distribute funds based on its own legal assessment of potential grantees.
@@ -47,6 +53,7 @@ The Ecosystem Assembly is the most active Assembly in the Neon DAO. Most Ecosyst
* Informing the Foundation on decisions taken, and letting the Foundation distribute funds based on its own legal assessment of potential grantees
#### Usage Scenarios
+
A typical scenario, funding an ecosystem initiative, would proceed as follows:
1. During the off-chain stage, the Assembly discusses and evaluates the proper incentives to provide for the initiative in question.
2. The proponent of the idea then creates a proposal to
@@ -55,12 +62,14 @@ A typical scenario, funding an ecosystem initiative, would proceed as follows:
3. The proposal is voted on and, if approved, leads to the transfer of funds to the Budget account.
### Neon Foundation
+
The Neon Foundation is an organization that is responsible for implementing Ecosystem Assembly proposals. These responsibilities include:
* Performing necessary Know-Your-Customer (KYC) and Anti-Money Laundering (AML) processes for contractors and grantees
* Signing agreements with contractors
* Processing signed agreements with regards to acceptance and payments
## Development
+
As the owner of the Neon EVM program, the Development Assembly is the only component of the Development Focus Area. This Assembly is the group that deals with the technical aspects of the Neon EVM, and can upgrade the Neon EVM version. In break-glass emergency scenarios, Emergency Engineers, appointed by the Development Assembly, may elect to stop the Neon EVM without the Assembly's approval.
### Development Assembly
@@ -95,4 +104,5 @@ Within the Security Focus Area, the Treasury Watchdog and EVM Emergency Assembly
The Treasury Watchdog is meant as a check on the Ecosystem Assembly, to make sure no malicious actors attempt to withdraw funds from any treasury wallets/accounts by taking advantage of the Ecosystem Assembly's decentralized nature. The Treasury Watchdog's main function is to identify malicious proposals that have been approved in rare cases and may target treasury accounts normally controlled by the Ecosystem Assembly. A Treasury Watchdog proposal to prevent such a withdrawal must be undertaken before or during the hold up period of the malicious Ecosystem Assembly proposal.
### EVM Emergency Assembly
+
The EVM Emergency Assembly is meant as a check on the Development Assembly, to make sure no malicious actors attempt to submit a malicious upgrade to the Neon EVM by taking advantage of the Development Assembly's decentralized nature. The EVM Emergency Assembly's main function is to prevent the Neon EVM being upgraded with malicious code. An EVM Emergency Assembly proposal to prevent such an upgrade must be undertaken before or during the hold up period of the malicious Development Assembly proposal.
diff --git a/docs/governance/overview/overview.md b/docs/governance/overview.md
similarity index 86%
rename from docs/governance/overview/overview.md
rename to docs/governance/overview.md
index 94b45838..722470fe 100644
--- a/docs/governance/overview/overview.md
+++ b/docs/governance/overview.md
@@ -1,10 +1,18 @@
---
-title: Overview
+title: DAO Overview
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: TODO requires overhaul
---
+import dao from '@site/static/img/doc-images/governance/dao_organization.png';
+
+
## The Neon DAO
-The Neon DAO is a collection of community-led, community-driven organizations that foster and enhance decentralization, resilence, and self-sustainability for the Neon EVM platform and ecosystem. To do so, community members reach consensus on solving issues, develop rules for the functioning of the Neon DAO, and change the governance rules themselves through contractual amendments, if applicable.
+The Neon DAO is a collection of community-led, community-driven organizations that foster and enhance decentralization, resilience, and self-sustainability for the Neon EVM platform and ecosystem. To do so, community members reach consensus on solving issues, develop rules for the functioning of the Neon DAO, and change the governance rules themselves through contractual amendments, if applicable.
The Neon DAO's Assemblies are built using [SPL Governance](https://github.com/solana-labs/solana-program-library/tree/master/governance), a versatile DAO creation tool for the Solana blockchain.
@@ -22,7 +30,7 @@ The Neon DAO's Assemblies are built using [SPL Governance](https://github.com/so
All Neon DAO parameters, such as the pass threshold to accept a proposal, voting period, hold-up period, and the minimum token amount required to create a proposal, can be found on the Neon Governance UI.
-Learn more about the [voting process](/docs/governance/proposals/proposals.md).
+Learn more about the [voting process](/docs/governance/proposals.md).
## Neon DAO Organization
@@ -30,10 +38,11 @@ Neon is decentralized and its economy is fee-based, with NEON tokens being used
-
+
+
### Ecosystem Focus Area
The [Ecosystem Focus Area](/docs/governance/neon_daos/#ecosystem-focus-area) contains the Assemblies responsible for the promotion of Neon community initiatives and incentivizing long-term ecosystem growth. The use cases involving this Focus Area include [rewarding users and teams for creating Neon ecosystem projects](/docs/governance/neon_daos/#usage-scenarios).
diff --git a/docs/governance/overview/img/dao_organization.png b/docs/governance/overview/img/dao_organization.png
deleted file mode 100644
index a0fcfdba..00000000
Binary files a/docs/governance/overview/img/dao_organization.png and /dev/null differ
diff --git a/docs/governance/principles/principles.md b/docs/governance/principles.md
similarity index 78%
rename from docs/governance/principles/principles.md
rename to docs/governance/principles.md
index 41bc2e40..767608f0 100644
--- a/docs/governance/principles/principles.md
+++ b/docs/governance/principles.md
@@ -1,5 +1,10 @@
---
title: Principles and Objectives
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
## Principles
@@ -18,7 +23,7 @@ There are also more concrete prohibitions on improper behavior that must be kept
* No member should improperly influence the vote of another.
* Members agree to hold software developers blameless for unintentional mistakes made by them in the expression of contractual intent, whether or not said mistakes were due to actual or perceived negligence.
-In addition, the NEON DAO is transparent and flexibile. All users have access to all relevant information in order to make well-informed decisions, and the governance process is adaptable to the ever-evolving needs of the community.
+In addition, the NEON DAO is transparent and flexible. All users have access to all relevant information in order to make well-informed decisions, and the governance process is adaptable to the ever-evolving needs of the community.
### Rules and Etiquette
@@ -36,7 +41,7 @@ The DAO Forum is not the place for general discussions, advertising, off-topic c
## Measures Against Abuse and Misuse
-Like any governance system, the Neon DAO faces the risk of malicious actors being involved, which could jeopardize the Neon ecosystem as well as treasury or user funds if their subversive proposals are erronously passed. To reduce this risk, the Neon DAO has implemented defensive measures in several key areas, corresponding to stages along the process of a proposal becoming implemented. These areas include limiting the number of proposals, detecting malicious proposals, and cancelling malicious proposals.
+Like any governance system, the Neon DAO faces the risk of malicious actors being involved, which could jeopardize the Neon ecosystem as well as treasury or user funds if their subversive proposals are erroneously passed. To reduce this risk, the Neon DAO has implemented defensive measures in several key areas, corresponding to stages along the process of a proposal becoming implemented. These areas include limiting the number of proposals, detecting malicious proposals, and cancelling malicious proposals.
### Limiting the Number of Proposals
Malicious actors have an easier time pushing through one of their proposals if they can submit as many proposals as they like. To prevent this, the Neon DAO's Assemblies have protections in place to limit the number of proposals an Assembly can accept from a given user. These measures include:
@@ -45,4 +50,4 @@ Malicious actors have an easier time pushing through one of their proposals if t
* A minimum amount of locked tokens necessary for a user to create a proposal (each Assembly has different requirements)
* Some Assemblies require a higher locked token threshold for creating proposals than for updating the Neon EVM
-Beside preventing the proliferation of malicious proposals, these measures also reduce spam, making the governance system easier to use and more efficient.
\ No newline at end of file
+Besides preventing the proliferation of malicious proposals, these measures also reduce spam, making the governance system easier to use and more efficient.
diff --git a/docs/governance/proposals/proposals.md b/docs/governance/proposals.md
similarity index 66%
rename from docs/governance/proposals/proposals.md
rename to docs/governance/proposals.md
index dd5fccdf..b9375387 100644
--- a/docs/governance/proposals/proposals.md
+++ b/docs/governance/proposals.md
@@ -1,14 +1,42 @@
---
title: Voting Process
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: todo requires overhaul
---
+import govern1 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_before_wallet.jpeg';
+import govern2 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_wallet_connect.png';
+import govern3 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_wallet_balance.png';
+import govern4 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_governance_topic.jpeg';
+import govern5 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_add_new_proposal.jpeg';
+import govern6 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_new_proposal_popup.png';
+import govern7 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_list_after_new_proposal.png';
+import govern8 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_new_proposal_page.png';
+import govern9 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_sign_off_popup.png';
+import govern10 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_signed_off_proposal.png';
+
+import govern11 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_cancel_proposal.png';
+
+import govern12 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_proposal_voting.png';
+import govern13 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_positive_popup.png';
+import govern14 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_negative_popup.png';
+import govern15 from '@site/static/img/doc-images/governance/proposals/new_gov_ui_voting_tipping_point.png';
+
+
+
+
+*Note: The screenshots (and the wallet addresses, token balances, and proposals) on this page are for illustrative and instructional purposes **only**. *
+
## Introduction
Any Neon user can submit an idea for potential implementation by the Neon DAO. Each idea is included in the list of promising solutions and discussed on the DAO forum. After an idea is proposed, it goes through a formal life cycle of technical reviews, research, and discussions. This discussion stage allows management to exclude the implementation of inefficient or risky solutions in Neon. After the discussion stage, finalized ideas are reworked into concrete on-chain **proposals** and are put to a vote by the Assembly. Proposals that are approved according to the rules of their Assembly are then automatically implemented by Neon.
## Discussing on the DAO Forum
-The DAO Forum is a place where Neon developers and third-party teams can discuss and debate ideas and express and articulate their opinions in preparation for becoming proposals. This forum is a vital part of the Neon DAO, because it provides transparency and accountability, fosters constructive discourse, and helps ensure the decentralization of the project.
+The DAO Forum is a place where Neon stakeholders, community members, developers, and third-party teams can discuss and debate ideas and express and articulate their opinions in preparation for becoming proposals. This forum is a vital part of the Neon DAO, as it provides transparency and accountability, fosters constructive discourse, and helps ensure the decentralization of the project.
Potential proposals can affect both the management and technical processes of Neon. If this is a proposal to change the logic of system contracts or to improve the technical capabilities of Neon, the proposal contract must be tested on either Devnet or Testnet. Proposals for the implementation of new features associated with risk or high labor costs go through the following formal process:
@@ -17,22 +45,70 @@ Potential proposals can affect both the management and technical processes of Ne
* Appointment of a worker for the implementation of the proposal. The worker may be an individual, a group of individuals, or a third-party company.
* Verification and decision on acceptance of the work done.
-All these details are discussed, revised, and debated civilly on the DAO Forum.
+All these details are discussed, revised, and debated civilly on the DAO Forum. To learn more about expectations on governance participants and discourse, refer to the [Principles and Objectives](principles.md) section.
+
+## Connecting Wallet
+
+:::tip
+Interacting with Neon Governance requires the use of NEON tokens. Make sure you are connecting a wallet account **with NEON tokens available**.
+:::
+
+1. Click on "Connect" to connect your Solana wallet to the DAO website.
+>
+
+2. Select the wallet application that you are using from the list.
+
+>
+
+3. If you wish to continue, respond to your wallet application's prompt to allow connecting.
+4. Confirm that you see your wallet address show up.
+
+>
+
+You are now ready to interact with the Neon Governance UI.
## Creating a Proposal
+Once an idea has reached its final form after discussions on the DAO Forum and the formal review process is complete, the proponent can create the actual proposal. The on-chain code to automatically implement the proposal that was tested and finalized on the DAO Forum is now ready to be included in a formal proposal on the Neon DAO website.
+
+Before proceeding, please make sure [your wallet is connected](#connecting-wallet).
+
+To create a proposal, follow the steps below.
+
+1. On the Neon DAO website, select the Governance topic for which the proposal is best suited.
-Once an idea has reached its final form after discussions on the DAO Forum and the formal review process is complete, the proponent can create the actual proposal. The on-chain code to automatically implement the proposal that was tested and finalised on the DAO Forum is now ready to be included in a formal proposal on the Neon DAO website.
+>
-To create a proposal, follow the following steps:
+2. Click on the "Add new proposal" button.
-1. On the Neon DAO website, select the Assembly for which the proposal is best suited.
-2. Connct your Solana wallet, with NEON tokens available, to the DAO website.
-3. Deposit the number of NEON tokens required by the Assembly for proposal submission.
-4. Create the proposal, with a link to the discussion on the DAO Forum.
+>
-Current proposals are displayed on the main page of the *Neon DAO* section, under the "How to Participate" heading.
+3. In the "Add new proposal" popup, enter the name of your proposal and a description with a link to a relevant [GitHub Gist](https://docs.github.com/en/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists), if applicable. Click on "Add proposal".
+>
+
+4. A transaction prompt will be displayed by your wallet application. If you have verified its details and wish to continue, approve it, then wait a few moments for the transaction to process.
+5. After the transaction has been processed, you will see your proposal in the list of proposals. In this case, we created a proposal called `[Test] Test Proposal 2`.
+
+>
+
+ Click on your proposal to see its details. This new proposal will be in the `Draft` state by default.
+
+>
+
+You can then sign off on your proposal by clicking on the "Sign off" button. Click "Sign off" in the pop up that follows.
+
+>
+
+6. A prompt by your wallet application will ask if you to approve the sign off transaction. If you have verified its details and wish to continue, approve it, then wait a few moments for the transaction to process.
+7. After the sign off transaction has been processed, your proposal is now signed off by you and put forth to the community for a vote. Your proposal is now in the `Voting` state and the "Voting Time Left" clock has started counting down.
+
+>
+
+8. Share the proposal link URL to the DAO Forum and elsewhere for the Neon community to vote on it.
+9. (Optional) Alternatively, if you wish to cancel this proposal for whatever reason, click on the "Cancel proposal" button, click "Yes, Cancel" in the pop up that follows, and approve the cancel transaction.
+
+>
## Voting
@@ -40,12 +116,31 @@ After a proposal is created, it is ready to be put to a vote. The community of e
To vote on a proposal, follow the following steps:
-1. On the Neon DAO website, select the Assembly for which the proposal is best suited.
-2. Connct your Solana wallet, with NEON tokens available, to the DAO website.
-3. Deposit the number of NEON tokens equivalent to the desired number of votes for your preferred option, whether it is to "Accept" or "Reject" the proposal.
-4. Click "Vote" to approve the transaction.
+1. You might have been given a link to a proposal that is in the `Voting` state, or you might have clicked on a proposal in the `Voting` stage from the list of proposals. Either way, you should see a proposal page like this:
+
+>
+
+2. Click on "Positive" or "Negative" depending on whether you are in favor of or against the proposal.
+ 1. If you choose "Positive", you will see a pop up as follows.
+
+ >
+
+
+ 2. If you choose "Negative", you will see a pop up very similar to the pop up above.
+
+ >
+
+
+ 3. You can then choose/customize the percentage of your NEON tokens you would like to commit for this vote
+ 4. Click "Confirm" once you are happy with your ballot.
+3. A prompt by your wallet application will ask you to approve the voting transaction. If you have verified its details and wish to continue, approve it, then wait a few moments for the transaction to process.
+5. You have now cast your vote on this proposal.
+
+Once the voting period is concluded, the votes are automatically counted. If the proposal's "Accept" votes pass the Assembly's required vote threshold ("Vote tipping point" in the image below), the proposal is passed and is ready for implementation. Otherwise, the proposal fails.
+
+>
-Once the voting period is concluded, the votes are automatically counted. If the proposal's "Accept" votes pass the Assembly's required vote threshold, the proposal is passed and is ready for implementation. Otherwise, the proposal fails.
+
diff --git a/docs/governance/proposals/img/govern-ui-1.png b/docs/governance/proposals/img/govern-ui-1.png
deleted file mode 100644
index 35142c34..00000000
Binary files a/docs/governance/proposals/img/govern-ui-1.png and /dev/null differ
diff --git a/docs/governance/proposals/img/govern-ui-2.png b/docs/governance/proposals/img/govern-ui-2.png
deleted file mode 100644
index 33e7bcff..00000000
Binary files a/docs/governance/proposals/img/govern-ui-2.png and /dev/null differ
diff --git a/docs/governance/proposals/img/govern-ui-3.png b/docs/governance/proposals/img/govern-ui-3.png
deleted file mode 100644
index da69a011..00000000
Binary files a/docs/governance/proposals/img/govern-ui-3.png and /dev/null differ
diff --git a/docs/governance/proposals/img/govern-ui-4.png b/docs/governance/proposals/img/govern-ui-4.png
deleted file mode 100644
index 1f668b88..00000000
Binary files a/docs/governance/proposals/img/govern-ui-4.png and /dev/null differ
diff --git a/docs/governance/proposals/img/govern-ui-5.png b/docs/governance/proposals/img/govern-ui-5.png
deleted file mode 100644
index 399af1da..00000000
Binary files a/docs/governance/proposals/img/govern-ui-5.png and /dev/null differ
diff --git a/docs/governance/proposals/img/govern-ui-6.png b/docs/governance/proposals/img/govern-ui-6.png
deleted file mode 100644
index 642ba1b3..00000000
Binary files a/docs/governance/proposals/img/govern-ui-6.png and /dev/null differ
diff --git a/docs/governance/technical_implementation/technical_implementation.md b/docs/governance/technical_implementation/technical_implementation.md
deleted file mode 100644
index b1882e20..00000000
--- a/docs/governance/technical_implementation/technical_implementation.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Technical Implementation
----
-
-The Neon DAO's Assemblies are built using the [SPL Governance program](https://github.com/solana-labs/solana-program-library/tree/master/governance) - a versatile DAO creation tool for the Solana blockchain.
-
-This program allows for the customization of the following parameters:
-
-* Pass threshold to accept a proposal
-* Voting period
-* Hold up period - the minimum time before executing an approved proposal
-* Vote weight calculation (e.g. percentage of total supply, based on vested tokens)
-* Whether to allow voting using a portion of vested tokens
\ No newline at end of file
diff --git a/docs/governance/technical_implementation/vote.md b/docs/governance/technical_implementation/vote.md
new file mode 100644
index 00000000..6a388f29
--- /dev/null
+++ b/docs/governance/technical_implementation/vote.md
@@ -0,0 +1,258 @@
+---
+title: Vote
+proofedDate: 20230602
+iterationBy: HB
+includedInSite: false
+approvedBy: na
+comments:
+boilerPlatable: no
+reference:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import appDownload from '@site/static/img/doc-images/governance/appDownload.png';
+import hardwareWallet from '@site/static/img/doc-images/governance/hardwareWallet.png';
+import squadsConnectWallet from '@site/static/img/doc-images/governance/squads-connect-wallet.png';
+import squadsSelectPhantom from '@site/static/img/doc-images/governance/squads-select-phantom.png';
+import squads5owners from '@site/static/img/doc-images/governance/squads-5-owners.png';
+import vaultDash from '@site/static/img/doc-images/governance/squads-vault-dash.png';
+import vaultDashSend from '@site/static/img/doc-images/governance/squads-vault-dash-send.png';
+import txSend from '@site/static/img/doc-images/governance/txSend.png';
+import activeTx from '@site/static/img/doc-images/governance/active-tx.png';
+import confirmTx from '@site/static/img/doc-images/governance/confirm-tx.png';
+import approveTx from '@site/static/img/doc-images/governance/approve-tx.png';
+import execute from '@site/static/img/doc-images/governance/execute-tx.png';
+import delegatedTx from '@site/static/img/doc-images/governance/delegated-create-tx.png';
+import delegatedTransfer from '@site/static/img/doc-images/governance/delegated-tx-transfer.png';
+import delegatedProposal from '@site/static/img/doc-images/governance/delegated-proposal.png';
+
+
+## TL;DR
+
+To manage a MultiSig wallet to engage in the Neon DAO you must:
+
+- Set up a Ledger hardware wallet with the Solana app
+- Set blind signing
+- Install and connect Phantom
+- Transfer assets using MultiSig: i.e. set up, vote on, and execute transactions
+
+## Introduction
+
+This tutorial covers setting up a Ledger wallet to apply MultiSig signing for the purposes of voting in the Neon DAO. This MultiSig is managed by the web app *Squads*. Squads provides a user-friendly interface for managing MultiSig wallets on the Solana blockchain. It allows multiple parties to manage a single address by requiring a specified number of signatures to complete a transaction.
+
+Within Squads the lifecycle of a transaction is creation, approval/rejection, and, if approved, execution.
+
+> Learn [more about Squads](https://squads.medium.com/squads-101-the-two-types-of-squads-34b67d1a6641).
+
+## Prerequisites
+
+- Ledger Nano S Plus or Ledger Nano X
+
+:::note
+We used a Ledger Nano S Plus, but the steps for Ledger Nano X are identical.
+:::
+
+- macOS
+
+- It's strongly recommended that you use the Chromium-based browsers, Chrome or Brave
+
+## Set up wallets and transact
+
+
+#### Step 1: Configure your Ledger wallet
+
+Ledger maintains and curates their to provide you the best support possible. However, if you want to stay here, you are welcome to follow the Neon Guide.
+
+
+
+
+
+See Ledger's [configuration guide](https://support.ledger.com/hc/en-us/articles/4416927988625-Set-up-your-Ledger-Nano-S-Plus).
+
+
+
+
+
+> Be aware, we don't maintain and curate guides to partner interfaces following testing.
+
+1.1 Unbox and charge your Ledger hardware wallet by connecting it to your computer with a USB-C cable.
+
+1.2 Download the Ledger Live Mac app from [https://www.ledger.com/start](https://www.ledger.com/start).
+
+> Select “Mac app” from the dropdown menu after you click **Download**.
+
+>
+
+1.3 When your Ledger wallet is sufficiently charged and displays "Welcome to Ledger Nano S Plus Press right button to continue."
+
+>
+
+> Press the right physical button to navigate through the on-screen instructions, and then press both buttons simultaneously to choose the option **Set up as new device”**.
+
+1.4 Press the right or left button to select the first digit of your PIN code, and then press both buttons to enter a digit.
+
+1.5 After you have confirmed your PIN code, your 24-word recovery phrase is displayed word by word on the Ledger device screen. The recovery phrase is the **only** backup of your private key and is crucial for accessing your wallet. It will be displayed only **once**, so it's vital to **write it down and store it in a secure location**.
+
+
+> Ensure you:
+>
+> - Remember your PIN code
+> - Store your 24-word recovery phrase in a safe and secure place
+
+Your device will display **”Processing”** and then **Your device is now ready** to validate successful set up.
+
+
+
+#### Step 2: Install the Solana app on your Ledger and enable blind signing
+
+2.1 Install the Solana app on your Ledger hardware wallet by following the steps outlined in [Ledger's official tutorial](https://support.ledger.com/hc/en-us/articles/360016265659-Solana-SOL)
+
+> Ensure that blind signing is enabled during the installation process. **Blind signing** allows you to sign transactions without revealing the contents to the other parties involved in a MultiSig wallet.
+> If you miss this step, enable it as per [Ledger's documentation](https://support.ledger.com/hc/en-us/articles/4499092909085-Allowing-blind-signing-in-the-Solana-SOL-app).
+
+#### Step 3: Install the Phantom wallet and connect Ledger to Phantom
+
+3.1 Install the Phantom wallet on your browser by visiting the [Phantom website](https://phantom.app/download).
+
+3.2 Next, connect your Ledger wallet as per [Ledger's documentation](https://support.ledger.com/hc/en-us/articles/4408131265169-Set-up-and-use-Phantom-to-access-your-Ledger-Solana-SOL-account)
+
+> Ensure you remember the password you set up for Phantom.
+
+#### Step 4: Access your squad on Squads
+
+4.1 Access Squads on:
+
+- [Devnet](https://devnet.squads.so/connect-squad)
+- [Mainnet](https://v3.squads.so/connect-squad).
+
+4.2 Click on **Connect wallet**, then **Agree and continue** when prompted to acknowledge the terms and conditions.
+
+>
+
+> Please do take care to read the Terms of Service and Squads Disclaimer first.
+
+4.3 Select “Phantom” from the list of wallet applications.
+
+>
+
+> A list of Vaults/Squads your wallet address is a signatory of is now available.
+
+:::note
+
+Example Squads Dash
+> In the following example, the Squad dashboard shows a Vault with 5 owners.
+>
+> Clicking on the Vault drills the dash down to show the details for this Vault.
+>
+
+:::
+
+Find out more about Vaults in the [Squads documentation](https://docs.squads.so/squads-v3-docs/navigating-your-squad/transactions). Take some time to familiarize yourself with this interface.
+
+#### Step 5: Create a transfer proposal
+
+
+This next step covers creating a transaction, note that the flow is slightly different from the perspective of the account owner vs. a delegated owner. Choose the path that applies to you.
+
+Due to the custody policy applied by the MultiSig wallet, you must both create *and* approve a transaction.
+
+This step covers creating a transaction, note that the flow is slightly different from the perspective of the account owner vs. a delegated owner. Choose the path that applies to you.
+
+
+
+
+ **Create transaction**
+
+ a. Within the **Vault** tab, click on the **Send** button.
+
+ >
+
+ b. Configure this transaction:
+
+ - Asset: the asset type to be sent
+ - Amount: the amount of assets to be sent
+ - To address: recipient of the assets
+ - (Optional): description
+
+ c. Click **Send**.
+
+ >
+
+
+
+
+
+
+ While an account owner may create a transaction and broadcast that for votes, as a delegate you must create a proposal first. For this tutorial, we will select to **Transfer** from **Token Program** template.
+
+ **Create proposal**
+
+ a. Within the **TX Builder** tab, click on the **Create transaction** button or select from the templates available in the dashboard: we will select the **Token Program** template.
+
+ >
+
+ b. Choose the **Transfer** instruction from the list.
+
+ >
+
+ c. Configure this transaction proposal:
+
+ > Note, the Token Program works with the DAO token, i.e. NEON, therefore, the token is already identified.
+
+ - Amount: the amount of the asset to be sent, detailed to the required decimal places
+ - Source: account holding the tokens to be transferred
+ - Destination: recipient of the assets
+
+ >
+
+ d. Click **Save draft**.
+
+ e. You may either **Run Simulation** to verify the transaction is executable, or **Initiate Transaction**.
+
+
+
+
+
+## Vote
+
+A MultiSig wallet applies a threshold policy to allow greater control and security over transactions. While you may set up a MultiSig wallet to behave like a single-signature wallet by creating a threshold of "1 of 1", this is ill-advised. The following steps provides a recently created transaction with an approval which will count toward the customized threshold for this Vault. Remember, you have connected your hardware wallet and Phantom wallet to manage your approval process; expect to use both to achieve the next step.
+
+a. From the **Transactions** tab, select the **Active** proposal you are interested in.
+
+>
+
+Under the **Results** section, you will see a number for *Confirmed* and a number for *Rejected*. When the transaction is first created, both numbers should be 0.
+
+b. Click **Confirm** to vote for the transaction, and **Reject** to vote against it.
+
+>
+
+Squads will prompt you to approve the transaction using your Phantom wallet extension.
+
+c. Click **Approve**.
+
+>
+
+To verify the transaction details on the Ledger device, connect your Ledger hardware wallet to the computer and open the Solana app. Approve the transaction using the physical buttons on the device.
+
+> Remember, a transaction request won't be signed until approvals are provided by other parties and the minimum threshold specified in the MultiSig wallet is met. In this example, the threshold is 3, so 2 or more signatures are required to execute this transaction.
+
+## Execute a transaction
+
+Once the minimum threshold of signatures is collected, the transaction may be executed, and the assets will be transferred.
+
+> Note that the previous step allowed the transaction to be signed. Initiating the "execute" allows this signed transaction to be broadcast to the Solana network.
+
+a. Click **Execute**.
+
+>
+
+Congratulations, your signed tx is now broadcast.
+
+> Should your transaction be rejected (i.e. if the minimum threshold of votes against the transaction was met), then the transaction enters the **Cancelled** status and will not be signed and, therefore, never executed.
+
+## Verify transaction
+
+If you wish to verify a transaction, you can either monitor the MultiSig wallet using a Solana block explorer, such as [Solana Explorer](https://explorer.solana.com/) or [Solscan](https://solscan.io/). Alternatively, you may verify in the Squads Vault that the assets transferred successfully.
+
diff --git a/docs/governance/withdraw_neon.md b/docs/governance/withdraw_neon.md
new file mode 100644
index 00000000..22439679
--- /dev/null
+++ b/docs/governance/withdraw_neon.md
@@ -0,0 +1,86 @@
+---
+title: Claiming Vested NEON Tokens
+proofedDate:
+iterationBy:
+includedInSite: true
+approvedBy:
+comment: This page explains the process for claiming vested NEON tokens through the Neon EVM Governance service
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import image1 from '@site/static/img/doc-images/vesting/connect_wallet.png';
+import image2 from '@site/static/img/doc-images/vesting/vesting_section.png';
+import image3 from '@site/static/img/doc-images/vesting/vesting_calendar2.png';
+import image4 from '@site/static/img/doc-images/vesting/withdraw_neon.png';
+import image5 from '@site/static/img/doc-images/vesting/advanced_option.png';
+
+## TL;DR
+
+
+
+## Introduction
+
+This guide explains how participants subject to a vesting schedule can access the Neon EVM Governance service and use it to claim available tokens.
+
+## How to prepare for claiming your vested tokens
+
+* Ensure you have one of the following Solana-compatible wallets installed in your browser:
+ * Phantom
+ * Solflare
+ * Ledger
+ * Backpack
+ * WalletConnect
+* Verify that this Solana wallet controls the wallet address provided to the Neon EVM team during the Token Generation Event of August 2023.
+* Ensure your Solana wallet contains enough SOL tokens to cover the gas fees for withdrawal transactions.
+
+## Steps to Claim the NEON Vested Tokens
+
+### 1. Access the Neon Governance interface & Connect Your Wallet
+
+* Navigate to https://vote.neondao.org/.
+* Click "Connect Wallet" and select your Solana-compatible wallet.
+
+
+
+### 2. Access the Vesting Section
+
+* Once connected, locate and click on the "Vesting" button to view the details of your vesting schedule.
+
+* The vesting schedule will show you:
+ * The remaining amount of NEON tokens that can be claimed monthly, starting from August 7 2024, and for a period of 12 months.
+ * The associated date of each monthly token unlock.
+
+
+
+:::note
+The numbers and dates shown in the image are for illustration only.
+:::
+
+
+
+### 3. Claim Available Tokens
+
+* Click on the "Withdraw NEON" button.
+
+
+
+* Select the amount of tokens to withdraw by checking the corresponding box.
+* (Optional) For advanced users:
+ * To broadcast your transaction faster to the Solana network, you can increase the priority fee by activating the advanced mode option.
+* Click on the "Withdraw" button.
+
+
+
+### 4. Confirm Withdrawal
+
+* Confirm the transaction in your Solana wallet to get your NEON tokens.
+
+## Troubleshooting
+
+If you encounter issues while claiming your tokens:
+
+1. Ensure you have a sufficient balance for transaction fees.
+2. If you encounter failed transactions, use the advanced mode feature and select the "Fast" priority fee.
+
+For further assistance, please contact our support team.
\ No newline at end of file
diff --git a/docs/operating/accounts.md b/docs/operating/accounts.md
new file mode 100644
index 00000000..d30c4d24
--- /dev/null
+++ b/docs/operating/accounts.md
@@ -0,0 +1,373 @@
+---
+title: Accounts & Payment
+proofedDate: 20230622
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: todo Page deserves major refactoring -- tries to do too much in one page here
+---
+
+import solBal from '@site/static/img/doc-images/operating/sol-bal.png';
+import neonBal from '@site/static/img/doc-images/operating/neon-bal.png';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+
+## TL;DR
+
+- Operator keys are whitelisted for Proxy access
+- Key accounts must provide SOL to support Neon EVM transactions
+- Key accounts have a 1:1 relationship with Neon accounts
+- Account balances may be queried and topped up
+- Security of SOL balances is an important consideration
+
+## The Operator key
+
+The Operator key is an account that is whitelisted by the Neon EVM. Neon Proxy creates several holder accounts linked to each Neon Operator key (if the Neon Operator key has enough SOLs).
+
+> Neon DAO provides the governance to determine the whitelist.
+
+:::info
+
+Operator keys should be spread [evenly between Proxy instances](operator-introduction#redundancy).
+
+:::
+
+## Holder accounts
+
+[Holder accounts](/docs/architecture/solana-accounts/#holder-accounts) are a crucial element of Neon EVM. Neon Proxy creates holder accounts with [rent-exempt balances](https://solana.com/docs/core/accounts#rent) on start. The number of holder accounts created determines the TPS provided to users and can be configured with `PRX_PERM_ACCOUNT_LIMIT`.
+
+You may retrieve a list of Neon Operator key accounts and attached holder accounts (see [**Retrieve your balance**](#query-balance) below).
+
+
+## Account balance
+
+The Neon Operator maintains a balance of SOLs in the account associated with each Operator key to pay gas on Solana in SOLs to process Neon transactions.
+
+### Required balance
+
+Solana requires SOLs on the balance of any account, and the balance depends on the size of the account. We recommend maintaining a balance of 100—200 SOLs in Neon Operator key accounts.
+
+:::info
+The Neon team recommends:
+
+- The number of Neon Operator keys = 40
+- The number of holder accounts per Neon Operator key = 32
+- The Neon Operator should have 2336.5287936 SOL on the balance of Neon Operator keys, or 2336.5287936 / 40 = 58,41321984 SOLs on each Neon Operator key at the start
+- The Neon Operator should have 200 SOLs available per month to process Neon transactions. That means the total balance on each Neon Operator key will be = 58,41321984 + 200 / 40 = 63,41321984 SOLs
+:::
+
+Let's take a look at the logic behind this recommendation.
+
+The number of required SOLs depends on:
+
+- The size of the [holder account](/docs/architecture/solana-accounts/#holder-account-size)
+- The number of holder accounts
+
+> Remember, the number of holder accounts correlates with the TPS of the Neon Proxy instance.
+
+
+
+
+
+To calculate the number of SOLs required by the Neon Operator, use the following logic:
+
+- The TPS depends on the finalization time of the Solana, which is equal to 32 Solana blocks because the content of the holder account should be retained until successful finalization of the the Neon transaction
+
+- The Solana block time is 400 ms. So in 1 second, Solana may produce 1 / 0.4 = 2.5 blocks
+
+:::info
+
+The formula to calculate the number of holder accounts and required SOLs is as follows:
+
+Number-of-Holders = TPS / Solana-Blocks-per-Sec * Solana-Blocks-for-Finalization
+- Solana-Blocks-per-Second = 2.5 (see above)
+- Solana-Blocks-for-Finalization = 32 (see above)
+
+SOLs-for-Holders = Rent-Exempt-Balance * Number-of-Holders
+
+- Rent-Exempt-Balance = 1.82541312 SOL (see Solana standard rent calculations in the tab above)
+
+Number-of-Holders-per-Operator-key = Number-of-Holders / Number-of-Operator-keys
+:::
+
+The following tabs provide worked examples of this formula:
+
+
+
+
+- Number-of-Holders = 100 / 2.5 * 32 = 1280
+- SOLs-for-Holders = 1.82541312 * 1280 = 2336.5287936 SOL
+- Number-of-Holders-per-Operator-key = 1280 / 40 = 32
+
+
+
+
+
+- Number-of-Holders = 50 / 2.5 * 32 = 640
+- SOLs-for-Holders = 1.82541312 * 640 = 1168,2643968 SOL
+- Number-of-Holders-per-Operator-key = 640 / 40 = 16
+
+
+
+
+
+
+
+
+For a rent-exempt account of 262,144 bytes, Solana requires:
+- Solana rent 262144
+- Rent per byte-year: 0.00000348 SOL
+- Rent per epoch: 0.004997815 SOL
+- Rent-exempt minimum: 1.82541312 SOL
+
+
+
+
+
+
+### Query balance
+
+You may query your account balances visually or programmatically.
+
+
+
+
+Neon Proxy provides a local Grafana dashboard that monitors statistics in the Prometheus/Grafana. They display metrics from `operator_neon_balance` and `operator_sol_balance`.
+
+>
+
+>
+
+
+
+
+The command that retrieves the list of Neon Operator key accounts and attached holder accounts provided by your Proxy instance:
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh info solana-accounts
+```
+
+
+
+
+```bash
+kubectl -nneon-proxy exec -it neon-proxy-0 -- ./proxy-cli.sh info solana-accounts
+```
+
+
+
+Returns both the account address and the account balances.
+
+```
+BMp6gEnveANdvSvspESJUrNczuHz1GF5UQKjVLCkAZih 499,845,973.855814040
+holder:
+ 2f372pRn7EMdw5zXg777AJT35KdjLSssFN5WF4tEwxLf 0.913152000
+ AUWqkg2YCPXRzuszZX84rQ8WhCKLKk7751QQv8VbXUoD 0.913152000
+9kPRbbwKL5SYELF4cZqWWFmP88QkKys51DoaUBx8eK73 5,997.928707200
+holder:
+ 5Hkx7V84kVPH1bhgnytS6GB7oH7yPXQ9Yvt6YML6SKcQ 0.913152000
+ 53ptDdWaL5w2kPHmhbewiu7TVBDpiL2fvEEPDFppqdhD 0.913152000
+....
+total_balance 499,991,914.067759640
+resource_balance 54.789120000
+
+```
+
+Alternatively, you may retrieve a structured JSON output with more detailed account information by using:
+
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh info | python3 -mjson.tool
+```
+
+
+
+
+```bash
+kubectl -nneon-proxy exec -it neon-proxy-0 -- ./proxy-cli.sh info | python3 -mjson.tool
+```
+
+
+
+
+
+
+
+### Topup balance
+
+Neon provides a docker compose file to add SOLs to your accounts. This is not released in the same cluster as the Proxy service, because it must access your SOL wallet. If you wish to use this tool, choose a safe environment to run this.
+
+:::caution
+
+Best practice is to use the dedicated script (wip: coming soon!) to automatically transfer SOLs to your Neon Operator key accounts when the balance becomes too low. This security measure avoids storing excessive SOLs in Neon Operator key accounts, to protect them from a malicious user. The potential vulnerability arises because the Neon Proxy has access to Neon Operator keys. Therefore, should a hacker gain access to the Neon Operator server, they may get access to the Neon Proxy configuration with the Neon Operator keys.
+
+:::
+
+> Link to [Docker compose file](https://github.com/neonlabsorg/proxy-model.py/tree/master/docker-compose).
+
+### Reduce holder account count and withdraw balance
+
+:::info
+
+To reduce the holder account number, the Neon Operator must restart the Neon Proxy with the new number of holder accounts; otherwise, the Neon Proxy recreates the holder account.
+
+:::
+
+The Neon Proxy checks existing holder account requirements and creates holder accounts when it starts. The Neon Proxy doesn’t delete them at the end of the work, because each creation and deletion executes Solana transactions, and this action requires additional SOLs.
+
+But, if you want to decrease the number of holder accounts, you can delete holder accounts by address, and withdraw SOLs from their balance back to the linked Operator key account with the following commands:
+
+1. **List existing holder accounts**:
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh holder-account list
+
+```
+
+
+
+```bash
+kubectl exec -it po/neon-proxy-0 -n neon-proxy -- ./proxy-cli.sh holder-account list
+
+```
+
+
+
+
+2. **Delete a specified account**:
+
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh holder-account delete
+```
+
+
+
+
+```bash
+kubectl exec -it po/neon-proxy-0 -n neon-proxy -- ./proxy-cli.sh holder-account delete
+
+```
+
+
+
+
+### Withdraw NEON
+
+Solana can process transactions in parallel — as long as the request passes an independent list of all affected accounts. To accommodate Neon parallel transactions, the Neon Proxy uses multiple Neon accounts to receive payments from Neon users. To simplify the logic, the Neon Proxy has one Neon account for each Neon Operator key.
+
+To get the list of Neon accounts, run the following command:
+
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh neon-account list
+```
+
+
+
+
+```bash
+kubectl exec -it po/neon-proxy-0 -n neon-proxy -- ./proxy-cli.sh neon-account list
+```
+
+
+
+
+Alternatively, you may retrieve a structured JSON output with more detailed account information by using:
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh info | python3 -mjson.tool
+```
+
+
+
+```bash
+kubectl -nneon-proxy exec -it neon-proxy-0 -- ./proxy-cli.sh info | python3 -mjson.tool
+```
+
+
+
+#### Withdraw NEON tokens from Neon Operator accounts
+
+To withdraw NEON tokens from Neon Operator accounts, pass the following variables:
+- Required:
+ - `ADDRESS`: destination address for withdrawal
+ - One of:
+ - `AMOUNT`: amount of NEON to withdraw from each Neon account
+ - `PERCENT|NEON`: the nature of the amount (percent by default)
+
+into the Docker or Kubernetes command:
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh neon-account withdraw
+```
+
+
+
+
+```bash
+kubectl -nneon-proxy exec -it neon-proxy-0 -- ./proxy-cli.sh neon-account withdraw
+```
+
+
+
+**For example: **
+
+##### Withdraw 100% of all NEON:
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh neon-account withdraw 0x0123AbC... 100
+```
+
+
+
+
+```bash
+kubectl -nneon-proxy exec -it neon-proxy-0 -- ./proxy-cli.sh neon-account withdraw 0x0123AbC... 100 PERCENT
+```
+
+
+
+
+##### Withdraw 10 NEON from all accounts:
+
+
+
+
+```bash
+docker exec -ti proxy ./proxy-cli.sh neon-account withdraw 0x0123AbC... 10 NEON
+```
+
+
+
+
+```bash
+kubectl -nneon-proxy exec -it neon-proxy-0 -- ./proxy-cli.sh neon-account withdraw 0x0123AbC... 10 NEON
+```
+
+
diff --git a/docs/operating/basic.md b/docs/operating/basic.md
new file mode 100644
index 00000000..25c00397
--- /dev/null
+++ b/docs/operating/basic.md
@@ -0,0 +1,596 @@
+---
+title: Proxy local testing
+proofedDate: 20230706
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import stats from '@site/static/img/doc-images/operating/local-proxy/docker-stats2.png';
+import network from '@site/static/img/doc-images/operating/local-proxy/mm-manual-network-add.png';
+import network2 from '@site/static/img/doc-images/operating/local-proxy/network.png';
+import nmap from '@site/static/img/doc-images/operating/local-proxy/nmap-local-host.png';
+import update from '@site/static/img/doc-images/operating/local-proxy/mmw_update.png';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+
+## Prerequisites
+
+- Ubuntu/Intel
+> This tutorial presents a flow using an Intel chip with Ubuntu (as of the time of writing, the Solana image does not support alternative operating systems).
+- Browser supporting a MetaMask wallet
+> [This tutorial uses Brave](https://brave.com/linux/).
+- [Docker compose](https://docs.docker.com/compose/install/) v>[2.12.1](https://docs.docker.com/compose/release-notes/#2121)
+- 1 Terabyte or more to run the Solana standalone node
+> Solana provides further details on the [recommended minimum requirements](https://docs.solana.com/ru/running-validator/validator-reqs).
+- nmap (or equivalent)
+
+:::important
+This example for setting up the local proxy works only with **Neon EVM Devnet**.
+:::
+
+## Step 1: Create a docker compose file
+
+
+Save the following code to a file in your local destination.
+
+
+docker-compose.yml file content
+
+```YAML
+version: "3"
+
+services:
+ solana:
+ container_name: solana
+ image: neonlabsorg/evm_loader:${NEON_EVM_COMMIT:-v1.7.2}
+ environment:
+ SOLANA_URL: http://solana:8899
+ RUST_LOG: solana_runtime::system_instruction_processor=trace,solana_runtime::message_processor=debug,solana_bpf_loader=debug,solana_rbpf=debug
+ hostname: solana
+ expose:
+ - "8899"
+ - "9900"
+ - "8900"
+ - "8001"
+ - "8001-8009/udp"
+ networks:
+ - net
+ ports:
+ - 8899:8899
+ - 8900:8900
+ healthcheck:
+ # Must be available from outside (calling without -u causes premature result)
+ test: [ CMD-SHELL, "./wait-for-neon.sh" ]
+ interval: 5s
+ timeout: 5s
+ retries: 20
+ start_period: 5s
+ entrypoint: /opt/solana-run-neon.sh
+
+ neon_test_invoke_program_loader:
+ container_name: neon_test_invoke_program_loader
+ image: neonlabsorg/neon_test_invoke_program:develop
+ environment:
+ SOLANA_URL: http://solana:8899
+ networks:
+ - net
+ depends_on:
+ solana:
+ condition: service_healthy
+ entrypoint: /opt/neon-test-invoke-program.sh
+
+ postgres:
+ container_name: postgres
+ image: postgres:15.3
+ command: postgres -c 'max_connections=1000'
+ environment:
+ POSTGRES_DB: neon-db
+ POSTGRES_USER: neon-proxy
+ POSTGRES_PASSWORD: neon-proxy-pass
+ hostname: postgres
+ healthcheck:
+ test: [ CMD-SHELL, "pg_isready -h postgres -p 5432" ]
+ interval: 3s
+ timeout: 3s
+ retries: 10
+ start_period: 5s
+ expose:
+ - "5432"
+ ports:
+ - "5432"
+ networks:
+ - net
+
+ dbcreation:
+ container_name: dbcreation
+ image: neonlabsorg/proxy:${PROXY_COMMIT:-v1.7.9}
+ environment:
+ SOLANA_URL: http://solana:8899
+ POSTGRES_DB: neon-db
+ POSTGRES_USER: neon-proxy
+ POSTGRES_PASSWORD: neon-proxy-pass
+ POSTGRES_HOST: postgres
+ entrypoint: /bin/sh
+ command: proxy/run-dbcreation.sh
+ networks:
+ - net
+ depends_on:
+ postgres:
+ condition: service_healthy
+
+ proxy:
+ container_name: proxy
+ image: neonlabsorg/proxy:${PROXY_COMMIT:-v1.7.9}
+ environment:
+ SOLANA_URL: http://solana:8899
+ FAUCET_URL: http://faucet:3333
+ PROXY_URL: http://proxy:9090/solana
+ POSTGRES_DB: neon-db
+ POSTGRES_USER: neon-proxy
+ POSTGRES_PASSWORD: neon-proxy-pass
+ POSTGRES_HOST: postgres
+ NEON_CLI_DEBUG_LOG: "YES"
+ FUZZ_FAIL_PCT: 0
+ GATHER_STATISTICS: "YES"
+ CONFIG: ci
+ MIN_OPERATOR_BALANCE_TO_WARN: 4565760000 # = 913152000 * 5 (5 storage accounts) = 4.56576 SOL
+ MIN_OPERATOR_BALANCE_TO_ERR: 913152000 # = solana rent 131072 (= Rent-exempt minimum: 0.913152 SOL) SOLs to create a storage
+ PP_SOLANA_URL: ${CI_PP_SOLANA_URL:-https://api.devnet.solana.com}
+ PYTH_MAPPING_ACCOUNT: ${CI_PYTH_MAPPING_ACCOUNT:-BmA9Z6FjioHJPpjT39QazZyhDRUdZy2ezwx4GiDdE2u2}
+ GAS_PRICE_SLIPPAGE: 0.3
+ ENABLE_PRIVATE_API: "NO"
+ ALLOW_UNDERPRICED_TX_WITHOUT_CHAINID: "YES"
+ LOG_FULL_OBJECT_INFO: "NO"
+ EVM_LOADER: 53DfF883gyixYNXnM7s5xhdeyV8mVk9T4i2hGV9vG9io
+ RUST_BACKTRACE: ${RUST_BACKTRACE:-0}
+ COMMIT_LEVEL: "Confirmed"
+ SOLANA_KEY_FOR_EVM_CONFIG: "BMp6gEnveANdvSvspESJUrNczuHz1GF5UQKjVLCkAZih"
+ hostname: proxy
+ depends_on:
+ solana:
+ condition: service_healthy
+ dbcreation:
+ condition: service_completed_successfully
+ ports:
+ - 9090:9090
+ - 8881:8888
+ expose:
+ - "8888"
+ - "9090"
+ networks:
+ - net
+ entrypoint: proxy/run-test-proxy.sh
+ healthcheck:
+ test: [ CMD-SHELL, "/opt/health_check_proxy.sh" ]
+ interval: 5s
+ timeout: 3s
+ retries: 20
+ start_period: 5s
+
+ faucet:
+ container_name: faucet
+ image: neonlabsorg/faucet:${FAUCET_COMMIT:-v1.7.x}
+ environment:
+ FAUCET_RPC_BIND: 0.0.0.0
+ FAUCET_RPC_PORT: 3333
+ FAUCET_WEB3_ENABLE: 'true'
+ WEB3_RPC_URL: http://solana:8899
+ WEB3_PRIVATE_KEY: 0x4deacb079b4714c38f39508aa8900039f2721ed8686835d43347ba9267da767b
+ NEON_ERC20_TOKENS: '["0xB521b9F3484deF53545F276F1DAA50ef0Ca82E2d", "0x8a2a66CA0E5D491A001957edD45A6350bC76D708", "0x914782059DC42d4E590aeFCfdbF004B2EcBB9fAA", "0x7A7510b9b18241C788a7aAE8299D1fA6010D8128"]'
+ NEON_ERC20_MAX_AMOUNT: 1000
+ FAUCET_SOLANA_ENABLE: 'true'
+ SOLANA_URL: http://solana:8899
+ NEON_OPERATOR_KEYFILE: /root/.config/solana/id.json
+ NEON_ETH_MAX_AMOUNT: 50000
+ TEST_FAUCET_INIT_NEON_BALANCE: 100000000
+ EVM_LOADER: 53DfF883gyixYNXnM7s5xhdeyV8mVk9T4i2hGV9vG9io
+ NEON_TOKEN_MINT: HPsV9Deocecw3GeZv1FkAPNCBRfuVyfw9MMwjwRe1xaU
+ NEON_TOKEN_MINT_DECIMALS: 9
+ SOLANA_COMMITMENT: confirmed
+ RUST_BACKTRACE: ${RUST_BACKTRACE:-0}
+ hostname: faucet
+ ports:
+ - 3333:3333
+ expose:
+ - "3333"
+ networks:
+ - net
+ entrypoint: ./run-test-faucet.sh
+ depends_on:
+ solana:
+ condition: service_healthy
+
+ indexer:
+ container_name: indexer
+ image: neonlabsorg/proxy:${PROXY_COMMIT:-v1.7.9}
+ environment:
+ SOLANA_URL: http://solana:8899
+ POSTGRES_DB: neon-db
+ POSTGRES_USER: neon-proxy
+ POSTGRES_PASSWORD: neon-proxy-pass
+ POSTGRES_HOST: postgres
+ POSTGRES_TIMEOUT: 5
+ GATHER_STATISTICS: "YES"
+ LOG_FULL_OBJECT_INFO: "NO"
+ CONFIG: ci
+ EVM_LOADER: 53DfF883gyixYNXnM7s5xhdeyV8mVk9T4i2hGV9vG9io
+ START_SLOT: latest
+ REINDEX_START_SLOT: continue
+ hostname: indexer
+ depends_on:
+ solana:
+ condition: service_healthy
+ dbcreation:
+ condition: service_completed_successfully
+ expose:
+ - "8887"
+ ports:
+ - 8882:8888
+ networks:
+ - net
+ entrypoint: proxy/run-indexer.sh
+
+networks:
+ net:
+```
+
+In case you want to use a remote Solana node, change the SOLANA_URL value to its URL.
+
+## Step 2: Configure environment variables
+
+Set the following optional variables to "latest" to work with the Docker image's latest settings. If a variable is not specified, the version 1.7 of the corresponding component is used by default.
+
+Run the commands:
+
+```bash
+export NEON_EVM_COMMIT=latest; export PROXY_COMMIT=latest; export FAUCET_COMMIT=latest
+```
+
+## Step 3: Run the Docker containers
+
+Use the docker compose file created in the Step 1 to pull and run the docker containers:
+
+3.1 Pull the Docker images:
+
+```bash
+docker-compose -f /path/to/docker-compose.yml pull
+```
+
+3.2 Start the proxy with:
+
+```bash
+docker-compose -f /path/to/docker-compose.yml up
+```
+
+
+
+
+
+> Let's check the status of our containers with:
+>
+> ```bash
+> docker stats
+> ```
+>
+
+
+
+
+
+
+
+
+
+
+
+
+Congratulations, you are now running Neon EVM deployed to a single, local node of Solana.
+
+:::tip
+
+> When you are at the point where you are willing to lose your data, then free your disk space and close the instance by running:
+> ```bash
+> docker-compose -f /path/to/docker-compose.yml down
+> ```
+:::
+
+## Step 4: Set up MetaMask wallet to run with the local proxy
+
+Set up your MetaMask wallet with the proxy:
+
+Tip:
+> Run nmap, or equivalent, to view the ports the services are running on:
+>
+> ```bash
+> nmap localhost
+> ```
+> The port 9090 is our proxy and 3333 is our faucet.
+
+
+
+
+From your browser's MetaMask extension, set the localhost as a network within the MetaMask wallet, click: **Settings** > **Networks** > **Add a Network** > **Add a network manually**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+4.2 Fill out the following fields:
+- **Network name**: Neon Localhost
+- **New RPC URL**: http://localhost:9090/solana
+- **Chain ID**: 111
+- **Currency symbol**: NEON
+
+And click **Save**.
+
+
+
+
+
+
+
+
+
+
+
+
+## Step 5: Use the faucet to populate your wallet with NEON tokens
+
+5.1 Copy your account address from your MetaMask wallet and update the following script to use your address:
+
+
+
+file: drop_neons.sh
+
+```bash
+#!/usr/bin/env bash
+
+if [ -z "$1" ]; then
+ echo "Usage: drop_neons.sh "
+ exit 1
+fi
+
+/usr/bin/curl --location --request POST 'http://localhost:3333/request_neon' \
+--header 'Content-Type: application/json' \
+--data-raw '{
+ "wallet": "'${1}'",
+ "amount": 1000
+}'
+```
+
+5.2 From your terminal, at the file location run `sh ./drop_neons.sh {wallet address}`.
+
+
+
+
+## Gotchas
+
+- It is recommended that you have a couple of terabytes of free space! Should you want to run your node with persistent data, the space requirements will grow.
+- The MetaMask Wallet may not update automatically:
+
+
+
+Neon Localhost to force a refresh after using the faucet
+
+
+
+
+
+
+
+
+- It is only possible to set up the localhost network in the MetaMask wallet while the proxy service is running.
+- If you are following best practice, and adding your [user to the `docker` group](https://docs.docker.com/engine/install/linux-postinstall/) to avoid running Docker as root or sudo, then restart to apply the update.
+
+
+
+## What next?
+
+Congratulations you can now deploy and test smart contracts on the NeonEVM. Consider:
+- [Deploying a contract](../developing/deploy_facilities/using_remix) via the Remix IDE
+- [Understanding how to configure your self-managed Proxy](enhanced.md#configuration)
+
+
+
+
+
+
diff --git a/docs/operating/configuration.md b/docs/operating/configuration.md
new file mode 100644
index 00000000..15c46705
--- /dev/null
+++ b/docs/operating/configuration.md
@@ -0,0 +1,39 @@
+---
+title: Variable Configuration
+proofedDate: 20230622
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: Need a location for the API calls ```notion.so/neonlabs/Neon-Specific-API-methods-3402baaad8fa4daeb12642495cf85eb3```
+---
+
+## Configuration of Neon Proxy
+
+The following variables may be configured to customize your Neon Proxy implementation:
+
+|Variable|Description/Link |
+|-----|:-----------------------------------------|
+|`PRX_PERM_ACCOUNT_LIMIT` |[Sets number of holder accounts / TPS](accounts#holder-accounts) to provide 100 TPS, PRX_PERM_ACCOUNT_LIMIT = 32|
+|`PRX_MINIMAL_GAS_PRICE`| [Hard set for minimum gas price to tx to mempool](transaction-gas#minimum-gas-price)|
+|`PRX_OPERATOR_FEE`|Sets [Operator fee](transaction-gas#gas-price-the-operator-fee) as a fraction of 100%, 0.1 = 10% fee|
+|`PRX_PP_SOLANA_URL`|[HTTP/S address of the Solana network with the main Pyth oracle contract](transaction-gas#calculation-configuration), e.g. this [Devnet](https://api.devnet.solana.com) address|
+|`PRX_PYTH_MAPPING_ACCOUNT`|[Solana address of the Pyth mapping account](transaction-gas#calculation-configuration), e.g. this Devnet address `BmA9Z6FjioHJPpjT39QazZyhDRUdZy2ezwx4GiDdE2u2` as per the Pyth account data page, [pyth.network/developers/accounts](https://pyth.network/developers/accounts?cluster=devnet)|
+|`PRX_UPDATE_PYTH_MAPPING_PERIOD_SEC`|[Time period to reread the Pyth mapping account](transaction-gas#calculation-configuration)|
+|`PRX_HOLDER_SIZE`|[Holder account](/docs/architecture/solana-accounts/#holder-account-size) size. Defaults to 262,144 bytes|
+|`FAUCET_URL`|For use in Devnet and Testnet: URL to the faucet service for distributing NEON tokens to the users|
+|`INDEXER_ERC20_WRAPPER_WHITELIST`|A comma-separated list of ERC20-for-Spl wrapped tokens for transfer (those transactions which trigger the service to allow gas-less transactions). The gas-tank looks for the first transfers of such tokens from Solana to Neon (those transfers that lead to the creation of Neon accounts).|
+|`PORTAL_BRIDGE_CONTRACTS`|A comma-separated list of Portal Bridge contracts|
+|`PORTAL_BRIDGE_TOKENS_WHITELIST`|An allowlist of tokens for the transfer which will trigger gas-less transactions. This set should contain "tokenChain:tokenAddress", where: tokenChain is an original token chain number in terms of Portal bridge numbers tokenAddress is the address of the token in hexadecimal lowercase form with a '0x' prefix. Alt: provide the ANY value to accept any token.|
+|`ERC20_BRIDGE_CONTRACTS`|A comma-separated list of Common ERC20 Bridge contracts|
+|`ERC20_BRIDGE_TOKENS_WHITELIST`|An allowlist of tokens whose transfer triggers the providing of gasless transactions. Comma-separated ERC20 addresses. Alt: provide the `ANY` value to accept any token.|
+
+## Gotchas
+
+`PORTAL_BRIDGE_CONTRACTS` & `PORTAL_BRIDGE_TOKENS_WHITELIST` should both be specified. If either is missed, the gas tank doesn't analyze Portal Bridge transfers.
+
+`ERC20_BRIDGE_CONTRACTS` & `ERC20_BRIDGE_TOKENS_WHITELIST` should both be specified. If they are missed, the gas tank doesn't analyze common ERC20 transfers.
+
+## What next?
+
+A full list of the parameters are available in the [sample configuration](https://github.com/neonlabsorg/infrastructure-kubernetes/blob/main/config.ini.sample).
+
diff --git a/docs/operating/enhanced.md b/docs/operating/enhanced.md
new file mode 100644
index 00000000..4db2b47b
--- /dev/null
+++ b/docs/operating/enhanced.md
@@ -0,0 +1,262 @@
+---
+title: 'Self-Managed: Build with Your Own k8s Cluster'
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comments: todo -- it may be more appropriate to have 1 page detailing all the environment variables common to both local and "enhanced" Proxy as they are the same tooling simply run in different environments
+---
+
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+## Who Should Use This Guide
+
+The guide provides instructions on how to run a self-managed instance of Neon Proxy that offers more flexibility, configurability, and control for its Operator. It is designed for operators who use or would like to use a Kubernetes cluster to host the Neon Proxy installation. Kubernetes could be either on-premise or provided by a third party, such as AWS(EKS), Azure(AKS), or GCP(GKE).
+
+Please note that operating a self-managed Neon Proxy requires certain technical expertise and a solid understanding of network and security protocols. The operator is responsible for ensuring the security and reliability of the proxy and the Kubernetes cluster it runs on, and will be well-advised to invest time and resources into managing and maintaining them.
+
+## Operator Requirements
+
+### Balance Recommendations
+
+First, you must be **registered** in Solana, which involves creating an account with a balance for storing SOL tokens, and getting the account's public and private keys.
+
+There is no strict minimum amount of SOL tokens required to run as an operator on the Neon EVM. However, you should take into account the fact that you will need SOL tokens to create accounts for new users, deploy contracts, and execute transactions.
+
+In addition to the balance for storing SOL tokens, an operator must also have the `NEON_TOKEN_MINT` balance for storing value tokens. These tokens are used to pay funds from users to an operator for the successful execution of transactions. Depending on the chosen configuration, specific values for `NEON_TOKEN_MINT` are described in the table below.
+
+CONFIG | NEON_TOKEN_MINT
+:-|:-
+devnet | 89dre8rZjLNft7HoupGiyxu3MNftR577ZYu8bHe2kK7g
+local | HPsV9Deocecw3GeZv1FkAPNCBRfuVyfw9MMwjwRe1xaU
+
+
+To create the `NEON_TOKEN_MINT` balance, you can use the following command:
+```bash
+spl-token -u create-account
+```
+
+### Kubernetes
+
+Our operators are based on three kind of kubernetes providers:
+* Local development, using tools such as [microk8s](https://microk8s.io/), [kind](https://kind.sigs.k8s.io/), [minikube](https://minikube.sigs.k8s.io/docs/start/), and [k3s](https://k3s.io/)
+* Managed Kubernetes environment with [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine), based on [Google Cloud Platform (GCP)](https://cloud.google.com/)
+* Managed Kubernetes environment with [Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), based on [Amazon Web Services (AWS)](https://aws.amazon.com/)
+
+This means that the following components need to be **installed** on your device prior to proceeding:
+* [Kubernetes](https://kubernetes.io/docs/setup/) version ≥ 1.21
+* [Helm 3](https://helm.sh/docs/intro/install/), Kubernetes' package manager
+* [kubectl](https://kubernetes.io/docs/reference/kubectl/), a command-line tool for Kubernetes' control plane
+* [jq](https://stedolan.github.io/jq/), a command-line JSON processor
+
+To set up Kubernetes with k0s, refer to [this guide](https://docs.k0sproject.io/head/install/).
+
+### Hardware Recommendations
+
+The following table represents the minimum specifications that you need to have to ensure a smooth operator experience.
+
+
+
+
+|Component|Requirement |
+|-----|:-----------------------------------------|
+|Servers/VMs | At least two (2) with Intel Processor x86_64 |
+|CPU | 16 vCPU (for each server/VM) |
+|RAM | 32 GB (for each server/VM) |
+|Storage | 1 TB |
+
+
+
+|Component|Requirement |
+|-----|:-----------------------------------------|
+|Servers/VMs | Intel Processor x86_64 |
+|CPU | 8 vCPU |
+|RAM | 16 GB |
+|Storage | 128 GB |
+
+
+
+## Installation
+
+A Neon proxy can be easily spun up using Kubernetes and the installation scripts at [neonlabsorg/infrastructure-kubernetes](https://github.com/neonlabsorg/infrastructure-kubernetes).
+
+First, clone the repository from GitHub:
+```bash
+git clone https://github.com/neonlabsorg/infrastructure-kubernetes.git
+cd infrastructure-kubernetes/
+```
+
+:::info
+The scripts in [neonlabsorg/infrastructure-kubernetes](https://github.com/neonlabsorg/infrastructure-kubernetes) will deploy the following:
+1. The `neon-proxy` namespace
+2. The `proxy-svc` Proxy service
+3. The `indexersvc` Indexer service
+4. Prometheus (used to gather application metrics from proxy and indexer services)
+5. Loki (tool for log collection from all applications inside the cluster)
+6. Grafana (visualization tool for monitoring metrics)
+
+For the database service, there are two options available, both of which will be described in detail in the following section.
+:::
+
+Next, copy the configuration file into `config.ini`:
+```bash
+cp config.ini.sample config.ini
+```
+
+This is where you configure various aspects of how you wish to run your Proxy. Open it with your text editor of choice.
+
+### Configuration
+
+`config.ini` contains environment variables that dictate how the services within the Proxy are run. It is organized into the following sections:
+* [`General`](#general)
+* [`Solana`](#solana)
+* [`Proxy`](#proxy)
+* [`Indexer`](#indexer)
+* [`Postgres`](#postgres)
+* [`Vault`](#vault)
+
+#### `General`
+
+* `P_ENV` - specifies the Neon network environment you will connect to: `devnet`, `testnet`, or `mainnet`.
+* `INGRESS_ENABLED` - enables/disables the ingress for the cluster
+* `VAULT_ENABLED` - enables/disables [Hashicorp Vault](https://www.vaultproject.io/) container inside your cluster as a service
+* `NEON_PROXY_ENABLED` - enables/disables Neon Proxy container
+* `POSTGRES_ENABLED` - enables/disables local Postgresql pods (see the [`Postgres` section](#postgres))
+* `NAMESPACE` - specifies the namespace that the Proxy will be deployed inside the cluster. Default is `neon-proxy`
+* `KEY_DIR` - path to the directory containing your neon-labs operator keys, relative to the current directory
+* `KEY_MASK` - regular expression that finds your operator key JSON files
+
+#### `Solana`
+
+* `SOLANA_URL` - specifies the Solana URL RPC endpoint that a Proxy is connecting to
+ * The public Solana endpoints have upper-bound limits for requests per minute (60)
+ * It is best for the operator to use their **own** Solana node running on their infrastructure
+ * For each endpoint's timeout values, see:
+
+ | CONFIG | SOLANA_URL | NEON_CLIT_TIMEOUT | CANCEL_TIMEOUT |
+ | --- | --- | --- | --- |
+ | devnet | https://api.devnet.solana.com/ | 10 | 60 (slot) |
+ | testnet | https://api.testnet.solana.com/ | 15 | 60 (slot) |
+ | local | http://localhost:8899 | 1 | 10 (slot) |
+* `PP_SOLANA_URL` - specifies the Solana URL RPC endpoint which is connected to PYTH. Used to obtain current crypto rates. For standalone Solana, different values (`SOLANA_URL` and `PP_SOLANA_URL`) are necessary. For testnet/devnet/mainnet-beta, you can use the same value for `SOLANA_URL` **and** `PP_SOLANA_URL`. If left empty, `PP_SOLANA_URL`'s value will be the same as `SOLANA_URL`
+
+#### `Proxy`
+
+* `PROXY_VER` - specifies the Proxy/Docker image version
+* `PROXY_COUNT` - specifies the number of pods that you need to host in your cluster namespace
+* `PROXY_COUNT` - specifies the number of keys that each pod will use from Hashicorp Vault
+* `PROXY_HOST` - if you want to use an ingress to serve your own DNS name inside the cluster, set this variable to point to the host
+* `PRX_FAUCET_URL` - specifies the internal name inside your namespace that calls the faucet application (only applicable to local development and devnet)
+* `PRX_PROXY_URL` - specifies the address of local Neon Proxy that resides inside in your namespace service
+* `PRX_LOG_NEON_CLI_DEBUG` - enables/disables debugging information in Neon CLI logs
+* `PRX_PYTH_MAPPING_ACCOUNT` - specifies a [Pyth Network](https://pyth.network/) account
+* `PRX_MINIMAL_GAS_PRICE` - specifies the lowest fee for gas price
+* `PRX_ENABLE_PRIVATE_API` - allows/disallows use of private APIs
+* `PRX_EVM_LOADER` - specifies which EVM loader to use (for local installations only)
+ * For each network endpoint's `EVM_LOADER` values, see:
+
+ | CONFIG | EVM_LOADER |
+ | --- | --- |
+ | devnet | eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU |
+ | testnet | eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU |
+ | local | N/A |
+* `PRX_NEON_CLI_TIMEOUT` - sets the timeout limit for Proxy to Solana cluster connectivity
+* `PRX_CONFIRM_TIMEOUT` - sets the confirm timeout for Proxy to Solana cluster connectivity
+
+#### `Indexer`
+
+* `IDX_GATHER_STATISTICS`
+* `IDX_LOG_FULL_OBJECT_INFO`
+
+#### `Postgres`
+The Proxy database is based on [Postgres](https://www.postgresql.org/). For database, we have two options in terms of connectivity:
+
+##### Option 1: Run Postgres database locally inside Kubernetes as a pod
+To run the Postgresql database inside Kubernetes as a cluster pod ([StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)) with local storage, simply set
+
+```bash
+POSTGRES_ENABLED="true"
+```
+
+##### Option 2: Run your own external Postgres database remotely
+Alternatively, you can use your external database from the Kubernetes cluster to your own PostgreSQL database such as RDS(AWS), CloudSQL(GCP), or other bare metal or Virtual Machine-based installation. This option is **recommended** if running in a production environment. Set the following variables to point to your Postgres database:
+
+```bash
+POSTGRES_ENABLED="false" # In the "General" section
+POSTGRES_HOST="postgres"
+POSTGRES_DB="neon-db"
+POSTGRES_USER="neon-proxy"
+POSTGRES_PORT="5432"
+POSTGRES_STORAGE_CLASS="host"
+POSTGRES_PASSWORD="SOME_PASSWORD"
+```
+
+where
+* `POSTGRES_HOST` - specifies the hostname/IP address of your database, if it is being run outside the cluster
+* `POSTGRES_DB` - specifies the schema name that will generate inside your database
+* `POSTGRES_USER` - specifies your database username
+* `POSTGRES_PORT` - specifies your database's TCP port. Default is `5432`
+* `POSTGRES_STORAGE_CLASS` - specifies the database's storage class.
+ - Set value to`"host"` if you set up your database in your local cluster;
+ - You can check other available options for self-hosted and third-party provided Kubernetes clusters with:
+ ```bash
+ kubectl get storageclasses.storage.k8s.io
+ ```
+* `POSTGRES_PASSWORD` - specifies the database password of your choosing. If left empty, the password will be randomly generated.
+ * If the password is randomly generated, you can use `kubectl` to get from the secret object and see its value by running
+ ```bash
+ kubectl get secret postgres-secret #--template={{.data.POSTGRES_PASSWORD}} -n #neon-proxy | base64 --decode
+ ```
+:::info
+**Disclaimer:** For production environments, we strongly recommend external PostgreSQL databases, such as AWS RDS, GCP CloudSQL, or your database installations.
+:::
+
+#### `Vault`
+
+The vault component, built on [HashiCorp Vault](https://www.vaultproject.io/), stores your private keys using a secure standard.
+
+* `VAULT_TYPE` - specifies what type of vault is used. Options are `"dev"`, `"standalone"`, or `"ha"`
+ * `"dev"`: For local installation/development purposes
+ * `"standalone"`: If you only want one container
+ * `"ha"`: If you want high availability
+* `VAULT_ROOT_TOKEN` - specifies the root token, which is a token that has the `root` policy attached to it, for the vault
+* `VAULT_UNSEAL_KEY` - specifies the unseal key, which is a key for unsealing a vault and encrypting the root key
+
+:::caution
+Upon the **first** installation of Neon Proxy, a `vault-keys.json` file is generated, and it contains the values for `VAULT_ROOT_TOKEN` and `VAULT_UNSEAL_KEY`. Please make sure to **safeguard** them in a **secure** place and manner. These will be re-used in the future.
+
+For subsequent installations/updates, please uncomment these two variables in `config.ini` and set their values accordingly.
+
+Learn more about how to root token and unseal key work together [here](https://developer.hashicorp.com/vault/tutorials/operations/generate-root).
+:::
+* `VAULT_KEYS_FILE` - specifies the path to the `vault-keys.json` file
+* `VAULT_DEV_TOKEN` - for development environments, use this variable to specify a simple token. Defaults to `"root"`
+* `VAULT_KEY_SHARED` - specifies the number of key shares to split the generated master key into. This is the number of "unseal keys" to generate
+* `VAULT_KEY_THRESHOLD` - specifies the number of key shares required to reconstruct the root key. This must be less than or equal to `VAULT_KEY_SHARED`
+* `VAULT_HA_REPLICAS` - specifies the number of replicas of vault pods inside your cluster
+
+### Running `neon-proxy.sh`
+```bash
+./neon-proxy.sh -i -f config.ini
+```
+
+
+
+Once Kubernetes pulls the necessary images, your Neon proxy will start, displaying a myriad of information, such as the network environment, namespace, keys information, Solana URL, and more.
+
+## Walkthroughs
+
+### Fresh installation in read-only mode without keys
+
+In this option, no operator key is passed to the command, and the proxy runs in read-only mode (`-r`)
+
+[](https://asciinema.org/a/aQygYbL2dnszJNm5Pw1f8rGZ7)
+
+### Fresh installation with operator keys
+
+Running an operator for the first time and all provisioned migrations (`-i`), with operator keys inside `operator-keypairs-full` path (`-k`) and using a local configuration file (`-f`) named `config.ini.local`
+
+[](https://asciinema.org/a/Wr91t5WbJBaWs7AH5m7VXbMBG)
diff --git a/docs/operating/operator-introduction.md b/docs/operating/operator-introduction.md
new file mode 100644
index 00000000..911cbeb5
--- /dev/null
+++ b/docs/operating/operator-introduction.md
@@ -0,0 +1,95 @@
+---
+title: Operate a Neon Proxy
+proofedDate: 20230622
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+*This guide is for people who want to register with Neon EVM as a Proxy Operator to process transactions on Solana. We assume you have prior experience compiling Solana-based blockchain nodes, or have worked as a blockchain validator.*
+
+## Introduction
+Ethereum dApps may run their smart contract-based applications on Solana via Neon EVM. Modified smart contracts generate transactions in accordance with the Ethereum rules. These are submitted to the Neon EVM and broadcast as Neon transactions. Since the structures of Ethereum and Solana transactions differ from each other, Neon EVM contains special Proxy servers that are responsible for packing and executing transactions in Solana. These servers are configured and maintained by Neon EVM Proxy Operators.
+
+This page introduces the Proxy Operator’s duties, and the following pages provide instructions to ensure the successful execution of transactions.
+
+## Duties of a Proxy Operator
+A Proxy Operator's main task is to install software on a server in order to provide an RPC endpoint to accept transactions formed according to Ethereum rules, and ensure their execution in Solana.
+
+This involves:
+ * Configuring at least [2 instances of the proxy server](#redundancy) to perform the following operations:
+ * Receive requests over Web3 API protocol
+ * Shape responses using Web3 API protocol
+ * Connect a Proxy server to a Solana cluster RPC endpoint
+ * Successfully executing transactions
+
+:::note
+All operations related to the execution of transactions on Solana are performed by the software installed on your node.
+:::
+
+### Hardware requirements
+
+Please make sure you have hardware that meets the corresponding minimum requirements before proceeding.
+
+
+
+
+For testing, the minimum recommended hardware is:
+
+|Component|Requirement |
+|-----|:-----------------------------------------|
+|Operating System | Linux (Ubuntu/CentOS recommended) |
+|CPU | 4 vCPU |
+|RAM | 8 GB |
+|Storage | 500 GB |
+
+
+
+To provide a public Proxy service, the minimum recommended hardware is:
+
+|Component|Requirement |
+|-----|:-----------------------------------------|
+|Servers/VMs | At least two (2) with Intel Processor x86_64 |
+|CPU | 16 vCPU (for each server/VM) |
+|RAM | 32 GB (for each server/VM) |
+|Storage | 1 TB |
+
+
+
+### Redundancy
+
+To provide fault tolerant (24x7) Neon Proxy availability, the Neon team recommends that Neon Operators run two instances of the Neon Proxy, each with the same number of [Neon Operator keys](accounts#the-operator-key). This maintains the service even if one of the servers should fail. Each Neon Proxy can process 350 TPS.
+
+> For example, if the Neon Operator has 40 keys, our recommendation is to run each instance of the Neon Proxy with 20 keys.
+
+As a Kubernetes service, Neon Proxy instances will rebalance user requests and user transactions.
+
+
+
+## Testing
+
+Running a local node of Solana, Proxy, and the Neon EVM supports users who are interested in testing, developing, and learning how to interact with Neon EVM. Whether you wish to deploy smart contracts, conduct transactions, or interact with the deployed NeonEVM smart contract, running a local Proxy solution will assist.
+
+To use Neon EVM's Mainnet entry point to Proxy, you must be on the allowlist, *whereas* running your own local installation does not require approval.
+
+While Solana does not recommend running a Solana instance from a container, it does work and is useful for testing. Running Solana in a container also allows users to quickly reset the Solana state and retrieve the hardware space claimed by the node.
+
+There are several options available to developers who wish to test transactions on Neon EVM.
+
+## 1. Local Neon Proxy to local Solana
+
+[This page](basic.md) provides a walk-through for option 1.
+
+## 2. Local Neon Proxy to remote Solana
+
+It is also possible to run Neon Proxy locally and configure it to use a public (or self-hosted) RPC endpoint to access Solana.
+
+## 3. Remote Neon Proxy to remote Solana
+
+Most dApps will use this service model to process their transactions via Neon EVM.
+
+
diff --git a/docs/operating/operator_guide.md b/docs/operating/operator_guide.md
deleted file mode 100644
index fd5b1efd..00000000
--- a/docs/operating/operator_guide.md
+++ /dev/null
@@ -1,359 +0,0 @@
----
-title: Running a Proxy server
----
-
-*This guide is for people who want to register with Neon EVM as a proxy operator for processing transactions on Solana. It is assumed these people have previous experience compiling Solana-based blockchain nodes or have worked as blockchain validators.*
-
-## Introduction
-Ethereum users have the opportunity to run their smart contract-based applications on Solana via Neon EVM. Smart contracts generate transactions in accordance with the Ethereum rules and submit them to Neon EVM. Since the structures of Ethereum and Solana transactions differ from each other, Neon EVM contains special proxy servers that are responsible for converting and executing transactions in Solana. These servers are configured and maintained by Neon EVM proxy operators.
-
-This guide contains a list of the proxy operator’s duties, as well as instructions to ensure the successful operation of a proxy and the successful execution of transactions.
-
-## Duties of a Proxy Operator
-A proxy operator’s main task is to install software on a server to accept a transaction formed according to Ethereum rules, and to ensure its execution in Solana. This involves:
- * Configuring a proxy server to perform the following operations:
- * Receiving requests over Web3 API protocol.
- * Shaping responses using Web3 API protocol.
- * Converting transactions to the Solana format.
- * Connecting a proxy server to a Solana cluster RPC endpoint.
- * Successfully executing transactions.
-
-> All operations related to the execution of transactions on Solana are performed by the software installed on your node.
-
-## Installation Using Docker
-
-After you have chosen the node (Neon EVM proxy) that meets the listed recommendations, you can start installing a proxy operator software on it.
-
-### Run a Daemon
-
-Make sure that you have a daemon running. If you see something like:
-
-```bash
-$ docker info
-
-Cannot connect to the Docker daemon at . Is the docker daemon running?
-```
-
-you need to run the daemon and PostgreSQL services first:
-
-```bash
-$ sudo systemctl start docker
-$ sudo docker run --rm -ti --network=host -e POSTGRES_HOST= -e POSTGRES_DB= -e POSTGRES_USER= -e POSTGRES_PASSWORD= --name=postgres postgres:14.0
-```
-
-**The command line options:**
- * `--rm` — Delete a container when the command is completed.
- * `-ti` — Allocate a pseudo-TTY connected to the container’s stdin; creating an interactive bash shell in the container.
- * `--network host` — Use the host network.
- * `-e POSTGRES_HOST=` — Specifies DB hosting; `localhost` is set by default and is recommended; the parameter can be skipped if you use PostgreSQL hosted locally.
- * `-e POSTGRES_DB=` — Specifies the name of DB; `neon-db` is recommended.
- * `-e POSTGRES_USER=` — Specifies a username of DB; `neon-proxy` is recommended.
- * `-e POSTGRES_PASSWORD=` — Specifies a username's password; `neon-proxy-pass` is recommended.
- * `--name=postgres` — Specifies a version of PostgreSQL; `postgres:14.0` is recommended.
-
-*Example:*
-```bash
-$ sudo docker run --rm -ti --network=host -e POSTGRES_DB=neon-db -e POSTGRES_USER=neon-proxy -e POSTGRES_PASSWORD=neon-proxy-pass --name=postgres postgres:14.0
-```
-
-### Start a Proxy in a Docker Container
-
-Create and run a proxy container on the daemon.
-When starting Docker, you need to set the *CONFIG* environment variable, which can take one of the following values: *local*, *devnet*, *testnet*.
-
-```bash
-$ sudo docker run --rm -ti --network=host -e CONFIG= -e POSTGRES_DB= -e POSTGRES_USER= -e POSTGRES_PASSWORD= -v :/root/.config/solana/id.json neonlabsorg/proxy:v0.5.1
-```
-
-**The command line options:**
- * `-e CONFIG=` — Specifies a Solana network configuration; `CONFIG=devnet` is recommended.
- * `-v :/root/.config/solana/id.json` — Specifies the path to the .JSON file where your keypair is stored and passes your private key to the container.
- * `neonlabsorg/proxy:v0.5.1` — The specific proxy image.
-
-> The option `-v ` is only relevant for authorized operators. If you are not yet registered as an operator and are just about to become one, you do not need to specify this option.
-
-This command line will automatically perform all the actions required to launch a Docker container and run a proxy.
-
-*Example:*
-```bash
-$ sudo docker run --rm -ti --network=host -e CONFIG=devnet -e POSTGRES_DB=neon-db -e POSTGRES_USER=neon-proxy -e POSTGRES_PASSWORD=neon-proxy-pass neonlabsorg/proxy:v0.5.1
-```
-
-### CONFIG values
-Each `CONFIG` value (devnet/testnet/local), by default, the corresponding variables are set:
- * `SOLANA_URL`
- * `NEON_CLI_TIMEOUT`
- * `CANCEL_TIMEOUT`
- * `POSTGRES_HOST`
- * `MINIMAL_GAS_PRICE`
- * `EVM_LOADER`
- * `NEON_TOKEN_MINT`
-
-When you start Docker, you can override all these parameters by specifying different values for them on the command line. The table below shows default values for the following variables:
-
-CONFIG | SOLANA_URL | NEON_CLI_TIMEOUT | CANCEL_TIMEOUT | POSTGRES_HOST | MINIMAL_GAS_PRICE
-:-|:-|:-|:-|:-|:-
-devnet | `https://api.devnet.solana.com` | 10 (s) | 60 (slot) | localhost | 1
-testnet | `https://api.testnet.solana.com` | 15 (s) | 60 (slot) | localhost | 1
-local | `http://localhost:8899` | 0,9 (s) | 10 (slot) | localhost | 0
-
-#### SOLANA_URL
-Specifies a Solana RPC endpoint that a proxy is connecting to. If you specify `CONFIG=local` and `SOLANA_URL=`, then the requests of a proxy will be sent to your node.
-
-#### NEON_CLI_TIMEOUT
-In Neon EVM, a transaction is run for emulation before execution to determine the accounts that will be involved in it. The `NEON_CLI_TIMEOUT` variable specifies the time (in seconds) required for a transaction to be executed.
-
-The emulation execution time is affected by the following factors:
- * The geographical distance between a node and proxy.
- * The load of the node due to processing requests at the moment.
-
-Setting the `NEON_CLI_TIMEOUT` time too short may not be sufficient to complete a transaction and pack it into a block. Therefore, `NEON_CLI_TIMEOUT` is set to the smallest value for `CONFIG = local`. Setting the `NEON_CLI_TIMEOUT` value too high may block other users from accessing this node.
-
-#### CANCEL_TIMEOUT
-This parameter limits the time (in [slots](about/terminology.md#slot)) for blocking an account. If the blocking time for the account exceeds the time specified in this parameter, an attempt will be made to cancel the transaction that blocked this account.
-
-#### MINIMAL_GAS_PRICE
-This parameter sets the lowest possible gas price specified in a transaction.
-
-#### EVM_LOADER
-`CONFIG` defaults the following values for the variable `EVM_LOADER`:
-
-CONFIG | EVM_LOADER
-:-|:-
-devnet | eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU
-testnet | eeLSJgWzzxrqKv1UxtRVVH8FX3qCQWUs9QuAjJpETGU
-local | —
-
-#### NEON_TOKEN_MINT
-`CONFIG` defaults the following values for the variable `NEON_TOKEN_MINT`:
-
-CONFIG | NEON_TOKEN_MINT
-:-|:-
-devnet | 89dre8rZjLNft7HoupGiyxu3MNftR577ZYu8bHe2kK7g
-testnet | 89dre8rZjLNft7HoupGiyxu3MNftR577ZYu8bHe2kK7g
-local | HPsV9Deocecw3GeZv1FkAPNCBRfuVyfw9MMwjwRe1xaU
-
-## Prometheus metrics in Proxy
-
-### Proxy Prometheus Metrics
-
-| Metrics title | units | description |
-|----------------------------|----------|----------------------------------|
-| request_count | count | App Request Count |
-| request_latency_seconds | ms | Request latency |
-| tx_total | tx count | Incoming TX Count |
-| tx_success_count | tx count | Count Of Succeeded Txs |
-| tx_failed_count | tx count | Count Of Failed Txs |
-| tx_in_progress | tx count | Count Of Txs Currently Processed |
-| operator_sol_balance | Sols | Operator Balance in Sol's |
-| operator_neon_balance | Neons | Operator Balance in Neon's |
-| usd_price_sol | USD | Sol Price USD |
-| usd_price_neon | USD | Neon Price USD |
-| gas_price | alans | Gas Price |
-| operator_fee | Percent | Operator Fee |
-
-### Indexer Prometheus Metrics
-
-| Metrics title | units | description |
-|--------------------------|---------------|-------------------------------------------------------------------|
-| tx_sol_spent | lamports | How many lamports being spend in Neon transaction per iteration |
-| tx_neon_income | alans | Neons payed for transaction |
-| tx_bpf_per_iteration | bpf units | How many BPF cycles was used in each iteration |
-| tx_steps_per_iteration | steps | How many steps was used in each iteration |
-| tx_count | tx count | Count of Neon transactions were completed (independent on status) |
-| tx_canceled | tx count | Count of Neon transactions were canceled |
-| count_tx_count_by_type | tx count | Count of transactions by type(single\\iter\\iter w holder) |
-| count_sol_tx_per_neon_tx | tx count | Count of solana txs within by type(single\\iter\\iter w holder) |
-| postgres_availability | 1 or 0 status | Postgres availability |
-| solana_rpc_health | 1 or 0 status | Solana Node status |
-
-### Prometheus formulas examples
-
-#### Profit and Loss monitoring
-
-```promql
-sum (avg by (operator_sol_wallet) (operator_sol_balance) ) * avg by (app) (usd_price_sol) + sum (avg by (operator_neon_wallet) (operator_neon_balance) ) * avg by (app) (usd_price_neon))
-```
-
-#### Solana Node status
-
-```promql
-solana_rpc_health{job="indexer-monitor"}
-```
-
-#### PostgreSQL DB status
-
-```promql
-postgres_availability{job="indexer-monitor"}
-```
-
-### Prometheus configuration example
-
-```yml
-global:
- scrape_interval: 15s
- evaluation_interval: 15s
-
-scrape_configs:
- - job_name: 'proxy-monitor'
- metrics_path: '/'
- scrape_interval: 5s
- static_configs:
- - targets: ['proxy:8888']
-
- - job_name: 'indexer-monitor'
- metrics_path: '/'
- scrape_interval: 5s
- static_configs:
- - targets: ['indexer:8887']
-```
-
-## proxy-cli
-
-### Example of execution
-
-```shell
-docker exec proxy ./proxy-cli.sh info
-```
-
-### Commands
-
-| Command | Description |
-|-------------------------|---------------------------------------------------------------------------------------------------------------------------------------|
-| info | Print full accounts (Solana accounts and Neon accounts, their balance and private key \| Resource accounts and their balance) in JSON |
-
-#### Output example
-
-```shell
-docker exec proxy ./proxy-cli.sh info | python3 -m json.tool
-```
-
-```json
-{
- "accounts":[
- {
- "address":"BMp6gEnveANdvSvspESJUrNczuHz1GF5UQKjVLCkAZih",
- "balance":"8972.78394124",
- "storage":[
- {
- "address":"62MMKXigkapYUDBo1swJRZvyQjH37WPh8SRvpBD5WS4F",
- "status":"FINALIZED_STORAGE",
- "balance":"0.913152"
- }
- ],
- "holder":[
- {
- "address":"EYb7qSkqS4wSg4wxxawCYThDRMdRhe72W4KdMjAdNbbA",
- "status":"EMPTY",
- "balance":"0.913152"
- }
- ],
- "private":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,81,105,105,99,114,88,7,110,109,112,70,52,110,56,8,85,81,122,52,74,118,77,100,77,57,106,101,84,53,86,1,102,117,117,70,51,87,102,9,98,90,111,71,56,119,55,84,82,53,53,84,56,76,85,107,54,52,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16],
- "neon_address":"0xd1b27c35c47bd37398ad6ab642b1bf63aec0ca43",
- "neon_private":"0xa1b2c3d4e5f68dec7c7bc8c0ff17a12274ca46b6b05ec344b9203d2acb39f5be",
- "neon_balance":"0.07031774"
- }
- ],
- "total_balance":"78921.04414876",
- "resource_balance":"54.789120",
- "total_neon_balance":"0.71927982004647600"
-}
-```
-
-| Command | Description |
-|-------------------------|-----------------------------------------------------|
-| info holder-accounts | Print list of Holder accounts owned by operator |
-
-```shell
-docker exec proxy ./proxy-cli.sh info holder-accounts
-```
-
-```shell
-EYb7qSkqS4wSg4wxxawCYThDRMdRhe72W4KdMjAdNbbA
-DEG7mDtzEVq4zUGxxajNCnRPLnumSDPQHGMMC4zyPz9h
-DueRTJ7WvwA2csPoVeheiDnZPXfpVstSuSsffgF8baTE
-2rJszXcUPuqJkpoW2ZgMRR7sLytSMDsGkecGAiBWqimD
-```
-
-| Command | Description |
-|-------------------------|----------------------------------------------------------|
-| info storage-accounts | Print list of Storage accounts owned by operator |
-
-```shell
-docker exec proxy ./proxy-cli.sh info storage-accounts
-```
-
-```shell
-7Jt1HpgrtaKadZgCvEPfAn2p55AJi6bovrH9byVVNNKh
-BkBzYwk7dL8yYAaYxyeS9LrDBuW5vMinPf1WUWQTLMpK
-9bw592nyQzmAR94JW9SgkN6baMoY1Y236RYgukFqHrov
-2rJszXcUPuqJkpoW2ZgMRR7sLytSMDsGkecGAiBWqimD
-```
-
-| Command | Description |
-|-------------------------|-----------------------------------------------------|
-| info solana-private-key | Print list of Solana accounts and its private key |
-
-```shell
-docker exec proxy ./proxy-cli.sh info solana-private-key
-```
-
-```shell
-BMp6gEnveANdvSvspESJUrNczuHz1GF5UQKjVLCkAZih [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 99, 114, 88, 57, 110, 109, 112, 70, 52, 110, 56, 98, 85, 81, 122, 52, 74, 118, 77, 100, 77, 57, 106, 101, 84, 53, 86, 81, 102, 117, 117, 70, 51, 87, 102, 89, 98, 90, 111, 71, 56, 119, 55, 84, 82, 53, 53, 84, 56, 76, 85, 107, 54, 52, 50, 121, 110, 116, 68, 90, 121, 53, 121, 65, 54, 76, 86, 112, 109]
-```
-
-| Command | Description |
-|-------------------------|-------------------------------------------------|
-| info neon-private-key | Print list of Neon accounts and its private key |
-
-```shell
-docker exec proxy ./proxy-cli.sh info neon-private-key
-```
-
-```shell
-0xd1b27c35c47bd37398ad6ab642b1bf63aec0ca43 0xa1b2c3d4e5f68dec7c7bc8c0ff17a12274ca46b6b05ec344b9203d2acb39f5be
-```
-
-| Command | Description |
-|-------------------------|----------------------------------------------------------------------|
-| info neon-address | Print list of Neon accounts and their balances plus total balance |
-
-```shell
-docker exec proxy ./proxy-cli.sh info neon-address
-```
-
-```shell
-0xb1239ffe4a30d4ad678f42cd5e56ce13c0daf3e9 5.293965780000000000
-0x910bc86b92aa1bda080648ae19216e7ebe8dc340 3.511933000000000000
-0x181fe64831130575ec6ea6a1de0183464dc13f8f 5.461316080000000000
-0xc6e5512efdb0c693c9a78755754f577e2fbb742d 5.969624380000078940
-total_balance 49.943540400046476000
-```
-
-| Command | Description |
-|-------------------------|--------------------------------------------------------------------------------------------|
-| info solana-accounts | Print list of Solana accounts balances and Resource accounts balances plus total balance |
-
-```shell
-docker exec proxy ./proxy-cli.sh info solana-accounts
-```
-
-```shell
-BMp6gEnveANdvSvspESJUrNczuHz1GF5UQKjVLCkAZih 8,972.619517760
-holder:
- EYb7qSkqS4wSg4wxxawCYThDRMdRhe72W4KdMjAdNbbA 0.913152000
- DEG7mDtzEVq4zUGxxajNCnRPLnumSDPQHGMMC4zyPz9h 0.913152000
-storage:
- 62MMKXigkapYUDBo1swJRZvyQjH37WPh8SRvpBD5WS4F 0.913152000
- BdX7H8cFVJwmmsRjZTYHSfaVVoRGijUkYT3T7FgrdejE 0.913152000
-9kPRbbwKL5SYELF4cZqWWFmP88QkKys51DoaUBx8eK73 4,995.719095600
-holder:
- BKLT27mXenjyeoKc7Fn8xkrezrNubuRdzbq19mmxW9vS 0.913152000
- Wup8BGZ1HiKPo7iw8owzCpgX5fnw2jVsk9gNLpi3Jtq 0.913152000
-storage:
- 5ky8gugmaB9YhVdgrfkwXxeqnQ2V8zEQ9jtxJKC4Ewg1 0.913152000
- HhMTo9nvqoiUMiXuDBUfSsbaxUdEicUxVzB7Sb5qZF5C 0.913152000
-...
-total_balance 78,913.573017880
-resource_balance 54.789120000
-```
diff --git a/docs/operating/operator_requirements.md b/docs/operating/operator_requirements.md
deleted file mode 100644
index 3df184bb..00000000
--- a/docs/operating/operator_requirements.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Operator Requirements
----
-
-### Balance Recommendations
-
-First, you must be registered in Solana, which involves creating an account with a balance for storing SOL tokens, and getting the public and private keys.
-There is no strict minimum amount of SOL required to run as an operator on the Neon EVM. However, you should take into account that you will need tokens to create accounts for new users, deploy contracts, and execute transactions.
-
-In addition to the balance for storing SOL tokens, an operator must also have the `NEON_TOKEN_MINT` balance for storing value tokens. These tokens are used to pay funds from users to an operator for the successful execution of transactions. Depending on the chosen configuration, specific values for `NEON_TOKEN_MINT` are indicated in the [table](operating/operator_guide.md#neon_token_mint).
-
-To create the `NEON_TOKEN_MINT` balance, you can use the following command:
-```
-spl-token -u create-account
-```
-
-### Hardware Recommendations
-We do not have strict hardware recommendations. The device specifications below are based on information obtained from official Solana [documentation](https://docs.solana.com/running-validator/validator-reqs).
-
-#### The specifications recommended for your Neon EVM proxy are:
-
-
-
-> Do not use a public or shared Solana RPC node for your Neon EVM proxy. Use only a device that you control.
-
-In addition to the Neon EVM proxy, you need a Solana RPC node. It should be a dedicated RPC node with low latency to interact with your Neon EVM proxy.
-
-The minimum specifications recommended to your Solana RPC node are:
- * CPU
- * 16 cores
- * EPYC Gen 2 or Gen 3
- * Core isolation
- * RAM
- * 256 GB memory
- * [Tmpfs](about/terminology.md#tmpfs)
- * Disk space
- * Depends on the transaction history required for storage
-
-### Software Recommendations
-The following software should be installed on your Neon EVM proxy:
- * OS
- * Ubuntu 20.04 or later
- * macOS Darwin 10.12 or later
- * Docker
- * Docker Compose
-
-### Solana Cluster Requirements (optional)
-If you want to use a local Solana cluster, you need to meet the following requirements:
- * Solana cluster with `--enable-rpc-transaction-history` enabled.
- * Solana cluster with `--enable-rpc-bigtable-ledger-storage` enabled.
-
-### Networking
-Internet service should be at least 300 Mbps.
diff --git a/docs/operating/transaction-gas.mdx b/docs/operating/transaction-gas.mdx
new file mode 100644
index 00000000..676a61b7
--- /dev/null
+++ b/docs/operating/transaction-gas.mdx
@@ -0,0 +1,97 @@
+---
+title: Fees & Gas
+proofedDate: 20231204
+iterationBy: na
+includedInSite: true
+approvedBy: na
+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:
+
+- [Configure the Operator fee](#gas-price-the-operator-fee)
+- [Configure oracle price sources](#calculation-configuration)
+- [May reject transactions based on gas price](#minimum-gas-price)
+- [Can set gas to zero for testing](#zero-gas-price-for-testing)
+- Must configure the Proxy to accept no-fee transactions
+
+
+
+## The Neon Operator economy
+
+Neon Proxy enables Neon Operators to earn NEON tokens by processing transactions from Neon users.
+
+The Neon Operator economy is based on providing a custom gas price returned by the eth_gasPrice method. The Neon Proxy calculates the gas price based on the assumption that it should cover the cost of transaction processing on the Solana cluster and include the profit of the Neon Operator. The Neon Operator should include all additional costs (such as hardware rent) plus profit in their Operator Fee.
+
+The Neon EVM calculates gas usage by tracking the SOL spent by the Neon Operator during transaction execution. The gas price includes the ratio of NEON and SOL tokens, so the payment from the Neon User to Neon Operator covers all spent SOLs. The ultimate gas price is variable because it depends on the prices of SOL and NEON.
+
+### Pass on gas savings
+
+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.
+
+
+
+> 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. The value of this parameter is currently set to **1**.
+
+
+
+For example:
+
+
+
+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.
+
+> A `PRX_OPERATOR_FEE` = “0.1” → 10% of the total possible Neon Operator fee.
+
+## Minimum gas price
+
+An Operator has two options:
+
+- **Recommended**: set up the `PRX_MINIMAL_GAS_PRICE` to 1 as per the default value in EVMs
+- Set up the `PRX_MINIMAL_GAS_PRICE` to reject low offers
+
+> For example, by setting the gas price minimum to 65 Galan, Neon Proxy rejects transactions with a gas price of less than 65.
+
+## Gas price: oracle configuration
+
+If a transaction request arrives with a gas price below that of the Operator costs + Operator fee, but with a gas price larger than the designated `PRX_MINIMAL_GAS_PRICE`, the Neon Proxy accepts the transaction into mempool.
+
+The Neon transaction will only be executed when the gas price covers Operator costs + Operator fee. If the number of transactions in the mempool grows to the `PRX_MEMPOOL_CAPACITY` (by default =4096), Neon Proxy removes the transaction with the smallest gas price from the mempool to accept transactions with the higher gas price. Therefore, it's not critical to set the `PRX_MINIMAL_GAS_PRICE` to a small value.
+
+## Calculation configuration
+
+The Neon Proxy has several settings that accommodate the calculation of gas-price on your required network:
+
+- `PRX_PP_SOLANA_URL`: the HTTP/S address of the Solana node (Devnet/Mainnet) that provides the Pyth data account that supplies $NEON and $SOL prices
+- `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
+
+
diff --git a/docs/quick_start.md b/docs/quick_start.mdx
similarity index 64%
rename from docs/quick_start.md
rename to docs/quick_start.mdx
index d9042dc9..8b8dd348 100644
--- a/docs/quick_start.md
+++ b/docs/quick_start.mdx
@@ -1,28 +1,31 @@
---
title: Quick Start
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
import {QuickStartList} from '@site/src/components/QuickStartList'
import {CommonBannerBlock} from '@site/src/components/CommonBannerBlock'
import {ServiceLink} from '@site/src/components/ServiceLink'
-import {PageHelpful} from '@site/src/components/PageHelpful'
-import {FeedbackForm} from '@site/src/components/FeedbackForm'
+
*Neon EVM is a synergetic solution for anyone looking to scale Ethereum dApps on Solana in a developer-friendly manner and tap into Solana's vibrant ecosystem.*
+
### Learn about Neon
-
+
### Join Neon Governance
-
+
+
### Become an Operator
-
+
### Help & Support
diff --git a/docs/single-source-snippets/_gas_price_calc.mdx b/docs/single-source-snippets/_gas_price_calc.mdx
new file mode 100644
index 00000000..b4f80409
--- /dev/null
+++ b/docs/single-source-snippets/_gas_price_calc.mdx
@@ -0,0 +1,10 @@
+| Component | Value | Units/Definition | Calculation |
+| ------------------------ | ---------------- | ----------------------- | ----------------- |
+| Sol | 125 | $ | |
+| Neon | 1.5 | $ | |
+| Ratio | | SOL:NEON | 83.3333 |
+| Galan ratio | | Ratio \*10-9 | 0.0000000833333 |
+| Operator fee ratio | 1 | | |
+| Adjustor | | 1+fee | 2 |
+| **Gas price** | **0.0000001666666** | NEON | Gas price formula |
+| |**166.6** | Galan | |
diff --git a/docs/single-source-snippets/_hardhat.mdx b/docs/single-source-snippets/_hardhat.mdx
new file mode 100644
index 00000000..048cea7e
--- /dev/null
+++ b/docs/single-source-snippets/_hardhat.mdx
@@ -0,0 +1 @@
+Hardhat is a development environment used to compile, deploy, test, and debug Ethereum software. It helps developers manage and automate the recurring tasks inherent to the process of building smart contracts and launching dApps, as well as supporting various add-on features that streamline this workflow.
\ No newline at end of file
diff --git a/docs/single-source-snippets/_hardhat_config.mdx b/docs/single-source-snippets/_hardhat_config.mdx
new file mode 100644
index 00000000..2b439d79
--- /dev/null
+++ b/docs/single-source-snippets/_hardhat_config.mdx
@@ -0,0 +1 @@
+To deploy a contract to Neon EVM with Hardhat, some Neon-specific information must be configured. The configuration file is called `hardhat.config.js` and is located at the root of your project directory. This JavaScript file can execute any code necessary to create your configuration. Its file schema, variables, and other documentation can be found on the [official Hardhat website](https://hardhat.org/hardhat-runner/docs/config).
\ No newline at end of file
diff --git a/docs/single-source-snippets/_price_formula.mdx b/docs/single-source-snippets/_price_formula.mdx
new file mode 100644
index 00000000..c4814c20
--- /dev/null
+++ b/docs/single-source-snippets/_price_formula.mdx
@@ -0,0 +1,9 @@
+> Gas price = $SOL / $NEON(* 10-9 NEON) * (1 + `PRX_OPERATOR_FEE`)
+
+which can also be represented as:
+
+> Gas price = SOL-to-NEON-rate in Galan * (1 + `PRX_OPERATOR_FEE`)
+
+
+
+
diff --git a/docs/single-source-snippets/_synergetic.mdx b/docs/single-source-snippets/_synergetic.mdx
new file mode 100644
index 00000000..b77a1953
--- /dev/null
+++ b/docs/single-source-snippets/_synergetic.mdx
@@ -0,0 +1,3 @@
+Neon EVM is a synergetic solution for anyone looking to scale Ethereum dApps on Solana in a developer-friendly manner and tap into Solana's vibrant ecosystem
+
+
diff --git a/docs/to_be_redistributed/how_to_guides/connect_metamask_to_solana.md b/docs/to_be_redistributed/how_to_guides/connect_metamask_to_solana.md
deleted file mode 100644
index fc3d2045..00000000
--- a/docs/to_be_redistributed/how_to_guides/connect_metamask_to_solana.md
+++ /dev/null
@@ -1,71 +0,0 @@
-# How to Connect Metamask to Solana's Network
-
-## Goal
-To connect Metamask to Solana's network via the Neon EVM.
-
-## Before You Begin
- * Understand the following:
- * What is the [Solana network](https://docs.solana.com/clusters)?
- * What is [MetaMask](https://metamask.io)?
- * MetaMask must be installed on your device and can be accessed from the browser you are using.
-
-## Steps
-
-### Step 1
-Open the https://chainlist.org/ web page. In the `Search Networks` field, type the NEON token symbol.
-The search will select three Neon EVM networks with their corresponding ChainIDs in which this token can be circulated.
-
-
-
-
-
-
-
-### Step 2
-In the upper right corner, click `Connect Wallet`. This field should display the address of your MetaMask wallet, which is accessible from your browser.
-
-
-
-
-
-
-
-### Step 3
-Select the Neon EVM network to which you are going to connect your wallet to perform operations and click `Add To MetaMask`. (For debugging or testing contracts, it is recommended to use the Neon EVM Devnet). The MetaMask window should appear with the selected network ID and proxy address.
-
-Check that the data in the MetaMask fields that correspond to the network you need. Click `Approve` to complete the MetaMask connection to the Neon EVM network.
-
-
-
-
-
-
-
-The MetaMask window will display a list of your accounts. (In our case, this will be "Account 1".)
-
-
-
-
-
-
-
-
-You can start performing all operations inherent in your wallet, including creating new accounts. For debugging work in the Neon EVM Devnet/Testnet networks, five tokens will be credited to each account balance. These tokens can only be used within Devnet/Testnet. If you connect to the Neon EVM Mainnet, NEON tokens will not be credited.
-
-### Step 4
-If you want to switch MetaMask to another network, you need to click `Add To MetaMask` on the new network and click `Switch network` in the MetaMask window.
-
-
-
-
-
-
-
-### Step 5
-You can close the browser window and reopen it at any time. Don't worry, your MetaMask will keep access to the connected network. To return to the Neon EVM network session, simply open the browser to which your wallet is attached and click on the MetaMask icon in the upper right corner.
-
-
-
-
-
-
diff --git a/docs/to_be_redistributed/how_to_guides/create_account.md b/docs/to_be_redistributed/how_to_guides/create_account.md
deleted file mode 100644
index 50060232..00000000
--- a/docs/to_be_redistributed/how_to_guides/create_account.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# How To Create An Ethtereum Account
-
-### Goal
-the text will be added soon
-
-### Before You Begin
- * Install the currently supported version of `neon-cli`.
- * Understand the following:
- * What is an account
- * What is a public and private key pair
- * Imported a key pair that can authorize on behalf of a creator account.
-
-### Steps
-See
-https://ethereum.org/en/developers/docs/accounts/
-
-
-----
-
-> **Usefull liks**
->
diff --git a/docs/to_be_redistributed/how_to_guides/deploy_contract.md b/docs/to_be_redistributed/how_to_guides/deploy_contract.md
deleted file mode 100644
index 7865e04b..00000000
--- a/docs/to_be_redistributed/how_to_guides/deploy_contract.md
+++ /dev/null
@@ -1,116 +0,0 @@
-# How to Deploy an Ethereum Contract
-
-## Goal
-To deploy a smart contract for it to be available to users of an Ethereum network.
-To deploy a smart contract, you have to:
-* Compile your smart contract.
-* Create and send an Ethereum transaction containing the code of the compiled smart contract without specifying any recipients.
-
-## Before You Begin
-* Understand the following:
- * What is the [Ethereum network](https://ethereum.org/en/developers/docs/networks/)?
- * What is a [transaction](https://ethereum.org/en/developers/docs/transactions/)?
- * What is a [smart contract](https://ethereum.org/en/developers/docs/smart-contracts/anatomy/)?
- * What are [gas and fees](https://ethereum.org/en/developers/docs/gas/)?
- * How to compile a [smart contract](https://ethereum.org/en/developers/docs/smart-contracts/compiling/).
-* Make sure you have some ETH to pay transaction fees.
-
-## Steps
-
-**Step 1**
-For the EVM to be able to run your contract, it needs to be in bytecode.
-Let's use a simple smart contract:
-```js
-pragma solidity ^0.5.12;
-
-contract helloWorld {
- string public text = "Hello World!";
-
- function callHelloWorld() public view returns (string memory) {
- return text;
- }
-}
-```
-[Compile](https://ethereum.org/en/developers/docs/smart-contracts/compiling/) your smart contract to get the contract's bytecode.
-
-
-**Step 2**
-Set your gas limit (in coins) like other transaction.
-Be aware that contract deployment needs a lot more gas than a simple coin transfer.
-
-**Step 3**
-Deploy the script or plugin.
-
-**Step 4**
-Access an [Ethereum node](https://ethereum.org/en/developers/docs/nodes-and-clients/), either by running your own, connecting to a public node, or via an API key using a service like Infura or Alchemy.
-
-Once deployed, your contract will have an Ethereum address like other [accounts](https://ethereum.org/en/developers/docs/accounts/).
-
-----
-
-## Example: Deploying a Smart Contract in Test Mode Using Remix
-
-### Goal
-To deploy your smart contract on an Ethereum test network.
-
-> Deploying a smart contract on the blockchain is just sending a transaction containing the code of the compiled smart contract without specifying any recipients.
-
-### Steps
-**Step 1**
-Visit [Remix](https://remix.ethereum.org/) and create a new file.
-
-
-
-
-
-
-
-**Step 2**
-On the upper left part of the Remix interface, add the new file and enter the file name you want. In the new file, paste your smart contract code.
-
-
-
-
-
-
-
-**Step 3**
-Navigate to the compile icon on the left-hand side and click `Compile`.
-
-
-
-
-
-
-
-
-You can select the "Auto compile" option so the contract will always be compiled when you save the content on the text editor.
-
-**Step 4**
-Navigate to the deploy icon and go to the transactions screen:
-
-
-
-
-
-
-
-Once you are on the `deploy and run transactions` screen, check that your contract name appears and click `Deploy`.
-The `Javascript VM` of the current environment will appear at the top of the page. It means that you will deploy and interact with the smart contract on a local test blockchain to be able to test without any fees.
-
-**Step 5**
-Click `Deploy`. Your contract will appear at the bottom.
-Click the arrow on the left to expand it so you can see the content of your contract.
-
-
-
-
-
-
-
-If your contract contains several modules, you can see the details of each of them by clicking on the corresponding name. You can also see logs of the transactions that are made at the bottom of the window.
-
-----
-
-> **Useful links**
-> https://ethereum.org/en/developers/tutorials/deploying-your-first-smart-contract/
diff --git a/docs/to_be_redistributed/how_to_guides/get_account_information.md b/docs/to_be_redistributed/how_to_guides/get_account_information.md
deleted file mode 100644
index 62b8609e..00000000
--- a/docs/to_be_redistributed/how_to_guides/get_account_information.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# How To Get Account Information
-(the text is to be added)
-
-
-
-----
-
-> **Usefull liks**
->
\ No newline at end of file
diff --git a/docs/to_be_redistributed/how_to_guides/get_transaction_information.md b/docs/to_be_redistributed/how_to_guides/get_transaction_information.md
deleted file mode 100644
index 9ef15d3b..00000000
--- a/docs/to_be_redistributed/how_to_guides/get_transaction_information.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# How To Get Transaction Information
-(the text is to be added)
-
-### Transaction Details:
-
-Transaction Hash -
-Status -
-Block -
-Timestamp -
-From -
-To -
-Value -
-Transaction Fee -
-Gas Limit -
-Gas Used by Transaction -
-Gas Price -
-Nonce -
-Input Data -
-
-
-
-----
-
-> **Usefull liks**
->
\ No newline at end of file
diff --git a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-1.png b/docs/to_be_redistributed/how_to_guides/images/connect-metamask-1.png
deleted file mode 100644
index 4e8f4948..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-1.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-2.png b/docs/to_be_redistributed/how_to_guides/images/connect-metamask-2.png
deleted file mode 100644
index cb1e3708..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-2.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-3.png b/docs/to_be_redistributed/how_to_guides/images/connect-metamask-3.png
deleted file mode 100644
index 4acdbdc6..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-3.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-4.png b/docs/to_be_redistributed/how_to_guides/images/connect-metamask-4.png
deleted file mode 100644
index 68840701..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-4.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-5.png b/docs/to_be_redistributed/how_to_guides/images/connect-metamask-5.png
deleted file mode 100644
index ffe6734d..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-5.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-6.png b/docs/to_be_redistributed/how_to_guides/images/connect-metamask-6.png
deleted file mode 100644
index 09ff8ad8..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/connect-metamask-6.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/depl-contr-1.png b/docs/to_be_redistributed/how_to_guides/images/depl-contr-1.png
deleted file mode 100644
index c76cc34c..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/depl-contr-1.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/depl-contr-2.png b/docs/to_be_redistributed/how_to_guides/images/depl-contr-2.png
deleted file mode 100644
index 4e06f8a9..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/depl-contr-2.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/depl-contr-3.png b/docs/to_be_redistributed/how_to_guides/images/depl-contr-3.png
deleted file mode 100644
index e979fdd5..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/depl-contr-3.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/depl-contr-4.png b/docs/to_be_redistributed/how_to_guides/images/depl-contr-4.png
deleted file mode 100644
index c3d19bf7..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/depl-contr-4.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/images/depl-contr-5.png b/docs/to_be_redistributed/how_to_guides/images/depl-contr-5.png
deleted file mode 100644
index fd767f47..00000000
Binary files a/docs/to_be_redistributed/how_to_guides/images/depl-contr-5.png and /dev/null differ
diff --git a/docs/to_be_redistributed/how_to_guides/install_metamask.md b/docs/to_be_redistributed/how_to_guides/install_metamask.md
deleted file mode 100644
index 508c5fbb..00000000
--- a/docs/to_be_redistributed/how_to_guides/install_metamask.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# How To Install the MetaMask Wallet
-
-### Goal
-
-Install the MetaMask wallet on your device.
-
-### Before You Begin
- * Make sure that one of the following systems is installed on your device. These are: *Ubuntu*, *Chrome*, *Opera*, *Firefox*, or *iOS*, *Android* if you’re a mobile user.
- * Understand the following:
- * What is [MetaMask](https://en.wikipedia.org/wiki/MetaMask)?
- * What is a keypair, including private and public keys?
-
-### Steps
-
-* Go to the MetaMask [download page](https://metamask.io/download.html). From there, select whichever platform you’re using, and follow the steps to install it on your device.
-* Follow along with the setup specified by the app. Go ahead and click `Create a Wallet`. Write down the backup [seed phrase](https://academy.binance.com/en/glossary/seed-phrase).
-* Confirm that you’ve written the seed phrase down on the next page.
-
-* Configuring !!!!!! - ДОПОЛНИТЬ
-Open the Networks menu. Click `Add Network` in the top-right corner to manually add the Binance Smart Chain one
-
-
-----
-
-> **Usefull liks**
->
diff --git a/docs/token_transferring/img/transfer-spl-1.png b/docs/token_transferring/img/transfer-spl-1.png
deleted file mode 100644
index 364feac5..00000000
Binary files a/docs/token_transferring/img/transfer-spl-1.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-10.png b/docs/token_transferring/img/transfer-spl-10.png
deleted file mode 100644
index c156bbad..00000000
Binary files a/docs/token_transferring/img/transfer-spl-10.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-2.png b/docs/token_transferring/img/transfer-spl-2.png
deleted file mode 100644
index b7808cc4..00000000
Binary files a/docs/token_transferring/img/transfer-spl-2.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-3.png b/docs/token_transferring/img/transfer-spl-3.png
deleted file mode 100644
index d84c7b03..00000000
Binary files a/docs/token_transferring/img/transfer-spl-3.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-4.png b/docs/token_transferring/img/transfer-spl-4.png
deleted file mode 100644
index 6a432a14..00000000
Binary files a/docs/token_transferring/img/transfer-spl-4.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-5.png b/docs/token_transferring/img/transfer-spl-5.png
deleted file mode 100644
index 3ddaec59..00000000
Binary files a/docs/token_transferring/img/transfer-spl-5.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-6.png b/docs/token_transferring/img/transfer-spl-6.png
deleted file mode 100644
index 2cc46f21..00000000
Binary files a/docs/token_transferring/img/transfer-spl-6.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-7.png b/docs/token_transferring/img/transfer-spl-7.png
deleted file mode 100644
index 3f5cd92d..00000000
Binary files a/docs/token_transferring/img/transfer-spl-7.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-8.png b/docs/token_transferring/img/transfer-spl-8.png
deleted file mode 100644
index 6f37f6d5..00000000
Binary files a/docs/token_transferring/img/transfer-spl-8.png and /dev/null differ
diff --git a/docs/token_transferring/img/transfer-spl-9.png b/docs/token_transferring/img/transfer-spl-9.png
deleted file mode 100644
index 42f80e17..00000000
Binary files a/docs/token_transferring/img/transfer-spl-9.png and /dev/null differ
diff --git a/docs/token_transferring/neonpass_overview.md b/docs/token_transferring/neonpass_overview.md
deleted file mode 100644
index 502c4e61..00000000
--- a/docs/token_transferring/neonpass_overview.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: NeonPass Overview
----
-
-[NeonPass](https://neonpass.live/) is an open-source service designed to transfer tokens between Solana and the Neon EVM, and provides users with the following features:
- * Transfer of SPL tokens from Solana to the Neon EVM to a non-existent account. The account with an ERC-20 balance is automatically created when transferring tokens.
- * Transfer of SPL tokens from Solana to the Neon EVM to an existing account with no ERC-20 balance. The balance is automatically created when transferring tokens.
- * Transfer of SPL tokens from Solana to the Neon EVM to an existing account with an ERC-20 balance.
- * Withdrawal of ERC-20 tokens from the Neon EVM to an existing account with an SPL balance in Solana.
- * Withdrawal of ERC-20 tokens from the Neon EVM to an existing account with no SPL balance in Solana. The balance is automatically created when transferring tokens.
-
-Solana has its own ERC-20 tokens generated by the special application. These tokens are on the balances of SPL accounts inside Solana. Transactions with balances are possible only through a Solana wallet (for example, through [Phantom](about/terminology.md#phantom)). There is no way to directly manage these balances from the Neon EVM.
-
-We provide you with NeonPass in order for you to make transactions with SPL tokens quickly and conveniently. To transfer tokens from Solana to the Neon EVM, as well as from the Neon EVM to Solana, two wallets are required: [Phantom](about/terminology.md#phantom) and [MetaMask](about/terminology.md#metamask), which provide the addresses of a recipient and a sender. Transactions are signed with keys obtained from these addresses.
-
-> The NeonPass service provides Ethereum users with the ability to transfer SPL tokens to the Neon EVM and withdraw them back.
diff --git a/docs/token_transferring/neonpass_usage.md b/docs/token_transferring/neonpass_usage.md
index 0894a4e0..a2006b35 100644
--- a/docs/token_transferring/neonpass_usage.md
+++ b/docs/token_transferring/neonpass_usage.md
@@ -1,124 +1,198 @@
---
-title: Transfer Solana Tokens
+title: Move Tokens Between Neon EVM and Solana
+proofedDate: 20231207
+iterationBy: na
+includedInSite: true
+approvedBy: VS
+comment:
---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import image1 from '@site/static/img/doc-images/neonpassV2/Connect_to_wallet.png';
+import image2 from '@site/static/img/doc-images/neonpassV2/Neon_to_Solana.png';
+import image3 from '@site/static/img/doc-images/neonpass/select_network.png';
+import image4 from '@site/static/img/doc-images/neonpassV2/Solana_to_Neon_transfer.png';
+import image5 from '@site/static/img/doc-images/neonpassV2/Transfer_completed_general.png';
+import image6 from '@site/static/img/doc-images/neonpassV2/Transfer_completed_general.png';
+import image7 from '@site/static/img/doc-images/neonpass/confirmation_transfer_neonscan.png';
+import image8 from '@site/static/img/doc-images/neonpass/confirmation_transfer_solana.png';
+import image9 from '@site/static/img/doc-images/neonpassV2/Not_Enough_SOL.png';
+import image10 from '@site/static/img/doc-images/neonpassV2/Wrong_network.png';
+import image11 from '@site/static/img/doc-images/neonpassV2/Transfer_completed.png';
+import image12 from '@site/static/img/doc-images/neonpassV2/Transfer_failed.png';
+import image13 from '@site/static/img/doc-images/neonpassV2/Homepage.png';
+import image14 from '@site/static/img/doc-images/neonpassV2/Mobile Wallet connect.png';
+import image15 from '@site/static/img/doc-images/neonpassV2/Transfer complete.png';
+import image16 from '@site/static/img/doc-images/neonpassV2/Transfer_failed.png';
+
+## TL;DR
+
+
+
## Overview
-This guide provides instructions on how to transfer ERC-20 tokens between Solana and Neon EVM using NeonPass. You can do it in any direction, i.e. transfer tokens from Solana to Neon EVM or withdraw them back. However, you need to keep in mind that each transaction in Neon EVM or Solana will be charged a fee in the form of NEON or SOL tokens, respectively. For example, withdrawing tokens from Neon EVM to Solana requires 2 transactions: one for Neon EVM (requires a fee in NEON) and another for Solana (requires a fee in SOL). Therefore, you will have to pay two fees.
-Before you start transferring ERC-20 tokens, you have to fulfill the following requirements:
- * On a source side, you should already have an account with the balance of tokens that will be transferred.
- * NeonPass uses [MetaMask](about/terminology.md#metamask) and [Phantom](about/terminology.md#phantom), two popular non-custodial browser based wallets.
- * The NeonPass application is deployed in the browser to which your wallets are attached.
+This guide demonstrates how to transfer tokens between Solana and Neon EVM using the [NeonPass](https://neonpass.live/) UI. The same tooling is available as an [npm package](/docs/developing/integrate/neon_transfer).
+
+You can transfer tokens in either direction, but each transaction incurs a gas fee in either NEON or SOL.
+
+:::info
+ Neon EVM's Devnet now supports a feature providing the option to pay the gas fees with the [token of transaction](https://neonevm.org/blog/feature-alternative-gas-fee-token), rather than only NEON or SOL.
+:::
+
+:::important
+When transferring tokens from Neon EVM to Solana for the first time, ensure that you have SOL in your Solana wallet to cover the transaction costs. This is a one-time requirement for the initial transfer.
+:::
+
+## Prerequisites
+
+- Neon EVM-compatible wallet (e.g. Atomic Wallet, MetaMask, Rabby Wallet, WalletConnect, Trust Wallet, Ledger, etc.)
+- Solana-compatible wallet (e.g. Phantom, Solfare, etc.)
+- Browser with both wallet applications attached
+- Token balance to pay gas fees
+
+## Transfer tokens with NeonPass
+
+### Step 1: Set up wallets
+
+1.1 Navigate to [NeonPass](https://neonpass.live/).
+
+1.2 Add your required Neon EVM Network in your Neon compatible wallet through [Chainlist.org/chain/245022934](https://chainlist.org/?chain=245022934&search=Neon+EVM&testnets=true).
+
+> For further help, see our [wallet setup walkthrough](/docs/wallet/metamask_setup).
+
+### Step 2: Connect wallets to NeonPass
+
+:::tip
+Remember to use a browser to which both your Solana and Neon EVM compatible wallets are attached.
+:::
-## Procedure
-This procedure presents the example of transferring USDT tokens from Neon EVM to Solana in Devnet. The task is to transfer 5 USDT from Neon EVM to Solana.
+2.1 Click **Connect Wallet** to connect your Solana compatible wallet to NeonPass. Follow the login procedure in your wallet's popup window and ensure it's connected to the network you require (e.g. Mainnet).
-Initial conditions:
- * Your Neon EVM account contains a non-zero USDT balance.
- * You have a non-zero NEON balance to pay the withdrawal approval fee.
- * Your Solana account contains a non-zero SOL-balance to pay the fee.
+
-Transferring tokens using NeonPass occurs in three stages:
- * Source — Connecting the MetaMask wallet to NeonPass and providing access to the sender's account balance.
- * Target — Connecting the Phantom wallet to NeonPass and providing access to the recipient's account balance.
- * Confirmation — Signing the transaction and checking the result of transferring tokens.
+2.2 Repeat this step for your Neon EVM compatible wallet.
-### The Source Stage
+### Step 3: Conduct transfer
-Go to the [NeonPass](https://neonpass.live/) page in the browser to which the Phantom and MetaMask wallets are attached.
+
-
+
-
+3.1 Select the transfer direction from Neon EVM to Solana.
-
+
-1. Make sure that the icons of these wallets are displayed at the top right.
-2. By default, the direction of transferring tokens is set from `Solana` to `Neon`. If this is not the case, you have to click on the arrow icon to reverse the forwarding direction.
-3. Click `Connect Wallet` to connect your MetaMask wallet to the NeonPass app. The MetaMask window should pop up on the screen. Follow the login procedure to your wallet and make sure it is connected to Devnet. Also, make sure you have enough USDT tokens in your account to transfer (there are 987.9 USDT in our example) and have a non-zero NEON balance to pay the withdrawal approval fee.
+:::important
+Your first ever transaction from your wallet includes a one time fee to generate the Solana account linked to your address. Therefore the first transaction will be more expensive than the subsequent ones.
+:::
-Upon successful connection of the MetaMask wallet to NeonPass and access to your account balance, the inscription `Connect Wallet` will change to the public key of your account in the Neon EVM.
+3.2 Choose the token and enter the amount to transfer.
-
+3.3 Click **Transfer** and sign the transaction in your connected wallets.
-
+3.4 Review the transaction summary and enjoy your tokens in Solana!
-
+
-On the NeonPass screen, click `Select a token`. In the list that appears, select the desired token symbol and specify the quantity to be sent. (In our example, it is 5 USDT.)
+
-
+3.1 Select the transfer direction from Solana to Neon EVM.
-
+
-
+3.2 Choose the token, enter the amount, and select the gas token (NEON or SOL).
-Click `Next` to continue the token transfer procedure and proceed to the Target stage.
+3.3 Are you an expert user? Click on 'Advanced Mode' and select a different priority fee to speed up
-### The Target Stage
+3.4 Click **Transfer** and sign the transaction in your connected wallets.
-The `Target` windows will appear on the NeonPass screen. Click `Select Wallet` to connect your Phantom wallet to NeonPass.
+3.5 Review the transaction summary and enjoy your tokens in Neon EVM!
-
+
-
+
-
+**Verify the transaction on [NeonScan](https://neonscan.org/) or [Blockscout](https://neon.blockscout.com/).**
-The Phantom window should pop up on the screen. Follow the login procedure to your wallet and make sure it is connected to Devnet. Also make sure you have a non-zero SOL balance in your account to pay the fee. (There are 10 SOL in our example.)
+We hope that you love NeonPass and that you are ready to leverage the full potential of Neon EVM by facilitating hassle-free transfers of assets to and from Solana.
-Upon successful connection of the Phantom wallet to NeonPass and access to your account balance, the inscription `Select Wallet` will change to the public key of your account in Solana. This means that a user authorizes NeonPass to use this key to sign transactions. Phantom stores sets of account keys, but does not store any balances. To obtain balances, Phantom will refer to the Solana blockchain.
+## Gas Fees and Priority Selection
-
+
-
+
-
+When transferring tokens from Neon EVM to Solana:
+- You can pay gas fees in NEON or the token of transaction.
+- If you're withdrawing to a new Solana account or an existing account that has never received the specific ERC-20 token before, ensure that you have sufficient SOL in your Solana wallet to cover the gas fees.
-Click `Next` to continue the token transfer procedure and proceed to the Confirmation stage.
+
-### The Confirmation Stage
+
-Read the details of the upcoming transfer of tokens and click `Confirm`.
+When transferring tokens from Solana to Neon EVM:
+- For sending NEON tokens, you can choose between NEON and SOL as the gas token.
+- For sending SPL tokens (e.g., USDC), only SOL can be used as the gas token.
-
+
-
+
-
+:::important
+Please be aware of the gas fee specificities for each transfer direction. Always ensure you have sufficient funds in the appropriate token to cover gas fees before initiating a transfer.
+:::
-The MetaMask window will pop up on the NeonPass screen with the amount of fee charged for using gas in Neon EVM. The fee is paid in NEON tokens. If you agree with these terms, click `Confirm`. The transaction will be signed automatically with the public key of your Neon EVM account.
+## Edge Cases
-
+1. Insufficient funds for gas fees
+
+
-
+2. Wallet connection issues
+
+
-
+3. Transfer completion and failure
+
+
+
+
-You should also approve the transaction in the Phantom window, which will display the amount transferred and fee charged in SOL tokens. The transaction will be signed automatically with the public key of your Solana account.
+:::info
+If you encounter any persistent issues or have questions about edge cases not covered here, please reach out to our [support team](http://discord.com/invite/neonevm) for assistance.
+:::
-
+## Using NeonPass on Mobile Devices
-
+NeonPass is designed to be responsive and user-friendly across various devices, including mobile phones.
-
+
-You should receive a notification that the token transfer was successful. Open the `View on Solana Explorer` page to see the results of transferring funds using NeonPass.
+1. Connecting wallets on mobile
+
+
-
+ :::tip
+ Make sure you have your mobile wallet apps installed and set up before attempting to connect them to NeonPass.
+ :::
-
+2. Selecting tokens and entering amounts
-
+3. Initiating and confirming transfers
+
+
-The `Token Balance Change` tab shows the change in balances upon completion of the procedure.
+ :::important
+ Always double-check the transaction details before confirming a transfer, especially on mobile devices where screen sizes are smaller.
+ :::
-
+4. Track transfer progress and history in a dedicated explorer
-
+
-
+By following these steps, you can easily transfer tokens using NeonPass on your mobile device, enjoying a seamless and user-friendly experience on the go.
-## Conclusion
+## Under the hood
-We examined the use of NeonPass in Devnet using the example of transferring USDT tokens from Neon EVM to Solana. The procedure for reverse transferring tokens from Solana to Neon EVM using NeonPass is not much different from the one given, and therefore we do not consider it here. The main difference will be only in the order of connecting wallets to NeonPass.
+Neon EVM isn't a blockchain, and so it follows that NeonPass isn't a conventional blockchain bridge. Your assets are not wrapped. Instead, Neon EVM applies an ERC-20 interface, making SPL tokens behave like Ethereum-natives when in the Neon network. [Learn more about how NeonPass works](/docs/tokens/token-accounts).
\ No newline at end of file
diff --git a/docs/token_transferring/sol_to_evm.md b/docs/token_transferring/sol_to_evm.md
deleted file mode 100644
index 066cf500..00000000
--- a/docs/token_transferring/sol_to_evm.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Transfer Tokens Between Solana and EVMs
----
-
-The ERC-20 wrapper allows users to manipulate balances inside SPL tokens. The user runs an application inside the Neon EVM with logic that releases new coins. To transfer these coins to the outside world, they need to use the ERC-20 bridge implementation. Inside the Neon EVM, these coins will be blocked and transferred inside the SPL token to different addresses. They will become liquid inside Solana, but under a different token name, which is registered inside Solana.
-
-A user can also transfer part of the funds to their balance inside Neon EVM and convert it into a new token using a token exchange algorithm of their choice.
-
-
-
-
-
-Fig. 1 — Process for transferring tokens between Solana and Ethereum.
-
-
-
-Ethereum tokens are generated in accordance with the ERC-20 standard. Therefore, to transfer tokens between the Solana and Ethereum blockchains, a separate ERC-20 wrapper must be deployed for each Solana token. The ERC-20 wrapper’s job is to ensure that the Solana applications interact with EVM (Solidity, Vyper, etc.) bytecode contracts, as well as to transfer funds in Solana tokens using Ethereum wallets such as MetaMask.
-
-The main interacting component in the token transfer is the ERC-20 bridge, which is a separate contract. When it’s called, it generates a Solana token, which represents the corresponding ERC-20 token in the SPL token contract. The Solana tokens registered in the SPL token contract can be transferred to Solana contracts.
-Bridge operators are responsible for the ERC-20 bridge operation. They get fees from the conversion of tokens.
diff --git a/docs/tokens/gas_fees.md b/docs/tokens/gas_fees.md
deleted file mode 100644
index e5446f14..00000000
--- a/docs/tokens/gas_fees.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Gas Fees
----
-
-## Key Takeaways
-
-The NEON token is used to pay the “gas fees” required for transaction execution. The gas fee is the amount of NEON tokens that a user needs to pays for a transaction to execute it successfully.
-
-On a high level, gas fee payments in the Neon EVM work as follows:
-1. The **User** pays for each transaction in NEON tokens to the **Proxy Operator**.
-2. The **Proxy Operator** then pays the **Solana Validator** and the **DAO Treasury**.
-
-
-
-
-
-
-
-As depicted in the diagram above, users of dApps built on the Neon EVM pay in NEON tokens for all the resources they consume, in addition to operator fees that differ between operators. Operators, however, use SOL to pay for the resources they consume. Specifically, operators pay Solana validators and governance fees in SOL. Operators pay the same amount for governance as they pay to Solana validators (for the signature validation).
-
-The gas fee that a user pays is calculated as **gas amount \* gas price**.
-
-
-The **gas amount** is the amount of computational resources, such as CPU time and storage, used to execute the transaction. The gas amount is calculated mainly in accordance with Solana's rules (in fact, 1 gas unit = 1 lamport) as a sum of the following amounts:
-* The **computational cost**, which is 5,000 units for each transaction (Solana charges 5,000 lamports for the signature validation for each transaction). This amount goes to Solana validator. This computational cost is **doubled** to give the same amount of gas fees to the **DAO Treasury**.
-* The **storage cost**, which is 6,960 units for each newly allocated byte (Solana charges 6,960 lamports for each byte), while re-use of existing or already-allocated storage is free.
-
-For example, for a Neon transaction with N iterations and S newly allocated bytes, the gas amount will be
-
-> 2 \* computational cost + storage cost
-
-> = 2 \* 5,000 \* N + 6960 \* S units
-
-The **gas price** is the cost of 1 unit of gas in NEON. This price is calculated using the following forumla:
-
-> (1 + Proxy Operator fee) \* SOL-to-NEON-rate \* 10-9 NEONs
-
-which can also be represented as:
-
-> (1 + Proxy Operator fee) \* SOL-to-NEON-rate Galans
-
-This amount is usually displayed for users in Galans (10-9 NEONs).
-
-The final formula for the gas fee for a Neon transaction with N iterations and S newly allocated bytes is:
-
-> “Gas amount” \* “Gas price”
-
-> = [ N \* 2 \* 5,000 + S \* 6,960 ] \* (1 + Proxy Operator fee) \* SOL-to-NEON-rate
-
-## Examples
-The following are some examples of gas fee calculation on Neon. They are all based on the following assumptions:
-* The SOL price is $30 and the NEON price is $0.25
-* The SOL-to-NEON rate is therefore 30 / 0.25 = 120.
-* The Proxy Operator fee is 10%.
-* The gas price is therefore (1 + 10%) \* 120 \* 10-9 NEON = 132 \* 109 Alan = 132 Galan
-
-### Example 1: A Normal Swap
-The gas amount in this case is 10 \* 2 \* 5,000 (computational cost + treasury) + 5 \* 6,960 (storage cost) ≈ 145,000 units
-The total gas fee is therefore 145,000 units \* 132 \* Galan = 0.01914 NEON.
-
-### Exampe 2: Creating a New Account
-According to [Solana](https://docs.solana.com/storage_rent_economics), the rental cost for storage can be paid via one of two methods:
-1. Set it and forget it. With this approach, accounts with two years' worth of rent deposited are exempt from network rent charges. By maintaining this minimum balance, the broader network benefits from reduced liquidity and the account holder can rest assured that their data will be retained for continual access and usage.
-2. Pay per byte. If an account has less than two years' worth of deposited rent, the network charges rent on a per-epoch basis, in credit for the next epoch. This rent is deducted at a rate specified in genesis, in lamports per kilobyte-year.
-
-To simplify the user experience, Neon charges two years' worth of rent deposits for each new account. Therefore, the gas cost of creating a new account is:
-> 0 \* 2 \* 5,000 (computational cost + treasury) + (128 + 71) \* 6960 (storage cost for the minimum Neon account size) ≈ 1,400,000 units
-
-Therefore, the total gas fee is 1,400,000 units \* 132 Galan = 0.1848 NEON tokens.
-
-### Example 3: A Simple NEON or ERC-20 Token Transfer
-In this case the gas amount is:
-> 1 \* 2 \* 5,000 (computational cost + treasury) + 0 \* 6,960 (storage cost in case the account exists) ≈ 10,000 units
-
-Therefore, the total gas fee is 10,000 units * 132 Galan = 0.00132 NEON tokens.
diff --git a/docs/tokens/gas_fees.mdx b/docs/tokens/gas_fees.mdx
new file mode 100644
index 00000000..63975de2
--- /dev/null
+++ b/docs/tokens/gas_fees.mdx
@@ -0,0 +1,122 @@
+---
+title: Gas Fees
+proofedDate: 20231204
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: Calc sheet https://docs.google.com/spreadsheets/d/1g2ms3DveyPgrG0Gf6cSwq6xhT0AgrrRus_pa9ICHP4w/edit?usp=sharing
+---
+
+import Formula from '../single-source-snippets/_price_formula.mdx'
+import Price from '../single-source-snippets/_gas_price_calc.mdx'
+
+## TL;DR
+
+- `Gas Fee` = `Gas amount` \* `Gas price`
+- [`Gas price`](#gas-price) depends on the SOL:NEON ratio and Proxy Operator fee
+- [`Gas amount`](#gas-amount) depends on the computational resources as per Solana's rules
+- The first transaction (i.e. requires account setup), is [more expensive](#example-2-create-a-new-account) than subsequent transactions
+
+
+## Introduction
+
+The NEON token is used to pay the “gas fees” required for transaction execution. The gas fee is the amount of NEON a user pays for a transaction to execute successfully.
+
+:::info
+Neon EVM will soon support fee payment in the same token as the transaction token for supported tokens e.g. SOL and USDC.
+:::
+
+> `Gas Fee` = `Gas amount` \* `Gas price`
+>
+> This amount is usually displayed for users in [Galans (10-9 NEON)](/docs/tokens/neon_token#token-parameters).
+
+On a high level, gas fee payments in the Neon EVM work as follows:
+1. The **User** pays for each transaction in NEON tokens to the **Proxy Operator**.
+2. The **Proxy Operator** then pays the **Solana Validator** and the **DAO Treasury**.
+
+
+
+
+
+
+
+As depicted in the diagram, users of dApps built on the Neon EVM pay for all the resources they consume plus the Operator fees (that may differ between Operators). Operators pay for the resources they consume in SOL. Specifically, Operators pay Solana validators and governance fees in SOL. Operators pay the same amount for governance as they pay to Solana validators (for the signature validation).
+
+### Gas amount
+
+The **gas amount** is the amount of computational resources, such as CPU time and storage, used to execute the transaction. The gas amount is calculated in accordance with Solana's rules (in fact, 1 gas unit = 1 Lamport) as a sum of the following amounts:
+* The **computational cost**
+> 5,000 units for each transaction (Solana charges 5,000 Lamports for the signature validation for each transaction). This amount goes to Solana validator. This computational cost is **doubled** to give the same amount of gas fees to the **DAO Treasury**.
+* The **storage cost**
+> 6,960 units for each newly allocated byte (Solana charges 6,960 Lamports for each byte), while re-use of existing or already-allocated storage is free.
+
+For example, for a Neon transaction with N iterations and S newly allocated bytes, the *gas amount* will be:
+
+> 2(computational cost) + storage cost
+
+> = 2(5,000 \* N) + (6960 \* S units)
+
+### Gas price
+
+The **gas price** is the cost of 1 unit of gas in NEON. This price is calculated using the price of SOL:NEON multiplied by an adjuster that is configured by the Proxy Operator:
+
+
+
+
+## Examples
+
+The following examples of gas fee calculations on Neon are all based on these assumptions:
+
+
+
+### Example 1: swap or transfer
+
+If the spend is already approved from an account that already exists, we can use the following Gas amount with the Gas price as calculated above.
+
+The Gas amount is calculated with N=1 iterations and S=0 storage costs:
+
+| Component | Value | Units/Definition | Calculation |
+| ------------------ | ---------- | ------------------ | ---------------------------- |
+| Computational cost | 1 | iterations \* 5000 | 1000 |
+| Storage cost | 0 | bytes \* 6960 | 34800 |
+| Gas amount | 54800 | Lamports | (2\*computational) + storage |
+| | | | |
+| **Gas Fee** | **0.002475** | NEON | [gas price](#examples) \* gas amount |
+
+### Example 2: create a new account
+Within [Solana](https://docs.solana.com/storage_rent_economics), the rental cost for storage can be paid via one of two methods:
+1. Set it and forget it.
+
+> With this approach, accounts with two years' worth of rent deposited are exempt from network rent charges. By maintaining this minimum balance, the broader network benefits from reduced liquidity and the account holder can rest assured that their data is retained for continual access and usage.
+
+2. Pay per byte.
+
+> The network can charge rent on a per-epoch basis, in credit for the next epoch. This rent is deducted at a rate specified in genesis, in Lamports per Kilobyte-year.
+
+To simplify the user experience, Neon takes option 1 and charges two years' worth of rent deposits for each new account. The gas cost of creating a new account is:
+
+
+| Component | Value | Units/Definition | Calculation |
+| ------------------ | ---------- | ------------------ | ---------------------------- |
+| Computational cost | 1 | iterations \* 5000 | 1000 |
+| Storage cost | 199 | bytes \* 6960 | 34800 |
+| Gas amount | 1395040 | Lamports | (2\*computational) + storage |
+| | | | |
+| **Gas Fee** | **0.3452724** | NEON | [gas price](#examples) \* gas amount |
+
+
+
+### Example 3: create a pool in Sobal
+
+| Component | Value | Units/Definition | Calculation |
+| ------------------ | ---------- | ------------------ | ---------------------------- |
+| Computational cost | 32 | iterations \* 5000 | 1000 |
+| Storage cost | 10000 | bytes \* 6960 | 34800 |
+| Gas amount | 69920000 | Lamports | (2\*computational) + storage |
+| | | | |
+| **Gas Fee** | **17.3052** | NEON | [gas price](#examples) \* gas amount |
+
+
+## What next?
+
+If you want to get your dApp started on Neon EVM, you may be wondering how you pay for the first transactions that are required to buy the NEON required to cover gas costs. This is where our starter pack of gasless transactions comes in. Furthermore, our "coming soon" feature will allow users to pay fees in [alternative tokens](https://neonevm.org/blog/feature-alternative-gas-fee-token).
diff --git a/docs/tokens/neon_token.md b/docs/tokens/neon_token.md
index 111a57a5..5ab3df28 100644
--- a/docs/tokens/neon_token.md
+++ b/docs/tokens/neon_token.md
@@ -1,5 +1,10 @@
---
title: The Neon Token
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
---
The NEON token is the native token of the Neon EVM. It is used as a:
diff --git a/docs/tokens/token-accounts.md b/docs/tokens/token-accounts.md
new file mode 100644
index 00000000..87a3ba7f
--- /dev/null
+++ b/docs/tokens/token-accounts.md
@@ -0,0 +1,37 @@
+---
+title: NeonPass and token accounts
+proofedDate: 20230928
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment:
+---
+import image1 from '@site/static/img/doc-images/neonpass/NeonPass.png';
+
+## TL;DR
+
+NeonPass seamlessly transfers assets between Solana’s Associated Token Accounts and Neon EVM’s ERC-20 token accounts.
+
+## Overview
+
+This page takes you under the hood of [NeonPass](/docs/token_transferring/neonpass_usage) as an excellent lens to examine how tokens are handled on Solana vs. Neon EVM.
+
+### How does NeonPass work?
+
+NeonPass isn't a conventional blockchain bridge. When working with ERC-20 assets in Neon EVM, they're not wrapped; instead, they're compatible with Neon EVM thanks to Neon EVM's interface contract and an account storage strategy.
+
+#### Account storage
+
+On Solana, SPL assets are stored within Solana Associated Token Accounts. For an SPL token, i.e. a Solana-native token, to interact with Ethereum-native Neon EVM, the token must be packaged in an ERC-20 interface that's deployed in the Factory contract of Neon EVM. Once packed, such assets are then transferred to Neon EVM ERC-20 token accounts. These token accounts are specialized Solana accounts that are instantiated within the Neon EVM Ecosystem. These are compatible with Solidity dApps and behave like any Ethereum account.
+
+### Moving SPL tokens between Neon EVM and Solana
+
+This transfer of SPL tokens between account types is a different approach to that provided by blockchain Bridges. Bridges lock the assets on the source blockchain and mint corresponding assets on the target blockchain. NeonPass moves tokens *between* accounts. Move an SPL token into your EVM-based wallet such as MetaMask and, under the hood, the source account is your Solana Associated Token Account, and the target is your Neon EVM ERC-20 Token Account that stores the assets associated with your EVM-based wallet.
+
+
+
+
+This transfer process also works in reverse. Neon EVM assets can be unpackaged into the SPL standard and transferred back to the Associated Solana Token Account. This allows the assets to seamlessly transition between Neon EVM and Solana accounts within Solana’s L1 Blockchain.
+
+
+The [NeonPass FAQ](/docs/faq/neonpass) provides further details of how NeonPass functions.
diff --git a/docs/tokens/token_list.md b/docs/tokens/token_list.md
index cece9fc3..4f58c2d9 100644
--- a/docs/tokens/token_list.md
+++ b/docs/tokens/token_list.md
@@ -1,61 +1,73 @@
---
title: ERC-20 Token List
+proofedDate: 20230526
+iterationBy: na
+includedInSite: true
+approvedBy: na
+updateDetails: This source provides the NeonPass-supported tokens HOWEVER not clear on the token naming (e.g. what is W_BTC? also not clear on which chain this applies to also not clear how bridger is identified -- what would SOETH look like compared to WETH -- sollet vs wormhole wrapped ETH?)
+comment: TODO source of truth for needs programmatic update from this page -- want to include bridger info too when that applies -- is this possible? NB only full code block results in copy option -- tried this in HTML table and it is not compatible
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-When performing operations on tokens in the Neon EVM, it is important to know which token symbol or address can be used. Having a list of possible tokens available, you can easily navigate when choosing the token you need.
+To use SPL or ERC-20 tokens from a Neon account, you need to transact via the token's ERC-20 interface. This page provides the supported token's interface addresses.
+
-## Token List
-The list of tokens whose contracts are deployed in Neon EVM and are available to you can be found in the [neonlabsorg/token-list](https://github.com/neonlabsorg/token-list/) repository.
+For the most up-to-date list of tokens whose contracts are deployed in Neon EVM and are available, call the list with the [Factory contract](docs/developing/deploy_facilities/interacting_with_spl_tokens.md).
-## ERC-20 Token Addresses on Neon
+
+
+## Token list: NeonPass-supported tokens
+
+The following tables provide the addresses of ERC-20 interface contracts for the tokens available through [NeonPass](docs/developing/integrate/neon_transfer.mdx).
+
+## ERC-20 interface addresses on Neon
-In addition to NEON and wNEON tokens, below are some common tokens that are deployed to the Neon Mainnet.
----
+**Chain ID: 245022934**
+
+| | Token | Mainnet ERC-20 interface address | SPL address |
+| ---------------------------------------------------------------------------------------------------------------------------------------- | --------------- | -------------------------------------------- | ---------------------------------------------- |
+| | wNEON | `0x202C35e517Fa803B537565c40F0a6965D7204609` | |
+| | wSOL | `0x5f38248f339Bf4e84A2caf4e4c0552862dC9F82a` | `So11111111111111111111111111111111111111112` |
+| | USDC | `0xEA6B04272f9f62F997F666F07D3a974134f7FFb9` | `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` |
+| | USDT | `0x5f0155d08eF4aaE2B500AefB64A3419dA8bB611a` | `Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB` |
+| | WETH (Wormhole) | `0xcFFd84d468220c11be64dc9dF64eaFE02AF60e8A` | `7vfCXTUXx5WJV5JADk17DUJ4ksgau7utNKj4b963voxs` |
+| | WBTC | `0x16a3Fe59080D6944A42B441E44450432C1445372` | `3NZ9JMVBmGAqocybic2c7LQCJScmgsAZ6vQqTDzcqmJh` |
+| | LST | `0x14CCfFC97aC156A7f1E3183adAa8E7CC888AD162` | `LSTxxxnJzKDFSLr4dUkPcmCf5VyryEqzPLz5j4bpxFp` |
+| | JitoSOL | `0xFA8fB7e3bd299B2A9693B1BFDCf5DD13Ab57007E` | `J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn` |
+| | mSOL | `0x6EFFb385713f22df4846d8156451a5efEC22a4c8` | `mSoLzYCxHdYgdzU16g5QSh3i5K3z3KZK7ytfqcJm7So` |
+| | Bonk | `0xD4B6520f7Fb78E1EE75639F3376c581a71bcdb0E` | `DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263` |
+| | MELL | `0x26320e7ffd9be68ca61c1C75b3Be4aAb0AA98E1f` | `MELLd8PyFoeNW3D5VaUe7L96eZeihtrzgLWrbKz5DR2` |
+| | MNGO | `0x6d12eAA69f8e4902D3F83d546B31F7318717014C` | `MangoCzJ36AjZyKwVj3VnYU4GTonjfVEnJmvvWaxLac` |
+| | 2080 | `0x96e636d3Ef60ee9745945120010c73619144632C` | `Dwri1iuy5pDFf2u2GwwsH2MxjR6dATyDv9En9Jk8Fkof` |
+| | PYTH | `0x0575dD4AFD93B7522fEE4e0179f243ecA3856137` | `HZ1JovNiVvGrGNiiYvEozEVgZ58xaU3RKwX8eACQBCt3` |
+| | BLZE | `0x09F8A075D6fca984EA0bAda25A64326DF00691A4` | `BLZEEuZUBVqFhj8adcCFPJvPVCiCyVmh3hkJMrU8KuJA` |
+| | JSOL | `0x7b9f9033afcf602b556a7aeac5871a52b56a06ee` | `7Q2afV64in6N6SeZsAAB81TJzwDoD6zpqmHkzi9Dcavn` |
+| | CGT | `0x9950ef047D87599EB28bF5E9Fc7F63cEd1b5F4AE` | `5qkTJu3hVd3SYToWpyHUmGfiLR48jj9oSz1WniV1UcgS` |
+| | JUP | `0x9F0fCE2AB962984b1EE50108A8510eA190BeEb8d` | `JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN` |
+| | $WIF | `0xF86934c2b05c31f3bBE3BCd6E3a8aA7790cAd9c1` | `EKpQGSJtjMFqKZ9KQanSqYXRcF8fBopzLHYxdM65zcjm` |
+| | WEN | `0xc61e8aB62666D25F0854C5723587507A7E92E289` | `WENWENvqqNya429ubCdR81ZmD69brwQaaBYY6p3LCpk` |
+| | POPCAT | `0xb89c62e960457d1d2c5f20135bedfd215d2466de` | `7GCihgDB8fe6KNjn2MYtkzZcRjQy3t9GHdC8uHYmW2hr` |
+| | WHALE | `0x663572b924db12e0e3822c6160df29154630c8e3` | `9uhHjyfc5tKdaZnjstLLKoLGcF889ub8zX9wtwhtzgK6` |
+
+
+
+
+**Chain ID: 245022926**
+
+| | Token | Devnet ERC-20 interface address | SPL address |
+| --------------------------------------------------------------------------------------------------------------------------------- | ----- | -------------------------------------------- | ---------------------------------------------- |
+| | wNEON | `0x11adC2d986E334137b9ad0a0F290771F31e9517F` | |
+| | wSOL | `0xc7Fc9b46e479c5Cb42f6C458D1881e55E6B7986c` | `So11111111111111111111111111111111111111112` |
+| | USDT | `0x6eEf939FC6e2B3F440dCbB72Ea81Cd63B5a519A5` | `3vxj94fSd3jrhaGAwaEKGDPEwn5Yqs81Ay5j1BcdMqSZ` |
+| | USDC | `0x512E48836Cd42F3eB6f50CEd9ffD81E0a7F15103` | `F4DgNXqiT3zUQA7dhqN5VzEPkRcd8vtqFwpJSwEEvnz5` |
-|Token|Mainnet Address |
-|-----|:-----------------------------------------|
-|USDC |Comming soon... |
-|USDT |Comming soon... |
-|wSOL |Comming soon... |
-
-
-
-|Token|Devnet Address |
-|-----|:-----------------------------------------|
-|WNEON|0x11adC2d986E334137b9ad0a0F290771F31e9517F|
-|USDT |0xAA24A5A5E273EFAa64a960B28de6E27B87FfDFfc|
-|wDAI |0x4954cd6230C19e63B7c7b131760Ef0C0c424321C|
-|USDC |0xC659B2633Ed725e5346396a609d8f31794d6ac50|
-|ETH |0x90306D9492eB658e47A64Ef834e76c81A0242598|
-|wBTC |0x07A274154D79C23d5cd7ba78a243645E419CDd46|
-|AAVE |0xAb94bD2221cAc77FEbDB0B979Eb8839Ed7dDB981|
-|wCRV |0xcd7cD0Fe96D89aA98F1cB8f17cD31dCb6eA90D0d|
-|SUSHI|0x74bcA1362b31d52198E102d9E5f5B9af360D6750|
-|wBAL |0x4C694ac087B2D1DFcB7e868af6C0561f070B7f6C|
-|wSOL |Not available (missed MetaPlesk metadata) |
-
-
-
-
-|Token|Testnet Address |
-|-----|:-----------------------------------------|
-|USDT |0x5EE2CDe31b5d88A0574DAD2B4bb6A073A5b228a8|
-|wDAI |0x437c2606460cf14cbD33F5E266a2FaD044C5b74c|
-|USDC |0x341b332b35441c37c1211f02F2C03c1516ac3AC8|
-|ETH |0xbd5C9b22c9e0C41fE93aA863Da1402306A76d4fe|
-|wBTC |0x7Db49A319636818f38dc2d12B51b13192e1b9141|
-|AAVE |0x142Ec1Db2dc73932AE590C429D2BFd13732b70e2|
-|wCRV |0x633AC0dE8749f6c2fACb73665a05c622a272f291|
-|SUSHI|0xa2b3D9E1E92Af208Ed6bc41d4428e500569Af66F|
-|wBAL |0x42D8b8A634F8e65e799BF762054647e589b4F73a|
-|wSOL |0x16869acc45BA20abEFB2DdE2096F66373fDe364F|
-
-
+
diff --git a/docs/wallet/metamask_setup.md b/docs/wallet/metamask_setup.md
index 7b866099..96442811 100644
--- a/docs/wallet/metamask_setup.md
+++ b/docs/wallet/metamask_setup.md
@@ -1,13 +1,24 @@
---
title: Set Up MetaMask
+proofedDate: na
+iterationBy: na
+includedInSite: true
+approvedBy: na
+comment: TODO -- update to tell user Step 4 Connect MM to Proxy is binding a MM WalletID to a Neon Account ID -- this allows signing with a Neon Account
---
+## TL;DR
+
+RPC endpoints are available on [Chainlist](https://chainlist.org/?chain=245022926&testnets=true&search=Neon+EVM).
+
+
+## Introduction
MetaMask is a convenient and fairly easy-to-use application for storing Ethereum addresses and private keys. This tutorial will guide you, step by step, in installing MetaMask on your device and connecting the wallet to the Neon Devnet environment.
## Configuring MetaMask
### Step 1: Install MetaMask
-Go to the MetaMask [download page](https://metamask.io/download.html). From there, select any platform you use and follow the instructions to load and install MetaMask on your device's browser.
+Go to the MetaMask [download page](https://metamask.io/download). From there, select any platform you use and follow the instructions to load and install MetaMask on your device's browser.
The
-
- NEON token
- is used to pay the
- gas fees
- required for transaction execution Neon Proxy is an essential tool for packaging a
- Neon transaction into a Solana transaction. It improves the user experience for operators
- in the Neon ecosystem, and it allows Ethereum dApps to be ported to Neon with virtually no
- code or configuration changes, as all the “translating” is handled by the proxy.
-
-
- Neon operators run Neon Proxy servers, which helps facilitate seamless
- execution of Ethereum-like transactions on Solana. This allows Ethereum dApps to be ported to
- Neon with no code change
-
- },
- {
- id: 'evm-program',
- content:
- The Neon EVM program is a smart contract on
- the Solana blockchain. This allows Neon EVM to receive Ethereum-like transactions and
- process them on Solana according to Ethereum rules. Ethereum transactions going through
- Neon EVM, called Neon Transactions, are used as inputs for the targeted Neon clients
-
- },
- {
- id: 'neon-evm',
- content:
- Neon EVM facilitates the usage of Ethereum tooling
- by dApp developers to scale and access liquidity on Solana.
- Neon EVM offers Ethereum ecosystem dApp developers increased
- throughput and swift block time on Solana, with low gas prices
- and no need for changing code – anyone can run Ethereum contracts
- on Solana with Neon EVM
-
- },
- {
- id: 'tracing-api',
- content:
- Tracing API is an extension for Neon Proxy. For historical requests,
- Neon Labs implemented a Tracing API to help developers better test,
- debug, and understand their smart contracts on Neon EVM. The API will
- give developers a full externality trace on any transaction executed
- on the chain. They’ll be able to rerun historic transactions, run new
- transactions on historic states, and analyze the state of the blockchain
- after the execution of each instruction. More details are available
- in
- our blog
-
-
- },
- {
- id: 'oracles',
- content:
- Oracles provide a way for the decentralized Web3 ecosystem to access price
- feeds and other external (off-chain) data sources. Neon EVM supports querying data from Solana
- deployed Oracles:
-
-
-
- Chainlink
-
-
-
-
- Pyth
-
-
-
-
- },
- {
- id: 'tokens',
- content:
- Tokens — on Neon EVM you can use:
-
-
-
- NEON token
- as a gas
-
-
-
- ERC-20 with SPL
- under the hood
-
-
-
- NeonPass
- to transfer tokens between Solana and Neon EVM
-
+
+
+
+
-
-
+2. Wallet connection issues
+
+ 
-
| wNEON | `0x202C35e517Fa803B537565c40F0a6965D7204609` | |
+| 
| wSOL | `0x5f38248f339Bf4e84A2caf4e4c0552862dC9F82a` | `So11111111111111111111111111111111111111112` |
+| 
| USDC | `0xEA6B04272f9f62F997F666F07D3a974134f7FFb9` | `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` |
+| 
| USDT | `0x5f0155d08eF4aaE2B500AefB64A3419dA8bB611a` | `Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB` |
+| 
| WETH (Wormhole) | `0xcFFd84d468220c11be64dc9dF64eaFE02AF60e8A` | `7vfCXTUXx5WJV5JADk17DUJ4ksgau7utNKj4b963voxs` |
+| 
| WBTC | `0x16a3Fe59080D6944A42B441E44450432C1445372` | `3NZ9JMVBmGAqocybic2c7LQCJScmgsAZ6vQqTDzcqmJh` |
+| 
| LST | `0x14CCfFC97aC156A7f1E3183adAa8E7CC888AD162` | `LSTxxxnJzKDFSLr4dUkPcmCf5VyryEqzPLz5j4bpxFp` |
+| 
| JitoSOL | `0xFA8fB7e3bd299B2A9693B1BFDCf5DD13Ab57007E` | `J1toso1uCk3RLmjorhTtrVwY9HJ7X8V9yYac6Y7kGCPn` |
+| 
| mSOL | `0x6EFFb385713f22df4846d8156451a5efEC22a4c8` | `mSoLzYCxHdYgdzU16g5QSh3i5K3z3KZK7ytfqcJm7So` |
+| 
| Bonk | `0xD4B6520f7Fb78E1EE75639F3376c581a71bcdb0E` | `DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263` |
+| 
| MELL | `0x26320e7ffd9be68ca61c1C75b3Be4aAb0AA98E1f` | `MELLd8PyFoeNW3D5VaUe7L96eZeihtrzgLWrbKz5DR2` |
+| 
| MNGO | `0x6d12eAA69f8e4902D3F83d546B31F7318717014C` | `MangoCzJ36AjZyKwVj3VnYU4GTonjfVEnJmvvWaxLac` |
+| 
| 2080 | `0x96e636d3Ef60ee9745945120010c73619144632C` | `Dwri1iuy5pDFf2u2GwwsH2MxjR6dATyDv9En9Jk8Fkof` |
+| 
| PYTH | `0x0575dD4AFD93B7522fEE4e0179f243ecA3856137` | `HZ1JovNiVvGrGNiiYvEozEVgZ58xaU3RKwX8eACQBCt3` |
+| 
| BLZE | `0x09F8A075D6fca984EA0bAda25A64326DF00691A4` | `BLZEEuZUBVqFhj8adcCFPJvPVCiCyVmh3hkJMrU8KuJA` |
+| 
| JSOL | `0x7b9f9033afcf602b556a7aeac5871a52b56a06ee` | `7Q2afV64in6N6SeZsAAB81TJzwDoD6zpqmHkzi9Dcavn` |
+| 
| CGT | `0x9950ef047D87599EB28bF5E9Fc7F63cEd1b5F4AE` | `5qkTJu3hVd3SYToWpyHUmGfiLR48jj9oSz1WniV1UcgS` |
+| 
| JUP | `0x9F0fCE2AB962984b1EE50108A8510eA190BeEb8d` | `JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN` |
+| 
| $WIF | `0xF86934c2b05c31f3bBE3BCd6E3a8aA7790cAd9c1` | `EKpQGSJtjMFqKZ9KQanSqYXRcF8fBopzLHYxdM65zcjm` |
+| 
| WEN | `0xc61e8aB62666D25F0854C5723587507A7E92E289` | `WENWENvqqNya429ubCdR81ZmD69brwQaaBYY6p3LCpk` |
+| 
| POPCAT | `0xb89c62e960457d1d2c5f20135bedfd215d2466de` | `7GCihgDB8fe6KNjn2MYtkzZcRjQy3t9GHdC8uHYmW2hr` |
+| 
| WHALE | `0x663572b924db12e0e3822c6160df29154630c8e3` | `9uhHjyfc5tKdaZnjstLLKoLGcF889ub8zX9wtwhtzgK6` |
+
+
+ {description &&