Nodes, target network and economics
Luvion is building decentralized, high-threshold authorization infrastructure for critical digital asset operations. The target network aims to reduce dependence on a single key or fixed small group while keeping each authorization bound to an exact operation, policy and execution boundary. Protocol Guard is the first product on this architecture, starting with EVM upgrades and high-risk administrator operations. The network's long-term scope also includes asset issuance, institutional treasury and custody workflows.
What nodes do
In the target network, independently operated nodes hold authorization-key shares, validate the bound intent and session context, and contribute partial signatures under the active committee's rules. Only a sufficient set of valid contributions can produce the required threshold authorization.
These nodes do not produce blocks for the target blockchain or replace the customer's business approvers. In the default architecture they authorize operations through a Luvion certificate, rather than take custody of the customer's complete asset key. Execution still needs a reviewed Gate or adapter. In particular, a FROST Ed25519 certificate is not an EVM-native transaction signature.
Three distinct responsibilities
| Layer | Responsibility |
|---|---|
| Business approval | Designated customer roles approve the exact operation under a defined policy, with separation of duties. |
| High-threshold authorization | Eligible signing participants jointly produce a cryptographic authorization bound to the same intent, policy and key epoch. |
| Operator independence | Distinct administrators, infrastructure, failure domains and key protection reduce shared control and correlated failure. |
Signing-share counts do not directly equal business-approver counts or the number of independent organizations. More processes on one host do not create more independent operators. A higher threshold alone does not establish better security: admission, correlated control, availability, key protection and recovery also matter.
Dynamic committees and key lifecycle
The target design selects and activates epoch-bound committees from a governed candidate pool. Each authorization uses the active participant set, threshold and key epoch. Committee rotation, proactive share refresh, participant reconfiguration and coordinator failover support the network over time; a request does not imply that all these lifecycle operations run again.
Admission and rotation need auditable rules and operator-independence checks. Rotation cannot remove shared control if the candidate pool is itself correlated. Proactive share refresh is not a remedy for an already exposed complete private key; that requires revocation and a new-key migration. See Dynamic committees and key lifecycle.
Network direction and present evidence
The 3-of-5, 5-of-7 and 22-of-33 FROST authorization-certificate profiles have controlled test evidence. The reviewed five-process signer profile shares one host and administration domain. This is not a live independent-operator production network. The 22-of-33 profile is a high-assurance reference, not a mandatory configuration for every customer.
An independent-operator testnet, cross-operator ceremonies, protected key infrastructure, operational drills and external security review remain progression requirements. Dynamic selection, rotation and proactive resharing remain experimental. Current evidence is recorded in the implementation status and compatibility matrix.
Progression to independent operation
| Stage | Engineering work | Acceptance evidence |
|---|---|---|
| Current controlled profile | Fixed signer processes, authenticated transport, DKG and certificate lifecycle checks. | Versioned test results and reproducible failure cases. |
| Independent operator testnet | Separate administrators, machines, identities and protected share custody. | Cross-operator DKG, offline-node and coordinator-failure drills; documented ownership of each failure domain. |
| Committee lifecycle | Governed admission, epoch activation, refresh and participant reconfiguration. | Replay and rollback rejection across epochs, auditable selection and recovery records. |
| Partner execution | Integrate one protected operation with a reviewed verification path. | Closed bypass routes, exact execution and recovery evidence accepted by the partner. |
| Production network | External review, monitoring, on-call ownership and tested key recovery. | Remediation closure, operational drills and agreed service obligations. |
The stages describe the engineering sequence. Network participation and launch dates follow their acceptance results.
Planned role of LUV
Luvion plans to introduce its native token, LUV, with the formal launch of its decentralized authorization network. No token has been issued and no TGE date has been announced. Controlled pilots and early software integrations do not depend on a token.
Proposed functions include operator admission bonds and staking, rewards for verifiable security services, accountability for objectively provable malicious behavior, protocol-level settlement and governance over non-critical network matters. These are design directions, not finalized production mechanisms.
Stake size must not directly determine signing authority or allow holders to override the protected operation's authorization policy. Correct security refusals should not be penalized; ordinary downtime should not automatically trigger slashing without reliable attribution. Governance does not substitute for the required business approvals or cryptographic threshold.
Supply, allocation, vesting, unlocks, reward and penalty parameters remain subject to economic, security and legal review. Network launch, public sale, transferability and exchange arrangements are separate decisions. This page does not announce a sale, listing or investment return.
Software services and network economics
The business model combines scoped integration services and annual platform services for protected authority domains, with optional additional integration, dedicated deployment and support. Early software services can be paid for in fiat or stablecoins. The bounded free design-partner program has its own written scope and licence conditions.
Network authorization services may add a separate revenue stream after the formal network is established. Customer software pricing, network fees and operator incentives are distinct mechanisms.