diff --git a/docs/architecture/neon_evm_arch.md b/docs/architecture/neon_evm_arch.md index f1ce1437..276f6f14 100644 --- a/docs/architecture/neon_evm_arch.md +++ b/docs/architecture/neon_evm_arch.md @@ -41,19 +41,19 @@ An application that has an EVM (Solidity, Vyper, etc.) bytecode contract loaded 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. ### Neon Web3 Proxy (proxy) -The software that an operator uses to do their job. Although the proxy is not a mandatory component in the Neon EVM architecture (for example, proxy logic can be implemented inside a client's browser), implementing it as a separate component can speed up transaction processing. In the Neon EVM mainnet, the proxy must provide multithreading to work in parallel. +The software that an operator uses to do their job. Although the proxy is not a mandatory component in the Neon EVM architecture (for example, proxy logic can be implemented inside a client's browser), implementing it as a separate component can speed up transaction processing. In the Neon EVM Mainnet, the proxy must provide multithreading to work in parallel. 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-trxes are signed by an operator. The Neon transaction text is loaded from the received S-trexes 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-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. -More details on how the proxy converts a N-trx to multiple S-trxes 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-trx to multiple S-trxs 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: * 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: - * The Neon EVM operator account from whom the given amount in SOL tokens should be withdrawn for the execution of the transaction + * The Neon EVM operator account from which the given amount in SOL tokens should be withdrawn for the execution of the transaction * The Neon EVM operator account where a payment is sent for the job done in tokens specified by the user * The Neon EVM account to deposit funds to be spent for iterative execution of a transaction * A list of accounts that are participating in the execution of Neon transactions (formed according to Solana rules) @@ -61,7 +61,7 @@ Below is a list of the main Neon Web3 Proxy features that are implemented in the * Executing read-only Solidity methods of contracts * Providing a method for linking accounts from SPL token contracts to ERC-20: an SPL wrapper to access SPL token contracts via Neon transactions * Giving users a method to switch a token to be used for gas payment - * Giving users a method to execute an Neon transaction without a test run. + * Giving users a method to execute a Neon transaction without a test run. ### Neon EVM An Ethereum Virtual Machine compiled into the Berkeley Packet Filter bytecode of a virtual machine running on Solana. Neon EVM is configured using a multisig EVM account that resembles a decentralized Neon EVM governance. Participants of the multisig EVM account (actors) can change the Neon EVM code and set up Neon EVM parameters. @@ -71,7 +71,7 @@ Governance participants perform the following functions: * Updating contracts * Adding functionality * Eliminating shortcomings in the program code - * Changing settings parameters such as the fee value, opening a new balance, the Mn value, the maximum number of iterations, etc. + * Changing settings parameters such as the fee value, opening a new balance, the Mn value and the maximum number of iterations. ### ERC-20 TKN @@ -84,12 +84,12 @@ Solana Program library (SPL) token is a contract that contains a system register This is a blockchain containing a stream of blocks. It stores a block-log of completed operations. It also contains the current Solana state, where the results of transactions, accounts, and public keys are stored. There are also two balances: one for ETH tokens, and another for the token that the transaction will be paid in. ### ERC-20 Wrapper -This is a separate contract developed using the ERC20 standard. It contains maps with user balances. Although this contract is hosted inside Neon EVM, it is completely standalone and independent. +This is a separate contract developed using the ERC-20 standard. It contains maps with user balances. Although this contract is hosted inside Neon EVM, it is completely standalone and independent. -A user can create a contract supporting the ERC20 standard for a specific token and generate the required number of tokens (coins). These tokens will only be liquid within Neon EVM. For these coins to be liquid in Solana, the SPL Token and ERC-20 TKN contracts must be interoperable. This function is performed by the ERC-20 Wrapper contract. +A user can create a contract supporting the ERC-20 standard for a specific token and generate the required number of tokens (coins). These tokens will only be liquid within Neon EVM. For these coins to be liquid in Solana, the SPL Token and ERC-20 TKN contracts must be interoperable. This function is performed by the ERC-20 Wrapper contract. -## Using Economics to Motivate Operators +## Using Economics to Motivate Operators Conventionally, the processing of a transaction is divided into several steps (iterations). The number of steps may vary depending on the number of operations required to complete the transaction. The next step starts only after the previous step has been successfully completed (Fig. 2). @@ -103,19 +103,19 @@ Fig. 2 -A transaction is considered to be successfully completed if the "Final" step finishes. The execution of the transaction should not go beyond the allotted number of Mn blocks. In other words, the operations performed at all steps must be completed within the Mn period, or the transaction is considered incomplete. +A transaction is considered to be successfully completed if the "Final" step finishes. The execution of the transaction should not go beyond the allotted number of Mn blocks. In other words, the operations performed at all steps must be completed within the Mn period or the transaction is considered incomplete. A user who forms a transaction will indicate an operator (proxy) within it. That operator will be responsible for the execution of the transaction. Each operator has a deposit account in Neon EVM. These accounts belong to Neon EVM, so no one can withdraw funds from the deposit account until the finalization step has been completed. Before processing a transaction, Neon EVM debits the funds from the operator account (op-acc) and transfers them to the operator's deposit account (dep-acc). -If for any reason (such as lack of funds), an operation is not performed at a given step, the next operator starts processing the transaction from the current step. This operator does not deposit any funds for the remaining steps. If they also do not complete all of the remaining steps, this process is passed to the next operator. At the "Final" step, a transaction is created that withdraws funds from the deposit in full and credits them to the operator who completed this last step. This method of implementation moivates not only the client, but also any operator involved in processing the transaction to have a vested interest in making sure that the transaction is successfully completed. +If for any reason an operation is not performed at a given step (such as lack of funds), the next operator starts processing the transaction from the current step. This operator does not deposit any funds for the remaining steps. If they also do not complete all of the remaining steps, this process is passed to the next operator. At the "Final" step, a transaction is created that withdraws funds from the deposit in full and credits them to the operator who completed this last step. This method of implementation motivates not only the client, but also any operator involved in processing the transaction to have a vested interest in making sure that the transaction is successfully completed. **Example:** -*Step 1*: transferring funds to a deposit. -*Step 2*: blocking an account. -*Additional Steps*: other actions. -*Final Step*: the deposit is returned to the operator's account (op acc). The results of the transaction have already been reflected in the Solana state. +*Step 1*: Transferring funds to a deposit. +*Step 2*: Blocking an account. +*Additional Steps*: Other actions. +*Final Step*: The deposit is returned to the operator's account (op acc). The results of the transaction have already been reflected in the Solana state. -In the Neon EVM settings, there is a limit on the number of blocks (Mn) that can be processed during a transaction. By default, the Mn value is 1. that is, a transaction must be completed during the processing of one block. There is also a limit on the number of steps (iterations) that can be taken to complete a transaction. The Mn value and the number of iterations are set by a multisig account. The number of steps is also limited by a user’s fund balance. +In the Neon EVM settings, there is a limit on the number of blocks (Mn) that can be processed during a transaction. By default, the Mn value is 1. That is, a transaction must be completed during the processing of one block. There is also a limit on the number of steps (iterations) that can be taken to complete a transaction. The Mn value and the number of iterations are set by a multisig account. The number of steps is also limited by a user’s fund balance. At every step, the "Continue" operation checks whether or not this is the last step in the transaction execution. @@ -123,18 +123,18 @@ At every step, the "Continue" operation checks whether or not this is the last s Solana's entire history is stored in the Solana state. Using this history, the operator can obtain the necessary information about all transactions related to Neon EVM. The proxy can track incomplete transactions in this history: transactions that can be continued by another operator. The operator who wishes to continue executing the unfinished transaction must first re-sign it with their key. If the number of blocks does not exceed Mn since processing was initiated by the previous operator, the signature of the initial operator is kept. If the number of blocks exceeds Mn, the transaction can be re-signed by any operator. ### Special Cases -*Case 1*: one of the initial and mandatory operations is blocking an account. That is, the execution of other transactions is blocked for an amount of time. +*Case 1*: One of the initial and mandatory operations is blocking an account. That is, the execution of other transactions is blocked for an amount of time. If an operator is interested in reducing this amount of time, they must complete a transaction in Mn blocks, otherwise another operator will perform this transaction. -For example (see Fig. 2), to go from Step 1 to Step 2), Operator 1 must process Mn blocks. During this time, the "Continue" operation will not be available to other operators. If Operator 1 is unable to complete a transaction during the processing of Mn blocks, this transaction remains incomplete. The funds on the balance are burned out. +For example (see Fig. 2), to go from Step 1 to Step 2, Operator 1 must process Mn blocks. During this time, the "Continue" operation will not be available to other operators. If Operator 1 is unable to complete a transaction during the processing of Mn blocks, this transaction remains incomplete. The funds on the balance are burned out. -Therefore, it is in every operator’s best interest to useg high-speed resources. +Therefore, it is in every operator’s best interest to use high-speed resources. -*Case 2*: a transaction cannot be completed if an error occurs. -If Step 1 is completed, and "Cancel" occurred in Step 2, the funds are not returned to the operator. Funds cannot be withdrawn from a client for the partial execution of a transaction. The funds are also not returned to the client. In this case, the funds on the deposit will be burned. To avoid losing funds, the operator is compelled to complete the transaction in full, not in part. +*Case 2*: A transaction cannot be completed if an error occurs. +If Step 1 is completed and "Cancel" occurred in Step 2, the funds are not returned to the operator. Funds cannot be withdrawn from a client for the partial execution of a transaction. The funds are also not returned to the client. In this case, the funds on the deposit will be burned. To avoid losing funds, the operator is compelled to complete the transaction in full, not in part. -*Case 3*: Insufficient funds. Before executing a transaction, two things are checked: the user’s account balance , and whether the gas limit will be exceeded. If there is a shortage of funds during any of the steps, the transaction is labelled as "Fail" and funds are debited from the user's account and transferred to the operator's account. +*Case 3*: Insufficient funds. Before executing a transaction, two things are checked: the user’s account balance, and whether the gas limit will be exceeded. If there is a shortage of funds during any of the steps, the transaction is labelled as "Fail" and funds are debited from the user's account and transferred to the operator's account. ## Transferring Tokens Inside Solana The ERC-20 wrapper, a special dApp (contract) with token balances, has been created. Application users know the address of this dApp. To transfer funds, they need to contact this dApp address and specify an account and the amount of funds to transfer. The transfer will take place within this contract. @@ -153,7 +153,7 @@ Fig. 3 There are two user balances: * User SPL Balance, whose tokens are traded within Solana. - * User ERC20 Balance, whose tokens are traded within Neon EVM. + * User ERC-20 Balance, whose tokens are traded within Neon EVM. The ERC-20 wrapper allows users to transfer their SPL tokens on the ERC-20 Balance, exchange them for tokens they need, and withdraw them back. Thus, a user can create a token inside Neon EVM and transfer any number of coins from User SPL Balance to User ERC-20 Balance. Then, using EVM contracts, they can use these coins. @@ -162,20 +162,20 @@ The ERC-20 wrapper allows users to transfer their SPL tokens on the ERC-20 Balan **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. -This will cause all N-trxes 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-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. **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. -The Neon client does not have an option to select a type of token for payment, and can only operate with ETH. Therefore, the storage of funds is implemented in the user's Solana state. The Neon account (user-acc) has a separate field that specifies the type of token. After a user specifies a type of token, this type will be indicated in the account field of this user. Having this information, Solana can use the ERC-20 wrapper to convert tokens. +The Neon client does not have an option to select a type of token for payment, and can only operate with ETH. Therefore, the storage of funds is implemented in the user's Solana state. The Neon account (user-acc) has a separate field that specifies the type of token. After a user specifies a type of token, this type will be indicated in the account field of this user. With this information, Solana can use the ERC-20 wrapper to convert tokens. An operator creates a deposit account for the transaction. It is possible to create a pool of such deposit accounts so that the ERC-20 wrapper logic will select the desired transaction from this pool rather than creating a queue for the payment of funds to the operator. -## Transferring tokens between Solana and Ethereum +## Transferring Tokens Between Solana and Ethereum The ERC-20 wrapper allows users to manipulate balances inside SPL tokens. The user runs an application inside 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 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 also can 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. +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. 4 shows the process for transferring tokens between Solana and Ethereum. @@ -194,9 +194,3 @@ Ethereum tokens are generated in accordance with the ERC-20 standard. Therefore, 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/faq/what-is-neon.md b/docs/faq/what-is-neon.md index 9d7a6b1d..53f69c05 100644 --- a/docs/faq/what-is-neon.md +++ b/docs/faq/what-is-neon.md @@ -20,7 +20,7 @@ The Neon Web3 Proxy allows users to access Solana via the existing Ethereum app ### 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 Neon EVM program on Solana. +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 @@ -42,4 +42,4 @@ NFTs (ERC-721 and ERC-1155) aren't supported right now but will be supported in 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 exists for Solana programs. The ERC-20/SPL bridge will allow you to transfer such tokens from an ERC-20 contract to SPL token accounts. +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/token_transferring/neonpass_usage.md b/docs/token_transferring/neonpass_usage.md index 27fe48fb..2bc15d07 100644 --- a/docs/token_transferring/neonpass_usage.md +++ b/docs/token_transferring/neonpass_usage.md @@ -3,29 +3,29 @@ title: Transferring SPL Tokens --- ## Overview -This guide provides instructions on how to transfer ERC-20 tokens between Solana and Neon EVM using Neon Pass. 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 fee in NEON) and another for Solana (requires fee in SOL). Therefore, you will have to pay 2 fees. +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 to transfer ERC-20 tokens, you have to fulfill the following requirements: +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. - * Neon Pass uses [Metamask](about/terminology.md#metamask) and [Phantom](about/terminology.md#phantom) — two popular non-custodial browser based wallets. - * The Neon Pass application is deployed in the browser to which your wallets are attached. + * 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. ## 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. Initial conditions: - * Your Neon EVM account contains non-zero USDT-balance. + * 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 non-zero SOL-balance to pay fee. + * Your Solana account contains a non-zero SOL-balance to pay the fee. -Transferring tokens using Neon Pass takes 3 stages: - * Source — connecting the Metamask wallet to Neon Pass and providing access to the sender's account balance. - * Target — connecting the Phantom wallet to Neon Pass and providing access to the recipient's account balance. - * Confirmation — signing the transaction and checking the result of transferring tokens. +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. -### The Source stage +### The Source Stage -Go to the [Neon Pass](https://neonpass.live/) page in the browser to which the Phantom and Metamask wallets are attached. Make sure that the icons of these wallets are displayed at the top right. 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. +Go to the [NeonPass](https://neonpass.live/) page in the browser to which the Phantom and MetaMask wallets are attached. Make sure that the icons of these wallets are displayed at the top right. 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.
@@ -33,7 +33,7 @@ Go to the [Neon Pass](https://neonpass.live/) page in the browser to which the P
-Click `Connect Wallet` to connect your Metamask wallet to the Neon Pass 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. Upon successful connection of the Metamask wallet to Neon Pass and access to your account balance, the inscription `Connect Wallet` will change to the public key of your account in Neon EVM. +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. 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.
@@ -41,7 +41,7 @@ Click `Connect Wallet` to connect your Metamask wallet to the Neon Pass app. The
-On the Neon Pass 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). +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.)
@@ -51,9 +51,9 @@ On the Neon Pass screen, click `Select a token`. In the list that appears, selec Click `Next` to continue the token transfer procedure and proceed to the Target stage. -### The Target stage +### The Target Stage -The `Target` windows will appear on the Neon Pass screen. Click `Select Wallet` to connect your Phantom wallet to Neon Pass. +The `Target` windows will appear on the NeonPass screen. Click `Select Wallet` to connect your Phantom wallet to NeonPass.
@@ -61,9 +61,9 @@ The `Target` windows will appear on the Neon Pass screen. Click `Select Wallet`
-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 non-zero SOL balance in your account to pay fee (there are 10 SOL in our example). +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.) -Upon successful connection of the Phantom wallet to Neon Pass 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 Neon Pass 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. +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.
@@ -73,7 +73,7 @@ Upon successful connection of the Phantom wallet to Neon Pass and access to your Click `Next` to continue the token transfer procedure and proceed to the Confirmation stage. -### The Confirmation stage +### The Confirmation Stage Read the details of the upcoming transfer of tokens and click `Confirm`. @@ -83,7 +83,7 @@ Read the details of the upcoming transfer of tokens and click `Confirm`.
-Metamask window will pop up on the Neon Pass 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. +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.
@@ -99,7 +99,7 @@ You should also approve the transaction in the Phantom window, which will displa
-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 Neon Pass. +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.
@@ -117,4 +117,4 @@ The `Token Balance Change` tab shows the change in balances upon completion of t ## Conclusion -We examined the use of Neon Pass 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 Neon Pass 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 Neon Pass. +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.