Non-custodial
EOA root authority remains with the user, including emergency-close and ultimate revocation power.
Spells v2 Walkthrough
Trust boundaries, key custody, and degraded safety behavior.
On This Page
The product trust model starts from a hard constraint: user EOAs never leave the user’s device. Backend-held session keys exist only to execute bounded, user-approved actions, and their blast radius is limited by on-chain policy and explicit recipient, contract, and amount constraints.
SIWE
Wallet identity verified server-side with support for smart-contract wallets.
365 days
Long-lived on-chain timeframe policy, with immediate DISARM available.
60s
Short-lived service-to-service JWTs for internal boundaries.
On-chain
Critical permission constraints are enforced by smart contracts, not by UI discipline alone.
EOA root authority remains with the user, including emergency-close and ultimate revocation power.
Session keys are useful precisely because they are constrained by contract, function, parameter, and spending policies.
ARM, DISARM, key lifecycle events, failover, and emergency paths all create structured audit signals.
User-facing routes go through `walletAuth`, then `scopeByAccount`, then schema validation. Internal services use short-lived signed tokens. The Worker never hands an unscoped DB client to a user-facing route.
| Layer | What it proves | What it does not prove |
|---|---|---|
| `walletAuth` | SIWE-backed identity for a wallet address. | It does not itself authorize access to arbitrary resources. |
| `scopeByAccount` | Ownership through user → smart account → position/resource chain. | It does not validate request shape or business rules. |
| `zValidator()` | Request structure and schema conformity. | It does not authorize access or prove identity. |
| Service auth | Internal call legitimacy between Worker, Workflow, Trigger Registry, and TLM. | It is not a replacement for wallet auth on public routes. |
Session keys are always generated server-side for autonomous execution, but they exist only because the user explicitly arms bounded permissions for a Metavault. Long-lived validity is acceptable only because the permission set is narrow and immediate revocation remains available.
Backend generates a secp256k1 key pair through Web Crypto. The public key is shown to the frontend for permission installation.
User authorizes bounded on-chain policies for that session key: allowlists, function selectors, amount limits, time bounds, and rate limits.
TLM decrypts ephemerally and signs only within those policy boundaries. For GMX automation it must route through SpellsGmxWrapper.
Revocation removes autonomous power immediately. If the user revokes on-chain directly, the next failed sign path produces an external-revocation signal.
Session private keys are never stored in plaintext. A per-session DEK encrypts the key, a versioned KEK-derived wrapping key protects the DEK, and TLM only reconstructs the usable key ephemerally for signing.
The resilience model removes capabilities step by step while preserving the ones that protect user funds: monitoring, alerting, trigger continuity where safe, and emergency close. That is why the system distinguishes safety-critical from convenience operations.