Skip to main content
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, Installation, and the funding steps in First Trade. Keep owner and trading keys separate.

​
Who signs what?

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, 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 and Trading-wallet Signing. Do not default either nonce to zero. See Trading-wallet Signing 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:
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, 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 for the SDK method map and Orders, Cancellation, and Replacement 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 when bringing the replacement online.