Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Atomically-committed sequences of instructions.
While [Instruction]s are the basic unit of computation in Solana, they are
submitted by clients in [Transaction]s 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 solana_rpc_client;
use Result;
use ;
use ;
use Instruction;
use Keypair;
use Message;
use Pubkey;
use RpcClient;
use Signer;
use 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.
#
# let client = new;
# let program_id = new_unique;
# let payer = new;
# send_initialize_tx?;
#
# Ok::