Skip to main content

Current implementation status

  • Status review date: August 15, 2026
  • Implementation evidence baseline: e4eb993a041fea7012e3e0e28c5db21b4a05eb17
  • Release-gate baseline: 1b6a8d42a8f582a7563c7b9c65de5b72e15262d6
  • Release candidate: 0.1.0-rc.1
  • Scope: controlled, non-production technical pilot
Current maturity

The current release is a controlled technical-validation system. Its supported scope is policy-bound authorization, distributed signing, restricted execution adapters, recovery, and evidence generation in pilot environments. Production scope begins after partner acceptance, independent infrastructure, external security review, and operational readiness.

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;
  • validation-only Lit integration with an immutable Action, dedicated PKP, strict request binding, durable reconciliation, and a deployed process recovery drill;
  • a canonical protocol-upgrade operation with a cross-language EVM ABI digest vector that binds the proxy, admin endpoint, new implementation, code and calldata hashes, and timelock delay;
  • a non-production UUPS upgrade gate that passed local-EVM tests for PKP authorization, delay enforcement, certificate replay rejection, cancellation, and exact upgrade execution;
  • deterministic commercial evidence export and independently signed witness receipts; and
  • reproducible release gates covering formatting, linting, tests, credential scanning, builds, and checksums.

Controlled-validation profile​

The earliest generic end-to-end engineering reference completes one policy-constrained treasury transfer. It remains implementation evidence, not the current commercial wedge. The current commercial product is Luvion Protocol Guard, beginning with protocol-upgrade and administrator-authority workflows through Upgrade Guard and Admin Guard.

The core authorization object also defines payout, signer rotation, policy change, emergency pause, emergency resume, and custom action identifiers. Those identifiers become product capabilities only after an operation-specific policy and execution adapter are implemented and accepted. The protocol-upgrade operation schema and acceptance scope are now frozen, and the UUPS gate has passed local-EVM validation. The dedicated upgrade Action now has a verified source bundle, an isolated Lit Group and PKP, a least-privilege usage key, a live Chipotle authorization receipt, a cross-language request vector, strict Unix transport, and a durable sidecar. A separate durable product state machine now distinguishes approvals, Luvion authorization, Lit/PKP gate authorization, on-chain scheduling, execution, cancellation, rejection, and expiry. It exports deterministic JSON and Markdown evidence and never represents a PKP signature as an executed upgrade. BSC testnet deployment and proof that every alternate upgrade path is closed remain P0 work. The authenticated HTTP API and persistent confirmed-event scanner are implemented locally. The testnet deployment preflight validates role separation, RPC identity, predicted contract addresses, deployment-data hashes, gas estimates, and deployer balance without reading a private key or broadcasting a transaction.

The current control-plane profile is single-tenant and designed for controlled validation. Key providers primarily use protected files or local sidecars. Production key custody progresses to HSM, KMS, TEE, or remote-attestation systems. Existing BSC evidence comes from automated tests and self-operated wallet trials; partner acceptance is the next validation gate.

The Lit path has completed a live Chipotle sandbox validation and a process-level recovery drill on the deployed pilot host. Its current capability is a PKP-signed validation receipt. Transaction construction and broadcast form the next Lit execution profile.

Experimental paths​

The 22-of-33 threshold ML-DSA path is an isolated research implementation that uses synthetic keys and retains a future migration point. Dynamic committee, incremental DKG, proactive resharing, and recovery paths currently provide implementations or state-machine tests at defined research maturity levels.

These capabilities remain part of the target architecture. Their experimental status limits current deployment claims; it does not remove them from the Luvion protocol design.

Production progression​

  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.

The Lit-backed production profile adds an approved transaction-construction and broadcast design, permission and PKP rotation drills, production monitoring, and external review.

See Release evidence for the release-gate baseline, completed integration validation, reviewer evidence, and the evidence roadmap.

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.