Additional Optimisations

Use this route when you want a lightweight request for keep-alive and connection warm-up.

The main optimization is not the route itself. The real gain comes from reusing the same persistent HTTP connection to Bifrost instead of opening a new connection for every transaction.

/healthz exists as a cheap request you can send on that same connection when you want to keep it active between transaction submissions.

Why It Helps

• Reduces the chance that your next transaction pays the full connection setup cost

• Lets you keep the client-to-Bifrost connection active without sending a transaction

• Gives you a lightweight probe for reachability on the public listener

/healthz does not forward anything to upstream providers. It only checks that Bifrost itself is reachable.

Important

/healthz only helps if your client reuses the same HTTP client / connection pool.

If your client opens a fresh connection for every call, /healthz does not keep the later transaction connection warm.

Recommended pattern:

• Keep one long-lived HTTP client

• Enable normal keep-alive / connection pooling

• Send transactions over that reused client

• Optionally call /healthz between bursts when you want to keep the connection active

Important

The public Thor-Gateway listener currently uses an idle keep-alive timeout of about 30 seconds .

If you want to keep the same client-to-Bifrost HTTP connection open, send a lightweight GET /healthz or HEAD /healthz roughly every 20-25 seconds .

Routes

Route	Use for
GET /healthz	Lightweight keep-alive and reachability check
HEAD /healthz	Same as GET /healthz, but without a response body

GET /healthz

Example request:

curl https://your-bifrost-endpoint/healthz

Example response:

{
  "status": "ok",
  "service": "Bifrost Transaction Proxy"
}

HEAD /healthz

Example request:

curl -I https://your-bifrost-endpoint/healthz

Expected behavior:

• Returns 200 OK

• Returns no response body

• Useful when you want the lightest possible keep-alive probe