Worked example: protocol upgrade

This controlled-pilot integration shows how Luvion protects one proxy upgrade. The current local implementation includes the canonical upgrade object, role-separated approval state machine, authenticated HTTP API, Luvion certificate, Lit/PKP gate-authorization contract, durable sidecar, evidence export, and a local UUPS gate test.

The dedicated Lit Action has completed a live Chipotle authorization run. August 9–10 records cover an older immutable-PKP Gate and BSC test proxies with exact scheduling/execution and a separate cancellation flow. Those tests used an internal 1-of-1 sandbox authorization certificate. They do not demonstrate the illustrative 3-of-5 design below end to end. The new signer-epoch / PKP-rotation Gate has local tests; public-testnet deployment and rotation validation for that version remain pending in the reviewed records. The HTTP API enters gate_authorized after Lit validation. A caller may then submit only a transaction hash; the configured observer independently verifies the chain, gate runtime-code hash, successful receipt, exact event, block time, confirmation depth, and operation binding before recording scheduled, executed, or cancelled. The service can also discover confirmed events from the fixed Gate with a private persistent block cursor. A scan range advances only after every matching event passes full receipt verification and the state transition is durably stored. The old-Gate BSC testnet records include main-RPC failure fallback and forced process restart recovery. Whole-host operational drills and partner acceptance remain outstanding. See Current implementation status for the separate version and environment boundaries.

Scenario

This is an illustrative partner acceptance design, not a report of a deployed mainnet integration. All addresses below are placeholders.

A protocol intends to upgrade proxy 0xProxy on chain eip155:1 to reviewed implementation 0xImplementationV2. The operation must use policy upgrade-mainnet-v3, receive one protocol approval, one security approval, and a 3-of-5 authorization before a timelock can execute it.

1. Build the canonical intent

The adapter binds:

• chain and proxy address;
• new implementation address;
• exact encoded call data and its hash;
• code hash or reviewed build identifier;
• policy version and approval-context hash;
• timelock delay and validity window;
• nonce, request ID, participant set, and key epoch.

Changing the implementation, initializer, call data, chain, or policy produces a different digest and invalidates prior approval.

2. Evaluate policy

The policy checks the permitted proxy, approved implementation/code hash, required role separation, maintenance window, timelock delay, and any external risk or review evidence. Missing, altered, expired, or conflicting data fails closed.

3. Collect approvals and authorization

Eligible protocol and security reviewers approve the same digest. After the role threshold is met, distributed signers verify the request and produce an intent-bound authorization certificate. The coordinator alone cannot create a valid certificate.

4. Enforce at the execution boundary

An accepted execution module must verify authorization and the exact call. The controlled UUPS Gate path uses Lit/PKP gate authorization; Safe modules, generic timelock verifiers, and other administration adapters remain integration-specific reference designs until implemented and accepted.

Complete protection places every proxy-administrator path, including legacy owners and emergency keys, behind the same verification boundary.

5. Execute and retain evidence

The adapter submits or reconciles the authorized operation using the stable request ID. The final evidence package binds the policy decision, approvals, certificate, timelock transaction, chain receipt, implementation address, code hash, and witness receipt.

In the controlled pilot, evidence can be exported after gate authorization. It records chain states only after the observer verifies a matching confirmed transaction, and otherwise explicitly states that no on-chain schedule or execution has occurred.

Acceptance tests

Test	Expected result
Exact reviewed upgrade	Authorized and executed after timelock
Changed implementation or initializer	Rejected before execution
Missing security approval	Authorization unavailable
Reused certificate	Rejected as consumed or replayed
Expired validity window	Rejected and recorded as expired
Coordinator restart	Same request resumes without mixed transcripts
Execution response lost	Reconciled by request ID, not blindly resubmitted
Direct legacy-owner path	Pilot fails non-bypassability acceptance

The same authorization principles can inform signer rotation, mint/burn, bridge, or emergency-control designs. Each extension still requires its own threat model, policy, adapter implementation, and enforcement acceptance; changing an operation identifier alone does not deliver a new integration.