> ## 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 schedules the resulting transactions for broadcast. It cannot change the action committed by a valid signature. The opt-in `wallet.finalize_twap` route is a permissionless contract action with no client signature; Relay still authenticates and scopes its caller.

## 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.md).

## 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.md) 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.md).

## 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.md). Do not blindly retry an unknown result.


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