Skip to main content
Hofund is ThorNode’s own submission surface. The aggregated Bifrost routes forward your request to an upstream provider; Hofund submits through ThorNode’s own transaction sender at the location you call. Hofund routes appear under Endpoints → Hofund next to the other providers, for every location where Bifrost is enabled on your access. Copy the complete route URL there. It uses the same Bifrost key and the same location base as every other Bifrost route.

​
Locations

Hofund runs at every edge location. Each one exposes the same routes on the same ports; the dashboard shows the exact URLs with your key.

​
Pick a lane

The fast lanes submit through the transaction sender at the location you call. Singapore is the designated stake-weighted location; it becomes stake-weighted once its sender identity is staked. Until then, swqos and swqos-only requests are accepted at every location and delivered through that location’s own sender. The Jito lanes go to the Jito block engine nearest the location you call over ThorNode’s own gRPC access; you need no Jito account or key. A Jito lane never falls back to a fast rail, and a fast lane never falls back to Jito.

​
Send a transaction

Every lane takes POST with the Solana JSON-RPC sendTransaction shape. Hofund does not run preflight, so pass skipPreflight: true; a request without it is rejected before anything is sent.
The response also carries an X-Hofund-Submission-Id header. Keep it: it is the handle for the status route below. A transaction is capped at 1232 bytes. Ordinary fast and protected sendTransaction routes require a recent blockhash and reject durable nonce. For a durable-nonce pair, use /hofund with sendIdeal when that capability is available.

​
Include a Thor tip

Every transaction on a fast lane includes a System transfer of at least 100,000 lamports (0.0001 SOL) to one of these ten addresses:
Pick any one per transaction. The same ten addresses are valid at every location. Read the live list and minimum from the status route (getFastTipConfig) rather than hard-coding them.

​
Send a Jito bundle

/hofund-bundle takes sendBundle with 1 to 5 base64 transactions. One member of the bundle — usually the last — must carry both tips: at least 100,000 lamports (0.0001 SOL) to a Thor tip address above and at least 1000 lamports to one of Jito’s tip accounts, and that same transaction must include a real application instruction (a program other than System, Compute Budget, or Memo, touching a writable account). A bundle made only of transfers and tips is rejected before it is sent.
The bundle ID is the SHA-256 of the comma-joined transaction signatures, so you can compute it yourself before you send. Query Jito’s own view of the bundle with getBundleStatuses on the same route:
/hofund-jito-bundle-only takes a single sendTransaction (with the same tip and application-instruction rules) and returns the transaction signature, with the bundle ID in X-Bundle-Id. Jito’s tip accounts, as accepted by Hofund today (minimum 1000 lamports; the dashboard’s Hofund tab shows the same list):
Jito publishes the authoritative list in its documentation; getTipAccounts on /hofund-bundle returns the live set.

​
Send everything through one endpoint

/hofund accepts the same sendTransaction body and defaults to the fast lane. Select the SWQoS-only lane with the query parameter ?swqos-only=true, or the Jito lane with ?mev-protect=true. It also answers sendBatch, sendBundle, sendIdeal, getNonce, and getHealth. sendIdeal is /hofund’s supported durable-nonce flow: it accepts a verified two-transaction fast/Jito pair that shares the same nonce account, live nonce value, and authority. Ordinary /hofund sendTransaction calls still require a recent blockhash. /hofund/plain takes the Base64 transaction as text/plain, and /hofund/binary takes raw bytes as application/octet-stream; both select the operation with ?method=sendTransaction (or ?method=getHealth).

​
Stream transactions over WebSocket or QUIC

Both raw transports take the same signed bytes you would base64 for JSON — no envelope, no method, one transaction per message — and send nothing back: no acknowledgement and no submission id. Reconcile every signature yourself.
  • WebSocket — open the ws:// form of the route URL from the dashboard (ws://<host>:4343/<key>/hofund/ws, or …/hofund/ws/mev-protect for the Jito lane) and send each transaction as one binary frame of at most 1232 bytes. Up to 10 connections per key, 16 in-flight transactions per connection.
  • QUIC — connect UDP to <host>:4802 with server-certificate verification, ALPN hofund-ingest/1, and authenticate exclusively with this account’s Bifrost key: immediately after connecting, open one bidirectional control stream and send {"type":"authenticate","token":"<your-bifrost-key>"}. The server answers {"type":"authenticated"}; only then open one unidirectional stream per raw signed transaction. ThorNode provides a reference client; see the QUIC reference.
The tip rules below apply on every transport.

​
Rate limits

Every Bifrost key has a per-key fast-lane rate set by the tier of the pass that owns it, enforced across all fast surfaces together (JSON-RPC, plain, binary, WebSocket, QUIC): The Jito lanes (mev-protect, /hofund-jito-bundle-only, /hofund-bundle, protected WebSocket) allow 5 requests per second per key, burst 5, at every tier. Over the limit, HTTP routes answer 429 with Retry-After: 1; the WebSocket and QUIC lanes drop the extra transaction silently, so pace your sends.

​
Check what happened

POST /hofund-status answers two methods: A submission’s status moves through Hofund’s own view of the transaction and reaches finalized with a landedSlot once the chain has it. An unknown submission ID returns submission not found. Submission records are kept for 10 minutes.

​
Next steps