Luvion
Protocol Guard

Secure Critical Onchain Authority

Distributed authorization for protocol upgrades and critical admin actions. Available for scoped, non-production design-partner pilots.

Discuss a Protected Workflow Read the Documentation

Luvion checks policy, binds approval to the exact execution intent, requires high-threshold authorization, and produces verifiable evidence before execution.

Why Luvion

Signatures prove approval. Luvion proves what was authorized.

A signature threshold can confirm that enough signers approved a transaction. It does not by itself establish that the transaction matches the approved policy, intended operation, authorized roles and exact execution payload. Protocol Guard brings these elements into one authorization process before execution.

01

Approval threshold

Confirms that the required number of eligible participants approved the request.

02

Authorization context

Binds policy, intended operation, authorized roles, target contract, parameters, and execution payload.

03

Protocol Guard

Turns approval context and high-threshold authorization into one reviewable pre-execution process.

Luvion Protocol Guard

Authorization for the operations that control a protocol.

Protocol Guard brings policy, exact intent, approvals, and distributed authorization together before execution. Current delivery is a controlled pilot, beginning with protocol upgrades; each additional operation needs its own adapter and acceptance.

Product boundary

Control what can execute, not just who can sign.

Protocol Guard manages a canonical authorization intent for a defined critical operation. It is not a general wallet, custody platform, audit service, or transaction-monitoring product.

  • PolicyEvaluate the requested operation against a defined policy before authorization begins.
  • IntentBind approval to the exact operation, target, parameters, payload, policy version, and validity period.
  • ApprovalsSeparate initiation, role approvals, authorization, and execution responsibilities.
  • ThresholdRequire a configurable high-threshold authorization over the same canonical intent.
  • HandoffProduce an authorization certificate and evidence before controlled execution handoff.

How It Works

Critical actions should be authorized by networks, not keys.

This is Luvion's target network architecture. Protocol Guard organizes each protected operation into one explicit authorization path without implying that a mature independent 33-node production network is already live.

  1. 01

    Canonical Intent

    Bind the operation, target, parameters, payload, policy version, validity, nonce, and approval context.

  2. 02

    Policy Evaluation

    Evaluate the exact request against the policy that governs the protected operation.

  3. 03

    Separated Approvals

    Collect the required role approvals without collapsing initiation, approval, authorization, and execution.

  4. 04

    Dynamic Committee Selection

    Experimental target: select an epoch-bound committee. Current controlled FROST pilots use a fixed participant configuration, not automatic rotation or replacement.

  5. 05

    High-Threshold Authorization

    Authorize the same canonical intent under the threshold policy for that session.

  6. 06

    Controlled Execution Handoff

    Present the authorization certificate to the configured execution control point.

  7. 07

    Verifiable Evidence

    Record what was authorized, which policy applied, and whether execution matched the approved intent.

Protected Operations

Protect the Actions That Control a Protocol

Protocol upgrades have controlled validation evidence. The other operations below are design-partner expansion scopes, not ready-made production integrations.

01Protocol Upgrades

Controlled validation. Bind upgrades to an exact payload. Old-Gate BSC testnet evidence uses a 1-of-1 sandbox authorization certificate; distributed end-to-end partner enforcement still needs acceptance.

02Administrator and Role Changes

Partner-specific design. Bind role and owner changes to policy and approvals after implementing and accepting the required adapter.

03Mint and Burn Permissions

Expansion scope. Supply-authority and mint/burn workflows require a dedicated policy, execution adapter, and acceptance tests.

04Oracle and Risk Parameter Updates

Expansion scope. Feed, collateral, and limit changes require protocol-specific policies, adapters, and acceptance.

05Emergency Controls

Expansion scope. Pause and recovery controls require an accepted emergency policy and execution boundary, including tests of alternate authority paths.

Integration

Connect Authorization to Existing Execution Infrastructure

These are integration targets, not an installed adapter catalog. Non-bypassable protection requires a verified execution point and technical closure of every alternate route for the same operation. Listing an emergency key as an exception does not close that bypass. Check integration status.

Reference designSafe Module or Guard
Reference designTimelock
Controlled validationUUPS Upgrade Gate
Partner-specific designOther Proxy and Admin Controls
Luvion Protocol Guard Authorization certificate verified before controlled execution handoff
OutputControlled Execution Handoff
OutputAuthorization Certificate
OutputVerifiable Evidence
OutputIntent-Execution Match

Use Cases

Focused on protocols with critical onchain authority.

Potential design partners include DeFi protocols, stablecoins and asset issuers, and bridges or cross-chain infrastructure. The examples below describe workflows to validate, not existing customers or completed integrations.

01

DeFi Protocols

Protect upgrades, administrator roles, oracle settings, risk parameters, and emergency controls.

02

Stablecoins and Asset Issuers

Protect supply permissions, issuer administration, reserve controls, and critical parameter changes.

03

Bridges and Cross-Chain Infrastructure

Protect bridge administration, signer rotation, route controls, mint and burn authority, and emergency actions.

Design Partner Pilot

Validate One Critical Workflow With Luvion

A design-partner pilot focuses on one defined operation, such as a protocol upgrade, administrator change, mint or burn permission, risk parameter update or emergency control. Together, we define the policy, convert the operation into canonical intent, run controlled authorization, inspect the resulting evidence and assess the required execution adapter.

Explore a Design Partner Pilot
  1. 01

    Choose the Operation

    Select one protocol upgrade or critical admin action with a defined execution boundary.

  2. 02

    Define Policy

    Set eligible roles, approval requirements, limits, validity, and evidence requirements.

  3. 03

    Bind Intent

    Convert the exact operation and execution payload into canonical intent with separated approvals.

  4. 04

    Run Authorization

    Exercise the configured high-threshold path under controlled, non-production conditions.

  5. 05

    Review the Result

    Inspect evidence, adapter requirements, bypass assumptions, and next-step integration scope.

Technical Depth

High-threshold architecture remains central to Protocol Guard.

Commercial focus narrows the first protected workflows. It does not remove configurable thresholds, dynamic committees, key lifecycle, recovery paths, execution adapters, or verifiable evidence from the Luvion target architecture.

Threshold policy

Configurable High-Threshold Authorization

Protocol Guard has controlled 3-of-5 FROST process tests and 22-of-33 FROST authorization-certificate tests. These are separate from the old-Gate BSC testnet upgrade flow, which used a 1-of-1 sandbox certificate. They do not establish an independently operated, high-threshold production network. The 22-of-33 profile is a reference, not a mandatory customer configuration. Threshold ML-DSA remains experimental research using synthetic keys.

Target network architecture

Dynamic Committee Authorization

Luvion's target architecture uses dynamic committees to prevent protected authority from remaining under one fixed signer group. Committee selection, rotation, threshold locking, resharing, recovery and coordinator failover remain part of the Luvion technical architecture. Their current implementation status is distinguished from the target production architecture below.

Demonstrated 3 of 5

Controlled FROST Ed25519 design-partner pilot path.

Tested 22 of 33

High-threshold FROST authorization-certificate reference path.

Experimental ML-DSA

Synthetic-key research path with unresolved production blockers.

Target Dynamic

Committee selection, rotation, recovery, and failover architecture.

Technical Overview

Target architecture and current evidence, clearly separated.

Luvion is currently under controlled, non-production validation. Public materials do not claim completed third-party audit, production custody readiness or live mainnet asset protection.

Architecture layer 01Authorization Semantics
  • ImplementedCanonical intent, policy evaluation, separation of duties, role approvals, session binding, replay protection, and no-blind-signing requirements.
Architecture layer 02Dynamic Network and Key Lifecycle
  • ImplementedConfigurable threshold policy in the current FROST authorization path.
  • Tested22-of-33 high-assurance FROST reference profile and key-epoch validation.
  • ExperimentalDynamic committee selection, committee rotation, proactive share refresh and resharing, participant reconfiguration, incremental DKG, recovery paths, and coordinator failover.
Architecture layer 03Execution and Evidence
  • ImplementedAuthorization certificates, hash-linked evidence export, and an independent witness protocol in a controlled environment.
  • DemonstratedControlled execution handoff and execution receipts in bounded testnet or sandbox paths.
  • TestedWitness interruption recovery, rollback detection, and intent-execution matching.
  • TargetConditional mandatory enforcement after the execution endpoint verifies Luvion authorization and legacy bypass paths are closed.
  • PlannedPartner-specific execution adapters for Safe, Timelock, proxy, and protocol administration control points require partner acceptance.
Architecture layer 04Algorithm Agility
  • ImplementedFROST Ed25519 is the current commercial signing path.
  • DemonstratedControlled 3-of-5 FROST Ed25519 pilot path.
  • Tested22-of-33 FROST authorization-certificate reference path.
  • TargetThreshold ECDSA, hardware-protected signers, and external custody backends remain within the target architecture.
  • ExperimentalThe threshold ML-DSA research path uses synthetic keys and is not production-ready cryptography.

Documentation

Review the product model, protocol architecture, implementation status, validation evidence, and integration path.

Open documentation

Request Technical Materials

Discuss controlled evidence, known limitations, adapter scope, and review requirements.

Request materials

Extended Contexts

Protocol foundations, custody platforms, treasury controls, payments, and institutional asset infrastructure remain extension contexts rather than the homepage's primary market focus.

Follow Updates

Product updates, incident analysis, and technical progress are published through X.

Open X