14 releases
| new 0.2.0 | Feb 26, 2026 |
|---|---|
| 0.2.0-alpha.2 | Feb 12, 2026 |
| 0.2.0-alpha.0 | Jan 29, 2026 |
| 0.1.10 | Dec 9, 2025 |
| 0.1.6 | Nov 28, 2025 |
#2 in #submitting
97 downloads per month
Used in 11 crates
(7 directly)
425KB
7K
SLoC
Atomically-committed sequences of instructions.
While Instructions are the basic unit of computation in Solana, they are
submitted by clients in Transactions containing one or more
instructions, and signed by one or more Signers. Solana executes the
instructions in a transaction in order, and only commits any changes if all
instructions terminate without producing an error or exception.
Transactions do not directly contain their instructions but instead include
a Message, a precompiled representation of a sequence of instructions.
Message's constructors handle the complex task of reordering the
individual lists of accounts required by each instruction into a single flat
list of deduplicated accounts required by the Solana runtime. The
Transaction type has constructors that build the Message so that clients
don't need to interact with them directly.
Prior to submission to the network, transactions must be signed by one or
more keypairs, and this signing is typically performed by an abstract
Signer, which may be a Keypair but may also be other types of
signers including remote wallets, such as Ledger devices, as represented by
the RemoteKeypair type in the solana-remote-wallet crate.
Every transaction must be signed by a fee-paying account, the account from which the cost of executing the transaction is withdrawn. Other required signatures are determined by the requirements of the programs being executed by each instruction, and are conventionally specified by that program's documentation.
When signing a transaction, the the valid from field must be provided. This allows validators to drop old but unexecuted transactions; and to distinguish between accidentally duplicated transactions and intentionally duplicated transactions — any identical transactions will not be executed more than once, so updating the valid from field between submitting otherwise identical transactions makes them unique.
use anyhow::Result;
use std::time::{SystemTime, UNIX_EPOCH};
use borsh::{BorshSerialize, BorshDeserialize};
use rialo_s_instruction::Instruction;
use rialo_s_keypair::Keypair;
use rialo_s_message::Message;
use rialo_s_pubkey::Pubkey;
use solana_rpc_client::rpc_client::RpcClient;
use rialo_s_signer::Signer;
use rialo_s_transaction::Transaction;
// A custom program instruction. This would typically be defined in
// another crate so it can be shared between the on-chain program and
// the client.
#[derive(BorshSerialize, BorshDeserialize)]
enum BankInstruction {
Initialize,
Deposit { kelvins: u64 },
Withdraw { kelvins: u64 },
}
fn send_initialize_tx(
client: &RpcClient,
program_id: Pubkey,
payer: &Keypair
) -> Result<()> {
let bank_instruction = BankInstruction::Initialize;
let instruction = Instruction::new_with_borsh(
program_id,
&bank_instruction,
vec![],
);
let valid_from = SystemTime::now().duration_since(UNIX_EPOCH)?.as_secs();
let mut tx = Transaction::new_signed_with_payer(
&[instruction],
Some(&payer.pubkey()),
&[payer],
valid_from as i64,
);
client.send_and_confirm_transaction(&tx)?;
Ok(())
}
#
#
Dependencies
~0.2–2.7MB
~52K SLoC