The relay

Planned

The relay is planned and not built. Its design was decided on 6 Oct 2026 (docs/decisions.md, “Guard in the browser through a relay”). Whether running it makes Orcastrate UG a receiver and transmitter of orders is a question for a lawyer, and the relay will not be public before it is answered.

The problem it solves

Two things cannot reach a Guard directly:

• TradingView posts webhooks only to ports 80 and 443 on a public server (TradingView).
• A Guard running in a browser tab cannot accept connections at all.

The relay is a small public server that both can reach. Your Guard connects out to it and keeps the connection open.

How it works

1. You get a personal relay URL.
2. Your Guard (local, or in your browser tab) opens a WebSocket to the relay.
3. A request arrives at your URL: a TradingView alert, or a bot’s Hyperliquid request.
4. The relay forwards it over the WebSocket to your Guard, unchanged.
5. Your Guard checks it, applies your rules, signs with the API wallet key it holds, and sends the order to Hyperliquid itself. The order does not go back through the relay.

bot / TradingView ──▶ relay ══(your Guard's outbound WebSocket)══▶ your Guard ──▶ Hyperliquid

Why it is not custody

• No key. The relay never holds an API wallet key or a client key.
• No funds. Nothing is deposited anywhere but your Hyperliquid account.
• No orders. The relay cannot sign, so it cannot place an order. Hyperliquid only accepts orders signed by your API wallet, which is in your Guard.
• No logs of content. The relay keeps no logs of what it forwards. Its code will be published, and anyone may run their own.

What a compromised relay could do

Bot requests carry a signature from a Guard-issued client key and a nonce, so a relay that is taken over:

• can delay or drop requests;
• cannot forge one (it has no client key), replay one (the nonce is used), or push one past your limits (your Guard judges every request).

TradingView alerts are different: TradingView cannot sign. An alert is authenticated by a secret in its text, which the relay sees. A compromised relay could therefore send alerts of its own. They would still pass your rules, the daily loss stop and the drawdown halt, but they could make your Guard open trades you did not ask for, within those limits. This is an open design point (Threat model).

Limits

• For trials and alerts, not for bots running around the clock. With a browser Guard the tab must stay open and the machine awake.
• Latency. The extra hop adds roughly 30–150 ms, an estimate recorded with the decision, not a measurement.
• Availability. If the relay is down, alerts are lost and bots behind it cannot trade. Exits through a local Guard are not affected.