Security
Trading, authorization and signing. Separate by design.
Application
The application validates the session, identifies the account and checks access to the requested operation.
It passes the action and account references into the signing path. Transaction private keys remain on the isolated signer, outside the application.
Authorization
Account ownership, signing authority, request contents and expiry are checked before the operation reaches the signing runtime.
Where approval is required, it is bound to the specific action and payload. Changing that payload invalidates the approval; a login alone cannot replace it.
Isolated signer
A dedicated runtime authenticates each signing request and checks its key ownership, freshness and replay state. Keys are encrypted at rest; signing returns a signature, not the private key.
Signing requests reach the isolated runtime through a single, authenticated interface.
Encryption & approval
PIN-protected key envelopes use Argon2id and HKDF-SHA256 with server unlock material, then AES-256-GCM. Authenticated context binds encrypted material to its intended account and key.
Authorization and transaction signing are separate steps. Approval is scoped to a request; logging in is not blanket permission to move funds.
Before a request is signed
The signing path checks ownership, permission, request contents and expiry. Approval is tied to the intended action and payload, rather than an unrestricted signing request.
The signer authenticates incoming service requests with mutual TLS and request authentication, and checks freshness and replay state before handling the signing operation. Its service interface does not provide a remote shell or return private keys.