Relay request lifecycle

REST and WebSocket requests share the same method payloads and validation semantics. Their outer envelopes, correlation identifiers, admission state, and retry behavior differ.

Common processing order

1. Apply transport, origin, rate, concurrency, and owned-byte bounds.
2. Decode a strict envelope. Unknown fields, duplicate fields, non-object payloads, and noncanonical values fail closed.
3. Authenticate the bearer token and bind its configured wallet claim to the request wallet or WebSocket session.
4. Require the wallet to pass the deployment's admission mode. Static deployments require a real allowlist record; allow-all testnet deployments admit every valid nonzero wallet. Wallet calls without an attached EIP-7702 authorization additionally require the configured delegation policy.
5. Decode only the selected method payload and validate widths, market allowlist, deadlines, nonce window, builder policy, order bindings, and EIP-712 signature.
6. Validate the optional EIP-7702 authorization and any required block-pinned AccountCore state.
7. Construct canonical ABI calldata and an immutable signer plan. The client cannot select outer transaction fields.
8. The signer independently revalidates the plan, freezes lane nonce and fees, signs, verifies the signed bytes, and broadcasts.
9. Return a definite BROADCAST, definite REJECTED, or ambiguous UNKNOWN result.

All integer JSON values are canonical unsigned decimal strings, including narrow Solidity integers. Values must not contain signs, whitespace, leading zeroes, exponents, or hexadecimal notation. Addresses and fixed bytes are exact-width 0x hexadecimal.

Correlation and idempotency

REST requires a canonical lowercase UUIDv7 requestId. It is a correlation identifier and a best-effort same-process duplicate signal, not durable idempotency. WebSocket clients provide an opaque id unique within the connection; the server caches a bounded number of recent responses for duplicate IDs.

The contracts remain the replay authority. Retrying an intent after an ambiguous broadcast can create a second sponsored outer transaction even when the signed wallet action later reverts as already consumed.

Result classes

Status	Meaning	Client action
BROADCAST	At least one configured RPC definitely accepted the candidate.	Track txHash; verify receipt plus expected event/state.
REJECTED	The request or candidate was definitely not accepted under the stated classification.	Correct the request, or retry only when retryable is true.
UNKNOWN	Broadcast may have happened, but the relay cannot prove acceptance or rejection.	Query candidateTxHash when present and make an explicit retry decision.

retryAfterMs is only a hint on retryable failures. BROADCAST_RESULT_UNKNOWN is deliberately non-retryable so generic clients cannot create blind retry loops.

Receipt reconciliation

The relay does not wait for inclusion and does not expose a receipt endpoint. A successful receipt is still insufficient for EIP-7702 onboarding: verify the authority's delegation indicator at the receipt block. AccountCore onboarding must also prove the expected AccountSignerAuthorized event or equivalent state transition. A reverted target call can still leave a valid EIP-7702 delegation installed.