Solana is a decentralized blockchain that launched in early 2020. It quickly began rising in popularity, and strong communities formed around applications such as Metaplex, Raydium, and more recently, pump.fun.

Solana has also built their own novel architecture aiming to solve the speed and scalability aspects of the blockchain trilemma. Due to its new architecture, the way accounts and transactions work on Solana is different from more traditional blockchains such as Bitcoin and Ethereum.

In this article we'll explore Solana accounts, how Solana transactions are structured, and how they differ from EVM transactions.

What are Solana Accounts?

The first key abstraction to understand is Solana Accounts.

On Solana, Accounts keep a balance of lamports as fractions of Solana’s native token ($SOL), and facilitate transactions on the network. But Accounts on Solana can include any kind of data — this means it can be a smart contract, or it can just hold wallet balances. This is different from Ethereum where there is a clear distinction between Externally Owned Accounts (EOAs) and smart contract accounts. On Solana, everything is built on Accounts.

Accounts are structured as a key-value pair, with an address as the “key”, and an account information (AccountInfo) object as the “value”. The Address is a public address similar to most blockchains. AccountInfo contains information about the account, like whether or not it is executable (i.e. a smart contract), its balance, and owner.

Owner is different from “holder”, which is the actual user of the account. Every Solana account is “owned” by a program, which is what Solana calls smart contracts. When a Solana account is first created,  it is owned by the System Program, a built-in smart contract which performs key actions on Solana.

The basics of Solana transactions

As we just learned, Solana accounts have an owner, or the System Program by default. This plays an important role in a typical Solana transaction.

Let’s say Bob is sending 1 $SOL to Alice. Bob’s account has a balance of 1 $SOL (or 1,000,000,000 Lamports), and he signs a transaction with his private key with the instruction to send this to Alice.

The “instruction” Bob sent is a basic building block of Solana, and is the way the state is changed. Instructions request the account’s owner to make these changes. In this case, the owner of the account (the System Program) checks that Bob has a valid signature, and sends the balance of $SOL in Lamports to Alice.

A transaction consists of a signature(s) and a message which contains these instructions.

Let’s take a look at the structure of the message itself in more detail:

• Header - Metadata about the number of message signers (Bob’s transaction only has one).

• Account Addresses - All addresses relevant to the transaction (e.g. Bob’s address, and Alice’s address). This is split into those requiring signatures, and those that don’t.

• Blockhash - A recent blockhash from within the last 150 blocks as a rough timestamp for the transaction.

• Instructions - A list of instructions to be executed — in this case, a SOL Transfer Instruction sent to the System Program).

Similar to Ethereum transactions, Solana transactions are atomic. This means if any of the instructions in the transaction fails to execute, the entire transaction fails.

In general, Solana transactions contain a lot of similar information to Ethereum transactions, but there are some major differences at the protocol level.

Key differences between Solana and Ethereum transactions

EVM transactions contain a lot of the same information that Solana transactions do, such as a transaction hash, any relevant addresses, as well as value (wallet-to-wallet transfers) and data (for smart contracts).

Solana and Ethereum also have similar approaches to fee structure. A base fee is included at the protocol level in both Solana and Ethereum, and both have an optional priority fee. There are differences such as the fee being more implicit with Solana, but generally, the structure contains similar information.

Multiple Signers

One of the main differences between Solana and Ethereum transactions is that Solana transactions can have multiple signers at the protocol level.

Users can partially sign transactions, which allows for different entities signing different parts of a transaction (e.g. fees or transfers), or creating offline transactions with signers before propagating to the network.

This allows for more complex actions to occur at the protocol level, whereas on Ethereum you would need to make use of smart contracts or other infrastructure which could introduce a large transaction overhead.

Transaction Actions

One of the more complex actions Solana can perform at the base level is Cross-Program Invocations (CPI).

Solana transactions can call different smart contracts within a single transaction, and contain instructions to execute the calls in order (e.g. swapping for a token and staking it within the same transaction). These are baked into the protocol and are called directly, where Ethereum requires intermediate transactions.

Another example would be Solana’s Proof-of-History (PoH) consensus mechanism, which allows for transaction scheduling and time-based execution logic.

How Turnkey policies can be used for Solana transactions

Although Solana can handle some complex interactions on the base layer, using dedicated wallet infrastructure tools like Turnkey can drastically improve the level of flexibility developers have. Turnkey is an enterprise-grade operating system for wallets that provides programmatic authentication for a variety of use cases across DeFi, developer tools, protocols, and more.

Allowing only Solana transactions that include a transfer from one specific sender or denying all Solana transactions transferring to a specific address are just a couple of ways that developers can make use of Turnkey's Solana Policy Engine. This also includes our open-source parser for Solana-specific transaction parsing.

By writing granular policies around transaction amounts, addresses, and program interactions using Turnkey’s API, developers can make their Solana implementations even more powerful and secure, and provide a more polished user experience for a wide range of users and customers.

Solana is a decentralized blockchain that launched in early 2020. It quickly began rising in popularity, and strong communities formed around applications such as Metaplex, Raydium, and more recently, pump.fun.

Solana has also built their own novel architecture aiming to solve the speed and scalability aspects of the blockchain trilemma. Due to its new architecture, the way accounts and transactions work on Solana is different from more traditional blockchains such as Bitcoin and Ethereum.

In this article we'll explore Solana accounts, how Solana transactions are structured, and how they differ from EVM transactions.

What are Solana Accounts?

The first key abstraction to understand is Solana Accounts.

On Solana, Accounts keep a balance of lamports as fractions of Solana’s native token ($SOL), and facilitate transactions on the network. But Accounts on Solana can include any kind of data — this means it can be a smart contract, or it can just hold wallet balances. This is different from Ethereum where there is a clear distinction between Externally Owned Accounts (EOAs) and smart contract accounts. On Solana, everything is built on Accounts.

Accounts are structured as a key-value pair, with an address as the “key”, and an account information (AccountInfo) object as the “value”. The Address is a public address similar to most blockchains. AccountInfo contains information about the account, like whether or not it is executable (i.e. a smart contract), its balance, and owner.

Owner is different from “holder”, which is the actual user of the account. Every Solana account is “owned” by a program, which is what Solana calls smart contracts. When a Solana account is first created,  it is owned by the System Program, a built-in smart contract which performs key actions on Solana.

The basics of Solana transactions

As we just learned, Solana accounts have an owner, or the System Program by default. This plays an important role in a typical Solana transaction.

Let’s say Bob is sending 1 $SOL to Alice. Bob’s account has a balance of 1 $SOL (or 1,000,000,000 Lamports), and he signs a transaction with his private key with the instruction to send this to Alice.

The “instruction” Bob sent is a basic building block of Solana, and is the way the state is changed. Instructions request the account’s owner to make these changes. In this case, the owner of the account (the System Program) checks that Bob has a valid signature, and sends the balance of $SOL in Lamports to Alice.

A transaction consists of a signature(s) and a message which contains these instructions.

Let’s take a look at the structure of the message itself in more detail:

• Header - Metadata about the number of message signers (Bob’s transaction only has one).

• Account Addresses - All addresses relevant to the transaction (e.g. Bob’s address, and Alice’s address). This is split into those requiring signatures, and those that don’t.

• Blockhash - A recent blockhash from within the last 150 blocks as a rough timestamp for the transaction.

• Instructions - A list of instructions to be executed — in this case, a SOL Transfer Instruction sent to the System Program).

Similar to Ethereum transactions, Solana transactions are atomic. This means if any of the instructions in the transaction fails to execute, the entire transaction fails.

In general, Solana transactions contain a lot of similar information to Ethereum transactions, but there are some major differences at the protocol level.

Key differences between Solana and Ethereum transactions

EVM transactions contain a lot of the same information that Solana transactions do, such as a transaction hash, any relevant addresses, as well as value (wallet-to-wallet transfers) and data (for smart contracts).

Solana and Ethereum also have similar approaches to fee structure. A base fee is included at the protocol level in both Solana and Ethereum, and both have an optional priority fee. There are differences such as the fee being more implicit with Solana, but generally, the structure contains similar information.

Multiple Signers

One of the main differences between Solana and Ethereum transactions is that Solana transactions can have multiple signers at the protocol level.

Users can partially sign transactions, which allows for different entities signing different parts of a transaction (e.g. fees or transfers), or creating offline transactions with signers before propagating to the network.

This allows for more complex actions to occur at the protocol level, whereas on Ethereum you would need to make use of smart contracts or other infrastructure which could introduce a large transaction overhead.

Transaction Actions

One of the more complex actions Solana can perform at the base level is Cross-Program Invocations (CPI).

Solana transactions can call different smart contracts within a single transaction, and contain instructions to execute the calls in order (e.g. swapping for a token and staking it within the same transaction). These are baked into the protocol and are called directly, where Ethereum requires intermediate transactions.

Another example would be Solana’s Proof-of-History (PoH) consensus mechanism, which allows for transaction scheduling and time-based execution logic.

How Turnkey policies can be used for Solana transactions

Although Solana can handle some complex interactions on the base layer, using dedicated wallet infrastructure tools like Turnkey can drastically improve the level of flexibility developers have. Turnkey is an enterprise-grade operating system for wallets that provides programmatic authentication for a variety of use cases across DeFi, developer tools, protocols, and more.

Allowing only Solana transactions that include a transfer from one specific sender or denying all Solana transactions transferring to a specific address are just a couple of ways that developers can make use of Turnkey's Solana Policy Engine. This also includes our open-source parser for Solana-specific transaction parsing.

By writing granular policies around transaction amounts, addresses, and program interactions using Turnkey’s API, developers can make their Solana implementations even more powerful and secure, and provide a more polished user experience for a wide range of users and customers.