At rest

Why keys are hashed rather than encrypted

Nothing in the system ever needs to read a key back. Given that, hashing is strictly stronger than encryption: an encrypted keystore plus its key is recoverable, and therefore leakable. A hashed one is not. Key comparison uses timingSafeEqual over derived hashes. The timing signal on high-entropy tokens is small, but the cost of doing it correctly is one function call.
v1 plaintext keystores migrate in place on first load, so installs predating the hashed keystore keep working without manual intervention. If you are auditing an older deployment, confirm the migration has run rather than assuming the format.

In transit

The self-hosted server speaks plain HTTP. That is correct on loopback and wrong on any interface that is not loopback. If you bind it beyond 127.0.0.1, put TLS in front of it and set tunnel_token. The application will not stop you.

What Scienter does not do

  • No application-level encryption of state/. Use full-disk or filesystem encryption. This is a deliberate scope decision, not an oversight: application-layer encryption whose key sits on the same disk buys very little.
  • No client-side encryption of anything.
  • No HSM integration. The relayer key belongs in a KMS in a production deployment; the code reads it from the environment and does not manage its lifecycle.

Signing, not encryption

The execution path’s security rests on EIP-712 scoped signatures, not on secrecy. A trade instruction is public; what makes it safe is that the signature commits to a scope the contract enforces — caps, strategy, expiry — and the relayer cannot alter a signed field. See Non-custodial execution.
Scienter publishes impersonal market signals of general and regular circulation. Nothing here is investment, legal, or tax advice, or a recommendation to buy, sell, or hold any asset. Scienter is not a registered investment adviser or broker-dealer. Trading digital assets can result in the total loss of your funds — see Disclaimers for the full text.