Skip to main content

ERC-20 for SPL Tokens

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.

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:

LocationFactory Contract address
Devnet0xF6b17787154C418d5773Ea22Afc87A95CAA3e957
Mainnet0x6B226a13F5FE3A5cC488084C08bB905533804720
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.

ERC-20 Factory Contract

The ERC-20-for-SPL Factory Contract 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.

Depending on the method called and the arguments passed to this contract, two variants of the deployment may be created and registered:

ERC-20-for-SPL

The ERC-20-for-SPL variant 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.

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.

ERC-20-for-SPL-Mintable

The ERC-20-for-SPL-Mintable variant 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.

Contract signing

Depending on which output you need to construct, you will sign with different accounts, as shown in the table:

| 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) |

Restrictions

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.

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(
<!-- string memory _name,
string memory _symbol, Is this to be removed for non-mintable?? -->
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.

Was this page helpful?