curl --request POST --url https://relay.testnet.kuru.io/relay \
--header "Authorization: Bearer $KURU_RELAY_JWT" \
--header 'Content-Type: application/json' \
--data '{"requestId":"018f5ef2-88a1-7b41-a826-4b679010f87f","method":"account_core.create_subaccount_by_sig","wallet":"0x1111111111111111111111111111111111111111","payload":{"rootOwner":"0x3333333333333333333333333333333333333333","authorizer":"0x3333333333333333333333333333333333333333","subaccountSeq":"2","authNonce":"1","deadline":"1792500000","signature":"0x..."}}'
{"requestId":"018f5ef2-88a1-7b41-a826-4b679010f87f","status":"BROADCAST","txHash":"0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","sponsorAddress":"0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb","sponsorNonce":"42","transactionType":"DYNAMIC_FEE"}
Opt-in operational REST methods
Create subaccount
Submit account_core.create_subaccount_by_sig through the opt-in Relay operational path.
POST
/
relay
curl --request POST --url https://relay.testnet.kuru.io/relay \
--header "Authorization: Bearer $KURU_RELAY_JWT" \
--header 'Content-Type: application/json' \
--data '{"requestId":"018f5ef2-88a1-7b41-a826-4b679010f87f","method":"account_core.create_subaccount_by_sig","wallet":"0x1111111111111111111111111111111111111111","payload":{"rootOwner":"0x3333333333333333333333333333333333333333","authorizer":"0x3333333333333333333333333333333333333333","subaccountSeq":"2","authNonce":"1","deadline":"1792500000","signature":"0x..."}}'
{"requestId":"018f5ef2-88a1-7b41-a826-4b679010f87f","status":"BROADCAST","txHash":"0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","sponsorAddress":"0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb","sponsorNonce":"42","transactionType":"DYNAMIC_FEE"}
Submits
The root owner or an authorized ADMIN/TRADE EOA signs. For an unregistered root, only the owner may bootstrap the first child.
account_core.create_subaccount_by_sig when this method is enabled for the selected deployment. This is a slow operational method, not the low-latency trading path. Relay validates the typed request and signature where applicable, simulates the exact call against latest, and only then queues a sponsored transaction. See Operational methods for availability, gas, and latency rules.
The example uses testnet WETH/USDC where a market is required, but all identities, nonces, timestamps, hashes, and signatures are illustrative. Read current state and build a fresh valid signature for the selected network. Omit
authorization7702 and makerSlotsPrimed; complete delegation first.string
required
New lowercase UUIDv7 for request correlation.
string
default:"account_core.create_subaccount_by_sig"
required
Must be
account_core.create_subaccount_by_sig.string
required
Trading wallet matching the bearer JWT; for AccountCore operations this is the sponsoring frontend identity, not necessarily the signed authorizer.
object
required
Method-specific payload shown below; unknown fields are rejected.
subaccountSeq is the next nonzero uint16 sequence, not an account ID. authNonce is the root authorization epoch read from AccountCore, not a millisecond nonce. Creation advances the sequence, not the epoch; wait for inclusion and read the next sequence before signing another. The trading wallet’s JWT is independent of the authorizer/root owner.
Sign the exact EIP-712 type below using the KuruAccountCore version 1, with the configured AccountCore proxy as verifyingContract and the selected chain ID (143 mainnet; 10143 testnet):
CreateSubaccount(address rootOwner,address authorizer,uint16 subaccountSeq,uint256 authNonce,uint256 deadline)
curl --request POST --url https://relay.testnet.kuru.io/relay \
--header "Authorization: Bearer $KURU_RELAY_JWT" \
--header 'Content-Type: application/json' \
--data '{"requestId":"018f5ef2-88a1-7b41-a826-4b679010f87f","method":"account_core.create_subaccount_by_sig","wallet":"0x1111111111111111111111111111111111111111","payload":{"rootOwner":"0x3333333333333333333333333333333333333333","authorizer":"0x3333333333333333333333333333333333333333","subaccountSeq":"2","authNonce":"1","deadline":"1792500000","signature":"0x..."}}'
{"requestId":"018f5ef2-88a1-7b41-a826-4b679010f87f","status":"BROADCAST","txHash":"0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","sponsorAddress":"0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb","sponsorNonce":"42","transactionType":"DYNAMIC_FEE"}
BROADCAST means scheduling for asynchronous RPC broadcast, not provider acceptance or successful execution. Check the receipt and expected events/state. A failed estimate returns an immediate error with no transaction signed or broadcast.