Skip to content

Relay signing and EIP-7702

Relay requests carry signatures made by user-controlled identities; the relay sponsor key signs only the outer transaction. These are separate authorization domains and separate nonce spaces.

Wallet intents

KuruTradingWallet intents use EIP-712 domain name KuruTradingWallet, version 1, the live chain ID, and the delegated wallet EOA as verifyingContract. The implementation address is never the wallet-domain verifier. Wallet signatures use the contract-supported 65-byte canonical low-s ECDSA representation with v equal to 27 or 28.

Immediate replace and batch intents share the wallet's strictly increasing order-nonce namespace. Trigger creation and cancellation use the separate unordered one-shot trigger-nonce namespace. The WebSocket session adds a transport rule: wallet intent nonces accepted on one connection must increase, even where the on-chain trigger namespace itself is unordered.

Use the contracts signing reference for exact EIP-712 type strings, payload hashes, units, and nonce behavior.

AccountCore signer authorization

account_core.authorize_account_signer_by_sig uses domain name KuruAccountCore, version 1, the live chain ID, and the configured AccountCore proxy. The request wallet must equal payload.signer. The authorizer signature is independent of the wallet's EIP-7702 authorization and may be an accepted EOA or ERC-1271 signature.

The current testnet policy requires the TRADE permission bit and block-pinned confirmation of the AccountCore authorization nonce and authorizer authority. The account owner cannot authorize itself as its own trading signer; onboarding therefore uses a distinct AccountCore owner and trading-wallet EOA.

Optional EIP-7702 authorization

The authorization7702 object is an optional component of another relay method, not a standalone endpoint. It authorizes exactly one authority—the request wallet—to delegate to the configured KuruTradingWallet implementation. The relay rejects universal chain ID zero, another delegate, another authority, a stale authority nonce, unsupported code state, noncanonical signature values, and redelegation from another delegate.

An accepted tuple changes the sponsor transaction from DYNAMIC_FEE to SET_CODE. The protocol processes the authorization before executing the target call, so delegation can persist even when the target call reverts. Clients must reconcile both effects independently.

Nonce separation

Never substitute one of these values for another:

  • EIP-7702 authority transaction nonce;
  • KuruTradingWallet immediate order nonce;
  • KuruTradingWallet trigger nonce;
  • AccountCore signer-authorization nonce;
  • relay sponsor outer-transaction nonce; or
  • REST request ID / WebSocket message ID.

The client supplies the first four only where the selected request schema requires them. The signer owns the sponsor nonce. Transport correlation identifiers are not blockchain nonces.