5

How do different components of a transaction contribute to the cost of a transaction on Solana?

3 Answers 3

5

Transaction fees are roughly the Solana equivalent of "gas fees" on other chains but are deterministic (it's not possible to pay higher fees for a better chance of being included in a block).

Currently, the amount of resources consumed by a transaction do not impact fees in any way. This is because the runtime imposes a small cap on the amount of resources that transaction instructions can use, not to mention that the size of transactions is limited as well.

The transaction fees are solely determined by the number of signatures that need to be verified in a transaction. The only limit on the number of signatures in a transaction is the max size of transaction itself.

lamports_per_signature * number_of_signatures

The fee per transaction signature can be fetched with the solana cli:

❯ solana fees
Blockhash: 7JgLCFReSYgWNpAB9EMCVv2H4Yv1UV79cp2oQQh2UtvF
Lamports per signature: 5000
Last valid block height: 141357699

You can get the fee's for a particular message (serialized transaction) by using the getFeeForMessage method.

getFeeForMessage(message: Message, commitment?: Commitment): Promise<RpcResponseAndContext<number>>
2

Currently the transaction fee is equal to lamports_per_signature * number_of_signatures.

This value of lamports_per_signature is supposed to be dynamic and dependent on the network congestion.
As of this 22/July/2022, this value is 5000 lamports on all three clusters devnet/testnet/mainnet.

Later Solana plans to introduce:

  • lamports_per_pubkey: Lamports needed to refer to an account in a transaction.
  • lamports_per_slot_distance: Higher cost to load older accounts.
  • lamports_per_byte: Higher cost for larger accounts.
  • lamports_per_bpf_instruction: Higher cost for more computationally program calls.

Reference: https://docs.solana.com/implemented-proposals/transaction-fees#fee-parameters

2

While the other answers here are correct that the transaction fee is calculated by lamports_per_signature * transaction_signature_count, they insinuate that lamports_per_signature is static, which is incorrect. Rather it is dynamic the total signatures in the previous block

            // lamports_per_signature can range from 50% to 1000% of
            // target_lamports_per_signature

constants for which are

pub const DEFAULT_TARGET_LAMPORTS_PER_SIGNATURE: u64 = 10_000;
pub const DEFAULT_TARGET_SIGNATURES_PER_SLOT: u64 = 50 * DEFAULT_MS_PER_SLOT; // 20_000

Since most programs on mainnet beta today are designed to minimize transaction signatures (typically only one) and most blocks contain just a few thousand transactions, lamports_per_signature has been been floored at the minimum 50% of target (10_000), or 5_000. Testnet however regularly sees lamports_per_signature exceed the floor during stress tests

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.