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.

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 distributed authorization​

Eligible signer participants verify the same intent digest and session transcript. 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. A deployment can use FROST Ed25519, another reviewed threshold scheme, a hardware remote signer, or an external custody authorization mechanism with an explicitly documented security model.

4. 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.

5. 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.

If a legacy owner or emergency key can execute the same protected operation without Luvion authorization, that path is outside the Luvion security boundary.

6. 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.

Independent evidence witnesses can retain signed terminal receipts so a local operator cannot silently rewrite or delete the history.

Conceptual flow​

critical operation request
  -> canonical intent
  -> exact policy and separated approvals
  -> high-threshold distributed authorization
  -> intent-bound authorization certificate
  -> mandatory execution module or adapter
  -> execution receipt and independent evidence