Using Hosted Relay

Hosted Relay validates supported signed actions, sponsors their gas, and broadcasts the resulting transactions. It cannot change the action committed by a valid signature.

​

Your application’s responsibilities

Use a dedicated secondary EOA as the trading signer and grant it only the AccountCore permissions it needs. Keep the owner key and trading key separate. A trading permission is not a spending cap or a market allowlist. Store trading keys and JWTs securely. Your application owns nonce allocation, payload signing, receipt tracking, order reconciliation, and signer retirement. See Delegated Trading with Relay.

​

The service operator’s responsibilities

The operator holds the sponsor key and manages gas budgets, transaction lanes, RPC routing, and service admission. Hosted-service clients do not need the sponsor key or control its transaction nonce. Handle the documented Relay errors for admission, quotas and nonce/deadline validation.

​

Authentication and permissions

A Relay JWT authenticates one secondary EOA to the service. It does not grant onchain trading permission, install delegation, or replace action signatures. Expiring it does not revoke those permissions. Retiring a signer requires onchain revocation and a separate decision about resting orders and liquidity. Follow Signer Lifecycle and Nonces.

​

REST and WebSocket

Use REST for a straightforward submission integration. WebSocket sessions support repeated actions and transaction-outcome subscriptions. The documented Relay WebSocket uses an Authorization header on the upgrade request; standard browser WebSocket constructors cannot supply that header. Browser applications should use the supported REST path, or an explicitly designed backend connection. A BROADCAST response is not execution or finality. Verify the receipt and resulting state, or use the documented transaction outcomes. Do not blindly retry an unknown result.