On This Page

Trust Boundaries

Non-custodial user control with bounded backend authority.

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.

Primary auth

SIWE

Wallet identity verified server-side with support for smart-contract wallets.

Session TTL

365 days

Long-lived on-chain timeframe policy, with immediate DISARM available.

Internal tokens

60s

Short-lived service-to-service JWTs for internal boundaries.

Security posture

On-chain

Critical permission constraints are enforced by smart contracts, not by UI discipline alone.

Non-custodial

EOA root authority remains with the user, including emergency-close and ultimate revocation power.

Bounded automation

Session keys are useful precisely because they are constrained by contract, function, parameter, and spending policies.

Auditability

ARM, DISARM, key lifecycle events, failover, and emergency paths all create structured audit signals.

Auth + service boundaries

Authn, authz, validation, and internal service trust are separate steps.

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.
Permissions lifecycle

Session authorization is the product’s most sensitive lifecycle.

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.

Generate

Backend generates a secp256k1 key pair through Web Crypto. The public key is shown to the frontend for permission installation.

ARM

User authorizes bounded on-chain policies for that session key: allowlists, function selectors, amount limits, time bounds, and rate limits.

Use

TLM decrypts ephemerally and signs only within those policy boundaries. For GMX automation it must route through SpellsGmxWrapper.

DISARM or expire

Revocation removes autonomous power immediately. If the user revokes on-chain directly, the next failed sign path produces an external-revocation signal.

Rate limit: 10 ops / 24h Immediate revocation available No raw GMX multicall for automated sessions
Envelope encryption

Envelope encryption keeps persistent key material opaque.

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.

KEK key ring Wrapping key Per-session DEK Encrypted key Versioned in Workers Secrets Store HKDF-derived in memory per record Wrapped, never stored raw Decrypted only in TLM memory

Why HKDF is in the middle

  • Per-record isolation through unique salts.
  • Domain separation for wrapping use only.
  • A clean seam for future KMS or HSM migration.

Persisted bundle fields

  • `key_ref`, `encrypted_key`, `iv`
  • `wrapped_dek`, `dek_iv`, `dek_salt`
  • `kek_version` for rotation-aware decryption
Resilience ladder

Security includes making sure safety-critical operations still function under failure.

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.

Vercel down
Users lose the UI, but Workflows keep monitoring, TLM keeps processing in-flight work, and emergency close remains reachable through the Worker.
Neon unavailable
Position monitor falls back to MetavaultRegistry + on-chain reads. Trigger evaluator reads live Trigger Registry DOs. Alert delivery uses KV-cached subscription descriptors.
Paymaster depleted
Sponsored UserOps stop, but emergency close can still shift to raw user-signed transactions where the EOA pays gas directly.
Catastrophic outage
On-chain contracts remain functional and users can still act directly through other frontends or block explorers. Automation is gone, but custody is not.