# Break the Runtime Barrier: EVM dApps That Talk to Solana - Julia Gallen | Neon EVM

- Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community)
- Date: 2025-10-07
- Duration: 20:53
- Topics: People & Blogs
- Watch: https://streameth.org/watch/yt-FhuMAgsMA6I
- YouTube: https://www.youtube.com/watch?v=FhuMAgsMA6I

## Description

Break the Runtime Barrier: EVM dApps That Talk to Solana - Julia Gallen | Neon EVM

## Transcript

Uh okay uh just to remind what we do uh we are at the hackathon and uh if you don't know uh where to find the bounty that newm has uh this is the uh taikai page where you can find it just click on newm and this is the description of the bounty if uh you haven't seen it yet. Uh so the task will be uh to create a DI use case of neonvm's composibility libraries that I'm going to talk about today. And we see DI in the broadest sense possible. Whenever you are going to interact with Salana through composibility libraries created by neonvm you will probably face with the SPL tokens and uh whenever you interact with the SPL tokens we see it as a D5 use case. So whatever you create with a composability feature is going to be okay for to submit for this bounty task. And uh so the uh task will be to create a use case using these composability libraries. And uh some of the examples are a cross-chain lending or borrowing platforms. These are clear defy, a composable radium amm, a arbitrage bot for example, or an ERC204 SPL launcher. uh ERC204 SPL is a hybrid token created by neon which is a wrapper a Salana wrapper for ERC20 token and you can go about it by either looking at the examples that we provide in our repos and you can find them here under neon repo and uh this is the one here you can simply start by forking one of these uh repositories and uh uh if you want for example a memecoin launchpad uh uh use case or if you want to replicate a flash loan use case then these are the ones that we can get you started with uh with this repository and uh when so basically yes you can start from uh here and you're going to have a working uh start of this uh composability use case. uh we also have uh an npm package which you can simply install and start working from there. But uh all this um is about composibility created by neonvm to link Ethereum and Salana and let me go right into that by um talking yes about neonvm first. So this was just a kind of an organizational introduction to what you can do in this hackathon and uh uh neonvm uh is uh a salana network extension that breaks the runtime barrier between EVM dabs and salana. Uh so at uh neon we try to take the best of the two ecosystems and take the EVM benefits which are for EVM developers obviously that the um Ethereum RPC compatibility is available all the familiar uh tooling and all the languages that they know are available uh for them to use to be able to connect to Salana's liquidity and user base through NeonVM. So we take the best of the two worlds from neonvm everything is known and familiar and you can use ethereum RPCs and from Salana we take parallel execution low gas fees and of course users a growing Solana ecosystem uh so what you you might think that new VM might have something to do with bridges or rollups but it couldn't Further from the truth, Neonvm is a Salana network extension. It's a program on Salana in other words and it consists of two main things uh neon proxy and neonvm program. Neonroxy prepares the transactions offchain. It wraps Ethereum like transactions into Salana style transactions by adding them mostly into the data field of the Salana transactions. It provides Ethereum RPCs and uh basically it prepares this transaction that goes into Salana and when it goes into Salana it hits the neonvm program. Neonvm program picks this transaction up and executes this transaction directly and natively on Salana without bridges or without anything else. So it's just since it's just an EVM a virtual machine on Salana it can do this uh directly and natively. So there is no overhead and yeah this is what I was talking about. So the Ethereum like transaction with nons with a gas price with the values and the data goes directly into the data field of a Salana transaction and um neonvm also packs the address list into the program index and the accounts list uh into the accounts list section. So uh under the hood is uh neonvm also creates all these accounts that are needed for a salana transaction to go through. As you probably know the accounts are a whole big thing on Salana. Unlike uh Ethereum where we have an externally owned account and contracts on Salana basically everything is an account. Token is an account. Uh balance is is an account. So um everything should go into the accounts list and uh one of the things that is uh that neonvm does thanks to this composability feature that I'm going to talk about is create all these uh accounts that are needed for Salana to execute transactions and packs them into this Salana style transaction in the accounts list. So um how does it do that? Neonvm has um composability feature which uh includes composability libraries and pre-ompiled contracts that abstract away all this complicated Salana architecture including these accounts and um basically these are the uh libraries that are available at the moment and they help uh EVM projects interact with these Salana programs. So these are native and custom Salana programs that you can interact with from EVM dab if you use composability libraries and these libraries uh they all called the same as these Salana programs. So the system program library, the SPL token program library, the associated token library and also metaplex and radium libraries. And uh with uh these composibility libraries that you import into your smart contracts that you write in solidity, you can access all these Salana programs. And um so the uh composability feature also consists of pre-ompiled contracts that help us execute the transactions on Salana in Salana runtime. And these uh composibility pre-ompiled contracts are different. We have several ones but this one is the main one. So if you are going to build uh with composibility feature, you are going to execute your transactions through this pre-ompiled contract which uh first of all uh prepares a list of um addresses uh with a payer account and uh uh Salana addresses for neon address that corresponds to the neon address and it's going to mainly execute the instruction with a call to salana uh through and return the data on this instruction. instruction but I'm going to show you an example a bit later. This is just the interface uh for the uh main pre-ompile that we are going to use. Uh so uh these pre-ompiles uh basically they allow you to access Salana state create accounts and execute transactions on Salana and uh this is again happens through the I call Salana pre-ompile and another thing uh with this pre-ompile you can batch uh you can pack several uh functions into um several instructions uh for example uh like hero for deploying a new SPL token and minting it on Salana into a batch and send it as one transaction through neonvm. And as for composibility libraries, these are the things that uh composability libraries contain and uh they are all built in the same way. they they are going to have a file well uh a file with a helper functions uh that are going to format the instructions in a specific way that Salana expects them. uh then there is a file with a getter functions where you can pull the data uh to get into your front end for example and uh then there are custom errors so that you can handle the errors and debug uh and on Salana it's done usually completely different but here with this library you're going to get errors that you can actually handle from solidity contracts and uh also there are salana constants for program ids account public keys and uh accounts for rent management. You don't have to deal with Salana's system for rent management because one of these libraries also calculates the rent exempt fee that you are going to get for two years and u yeah basically you don't need to go into Salana architecture and think about uh the accounts you don't need to think about the uh rent uh but because this all happens within composibility libraries is and uh the flow uh is going to be very simple. you have a caller contract where you import a composibility library or rather many composibility libraries at the same time and uh from that you send a call to a pre-ompiled contract I call Salena which natively executes the instructions and uh the caller contract has um is an account owned by neonvm program on salana so the ownership is going to be within in this contract and later when uh I'm going to show you how to deploy an SPL token we are going to keep ownership within the uh caller contract then you can obviously delegate the ownership and pass the ownership to another um account but uh when we are talking about this cluster of functions this cluster of instructions uh at this point the owner is the um contract that uh then it can request a payer account to pay for execution costs on Salana. Uh as I've told you before, rent is going to be covered from the payer account and the contract is going to request that but it won't have to calculate it manually. Then uh the contract owns the accounts created on Salana. uh all the uh system accounts token mints are going to be owned again by this um account uh by this contract and uh yes it must implement authentication logic to manage access to those accounts and uh about the current libraries as I've told you before we have five of them and uh three are uh communicating with the native Salana programs and four and one of them liradium program communicates with uh Radium Dex. So if you're building a DI use case, that's probably the one you're going to be most interested in. And if you're going to be launching, for example, a memecoin launchpad starting from the example in our libraries and in our uh uh GitHub repositories, then you'll be able to connect to Radium CPMM pools with concentrated liquidity, which are basically the same thing as unis swap v3. So if you have an idea for uh unis swap v3 you can basically do the same thing on salana using this lib radium program library uh radium program library. Uh so but now I want to uh spend uh several minutes talking about the spl token program library because it's kind of the basis of uh what's going to happen if you interact with SPL tokens from uh solidity contracts using the composibility feature. Uh so you have uh these basic instructions to interact with the token. You can uh mint, you can uh um transfer, you can approve or evoke authority, burn and close account. And uh an example for um interacting with this SPL token library for the caller contract would be a very basic contract uh with a transfer function here where you basically uh create um derive the PDA account uh from the address from the Ethereum address that you provide uh with a message sender. Then you derive the sender's token account from the uh sender account and the token mint account. So everything is an account even tokens. That's why we need to derive this many accounts. Uh then you format instructions with the uh sender recipient and amount. uh then you basically prepare build the instruction um uh prepare and build and execute with the call to I call Salana pre-ompile and when you're going to open the um composibility libraries GitHub repo you're going to see these examples of color contracts to different uh programs on Salana they are all formatted and they're all structured in the same way where you basically get the accounts, you uh build the instruction and you send the instruction to the pre-ompile. Now this is uh an example of how to deploy an SPL token on Salana using hard hat. Uh so yeah a good thing about neonvm is that you can use all the familiar EVM tooling including hard hat and write in solidity and here is how you deploy an SPL token. Here we actually deploy the caller contract where which has an imported SPL token library and all these functions for uh deploying the token. And we basically just specify the seed and the nine decimal precision which is typical to Salana. And uh uh with a method create initialize token mint uh we pass the same seed uh that we passed before. And uh basically we call this uh caller contract and uh we deploy the mint uh deploy the token. Uh so and then uh once we deploy the token we need to create an account that's going to hold uh this token and uh as I've told you before the ownership is at the neon program that's why we leave the owner field empty we zero it out at the first and the second row and uh we get the neon address and the arbitrary token account to which we are going to send this token. uh which is going to own this token mint. And then once we have uh the token and once we have the balance that is going to hold these tokens, we can go ahead and mint actual tokens to this uh balance account. And we do this uh with a seed that we provide before. Uh then the recipient token account it's not a transfer. So this means that recipient is just the token account that we just created and an amount and basically the same functions but the same function only for transfer. Uh we use a transfer method with uh a token mean field a recipient and an amount to transfer. So uh this is all very uh simple uh and uh um basically this is how you can um deploy a token and mint tokens to an account using a composibility library and uh I've told you that we have these uh repositories with the libraries and the caller contracts. So uh this is one of those libraries where yeah these are all of them actually and here you can see this call SPL token program uh call a contract which um we just looked at the snippets from it uh but here you can see that it gets all these helper libraries. Oh it's too small. Okay. and the I call Salana pre-ompile and then uh we just uh create this token mint uh then we build the instruction or the uh yes the contract yes we prepare the instruction and executed uh through the I call Salana pre-ompile and the same for each of the functions that uh we are going to have here so again for the initializing arbitrary token account to which we have sent uh the mints. Again we um first define the um owners, we define uh the accounts uh then we build the instruction uh we format it with the help of these methods that we get from the libraries and we send the in the instruction to the I call Salana pre-ompile. So this is going to happen for every uh one of these um functions. So basically as you can see you write solidity code with uh the same functions that you would do normally for an EVM app but uh with by sending uh the instructions to the I call Salana pre-ompile and uh using the libraries to format the instruction you send them to be executed on Salana. Uh I think this is all I wanted to tell you and uh again this is where you can find the um bounty task for for this thing and uh don't hesitate to contact me. Uh I'm going to uh I hope I'm going to be able to tell you in more detail everything about this composibility feature. Thank you so much for your time and attention. I hope you have a great day.