Skip to main content

Current implementation status

Status date: July 27, 2026
Release candidate: 0.1.0-rc.1
Scope: controlled, non-production technical pilot

Not production ready

The current release must not be described as a production bank deployment, audited custody system, mature public mainnet, or protection for live high-value assets.

Implemented with test evidence​

  • canonical intent and exact policy binding;
  • initiator, approver, and executor role separation;
  • RFC 9591 FROST Ed25519 authorization-certificate tests for 3-of-5, 5-of-7, and 22-of-33 profiles;
  • remote signer services using pinned mutual TLS and signed application envelopes;
  • participant-isolated, restartable FROST DKG processes;
  • key and certificate activation, overlap, revocation, expiry, and emergency replacement records;
  • restricted BSC ERC-20 wallet handoff and strict receipt reconciliation;
  • deterministic commercial evidence export and independently signed witness receipts; and
  • reproducible release gates covering formatting, linting, tests, credential scanning, builds, and checksums.

Controlled-validation only​

The control plane remains single-tenant and non-production. Current key providers rely primarily on protected files or local sidecars rather than production HSM, KMS, TEE, or remote-attestation systems. Existing BSC evidence comes from automated tests and self-operated wallet trials, not partner production acceptance.

Experimental paths​

The 22-of-33 threshold ML-DSA research path is not a standardized threshold ML-DSA construction and must not process real keys. Dynamic committee, incremental DKG, proactive resharing, and recovery paths have implementations or state-machine tests at different maturity levels but are not complete production cryptographic protocols.

Required before production​

  1. a named design partner and a frozen critical-operation use case;
  2. separately administered signer, control-plane, and witness infrastructure;
  3. production HSM, KMS, TEE, or equivalent key protection;
  4. a completed third-party security audit and remediation cycle;
  5. partner-environment monitoring, fault drills, and operational acceptance;
  6. company, contract, liability, data, and key-responsibility boundaries; and
  7. a non-bypassable protocol module or execution adapter accepted by the partner.

What can be offered now​

Luvion can currently offer a use-case and threat-model workshop, a controlled pilot using synthetic data or test assets, a complete policy-to-evidence demo, and a partner-specific interface and acceptance matrix.