send
Submits 1 to 5 signed transactions as one atomic bundle and returns its bundle id.
sendBundle submits a bundle in the Jito Block Engine format: 1 to 5 signed transactions that run in order and land together, or none land. The call returns the bundle id.
Requests are relayed to the Jito Block Engine in the same region as the endpoint. A bundle lands only when the current leader runs a Jito or BAM client; on other leaders it does not land.
Parameters
params is a JSON array, with values in this order: transactions, config.
1 to 5 signed transactions, wire-encoded strings, in the order they should run.
Optional configuration.
Show propertiesProperties
Wire encoding of the transactions items. base58 is the default; base64 is recommended.
base58base64Result
The bundle id, a string. getBundleStatuses and getInflightBundleStatuses take it as input.
Notes
- The example transactions are placeholder strings, not real signed transactions; the example bundle id is fake.
- The bundle must pay a tip of at least 1,000 lamports to a Jito tip account, inside one of its transactions. The tip is the user's, not constant-k's.
- Each transaction in the bundle counts as one send against the plan's transaction limit: a five-transaction bundle uses five.
- Bundle requests share a per-region relay rate set by Jito, in proportion to each plan's bundle rate: the next opening goes to the waiting key furthest behind its share, and a key alone takes every opening. When the relay is busy the call returns HTTP
429with code-32005and the headersRetry-AfterandX-Retry-After-Ms; retry after that wait. The refused call does not count against the plan's transaction limit. See Errors. - Not accepted in batch requests, and not served on the staked or Neon Zero hostnames. Not included in the Free plan.
- Limits and how keys take turns at the relay: see Jito bundles.