Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
SEPOLIA FAUCET
Get free Sepolia ETH.
Start Building Today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Build with Alchemy's
Gas Manager & Bundler APIs
Learn
Solidity at
Alchemy
University
Get started today
Build with Alchemy's
Gas Manager & Bundler APIs
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Solana
ACCOUNT MODEL OVERVIEW

What is the Solana Account Model and how does it work?

Learn About the Solana Account Model, the Different Account Types, and How They All Work Together
Last Updated:
January 26, 2023
Table of Contents
Table of Contents
Table of Contents

{{get-started-solana}}

Everything on Solana can be considered an account, and accounts are the way the protocol “organizes” the data on the blockchain. This article will provide a holistic overview of the Solana Account Model including types and categories, account components, and the notion of ‘rent’.

What is a Solana account and how does it work?

Solana accounts can be thought of as storage buckets, capable of holding every data type: from tokens such as SOL to a program’s state variables (e.g. integers, strings, public keys), and even entire programs themselves. Every account has a specified owner, and a single owner can own many different accounts.

The Account Model is often compared to a computer file system:

Computer file and a Solana account

What are Solana account types?

Solana account types are of two main types of accounts: executable and non-executable. This is because Solana programs do not store state like Ethereum smart contracts do, so it needs to separate both type of actions.

What are executable programs?

Executable programs are comprised of immutable code that own and create other accounts that store the state. That code is written in a language like Rust and then compiled to eBPF, which is a form of bytecode.

The most common example of executable programs is the core System Program of Solana, responsible for the creation of the accounts (wallets) that people use to access their tokens and NFTs.

What are non-executable programs?

Non-executable programs are “storage” accounts which contain all other types of data like program variables, token balances, NFTs, fungible currencies, etc. Through non-executable accounts, the protocol reflects the state changes that have occurred after every transaction.

Ethereum Smart Contracts vs. Solana Programs

A smart contract comes prebuilt with a special compartment called “storage” where its state variables are stored. Smart contracts then uses its executable code to modify those state variables. An Ethereum contract can be seen as a unified place for executable and non-executable code to co-exist.

Let’s take the USDC token for example. Its contract contains a mapping called “balances” which maps a user’s address to his own USDC amount. Upon sending or receiving USDC tokens, the contract reflects the changes by itself thanks to its executable code.

Solana handles this in a different manner. There is a USDC token program that creates a new account for each individual token holder. These accounts store the holder’s available USDC amount. When a user propagates a transaction, the USDC Token account looks for the associated token accounts of the users that want to make the exchange and then reflect the change in them.

Solana's Associated Token Account Structure

What are Solana account categories?

Executable and non-executable accounts can be divided into several additional categories such as native programs, program accounts, and data accounts.

What are executable native programs?

Executable native programs are “native” to the Solana ecosystem and are responsible for tasks like maintaining and running the validator nodes. The most well-known example of this type is the System Program, which is in charge of creating new system accounts (what we commonly know as “wallets”), transfer of SOL, etc. Other instances of Native Programs are the Stake Program, which is responsible for the staking mechanism, and the BPF Loader, which is similar to Ethereum’s EVM.

What are executable program accounts?

Executable program accounts are pre-made Solana programs that create and store other programs. A good example of these is the Solana Program Library (SPL) — a collection of programs that support a number of on-chain activities, including creating, swapping, and lending tokens, generating stake pools, and maintaining an on-chain name service. A prominent representative of the SPL is the Token Program, which creates and manages tokens.

Solana’s USDC token is just a Token account, managed by the Token Program. However, the Token account does not store the users’ token balances. This is handled by a member of the third type of accounts: data accounts.

What are non-executable data accounts?

While the Native Programs and Program accounts are considered executables, data accounts are the opposite: they are a registry that reflects the state changes for specific programs and the Solana protocol as a whole.

Data accounts can be divided into:

  1. Token accounts - accounts created by the Token Program
  2. Associated Token Accounts (ATA) - accounts that store the token balances for each individual user
  3. System Owned Accounts - store data and allow for the signing of transactions

Token accounts represent each individual fungible currency (USDC, USDT, etc.), and contain basic information for the token like supply, number of decimals, name, etc. For each unique Token account a different associated token account (ATA) is generated. For instance, if you own both USDC and USDT, you have access to two ATAs that have been created by the USDC and the USDT Token accounts respectively.

Solana account types and categories

What are Solana account elements?

Each account element is a metadata set, so the protocol can easily understand the account’s type and additional information. Metadata consists of:

  • lamports - the account’s SOL balance, denominated in lamports where 1 lamport is equivalent to one billionth of a SOL token
  • owner - this is the address of the program that owns the account
  • executable - a boolean variable that indicates if the account contains executable code
  • data - the raw data byte array, stored in the account, be it storage variables or executable code
  • rent_epoch - indicates the next epoch at which the account will owe rent

The difference between an owner and a holder is that the owner is the program that controls the account and a holder is the user who holds the private key to the account. For example, the System Owned Account is owned by Solana’s Native System Program.

What is Solana account rent?

Every account pays a rent fee to use memory on the blockchain, and is a preventative measure to keep attackers from clogging the network by using all of its memory.

For a blockchain to satisfy all its users, it must include some kind of economic incentive. This applies especially to the validators, who supply their hardware and computational power to verify all the transactions. Validators need to maintain a working copy of all the state changes and receive rent as a reward.

An account that maintains a minimum balance equivalent to 2 years of rent fees is exempt. If not, it is charged when it is referenced by a transaction or at every epoch, which currently equates to two days. If an account does not contain the minimum amount of SOL to be rent exempt, its data is deleted from the chain.

How to Create a Solana Account

Creating a System Account on Solana is what Solana wallets do in the background each time a user creates a new “wallet”. A wallet creates a new account by generating a 64-byte keypair that lies on an ED25519 elliptic curve. The first 32 bytes are the private key, which is used when the user wants to create a transaction and interact with another account or program. The second set of 32 bytes is the public key of the wallet.

Start Building on Solana

The Account Model is the system that the Solana protocol uses to organize data. Accounts can be thought of as storage buckets, capable of holding everything- from raw data, code and state variables, to token balances, NFTs, etc. Accounts are of 2 main types: executable and non-executable.

To start building with Alchemy, open a free Solana developer account today!

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Solana
ACCOUNT MODEL OVERVIEW

What is the Solana Account Model?

Learn About the Solana Account Model, the Different Account Types, and How They All Work Together
Last Updated:
January 26, 2023
Last Updated:
March 14, 2023
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Table of Contents

Talk to an Expert

Learn how Alchemy's blockchain developer tools can help your business succeed in web3!
Valid number
Thank you! An Alchemy expert will be in touch with you shortly!
Oops! Something went wrong while submitting the form.

{{get-started-solana}}

Table of Contents

Everything on Solana can be considered an account, and accounts are the way the protocol “organizes” the data on the blockchain. This article will provide a holistic overview of the Solana Account Model including types and categories, account components, and the notion of ‘rent’.

What is a Solana account and how does it work?

Solana accounts can be thought of as storage buckets, capable of holding every data type: from tokens such as SOL to a program’s state variables (e.g. integers, strings, public keys), and even entire programs themselves. Every account has a specified owner, and a single owner can own many different accounts.

The Account Model is often compared to a computer file system:

Computer file and a Solana account

What are Solana account types?

Solana account types are of two main types of accounts: executable and non-executable. This is because Solana programs do not store state like Ethereum smart contracts do, so it needs to separate both type of actions.

What are executable programs?

Executable programs are comprised of immutable code that own and create other accounts that store the state. That code is written in a language like Rust and then compiled to eBPF, which is a form of bytecode.

The most common example of executable programs is the core System Program of Solana, responsible for the creation of the accounts (wallets) that people use to access their tokens and NFTs.

What are non-executable programs?

Non-executable programs are “storage” accounts which contain all other types of data like program variables, token balances, NFTs, fungible currencies, etc. Through non-executable accounts, the protocol reflects the state changes that have occurred after every transaction.

Ethereum Smart Contracts vs. Solana Programs

A smart contract comes prebuilt with a special compartment called “storage” where its state variables are stored. Smart contracts then uses its executable code to modify those state variables. An Ethereum contract can be seen as a unified place for executable and non-executable code to co-exist.

Let’s take the USDC token for example. Its contract contains a mapping called “balances” which maps a user’s address to his own USDC amount. Upon sending or receiving USDC tokens, the contract reflects the changes by itself thanks to its executable code.

Solana handles this in a different manner. There is a USDC token program that creates a new account for each individual token holder. These accounts store the holder’s available USDC amount. When a user propagates a transaction, the USDC Token account looks for the associated token accounts of the users that want to make the exchange and then reflect the change in them.

Solana's Associated Token Account Structure

What are Solana account categories?

Executable and non-executable accounts can be divided into several additional categories such as native programs, program accounts, and data accounts.

What are executable native programs?

Executable native programs are “native” to the Solana ecosystem and are responsible for tasks like maintaining and running the validator nodes. The most well-known example of this type is the System Program, which is in charge of creating new system accounts (what we commonly know as “wallets”), transfer of SOL, etc. Other instances of Native Programs are the Stake Program, which is responsible for the staking mechanism, and the BPF Loader, which is similar to Ethereum’s EVM.

What are executable program accounts?

Executable program accounts are pre-made Solana programs that create and store other programs. A good example of these is the Solana Program Library (SPL) — a collection of programs that support a number of on-chain activities, including creating, swapping, and lending tokens, generating stake pools, and maintaining an on-chain name service. A prominent representative of the SPL is the Token Program, which creates and manages tokens.

Solana’s USDC token is just a Token account, managed by the Token Program. However, the Token account does not store the users’ token balances. This is handled by a member of the third type of accounts: data accounts.

What are non-executable data accounts?

While the Native Programs and Program accounts are considered executables, data accounts are the opposite: they are a registry that reflects the state changes for specific programs and the Solana protocol as a whole.

Data accounts can be divided into:

  1. Token accounts - accounts created by the Token Program
  2. Associated Token Accounts (ATA) - accounts that store the token balances for each individual user
  3. System Owned Accounts - store data and allow for the signing of transactions

Token accounts represent each individual fungible currency (USDC, USDT, etc.), and contain basic information for the token like supply, number of decimals, name, etc. For each unique Token account a different associated token account (ATA) is generated. For instance, if you own both USDC and USDT, you have access to two ATAs that have been created by the USDC and the USDT Token accounts respectively.

Solana account types and categories

What are Solana account elements?

Each account element is a metadata set, so the protocol can easily understand the account’s type and additional information. Metadata consists of:

  • lamports - the account’s SOL balance, denominated in lamports where 1 lamport is equivalent to one billionth of a SOL token
  • owner - this is the address of the program that owns the account
  • executable - a boolean variable that indicates if the account contains executable code
  • data - the raw data byte array, stored in the account, be it storage variables or executable code
  • rent_epoch - indicates the next epoch at which the account will owe rent

The difference between an owner and a holder is that the owner is the program that controls the account and a holder is the user who holds the private key to the account. For example, the System Owned Account is owned by Solana’s Native System Program.

What is Solana account rent?

Every account pays a rent fee to use memory on the blockchain, and is a preventative measure to keep attackers from clogging the network by using all of its memory.

For a blockchain to satisfy all its users, it must include some kind of economic incentive. This applies especially to the validators, who supply their hardware and computational power to verify all the transactions. Validators need to maintain a working copy of all the state changes and receive rent as a reward.

An account that maintains a minimum balance equivalent to 2 years of rent fees is exempt. If not, it is charged when it is referenced by a transaction or at every epoch, which currently equates to two days. If an account does not contain the minimum amount of SOL to be rent exempt, its data is deleted from the chain.

How to Create a Solana Account

Creating a System Account on Solana is what Solana wallets do in the background each time a user creates a new “wallet”. A wallet creates a new account by generating a 64-byte keypair that lies on an ED25519 elliptic curve. The first 32 bytes are the private key, which is used when the user wants to create a transaction and interact with another account or program. The second set of 32 bytes is the public key of the wallet.

Start Building on Solana

The Account Model is the system that the Solana protocol uses to organize data. Accounts can be thought of as storage buckets, capable of holding everything- from raw data, code and state variables, to token balances, NFTs, etc. Accounts are of 2 main types: executable and non-executable.

To start building with Alchemy, open a free Solana developer account today!

Everything on Solana can be considered an account, and accounts are the way the protocol “organizes” the data on the blockchain. This article will provide a holistic overview of the Solana Account Model including types and categories, account components, and the notion of ‘rent’.

What is a Solana account and how does it work?

Solana accounts can be thought of as storage buckets, capable of holding every data type: from tokens such as SOL to a program’s state variables (e.g. integers, strings, public keys), and even entire programs themselves. Every account has a specified owner, and a single owner can own many different accounts.

The Account Model is often compared to a computer file system:

Computer file and a Solana account

What are Solana account types?

Solana account types are of two main types of accounts: executable and non-executable. This is because Solana programs do not store state like Ethereum smart contracts do, so it needs to separate both type of actions.

What are executable programs?

Executable programs are comprised of immutable code that own and create other accounts that store the state. That code is written in a language like Rust and then compiled to eBPF, which is a form of bytecode.

The most common example of executable programs is the core System Program of Solana, responsible for the creation of the accounts (wallets) that people use to access their tokens and NFTs.

What are non-executable programs?

Non-executable programs are “storage” accounts which contain all other types of data like program variables, token balances, NFTs, fungible currencies, etc. Through non-executable accounts, the protocol reflects the state changes that have occurred after every transaction.

Ethereum Smart Contracts vs. Solana Programs

A smart contract comes prebuilt with a special compartment called “storage” where its state variables are stored. Smart contracts then uses its executable code to modify those state variables. An Ethereum contract can be seen as a unified place for executable and non-executable code to co-exist.

Let’s take the USDC token for example. Its contract contains a mapping called “balances” which maps a user’s address to his own USDC amount. Upon sending or receiving USDC tokens, the contract reflects the changes by itself thanks to its executable code.

Solana handles this in a different manner. There is a USDC token program that creates a new account for each individual token holder. These accounts store the holder’s available USDC amount. When a user propagates a transaction, the USDC Token account looks for the associated token accounts of the users that want to make the exchange and then reflect the change in them.

Solana's Associated Token Account Structure

What are Solana account categories?

Executable and non-executable accounts can be divided into several additional categories such as native programs, program accounts, and data accounts.

What are executable native programs?

Executable native programs are “native” to the Solana ecosystem and are responsible for tasks like maintaining and running the validator nodes. The most well-known example of this type is the System Program, which is in charge of creating new system accounts (what we commonly know as “wallets”), transfer of SOL, etc. Other instances of Native Programs are the Stake Program, which is responsible for the staking mechanism, and the BPF Loader, which is similar to Ethereum’s EVM.

What are executable program accounts?

Executable program accounts are pre-made Solana programs that create and store other programs. A good example of these is the Solana Program Library (SPL) — a collection of programs that support a number of on-chain activities, including creating, swapping, and lending tokens, generating stake pools, and maintaining an on-chain name service. A prominent representative of the SPL is the Token Program, which creates and manages tokens.

Solana’s USDC token is just a Token account, managed by the Token Program. However, the Token account does not store the users’ token balances. This is handled by a member of the third type of accounts: data accounts.

What are non-executable data accounts?

While the Native Programs and Program accounts are considered executables, data accounts are the opposite: they are a registry that reflects the state changes for specific programs and the Solana protocol as a whole.

Data accounts can be divided into:

  1. Token accounts - accounts created by the Token Program
  2. Associated Token Accounts (ATA) - accounts that store the token balances for each individual user
  3. System Owned Accounts - store data and allow for the signing of transactions

Token accounts represent each individual fungible currency (USDC, USDT, etc.), and contain basic information for the token like supply, number of decimals, name, etc. For each unique Token account a different associated token account (ATA) is generated. For instance, if you own both USDC and USDT, you have access to two ATAs that have been created by the USDC and the USDT Token accounts respectively.

Solana account types and categories

What are Solana account elements?

Each account element is a metadata set, so the protocol can easily understand the account’s type and additional information. Metadata consists of:

  • lamports - the account’s SOL balance, denominated in lamports where 1 lamport is equivalent to one billionth of a SOL token
  • owner - this is the address of the program that owns the account
  • executable - a boolean variable that indicates if the account contains executable code
  • data - the raw data byte array, stored in the account, be it storage variables or executable code
  • rent_epoch - indicates the next epoch at which the account will owe rent

The difference between an owner and a holder is that the owner is the program that controls the account and a holder is the user who holds the private key to the account. For example, the System Owned Account is owned by Solana’s Native System Program.

What is Solana account rent?

Every account pays a rent fee to use memory on the blockchain, and is a preventative measure to keep attackers from clogging the network by using all of its memory.

For a blockchain to satisfy all its users, it must include some kind of economic incentive. This applies especially to the validators, who supply their hardware and computational power to verify all the transactions. Validators need to maintain a working copy of all the state changes and receive rent as a reward.

An account that maintains a minimum balance equivalent to 2 years of rent fees is exempt. If not, it is charged when it is referenced by a transaction or at every epoch, which currently equates to two days. If an account does not contain the minimum amount of SOL to be rent exempt, its data is deleted from the chain.

How to Create a Solana Account

Creating a System Account on Solana is what Solana wallets do in the background each time a user creates a new “wallet”. A wallet creates a new account by generating a 64-byte keypair that lies on an ED25519 elliptic curve. The first 32 bytes are the private key, which is used when the user wants to create a transaction and interact with another account or program. The second set of 32 bytes is the public key of the wallet.

Start Building on Solana

The Account Model is the system that the Solana protocol uses to organize data. Accounts can be thought of as storage buckets, capable of holding everything- from raw data, code and state variables, to token balances, NFTs, etc. Accounts are of 2 main types: executable and non-executable.

To start building with Alchemy, open a free Solana developer account today!

{{get-started-solana}}

Contact Us

Talk to an expert at Alchemy to answer all of your product questions.
Valid number
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Build blockchain magic with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free