Skip to main content
Sisera’s security and risk architecture (@sisera/risk, @sisera/portfolio, and apps/api/src/auth.ts) is built around a strict institutional premise: never hold user keys, never trust client-supplied risk limits, and fail closed on missing or stale data.

​
Five Institutional Stress Scenarios (STANDARD_SCENARIOS)

Every portfolio in Sisera is continuously evaluated against five multi-asset shock scenarios (GET /v1/portfolio and /risk in the terminal):

​
Deterministic Pre-Trade Risk Engine (@sisera/risk)

Both paper and live orders execute through the exact same side-effect-free pre-trade risk function:
  1. Server-Loaded Mandate Limits: Risk preferences (GET /v1/risk/preferences and PUT /v1/risk/preferences) and portfolio state are loaded strictly server-side from PostgreSQL.
  2. Quote Quality & Freshness Gate: Every quote carries source, observedAt, receivedAt, and quality state. Stale, delayed, or degraded quotes are rejected before order creation.
  3. Machine-Readable Dispositions: Every risk evaluation returns a deterministic pass/fail decision accompanied by structured rejection codes (e.g., position weight breach, underlying duplicate exposure breach, pool liquidity breach, daily drawdown breach, or stale reference feed).

​
Identity, RBAC & Non-Custodial Signing

  • Browser sessions authenticate via Privy bearer tokens stored in HttpOnly, SameSite cookies.
  • apps/api cryptographically verifies the Privy token server-side and resolves organization membership and role permissions (market:read, agent:read, trade:execute, risk:manage).
  • Wallet ownership alone is never sufficient authorization to trade—an identity defaults to viewer-only until explicit permissions are granted.
  • Sisera never stores or accesses user private keys.
  • When preparing a Solana swap (POST /v1/solana/orders/prepare), marketplace license purchase (POST /v1/marketplace/:id/checkout), or Meteora DBC launch (POST /v1/launches/dbc/prepare), the server records the exact expected unsigned transaction message.
  • Upon submission (verifySignedSwap), apps/api deserializes the user-signed transaction and verifies that the program instructions, accounts, and amounts match what Sisera prepared byte-for-byte before broadcasting to the Solana RPC.
  • For operators who want policy_auto or autonomous agents to execute live onchain swaps without manual wallet popups on every trigger, Sisera supports Privy Delegated Session Signers.
  • Requires both SISERA_DELEGATED_SIGNING_ENABLED=true and PRIVY_AUTHORIZATION_PRIVATE_KEY on the server, plus explicit wallet delegation by the owner.
  • Even with delegated signing enabled, every automated transaction must still pass the deterministic policy evaluator and pre-trade risk engine.