Skip to main content
Choose Apex in Endpoints → Bifrost and copy the operation’s complete URL. ThorNode supplies the upstream credential; authenticate with your Bifrost key using the standard route authentication.

​
Transaction and tip requirements

Legacy and v0 transactions may contain at most 1232 serialized bytes; v1 transactions may contain at most 4096 bytes. Sign the final message before submitting it. Each independent transaction must include exactly one top-level System Program transfer of at least 1,000,000 lamports (0.001 SOL) to an accepted Apex tip account. The tip’s source must sign the transaction, and the recipient must appear in the static account keys rather than an address lookup table. A bundle needs exactly one such tip across all its members.

​
Dedicated tip accounts

​
Default tip accounts

Call getTipAccounts on /apex for the current upstream list. Bifrost forwards that list unchanged and requires authentication even for utility methods:
The result is an array of base58 account addresses, including the dedicated and default accounts above.

​
JSON-RPC send

Use the same /apex URL:
Response: {"jsonrpc":"2.0","id":1,"result":"<TRANSACTION_SIGNATURE>"}. Apex performs no simulation or preflight. Use simulateTransaction on your regular Solana RPC before submission when needed.

​
JSON send

Copy Apex → JSON send for /apex-send. Send Content-Type: application/json with:
transaction is required. Optional mevProtect (boolean) and maxRetries (number) select Apex behavior; omit them for upstream defaults. Response: {"signature":"<TRANSACTION_SIGNATURE>"}.

​
Binary send and batch

Copy Binary send for /apex-send-bin and POST the raw signed bytes with Content-Type: application/octet-stream. Its response is {"signature":"<TRANSACTION_SIGNATURE>"}. For Binary batch (/apex-send-batch), concatenate 1–16 signed transactions with a two-byte unsigned big-endian length before each transaction:
Send the framed body as application/octet-stream. Each transaction is sent independently and needs its own tip. Inspect results and the accepted/rejected counts; batch acceptance does not establish atomic execution. Binary routes accept query options mev_protect=0|1 and max_retries=N. Append options to the copied operation URL. See the upstream sending reference for option semantics.

​
Atomic bundles

Use sendBundle on /apex:
Response: {"jsonrpc":"2.0","id":1,"result":"<BUNDLE_ID>"}. Alternatively, copy Binary bundle for /apex-send-bundle and send 1–4 binary frames using the batch framing above. Response: {"bundle_id":"<BUNDLE_ID>","signatures":["<TRANSACTION_SIGNATURE>"]}. Exactly one tip is allowed across the bundle. Apex submits bundles through Jito; members execute in order with all-or-nothing semantics. See the upstream bundle reference.

​
Status, quota, and errors

On /apex, getTipAccounts, getInflightBundleStatuses, getVersion, and health are authenticated utility methods. They do not consume Bifrost transaction quota. Each submitted batch or bundle member counts as one transaction against a subscription’s TPS allowance. For bundle status, send:
Parse every response body, including HTTP 200 responses containing a JSON-RPC error. Bifrost returns 400 for invalid transactions, size/count violations, or missing, duplicate, and insufficient tips. A 429 can come from your subscription allowance or Apex’s own limits. See Bifrost errors. An acceptance signature or bundle ID does not prove confirmation. Query each transaction signature through Solana RPC until it reaches your required commitment or expires; inspect err as well as confirmationStatus.

​
Next steps