Skip to main content

How Luvion works

Luvion separates the meaning of an authorization from the cryptographic backend used to produce it. Every protected operation follows one request-bound state machine. The numbered steps describe a single authorization request. Committee rotation, share refresh and recovery are a separate lifecycle, described after the request flow; they are not repeated stages of every operation. Current validation does not establish a fully deployed production network.

1. Canonicalize the intent​

The adapter converts an external operation into a deterministic record. The record binds the operation type, chain, target, parameters, policy version, validity window, nonce or replay boundary, participant set, and key epoch.

Two operations that differ in any protected field must produce different intent digests.

2. Evaluate policy and roles​

The control plane evaluates the exact policy version associated with the request. It verifies eligible roles, approval thresholds, initiator separation, destination or target restrictions, expiration, and any external risk inputs.

Rejected, conflicting, expired, or replayed requests fail closed.

3. Collect separated approvals​

The required business roles approve the same intent under the bound policy. Initiation, approval, authorization and execution remain separate where the policy requires it. A business approval is not a node's partial signature; meeting the business approval rule does not remove the cryptographic threshold.

4. Bind the active committee and collect high-threshold authorization​

Eligible signer participants verify the same intent digest and session transcript, including the active participant set, threshold and key epoch. An authorization cannot be moved to a different committee or key epoch. Each participant contributes a partial signature without exposing a complete signing key. The coordinator can assemble an authorization only after the required threshold is reached.

The signer interface is algorithm-neutral. The currently tested path uses FROST Ed25519; other threshold schemes, hardware signers and external custody backends require their own implementation and review.

5. Issue an authorization certificate​

A successful session produces an authorization certificate and evidence bundle that bind:

  • the canonical intent and policy decision;
  • approvals, signer set, threshold, key epoch, and session transcript;
  • the final threshold signature or backend authorization output; and
  • the request identifier used for idempotent execution and reconciliation.

6. Enforce before execution​

The critical authority must be migrated or bound to an enforcement point such as a protocol administration module, Safe module, timelock, bridge management layer, mint/burn controller, custody endpoint, or equivalent wrapper.

A legacy owner or emergency key that can execute the same protected operation without Luvion authorization creates a bypass. Remove that path or subject it to the same authorization checks.

7. Reconcile and retain evidence​

The execution adapter verifies that the final operation matches the authorized intent, submits or reconciles it idempotently, and binds the resulting receipt or onchain event back to the original request.

Evidence witnesses can retain signed terminal receipts to make tampering detectable. Production independence requires separately administered witnesses; same-host test processes do not establish that independence. Provider acceptance or broadcast alone is not confirmed onchain execution; evidence must state the adapter's exact completion semantics.

Conceptual flow​

critical operation request
  -> canonical intent
  -> exact policy and separated approvals
  -> active committee, threshold and key-epoch binding
  -> configured FROST threshold authorization (controlled pilot)
  -> intent-bound authorization certificate
  -> execution module or adapter (deployment-specific acceptance required)
  -> precisely labelled receipt and evidence

Separate target lifecycle: rotate, refresh, and recover​

The target network selects and activates committees by epoch. A request uses the active configuration; it does not itself imply a new random selection, share refresh or membership change. Lifecycle changes require their own activation and session-isolation rules.

Dynamic selection, proactive refresh/resharing, and automatic replacement are experimental, not current production capabilities. The target lifecycle aims to rotate epoch-bound committees and restore availability without reconstructing a master key or lowering the threshold. Controlled restart or manual replacement tests must not be described as automatic committee failover.

See Dynamic committees and key lifecycle and Nodes, target network and economics.