Review a cross-chain configuration change
Protocol Guard applies Luvion's authorization model to protocol upgrades, administrator operations and cross-chain configuration. This walkthrough follows one concrete change: raising the receive-confirmation count for a fixed OApp from 20 to 32, while retaining the other configuration values.
Open the interactive demo · Inspect the example source
The example uses an isolated local EVM chain with chain ID 31337, test identities and a local attestor. It changes configuration; it does not send cross-chain messages or move assets. The confirmation counts and 60-second delay are demonstration settings.
Follow one operation
| Step | What is checked | What to inspect |
|---|---|---|
| Prepare | Endpoint, OApp, receive library, remote EID and the current configuration are fixed. | Before/after values, baseline hash, configuration hash, nonce and validity window. |
| Approve | Distinct issuer and operator addresses approve the same operation digest. | Both business ECDSA approvals and the exact change they cover. |
| Authorize | The service checks approvals and constructs a PolicyChange intent. Controlled local 3-of-5 FROST produces the authorization certificate. | Intent, certificate digest, aggregate signature and session evidence. |
| Schedule | A local attestor binds the operation digest to the certificate digest. The Gate checks business approvals, attestation and current state. | Scheduling receipt, consumed nonce/certificate and readyAt. |
| Execute | After the delay, the Gate rechecks expiry, cancellation, permissions, baseline and payload. | Endpoint.setConfig transaction, events and final configuration. |
| Review | Compare the requested change with the receipt and effective configuration. | Exported evidence tied to the same request. |
The hosted client waits through the delay. The standalone contract test runner advances local test time. An uncertain transaction result is reconciled before another action is attempted.
What is verified where
FROST authorizes a structured intent off-chain. The EVM Gate checks the two business signatures and the local attestor's signature over the operation/certificate binding. The Gate does not directly verify the FROST certificate. The attestor is an explicit trust point; the demo identities share one administration domain.
The Gate digest binds chain ID, Gate, policyHash, Endpoint, OApp, library, EID, beforeHash, configHash, nonce and validity times using Keccak-256 and ABI encoding. Business signatures use Ethereum Signed Message. Canonical encoding, ordered nonzero test DVN addresses and the allowed confirmation range are also checked.
Inspect the source and recorded results
The public repository provides:
LuvionConfigGate.sol: policy binding, dual approvals, attestation, delay, baseline checks, replay handling and cancellation.LuvionClientConfigGate.sol: revocation before scheduling through nonce consumption.review/check.mjs: contract checks and a real Safe 1.5.0 comparison.REFERENCE-REPORT.json: the recorded contract-test results and source hashes.
Source can be read directly on GitHub. The repository's current licence and evaluation-permission instructions govern copying and running the sample. Its standalone runner uses a synthetic attestation and does not run the private FROST service. The source report, hosted session evidence and core tests cover different components.
Check that the relevant source hashes match the build identifiers in the evidence you are reviewing. A matching hash helps identify the source; it is not an independent attestation of a hosted deployment.
Rejection and cancellation cases
Review missing approvals, changed payloads, stale baselines, premature execution, expiry, replay and cancellation. The client Gate supports revocation before scheduling; the base Gate supports cancellation after scheduling. Neither action reverses a completed change.
Ownership migration also needs a delegate check: transferring OApp ownership alone can leave the previous Endpoint delegate active. The sample explicitly tests this gap before activation replaces that delegate. A partner deployment needs an atomic or otherwise reviewed migration procedure.
What the comparison measures
Safe already rejects insufficient approvals, altered calls and replays. In the October 23 local comparison, adding a timelock and state-checking adapter to Safe also rejected stale baselines and out-of-policy parameters. The Luvion demonstration Gate used more execution gas in that comparison.
The practical question for a partner pilot is whether a combined workflow reduces manual preparation, tool switching, repeated checks and evidence compilation. Measure those steps using the same operation and existing tools. See Release evidence for the dated results.
Next integration step
For a partner trial, select one configuration change and agree on policy, authority migration, the attestation or verification path, failure recovery and acceptance tests. The fixed-policy demonstration provides a reviewable starting point. Start a controlled pilot.