Mirror
Who it’s for
Banks and trade-finance headsThe five-minute brief: what it does, what it refuses, what it costs, where it stands.Supervisors and FIUsThe macro ledger: corridor divergence, measured from signed verdicts.Examiners and auditorsOne signed record, and the checks you run with the network unplugged.EngineersThe operator API, the SDKs and the conformance vectors.Every documentThe protocol, procurement and operations library, in reading order.
ConsoleStart a pilot

DocumentsProcurement and compliance

How Mirror is built: the secure development practice, as it actually is

2 min readSource secure-development.mdsha256 f9c63bfe2d5959e3…

This statement describes what is done today, including where it falls short. It is not a certification. A bank should read it next to the threat-model review history and the signed provenance.

The rules every change follows#

  • The test suite gates. The suite is several thousand assertions across well over a hundred files; the current count is pinned with a hash in /conformance-suite.json and on the site. It runs before anything ships. A red test is not shipped around.
  • Fail closed, in the AML direction. Ambiguity, malformed input and missing checks become undetermined, review or invalid, never a pass. An absent verifier is treated as a removed one.
  • The dangerous things are guarded by tests, not by care:
    • The raw-data wall and the filing-decision wall are tested against a published corpus of disguises.
    • The refusal list (/cannot) is change-controlled: a refusal cannot be removed or weakened within a major version without the build failing.
    • The roadmap's refusals (/roadmap) are under the same rule.
    • The verdict rule is checked across every configuration in the verdict certificate.
  • No third-party runtime code in the kernels. Kernels are dependency-free. The only external library is the database client of the Node host. The SBOM and the signed CBOM list everything.
  • Cryptography is not hand-rolled where it matters. Signatures use the platform's ECDSA, low-S normalised. The one construction beyond that, a zero-knowledge label proof, is commissioned from a cryptographer, not written here.
  • Honest boundaries in the record. Every signed record carries a disclaimer stating what it does not prove, and overclaiming is treated as a defect.
  • Generated artefacts are regenerated, never hand-edited: OpenAPI, SBOM, CBOM, conformance vectors, the verification kit and provenance. Each has a freshness test that fails when the source changed and the artefact did not.
  • Adversarial review becomes tests. When a review finds a hole, the fix ships with a test that reproduces the attack. The review history lists them.

Where it falls short today#

  • No version control repository is published, and there is no branch protection or mandatory second reviewer. Mirror is maintained by one person. A bank should weigh that. Mitigations: the test gates, the signed provenance (which lists every source file by digest), and the byte-reproducible JavaScript builds.
  • No independent penetration test, and no external security review. None is claimed.
  • No SOC 2 or ISO 27001. None is claimed; see the roadmap's Refused list on badges.

Vulnerability handling#

A disclosure address and a response time will be published when the maintainer has decided the channel. Until then no intake channel is invented.

Fixes follow the rule above: the reproducing test first, then the fix, then the regenerated artefacts and the signed provenance.

More in Procurement and compliance

PreviousRelease provenance and reproducible buildsNextFIPS 140: Mirror's position

Every document, grouped