Security questionnaire

For security reviewers.

In short

This page answers the questions most vendor security assessments ask, so your reviewer can fill in their questionnaire from evidence rather than from a sales call. Each answer is short and names where to check it: a claim on this site, a section of another deep dive, or a document we can send.

Some answers are “no” or “not yet”, and they are written as such. No external security audit or penetration test has been carried out, and CryptoRail holds no certification such as SOC 2 or ISO 27001. Self-hosted deployments and pilots are offered today; running CryptoRail for you in production waits for the external audit.

Most questions assume a vendor that runs a service for you. When CryptoRail is self-hosted, it runs in your infrastructure, over your database, with your keys and your monitoring, and we have no access to it. The picture below is the split of responsibilities that the answers follow.

flowchart LR
    subgraph US[CryptoRail, the vendor]
        P[The product: code, tests, journeys]
        D[Dependency audit, pinned contracts]
        S[The sandbox, never for value]
    end
    subgraph YOU[You, when self-hosted]
        I[Infrastructure, network, TLS]
        DB[(PostgreSQL: encryption at rest, backups, retention)]
        K[Keys: HSM, cloud KMS or your signer]
        M[Monitoring, alerting, incident response]
    end
    P -->|container image, configuration| I
    I --> DB
    I <-->|bytes to sign, signature| K
    I -->|traces, metrics, logs| M

Governance and audits

Every Must requirement has at least one automated test that names it, and a change is merged only with its tests, every check green and no loss of requirement coverage.

Access control and authentication

API keys are stored only as a keyed hash under a pepper kept in your secret manager, so whoever reads the database cannot call the API with what they find.

Authentication with mutual TLS or OIDC tokens, beside API keys. On request

Who may do what is checked per call: read-only, submitter, signer, sponsor, operator and admin roles.

An API key's secret is shown once when it is created; a rotation keeps the old key working through a configurable overlap, a revocation ends it at once on every API process, and a tenant's last admin key cannot be revoked.

A tenant sees only its own resources, proven on every route of the API on every change.

Each process has its own database role: the API cannot allocate a nonce, the worker cannot read API keys, the indexer cannot touch transactions, identities or signing requests, and no process can change the schema.

Rate limiting per API key, configurable, reported with standard rate-limit headers and a refusal that says when to come back.

Per-tenant limits set by the operator, with refusals that name the limit reached.

Cryptography and key management

Keys never enter CryptoRail: signing happens in your HSM, your cloud KMS or your own signer, and only the development signer ever touches a key.

Your own signer keeps the key: CryptoRail prepares the exact bytes, your system signs them, CryptoRail verifies and broadcasts.

Keys in a hardware security module over PKCS#11 (Thales, Utimaco, Entrust, AWS CloudHSM): tested on every change against SoftHSM2, each vendor declared after a manual test on its device. Built, certification pending

Signing keys in AWS KMS, with the curve checked at startup. Built, certification pending

Every signature is checked against the expected address before anything is sent.

Secrets passed by reference and never written to logs, traces, metrics or responses.

A secret written into the configuration instead of a reference to your secret manager is refused at startup.

Each webhook endpoint gets a secret shown once, sealed at rest under a key from your secret manager, and rotated without a gap; endpoints must be HTTPS unless the deployment explicitly allows otherwise.

The development signer warns on every start and refuses to load in production unless an explicit override is set.

Only the development signer's package may touch key material, enforced by a dependency check on every change.

The hosted profile refuses to start if it is given a key of its own, listing every reason.

Data protection and retention

Runs in your infrastructure, as a container image over your PostgreSQL, with schema migrations applied by an explicit command.

The complete history of any operation, exported in a machine-readable file for audit.

Logging and monitoring

Every approval, signature and decision is recorded with who, when and what, and every change made through the API lands in an audit log.

Traces, metrics and structured logs through OpenTelemetry, into the monitoring tools you already run.

The full history of every operation, every transition and every attempt with its time and cause, can be queried.

The actual cost of every operation is recorded, and a payer running low on funds raises an alert before operations fail.

Health and readiness that tell the truth, and a configuration checked at startup with every problem listed at once.

Vulnerability and dependency management

Dependencies scanned on every change; a high or critical vulnerability blocks the release.

Every dependency version is fixed in a committed lockfile, and every build installs exactly that set.

Releases per customer: the service image signed with cosign and pushed to that customer's project of a private registry that scans it, and the npm packages and an image archive published with their checksums. On the roadmap

Only the canonical EntryPoint and public account and paymaster contracts from audited lineages, pinned per network; no custom contract.

Secure development and testing

Tested on every change to the code against Anvil and a Hyperledger Besu QBFT network, and run on public test networks by recorded manual procedures.

Every behaviour a consumer sees has a journey: a scenario run on every change whose HTML report shows, step by step, the request, the response, the resulting state, the events and, for a negative case, the failure report.

Deployment and network

Embedded as a library in your Node.js application, or run as a service with an HTTP API described in OpenAPI and generated SDKs.

One process, or separate API, worker, signing gate and indexer processes sharing only the database, each with a database role limited to what it needs.

In a split deployment the signing gate is a process of its own, the only one with signer credentials: it reaches the database and your signer and nothing else, and re-checks every request before it signs.

The API process builds no signer, and a split deployment that configures one for it is refused at startup.

A production deployment refuses to start with authentication on but no pepper, or without a webhook encryption key, rather than pretend to a protection it lacks.

A change to a tenant's policy is a new version that can be made to wait for a quorum of named approvers, required by default when CryptoRail is run for you; every proposal, approval and activation is recorded.

A sandbox says it is one: in its logs, on its health endpoint and on every screen built over it. It is never supported for value.

Incident response and business continuity

An operation CryptoRail has acknowledged is never lost: not across crashes and restarts, not through a node outage of up to ten minutes.

A stopping process finishes its broadcasts and deliveries in flight within a grace period, and whatever it could not finish is picked up again on restart.

Several node endpoints per network: calls go to the first healthy one, an operation stays on the endpoint it started on, and a dead or lagging node is left aside without losing anything.

Several workers on the same database without sending anything twice.

An identity can be paused: new operations are accepted and wait without taking a nonce until it is resumed.

An operator command line for the daily work: pause an identity, redeliver a webhook, reconcile nonces, export a history, onboard a tenant.

Third parties

Works with your own nodes or a provider's, through standard Ethereum JSON-RPC over plain HTTP.

Signing with Azure Key Vault or GCP Cloud KMS, or through Fireblocks. On request

A licence file signed per customer and verified locally at startup, which warns with a grace period and never stops a running system. On the roadmap

What it does not do

• It has not been audited externally or certified. The tests, the journeys and the requirements are the evidence today.
• It does not encrypt your operational data at rest, keep a tamper-evident audit log, or purge data on a schedule; those are your database platform’s.
• It does not terminate TLS or authenticate with SSO, OIDC or mutual TLS today.
• It comes with no incident response service, support SLA or breach notification commitment for self-hosted deployments yet.
• It does not publish a software bill of materials or a vulnerability disclosure policy yet.
• Custody of your end customers' keys. Not supported

Evidence

Every claim above links to its evidence on the evidence page. The main ones: