Accounts

All data on the Solana network is stored in accounts. You can think of the Solana network as a public database with a single Accounts table. The relationship between an account and its address is similar to that of a key-value pair, with the key being the address and the value being the account.

Each account has the same basic structure and can be located using its address.

Diagram of 3 accounts and their addresses. Includes the account structure definition.Diagram of 3 accounts and their addresses. Includes the account structure definition.

Account address

The account's address is a 32-byte unique ID used to locate the account on the Solana blockchain. Account addresses are often shown as base58 encoded strings. Most accounts use an Ed25519 public key as their address, but this is not required, as Solana also supports program derived addresses.

An account with its base58 encoded public key addressAn account with its base58 encoded public key address

Public key

The example below demonstrates how to use the Solana SDK to create a keypair.

import { generateKeyPairSigner } from "@solana/kit";
// Kit does not enable extractable private keys
const keypairSigner = await generateKeyPairSigner();
console.log(keypairSigner);
Console
Click to execute the code.

Program derived address

A program derived address (PDA) is an address that is deterministically derived using a program ID and one or more optional inputs (seeds). The example below demonstrates how to use the Solana SDK to create a program derived address.

import { Address, getProgramDerivedAddress } from "@solana/kit";
const programAddress = "11111111111111111111111111111111" as Address;
const seeds = ["helloWorld"];
const [pda, bump] = await getProgramDerivedAddress({
programAddress,
seeds
});
console.log(`PDA: ${pda}`);
console.log(`Bump: ${bump}`);
Console
Click to execute the code.

Account structure

Every Account has a maximum size of 10MiB and contains following information:

  • lamports: The number of lamports in the account
  • data: The account's data
  • owner: The ID of the program that owns the account
  • executable: Indicates whether the account contains executable binary
  • rent_epoch: The deprecated rent epoch field
Account
pub struct Account {
/// lamports in the account
pub lamports: u64,
/// data held in this account
#[cfg_attr(feature = "serde", serde(with = "serde_bytes"))]
pub data: Vec<u8>,
/// the program that owns this account. If executable, the program that loads this account.
pub owner: Pubkey,
/// this account's data contains a loaded program (and is now read-only)
pub executable: bool,
/// the epoch at which this account will next owe rent
pub rent_epoch: Epoch,
}

Lamports

The account's balance in lamports.

Every account must have a minimum lamport balance, called rent, which allows its data to be stored on-chain. Rent is proportional to the size of the account.

Although this balance is called rent, it works more like a deposit, as the full balance can be recovered when the account is closed. (The name "rent" comes from the now deprecated rent epoch field.)

(See the minimum balance formula and the applicable constants.)

Data

This field is commonly referred to as "account data". The data in this field is considered arbitrary as it can contain any sequence of bytes. Each program defines the structure of the data stored in this field.

  • Program accounts: This field contains either executable program code or the address of a program data account which stores the executable program code.
  • Data accounts: This field generally stores state data, meant to be read.

Reading data from a Solana account involves two steps:

  1. Fetching the account using its address
  2. Deserializing the account's data field from raw bytes into the appropriate data structure, as defined by the program that owns the account.

Owner

This field contains the program ID of the account's owner.

Every Solana account has a program designated as its owner. The account's owner is the only program that can change the account's data or deduct lamports, as indicated by the program's instructions.

(In the case of a program account, the owner is its loader program.)

Executable

This field indicates whether an account is a program account or a data account

  • If true: The account is a program account
  • If false: The account is a data account

Rent epoch

The rent_epoch field is deprecated.

In the past, this field tracked when an account would need to pay rent. However, this rent collection mechanism has since been deprecated.

Lamports

The account's balance in lamports.

Every account must have a minimum lamport balance, called rent, which allows its data to be stored on-chain. Rent is proportional to the size of the account.

Although this balance is called rent, it works more like a deposit, as the full balance can be recovered when the account is closed. (The name "rent" comes from the now deprecated rent epoch field.)

(See the minimum balance formula and the applicable constants.)

Data

This field is commonly referred to as "account data". The data in this field is considered arbitrary as it can contain any sequence of bytes. Each program defines the structure of the data stored in this field.

  • Program accounts: This field contains either executable program code or the address of a program data account which stores the executable program code.
  • Data accounts: This field generally stores state data, meant to be read.

Reading data from a Solana account involves two steps:

  1. Fetching the account using its address
  2. Deserializing the account's data field from raw bytes into the appropriate data structure, as defined by the program that owns the account.

Owner

This field contains the program ID of the account's owner.

Every Solana account has a program designated as its owner. The account's owner is the only program that can change the account's data or deduct lamports, as indicated by the program's instructions.

(In the case of a program account, the owner is its loader program.)

Executable

This field indicates whether an account is a program account or a data account

  • If true: The account is a program account
  • If false: The account is a data account

Rent epoch

The rent_epoch field is deprecated.

In the past, this field tracked when an account would need to pay rent. However, this rent collection mechanism has since been deprecated.

Account Examples
// Example Token Mint Account
Account {
lamports: 1461600,
data.len: 82,
owner: TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb,
executable: false,
rent_epoch: 0,
data: 010000001e213c90625a7e643d9555bb01b6c3fe6416d7afd523ce8c7ddd9b923ceafb9d00000000000000000901010000001e213c90625a7e643d9555bb01b6,
}
// Example Token Program Account
Account {
lamports: 4513200894,
data.len: 134080,
owner: BPFLoader2111111111111111111111111111111111,
executable: true,
rent_epoch: 18446744073709551615,
data: 7f454c460201010000000000000000000300f70001000000d8f90000000000004000000000000000800902000000000000000000400038000400400009000800,
}

Types of accounts

There are two basic categories that accounts fall into:

This separation means that a program's executable code and its state are stored in separate accounts. (Similar to operating systems, which typically have separate files for programs and their data.)

Program accounts

Every program is owned by a loader program, which is used to deploy and manage the account. When a new program is deployed, an account is created to store its executable code. This is called a program account. (For simplicity, you can consider the program account to be the program itself.)

In the diagram below, you can see a loader program is used to deploy a program account. The program account's data contains the executable program code.

Diagram of a program account, its 4 component and its loader program.Diagram of a program account, its 4 component and its loader program.

Program data accounts

Programs deployed using loader-v3 do not contain program code in their data field. Instead, their data points to a separate program data account, which contains the program code. (See the diagram below.)

A program account with data. The data points to a separate program data accountA program account with data. The data points to a separate program data account

During program deployment or upgrades, buffer accounts are used to temporarily stage the upload.

The example below fetches the Token Program account. Notice that the executable field is set to true, indicating the account is a program.

import { Address, createSolanaRpc } from "@solana/kit";
const rpc = createSolanaRpc("https://api.mainnet-beta.solana.com");
const programId = "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA" as Address;
const accountInfo = await rpc
.getAccountInfo(programId, { encoding: "base64" })
.send();
console.log(accountInfo);
Console
Click to execute the code.

Data accounts

Data accounts do not contain executable code. Instead, they store information.

Program state account

Programs use data accounts to maintain their state. To do so, they must first create a new data account. The process of creating a program state account is often abstracted, but it helpful to understand the underlying process.

To manage its state, a new program must:

  1. Invoke the System Program to create an account. (The System Program then transfers ownership to the new program.)
  2. Initialize the account data, as defined by its instructions.

Diagram of a data account owned by a program accountDiagram of a data account owned by a program account

The example below creates and fetches a Token Mint account owned by the Token 2022 program.

import {
airdropFactory,
appendTransactionMessageInstructions,
createSolanaRpc,
createSolanaRpcSubscriptions,
createTransactionMessage,
generateKeyPairSigner,
getSignatureFromTransaction,
lamports,
pipe,
sendAndConfirmTransactionFactory,
setTransactionMessageFeePayerSigner,
setTransactionMessageLifetimeUsingBlockhash,
signTransactionMessageWithSigners
} from "@solana/kit";
import { getCreateAccountInstruction } from "@solana-program/system";
import {
getInitializeMintInstruction,
getMintSize,
TOKEN_2022_PROGRAM_ADDRESS,
fetchMint
} from "@solana-program/token-2022";
// Create Connection, local validator in this example
const rpc = createSolanaRpc("http://localhost:8899");
const rpcSubscriptions = createSolanaRpcSubscriptions("ws://localhost:8900");
// Generate keypairs for fee payer
const feePayer = await generateKeyPairSigner();
// Fund fee payer
await airdropFactory({ rpc, rpcSubscriptions })({
recipientAddress: feePayer.address,
lamports: lamports(1_000_000_000n),
commitment: "confirmed"
});
// Generate keypair to use as address of mint
const mint = await generateKeyPairSigner();
// Get default mint account size (in bytes), no extensions enabled
const space = BigInt(getMintSize());
// Get minimum balance for rent exemption
const rent = await rpc.getMinimumBalanceForRentExemption(space).send();
// Instruction to create new account for mint (token 2022 program)
// Invokes the system program
const createAccountInstruction = getCreateAccountInstruction({
payer: feePayer,
newAccount: mint,
lamports: rent,
space,
programAddress: TOKEN_2022_PROGRAM_ADDRESS
});
// Instruction to initialize mint account data
// Invokes the token 2022 program
const initializeMintInstruction = getInitializeMintInstruction({
mint: mint.address,
decimals: 9,
mintAuthority: feePayer.address
});
const instructions = [createAccountInstruction, initializeMintInstruction];
// Get latest blockhash to include in transaction
const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();
// Create transaction message
const transactionMessage = pipe(
createTransactionMessage({ version: 0 }), // Create transaction message
(tx) => setTransactionMessageFeePayerSigner(feePayer, tx), // Set fee payer
(tx) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx), // Set transaction blockhash
(tx) => appendTransactionMessageInstructions(instructions, tx) // Append instructions
);
// Sign transaction message with required signers (fee payer and mint keypair)
const signedTransaction =
await signTransactionMessageWithSigners(transactionMessage);
// Send and confirm transaction
await sendAndConfirmTransactionFactory({ rpc, rpcSubscriptions })(
signedTransaction,
{ commitment: "confirmed" }
);
// Get transaction signature
const transactionSignature = getSignatureFromTransaction(signedTransaction);
console.log("Mint Address:", mint.address);
console.log("Transaction Signature:", transactionSignature);
const accountInfo = await rpc.getAccountInfo(mint.address).send();
console.log(accountInfo);
const mintAccount = await fetchMint(rpc, mint.address);
console.log(mintAccount);
Console
Click to execute the code.

System accounts

Not all accounts are assigned a new owner after being created by the System Program. Accounts owned by the System Program are called system accounts. All wallet accounts are system accounts, which allows them to pay transaction fees.

A wallet owned by the System Program containing 1,000,000 lamportsA wallet owned by the System Program containing 1,000,000 lamports

When SOL is sent to a new address for the first time, an account is created at that address owned by the System Program.

In the example below, a new keypair is generated and funded with SOL. After running the code, you can see the address of the account's owner is 11111111111111111111111111111111 (the System Program).

import {
airdropFactory,
createSolanaRpc,
createSolanaRpcSubscriptions,
generateKeyPairSigner,
lamports
} from "@solana/kit";
// Create a connection to Solana cluster
const rpc = createSolanaRpc("http://localhost:8899");
const rpcSubscriptions = createSolanaRpcSubscriptions("ws://localhost:8900");
// Generate a new keypair
const keypair = await generateKeyPairSigner();
console.log(`Public Key: ${keypair.address}`);
// Funding an address with SOL automatically creates an account
const signature = await airdropFactory({ rpc, rpcSubscriptions })({
recipientAddress: keypair.address,
lamports: lamports(1_000_000_000n),
commitment: "confirmed"
});
const accountInfo = await rpc.getAccountInfo(keypair.address).send();
console.log(accountInfo);
Console
Click to execute the code.

Sysvar accounts

Sysvar accounts exist at predefined addresses and provide access to cluster state data. They update dynamically with data about the network cluster. See the full list of Sysvar Accounts.

The example below fetches and deserializes data from the Sysvar Clock account.

import { createSolanaRpc } from "@solana/kit";
import { fetchSysvarClock, SYSVAR_CLOCK_ADDRESS } from "@solana/sysvars";
const rpc = createSolanaRpc("https://api.mainnet-beta.solana.com");
const accountInfo = await rpc
.getAccountInfo(SYSVAR_CLOCK_ADDRESS, { encoding: "base64" })
.send();
console.log(accountInfo);
// Automatically fetch and deserialize the account data
const clock = await fetchSysvarClock(rpc);
console.log(clock);
Console
Click to execute the code.

Is this page helpful?

सामग्री तालिका

पृष्ठ संपादित करें

द्वारा प्रबंधित

© 2025 सोलाना फाउंडेशन। सर्वाधिकार सुरक्षित।
Accounts | Solana