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

# Delegated Trading with Relay

> Fund an owner account, authorize a secondary signer, and submit signed actions.

Use a funded owner account and a separate secondary EOA for trading. Relay submits supported signed actions and sponsors their gas. The secondary EOA uses KuruTradingWallet through EIP-7702 delegation.

## Before you start

Complete [Testnet Setup](/deployments/setup), [Installation](/sdk/installation), and the funding steps in [First Trade](/sdk/quickstart). Keep owner and trading keys separate.

## Who signs what?

| Item | Signed by | Effect |
| - | - | - |
| AccountCore authorization | Owner or live administrator | Grants trading permission across the owner’s account family |
| EIP-7702 authorization | Secondary EOA | Installs KuruTradingWallet delegation on that EOA |
| Relay challenge | Secondary EOA | Obtains a wallet-bound service JWT |
| Order intent | Secondary EOA | Authorizes a specific trading action |

These are separate authorizations. A JWT cannot replace AccountCore permission or an order signature.

## 1. Read the funded account

Read `getRootAccountId({ rootOwner: owner.address })`, the current available balance, and `getSignerAuthorizationNonce({ account: owner.address })`. The order's account ID identifies the funded owner account, not the secondary signer.

## 2. Prepare both onboarding authorizations

Use `buildAuthorizeAccountSignerTypedData` with the owner account, secondary signer, `TRADE` permission, current AccountCore nonce, expiry, and deadline. Have the owner sign that typed data.

Read the secondary EOA's pending transaction count for its EIP-7702 authority nonce. Sign an authorization for the KuruTradingWallet implementation from [Testnet Deployments](/deployments/testnet), on chain `10143`.

If this EOA is **already delegated to an older or unsupported implementation**, do not assume Relay can combine its re-delegation with the AccountCore grant. Relay may reject that path with `7702_UNSUPPORTED_CODE_STATE` before broadcasting. Use a fresh secondary EOA, or submit the existing EOA's signed EIP-7702 re-delegation through a separately funded sender. Confirm the new delegation on-chain, then submit the owner-signed AccountCore grant through Relay with `authorization7702: null`. A re-delegation changes the wallet implementation; it does not itself grant `TRADE` permission or migrate old wallet signatures and storage. See [Relay errors](/api/relay/errors) and [Trading-wallet Signing](/sdk/trading-wallet).

Do not default either nonce to zero. See [Trading-wallet Signing](/sdk/trading-wallet) for the signing helpers.

## 3. Authenticate and submit

Authenticate the secondary EOA with `relay.authenticate()`. Submit the owner-signed grant and the secondary EOA's delegation authorization using `relay.authorizeAccountSigner`.

The typed example in `examples/src/relay-authorize-account-signer.ts` reads both nonces before signing. From a local checkout of these docs, provide `RPC_URL`, `ACCOUNT_OWNER_KEY`, `TRADING_WALLET_KEY`, `KURU_ACCOUNT_CORE`, and `KURU_TRADING_WALLET_DELEGATE`, then run:

```bash theme={null}
node --experimental-strip-types examples/src/relay-authorize-account-signer.ts
```

Load secrets through your local environment or secret manager; do not put them in documentation, source files, or shell command arguments.

## 4. Verify onboarding

A broadcast response is only submission. Require a successful receipt, check the secondary EOA's EIP-7702 delegation target, and read back its `TRADE` permission. Read the AccountCore authorization nonce again: granting the signer advances it.

Use this new authorization nonce in subsequently signed order intents. Previously prepared intents may now be stale.

## 5. Sign and submit an order

Read market precision, tick, and notional constraints. Allocate an immediate-action nonce using the policy in [Signer Lifecycle and Nonces](/sdk/signer-lifecycle), then create an intent with `signBatchIntent` and submit it with `relay.executeBatch`.

The same batch method supports cancellation. Bind cancellation slots to current order IDs when the instruction must target a specific order. Verify the actual resting-order state; post-only crossing can be skipped in a successful transaction.

See [Relay Submission](/sdk/relay) for the SDK method map and [Orders, Cancellation, and Replacement](/sdk/orders-and-cancellation) for order construction.

## 6. Retire or rotate the signer

Stop new signing, reconcile submitted work, and decide whether to cancel outstanding orders. Revoke the old signer with owner authority and verify the permission is no longer live. Revocation does not remove resting orders or liquidity positions. Follow the [signer lifecycle](/sdk/signer-lifecycle) when bringing the replacement online.


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