ProofPatch
V3 consoleLaunch app
LIVE ON GENLAYER BRADBURY

Code can change.
Trust shouldn't.

ProofPatch is a semantic upgrade firewall for GenLayer Intelligent Contracts. An exact candidate becomes live code only after trusted evidence, validator consensus, finality and post-install proof.

Launch ProofPatch Read the architecture
No admin-key bypass
Exact-byte install
Finality-gated consequence
proofpatch / live release BRADBURY
PROTECTED TARGETProofPatch Protected Target
ACTIVE
registeredv2.0.09da36f6983…f353c9fe
activev2.0.09da36f6983…f353c9fe
SOURCEPASS
POLICYPASS
BINDINGSPASS
FINALITYPASS
ACTIVEPASS
01

Registration finalized

02

Policy materialized

03

Target active

FACADE0x46eE236d…c6ea8c6D
TARGET0x9e8ACf20…029BCf4f
STATEACTIVE
RELEASE2.0.0
THE ADMIN-KEY BLIND SPOT

A code hash proves bytes.
It does not prove permission.

Upgradeable contracts usually answer “who can change code?” ProofPatch answers the harder question: “what must be proven before these exact replacement bytes are allowed to become the contract?”

01

Integrity ≠ authority

Matching a hash can prove the bytes are unchanged. It says nothing about whether the publisher is trusted or the change is semantically safe.

02

Schema ≠ semantics

A candidate can preserve interfaces while adding a privilege path, weakening evidence rules or changing user rights.

03

Accepted ≠ final

Consensus decisions remain appealable. Irreversible installation must be bound to protocol finality, not an early status badge.

HOW PROOFPATCH WORKS

A six-stage path from candidate to consequence.

Each stage removes a different class of upgrade risk. None is allowed to impersonate another.

01

Register the protected target

The target binds ProofPatch as its sole upgrade authority and registers an immutable security policy from the target itself.

gateREQUIRED
02

Freeze candidate + evidence

Candidate bytes, immutable source URL, CI evidence and independent audit evidence become one proposal envelope.

gateREQUIRED
03

Verify provenance first

Approved publisher namespaces, immutable references, evidence IDs, freshness windows and corroboration are checked before semantics can matter.

gateREQUIRED
04

Reach exact semantic consensus

Leader and validators independently evaluate the consequential safety vector. Authorization-driving values must agree exactly.

gateREQUIRED
05

Wait for finality

Acceptance is provisional. The upgrade call is emitted only through the finality path—never merely because a committee accepted a receipt.

gateREQUIRED
06

Re-hash, install, confirm

The target re-fetches approved bytes, hashes them again, installs the exact candidate, then sends a finality-bound confirmation back to ProofPatch.

gateREQUIRED
SECURITY MODEL

Designed to fail closed.

ProofPatch binds evidence trust, exact consequences and recovery rules into the same upgrade policy instead of relying on reviewer convention.

Publisher-bound evidence

Source, CI and independent audit authorities are policy-bound before a proposal can influence execution.

Immutable/versioned records

Candidate and evidence URLs must resolve through approved immutable repository prefixes.

Freshness + replay resistance

Evidence carries publication/expiry rules and scoped identifiers that cannot be reused for the same authority and target.

Repairable evidence failures

Correctable fetch, parse and hash failures move the proposal into a repair state instead of forcing an unsafe terminal path.

Exact consequential agreement

The candidate hash and authorization-driving semantic result are exact values, never fuzzy confidence thresholds.

Finality before consequence

The upgrade message is finality-bound; acceptance alone cannot replace the protected target code.

DOCUMENTATION

Understand the system before you launch it.

This landing page is intentionally part product page, part operator manual. The app should never ask a user to sign something they do not understand.

01 / Security model

A semantic firewall, not an admin multisig.

ProofPatch separates integrity from authorization. SHA-256 tells the target which bytes it received; policy-bound evidence and validator consensus decide whether those exact bytes are permitted to become live code.

02 / Evidence

Authority is explicit.

The policy binds distinct source, CI and independent-audit authorities plus immutable repository prefixes. Evidence has stable IDs, freshness limits and replay resistance. A URL or hash by itself is never treated as proof of authority.

03 / Repair + recovery

Correctable failures stay correctable.

Fetch, parse and hash problems can move a proposal into a repair/retry state without changing the frozen candidate bytes. TTL and execution deadlines prevent stale proposals from holding an upgrade path indefinitely.

04 / Consensus

Exact consequences require exact agreement.

The semantic review evaluates storage compatibility, user rights, privilege paths, upgrader authority, evidence trust, finality safety, liveness and hidden value movement. Consequential values are not accepted through fuzzy tolerance.

05 / Finality

Accepted is not installed.

A review decision can be accepted while still appealable. ProofPatch does not emit the upgrade consequence on acceptance. Installation is reached through finality, and a separate post-install confirmation proves the target persisted the approved proposal/hash.

06 / Product UX

The UI follows the protocol lifecycle.

The application keeps a submitted transaction ID, never blindly retries after submission, refreshes responsive non-final state after decisions and refreshes durable finalized state after finalization—without requiring a browser reload.

REFERENCE FLOW

Consensus → finality → install → confirmation

review_proposal(#1)
    ↓ validators agree on exact consequential result
Accepted (appealable)
    ↓ protocol finalization
proofpatch_upgrade(#1, approved_sha256)
    ↓ target re-hashes approved bytes + replaces code
confirm_install(#1, installed_sha256)
    ↓ confirmation finalizes
VERIFIED / INSTALL_VERIFIED
DEPLOYED REALITY

Don't trust the landing page. Read Bradbury.

The product UI reads finalized governor and target state and checks the same values preserved in the independent final audit.

LIVE BRADBURY PROOF

Repository claims meet finalized V3 state.

Reading chain
Current release—
Registration—
Active proposal—
Release ID—
Registered SHA-256—
Registration recordUnavailable
Policy fingerprint—
Target modeUnavailable

Reads use finalized Bradbury state. No historical V1 value is substituted.

READY TO INSPECT THE LIVE SYSTEM?

Open the actual ProofPatch workspace.

Read finalized state without a wallet. Connect only when an authorized action genuinely requires a signature.

Launch ProofPatch