Relay testnet deployment

The public Monad testnet integration endpoints are:

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

An admitted EOA obtains a bearer JWT by signing the one-time challenge returned by the authentication API. The JWT wallet must be the exact trading wallet used by the REST request or WebSocket session. The deployment's JWT signing secret never leaves the relay.

Wallet-admission modes

The testnet registry supports exactly one of these modes:

Mode	Environment	Behavior
Static allowlist	KURU_RELAY_TESTNET_ALLOW_ALL=false and a nonempty KURU_RELAY_TESTNET_ALLOWLIST	Only configured wallet addresses can exchange a signed challenge for a JWT or submit Relay requests.
Allow-all	KURU_RELAY_TESTNET_ALLOW_ALL=true and an empty KURU_RELAY_TESTNET_ALLOWLIST	Every valid nonzero wallet is admitted automatically. It can self-register for API access by signing a challenge without an operator adding its address first.

An empty allowlist does not implicitly enable allow-all. If allow-all is false and the list is empty, the registry refuses to start. If allow-all is true and the list is nonempty, it also refuses to start so operator intent cannot be ambiguous.

Allow-all changes only wallet admission. The client must still prove control of the EOA, and the relay continues to enforce JWT binding, typed request schemas, wallet signatures, market policy, AccountCore permissions, and EIP-7702 validation.

Example allow-all configuration:

KURU_RELAY_TESTNET_ALLOW_ALL=true
KURU_RELAY_TESTNET_ALLOWLIST=

The testnet challenge lifetime is five minutes and the issued token lifetime is one hour. The challenge store is bounded and currently process-local. The present deployment therefore routes authentication to one relay API instance; horizontal authentication scaling requires a shared store or affinity that guarantees challenge and exchange reach the same instance.

Current method availability

Method	Testnet
wallet.execute_replace_by_slot_packed	enabled
wallet.execute_batch	enabled
wallet.cancel_trigger	enabled
account_core.authorize_account_signer_by_sig	enabled
wallet.create_replace_trigger	disabled
wallet.create_batch_trigger	disabled

Trigger-create schemas remain in the versioned interface so the protocol is reviewable before activation. The server currently rejects disabled methods as unavailable to its method registry; clients must not infer deployment enablement solely from schema presence.

Network identity

The deployment uses Monad testnet chain ID 10143. Contract proxies, implementations, KuruTradingWallet delegate, KeeperAuthority, market allowlist, runtime hashes, EIP-712 domains, selectors, and type hashes are immutable startup/readiness inputs. Refer to the Contracts deployment documentation for reviewed live addresses and market units; do not copy addresses into client code without a versioned deployment source.

Operational behavior

• The relay consumes only strictly increasing Proposed notifications from monadNewHeads.
• The latest cached snapshot remains usable for five seconds after its last update, regardless of connection state.
• An RPC or head-cache failure removes the affected signer pod from readiness; the load balancer must stop routing transaction traffic to it.
• REST requests can be assigned to any ready lane. WebSocket sessions remain pinned to one lane and reconnect when close code 4003 reports loss of that lane.
• BROADCAST ends relay delivery responsibility. Receipt, revert, event, and finality monitoring belongs to the client or an external chain-data service.

Deployment-private surfaces

Health, readiness, Prometheus, private signer RPC, wallet-registry mTLS, and operator tooling are not part of the public API contract and must not be routed through the public testnet hostnames.