Network.Solana.Core.Message

Builds and signs a transaction from a list of signing keys and instructions. The fee payer is the first writable signer encountered across the instructions' account metas, and account keys are canonically ordered (fee payer first, then each privilege section sorted by pubkey bytes; see canonicalizeAccountOrder). The private keys passed here must be ordered to match the resulting account order (fee payer first), otherwise the produced signatures will not correspond to the right account keys. If you would rather name the fee payer explicitly and not worry about signer order, consider newTransactionIntentWithPayer, which orders signatures automatically.

If no instruction marks a signer writable (a memo-only or SPL authority-only instruction list), the message compiled here has no valid fee payer and the node rejects it at sanitize time; use newTransactionIntentWithPayer for such transactions.

Builds and signs a transaction with an explicitly named fee payer. Unlike newTransactionIntent, the fee payer is always account 0 (sponsored fees are supported: the payer need not appear in any instruction at all), and the given private keys may be listed in any order — they are matched against the compiled message's required signers and the resulting signatures are placed in message order automatically. Left if a required signer has no corresponding private key, or if a given private key does not correspond to any required signer. Duplicate private keys for the same required signer are tolerated: the first match signs, mirroring the Rust SDK's try_sign.

Builds and signs a durable-nonce transaction: prepends SystemProgram.advanceNonceAccount nonceAccount nonceAuthority ahead of the given instructions and delegates to newTransactionIntent. The durable nonce — read from the nonce account's on-chain NonceState via nsDurableNonce — is passed in place of a recent block hash, since a durable-nonce transaction never expires and does not depend on a recent ledger entry. The nonce authority must be among the given signers, or the resulting transaction will be rejected on submission.

ORDER-SENSITIVE: as with newTransactionIntent, the given private keys must be ordered to match the resulting canonical account order (fee payer first), or the produced signatures will not correspond to the right account keys. If you would rather name the fee payer explicitly and not worry about signer order, use newDurableNonceTransactionIntentWithPayer instead.

Builds and signs a durable-nonce transaction with an explicitly named fee payer: prepends SystemProgram.advanceNonceAccount nonceAccount nonceAuthority ahead of the given instructions and delegates to newTransactionIntentWithPayer, composing sponsored fees with durable nonces. As with newTransactionIntentWithPayer, the fee payer is forced into account 0 (even if it appears in no instruction), and the given private keys may be listed in any order — signatures are auto-ordered to match the compiled message. The nonce authority must be among the given signers, or the resulting transaction will be rejected on submission.

A transaction awaiting a recent block hash: applying one yields the Base64-encoded signed transaction, or a CompileException.

The structure of a transaction message.

Three bytes at the front of every message declaring account privileges.

The structure of a Compiled Message.

Compile instructions into serialized legacy-message bytes using the given recent block hash. Account keys are collected and canonically ordered as described at newTransactionIntent.

Like newMessage, but returns the message bytes Base64-encoded.

Assemble the uncompiled Message: fold the instructions' account metas into a deduplicated, privilege-merged key list, then put it in canonical order.

Like mkNewMessage, but with an explicitly named fee payer. The payer is seeded as a writable signer before the instructions' account metas are folded in, so it ends up in the message (and pinned first by canonicalizeAccountOrder) even if no instruction references it — enabling sponsored-fee transactions.

Orders the given private keys to match the required signers of the given message (its first numRequiredSignatures account keys, fee payer first). Left if a required signer has no corresponding key, or if a given key corresponds to no required signer. Duplicate keys for the same signer are tolerated: the first match signs, mirroring the Rust SDK's try_sign.