Skip to content

Kuru Relay

Kuru Relay pays gas and broadcasts signed Kuru trading actions. The user signs an instruction; the relay validates it, builds the contract call, sponsors the transaction, and returns its transaction hash.

The relay never takes custody and cannot change the signed account, market, order, price, size, expiry, or builder fee. It also does not accept arbitrary contract addresses or calldata.

Keep the user's main wallet as the AccountCore owner. Create a separate trading EOA controlled by a passkey or embedded-wallet provider, such as Privy or Mera, and give that EOA only the TRADE permission.

main wallet
  owns and administers the AccountCore account
  signs one AccountCore authorization
              |
              | grants TRADE only
              v
secondary trading EOA
  controlled by a passkey / one-click wallet
  delegates itself to KuruTradingWallet with EIP-7702
  signs orders and cancellations
              |
              | signed intent
              v
Kuru Relay
  sponsors and broadcasts the transaction

The main wallet is not changed by EIP-7702. The secondary EOA is disposable, narrowly permissioned, and can be revoked from AccountCore without moving the user's assets.

Integration sequence

  1. Connect the main wallet and identify its AccountCore account.
  2. Create a secondary trading EOA.
  3. Request a relay challenge, sign it with the secondary EOA, and exchange it for a JWT.
  4. Have the main wallet sign permission for the secondary EOA.
  5. Have the secondary EOA sign its EIP-7702 delegation.
  6. Submit both onboarding signatures with the JWT.
  7. Confirm the delegation and AccountCore permission on-chain.
  8. Use the secondary EOA to sign orders and cancellations.
  9. Send those signed intents to the relay over REST or WebSocket.
  10. Track every returned transaction hash until its receipt succeeds or reverts.

Start with the REST API guide. It explains the complete flow and links to every request method.

Testnet endpoints

Interface URL
Authentication challenge POST https://api.relay.testnet.kuru.io/auth/challenge
Authentication token POST https://api.relay.testnet.kuru.io/auth/token
REST POST https://api.relay.testnet.kuru.io/relay
WebSocket wss://ws.relay.testnet.kuru.io/relay/ws

The secondary EOA signs a one-time challenge and the relay issues a short-lived JWT bound to it. Use that token for both transaction interfaces. See Authentication and JWTs for the complete login flow.

Important response rule

BROADCAST only means an RPC accepted the sponsored transaction. It does not mean the transaction succeeded. Always fetch the receipt and verify the expected event or state change.