Target architecture and deployment profiles
Luvion's target architecture is a decentralized, algorithm-neutral, high-threshold authorization network for critical digital asset operations. It is designed to connect independently operated nodes, dynamic committees, business approval and verifiable execution across protocol administration, asset issuance, institutional treasury and custody workflows. Luvion Protocol Guard is the first product built on that architecture, not its full long-term scope.
This page describes the target protocol and its deployment profiles. Current evidence is recorded in the compatibility matrix and implementation status.
Architecture overview
Architecture layers
| Layer | Responsibility |
|---|---|
| Authorization control plane | Canonical intent, policy evaluation, separated approvals, request state, and evidence export |
| Distributed authorization protocol | Committee selection, threshold signing, key epochs, refresh, reconfiguration, and recovery |
| Execution adapters | Safe, timelock, proxy, bridge, mint and burn, custody, or equivalent enforcement points |
| Evidence and verification | Authorization certificates, execution receipts, independent witnesses, and intent-execution matching |
Standard authorization path
Canonical Intent
-> Policy Evaluation
-> Separated Approvals
-> Active Committee and Key-Epoch Binding
-> High-Threshold Authorization
-> Intent-Bound Authorization Certificate
-> Controlled Execution Handoff
-> Verifiable Evidence
This is the per-operation path. The target network selects and activates committees by epoch; requests bind to that active configuration. Committee rotation, share refresh, reconfiguration and recovery belong to the separate network lifecycle, not to a new selection or refresh for every request. Controlled pilots use a fixed participant configuration.
Controlled pilots use a controlled execution handoff. Mandatory, non-bypassable enforcement requires the target execution point to verify Luvion authorization. Every alternate path for the same protected operation must be removed, revoked or migrated behind the same mandatory check, then verified by bypass tests.
Deployment profiles
| Profile | Purpose | Current evidence boundary |
|---|---|---|
| 3-of-5 pilot profile | Controlled design-partner validation | Demonstrated on controlled infrastructure; not an independent production network |
| 5-of-7 launch profile | Early multi-operator launch configuration | Authorization-certificate path tested; production operator independence and key custody remain gates |
| 22-of-33 high-assurance profile | Whitepaper reference for operations that cannot accept small-group control risk | FROST authorization-certificate path tested; not a live 33-node production network |
Thresholds remain configurable by operation risk. The 22-of-33 profile is a high-assurance reference, not a mandatory configuration for every customer.
Initial customer focus and expansion
Protocol Guard initially targets cross-chain protocol teams, starting with critical administrative operations such as receive-configuration changes, contract upgrades and administrator-authority changes.
The first customer workflow is a cross-chain receive-configuration change. The cross-chain configuration walkthrough describes its validation path. EVM protocol upgrades provide a separate engineering reference: the V3 Gate and UUPS path have been exercised on BSC testnet. The implementation status separates evidence for each workflow from customer deployment and acceptance.
The same authorization architecture can extend to asset issuance, emergency controls, institutional treasury and custody workflows as their policies, adapters and execution boundaries are validated. See Nodes, target network and economics for operator responsibilities and the formal-network direction.