Compatibility matrix
This matrix separates tested pilot behavior from interfaces, reference designs, and research paths. It is the source of truth for external capability claims.
Status vocabulary
| Status | Meaning |
|---|---|
| Controlled validation | Implemented and covered by automated or recorded non-production tests |
| Interface defined | Contract and validation rules exist; a named partner implementation is still required |
| Reference design | Integration and security requirements are documented; partner enforcement acceptance is the next gate |
| Experimental | Research-only; prohibited for real keys or production assets |
None of these labels means production readiness, third-party audit completion, or acceptance by a named design partner.
Capability matrix
| Component or path | Current status | Evidence available now | Missing before production |
|---|---|---|---|
| Policy, roles, approvals, request state, and evidence export | Controlled validation | Deterministic tests and reproducible release evidence | Multi-tenant admission, production operations, external audit, partner acceptance |
| FROST Ed25519, 3-of-5 on one controlled host | Controlled validation | Real process tests, restart recovery, signer replacement, aggregate verification | Independent machines, administrators, failure domains, and protected key hardware |
| FROST Ed25519, 5-of-7 and 22-of-33 certificate profiles | Controlled validation | RFC 9591 authorization-certificate tests for both profiles | Independent operator deployment, production DKG, protected key custody, load and fault evidence |
| Algorithm-neutral signer backend | Controlled validation | FROST backend and stable backend boundary | Reviewed threshold ECDSA, hardware signer, or external custody implementations |
| Dynamic committee selection and rotation | Experimental | Research implementations and state-machine tests | Governed candidate registry, bias-resistant randomness, Sybil controls, multi-operator rotation drills |
| Proactive resharing and incremental DKG | Experimental | Research implementations and lifecycle tests | Reviewed production protocol, participant-isolated ceremony, complaint handling, HSM/KMS custody |
| Remote FROST signer transport over pinned mTLS | Controlled validation | TLS 1.3, leaf pinning, signed envelopes, bounded requests | Multi-host deployment, capacity controls, metrics, certificate automation, external review |
| Registry, key-epoch, and certificate lifecycle | Controlled validation | Staging, overlap, activation, revocation, expiry, rollback rejection | Multi-operator approval, automated issuance, trusted time, HSM/KMS-backed identities |
| Independent evidence witness transport | Controlled validation | Signed receipts, exact retry, restart recovery, rollback detection | Separately administered retention-locked or WORM service |
| Restricted BSC ERC-20 wallet handoff | Controlled validation | Self-operated testnet and restricted wallet workflow with receipt reconciliation | Named partner environment, production key custody, operational acceptance |
| Vendor-neutral custody adapter | Interface defined | Stable request binding, idempotency, outcome and completion semantics | Provider mapping, authenticated transport, sandbox implementation, partner sign-off |
| Optional Lit PKP validation backend | Controlled validation | Live Chipotle sandbox validation, immutable Action binding, durable reconciliation, rotation drill | Reviewed transaction construction and broadcast path, monitoring, external review |
| Safe module, guard, or timelock verifier | Reference design | Exact certificate-binding and bypass requirements | Reviewed onchain verifier, testnet enforcement, bypass closure, partner acceptance |
| Operational alert webhook | Controlled validation | Durable deduplication, degraded/reminder/recovered transitions, restart recovery | Real alert destination, on-call ownership, escalation and response drills |
| Threshold ML-DSA path | Experimental | Research tests only | Standardized construction, external cryptographic review, production implementation |
Integration decision rule
Start a design-partner pilot only when one row maps to a specific operation, owner, environment, and acceptance test. Do not combine several unaccepted paths into one pilot and describe the result as an end-to-end production system.
For any execution integration, first complete the non-bypassable checklist. If an owner, emergency key, legacy module, or provider credential can execute the same operation around Luvion, that path remains outside Luvion protection.