Docs
Security model
Sessions, nonces, signature verification, request binding, and a server that fails closed.
Signing and verification
- Actions use canonical, human-readable messages you can read before signing.
- Login signatures are verified server-side for the claimed account before any session is issued.
- At settlement, the on-chain verifier validates the signature on your intent.
Two nonce models
- Login nonces
- Single-use, short-lived, and backed by a shared store that fails closed in production — they stop login-signature replay.
- Intent nonces
- A salt-prefixed 32-byte nonce for the raw settlement path; a fully-random nonce is rejected, so the current salt is read at signing time.
Request binding
Published intents are bound to your session: the signing format must match your wallet family, the signer must equal your account, and the deadline must be present and in the future. This prevents one session from publishing on behalf of another account and rejects expired intents without a wasted round-trip.
Privileged actions additionally bind a hash of the entire execution payload into the signature, recomputed and verified server-side, so no execution-sensitive field can be changed after you sign.
Server-only secrets and limits
- The solver credential is server-only and never exposed to the browser; the proxy fails closed when it is absent.
- Per-account rate limits protect the metered proxy and fail closed in production.
- Debug and raw-execution surfaces are dead unless explicitly enabled, and stay off in production.
Replay protections
- Login replay is stopped by single-use nonces.
- Intent replay within a deadline is mitigated by short deadlines, salted nonces, and a do-not-share diagnostic that auto-clears.
- Cross-account publishing is stopped by session binding, and account confusion at signing by an account-match check.