> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kuru.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Using Hosted Relay

> Responsibilities and boundaries for applications using Kuru 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](/sdk/relay-onboarding).

## 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](/api/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](/sdk/signer-lifecycle).

## 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](/api/relay/errors). Do not blindly retry an unknown result.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.