send
Submits a signed transaction to the cluster and returns its signature immediately.
sendTransaction forwards a fully signed, wire-encoded transaction toward the current and upcoming slot leaders, returning its first signature as soon as the node accepts it for forwarding. This is not confirmation that the transaction landed or executed; getSignatureStatuses, polled afterward, or a subscription, reports what happened on-chain.
By default the node runs a preflight simulation and rejects the submission up front on failure (invalid blockhash, insufficient funds, a program error). Skipping preflight only makes sense when the transaction is already known to be well-formed.
Parameters
params is a JSON array, with values in this order: transaction, config.
The fully signed transaction, wire-encoded per the encoding config field.
Optional configuration.
Show propertiesProperties
Skips the node's local simulation before forwarding; faster, but a doomed transaction then fails on-chain, or never lands, instead of being rejected early with a specific reason.
Bank state to run the preflight simulation against. Ignored when skipPreflight is true.
finalizedconfirmedprocessedWire encoding of the transaction param. base64 is more reliable than base58 for large, especially versioned, transactions, which some clients no longer support sending as base58.
base58base64Maximum number of times the node's own transaction-forwarding service should rebroadcast this transaction while waiting for it to land. Omit to use the node's default retry behavior.
Minimum slot the node must have processed before running preflight.
Result
The transaction's first signature, base-58 encoded — returned on acceptance for forwarding, not on confirmation.
Notes
- The network row above is constant-k's normal, best-effort forwarding over the standard TPU path. A separate staked / SWQoS allowance forwards through constant-k's staked connection, which leaders prioritize under Solana's stake-weighted QoS: Free unavailable, Operator 1/s, Blade Runner 5/s, Nexus 20/s.
- The example transaction is a syntactically valid legacy SystemProgram transfer with an all-zero placeholder signature, not a real keypair; submitting it as-is is rejected for a bad signature, since only a transaction signed by its actual keypair is accepted.
- Preflight simulation failures come back as a JSON-RPC error at send time, with logs attached.
- A transaction using Address Lookup Tables (version 0) requires
base64; some client libraries cannot represent the larger versioned wire format asbase58at all.