When does a fix proposal auto-approve instead of requiring a vote?

When the reported vulnerability's class has an active, registered fix template and auto-approval is globally enabled. In that case the proposal is approved immediately on submission rather than entering the normal voting period.

What happens for a vulnerability class with no registered template?

The proposal enters a fixed voting period during which addresses holding a voter role cast approve or reject votes; the proposal is approved once a minimum approval count is reached, or finalized as approved or rejected once the voting deadline passes based on which side has more votes.

Can an already-approved fix still be stopped before it executes?

Yes. A default-admin-held veto can move any proposal that has not yet reached the executed state - including one that was auto-approved - into a vetoed state, closing a window where a bad template or a compromised voter majority could otherwise force an upgrade through.

How is the actual code change applied on-chain?

Execution calls the target's UUPS upgradeToAndCall entrypoint with the approved new implementation address. The call is fail-closed: if the target does not expose the expected upgrade entrypoint, the new implementation has no code, or the upgrade call reverts, the entire execution reverts rather than silently no-op-ing.

Self-Healing Contracts with Templated Auto-Approval and Multi-Voter Veto Governance

Executive Summary

This claim is the governance-workflow refinement sitting directly on top of the Self-Healing Smart Contract detection system (Patent Claim 115): once a contract has been auto-paused, this layer decides whether and when a proposed fix may actually execute. A fix proposal for a vulnerability class with an active, registered fix template auto-approves immediately and becomes executable after a fixed timelock. A fix proposal for a vulnerability class with no registered template instead enters a bounded multi-voter governance period, requiring a minimum number of approving votes before it can proceed.

Critically, a veto authority independent of both paths can move any proposal - including one that auto-approved - into a vetoed state at any point before execution, so neither a stale template nor a captured voter majority can force an upgrade through without a final human check.

Core Innovation: Response speed is matched to actual novelty, not treated as a single fixed SLA - a known vulnerability class with a pre-vetted fix template ships fast under timelock, a novel vulnerability is deliberately slowed down for multi-voter review, and a veto remains reachable through both paths right up to the moment of execution.

Problem Statement

Governance for on-chain remediation faces a dilemma: requiring a full vote on every fix, even for well-understood, previously-patched vulnerability classes, adds delay that can matter when a contract is actively paused and losing usability by the hour; but auto-approving every fix without any human check invites exactly the kind of unilateral, silent contract rewrite that responsible on-chain governance exists to prevent. Most self-healing or auto-patching designs pick one extreme or the other rather than routing by actual novelty.

Vulnerability classes with pre-registered fix templates at genesis (reentrancy, overflow/underflow, access control)

1 hour

Minimum execution timelock after any approval, auto or voted, before a fix can be applied

100%

Of proposals - auto-approved or voted - that remain vetoable up until execution

Why Existing Solutions Are Insufficient

Uniform full-vote-every-time governance: treats a previously-solved, well-understood vulnerability class the same as a genuinely novel one, adding unnecessary delay when speed matters most.
Uniform auto-approve-everything designs: apply the same blanket trust to a known reentrancy fix and a completely novel exploit class, with no differential scrutiny and often no persistent veto path.
Vote-only governance without a post-approval veto: once a proposal clears its vote, there is no remaining check if the voter set itself is later found to have been compromised or misled before execution.

Technical Architecture

Fix-Proposal Lifecycle

Status	Meaning
Pending	Awaiting votes (no registered template for this vulnerability class, or auto-approval globally disabled)
Approved	Either auto-approved on submission (template path) or approved by vote (governance path)
Rejected	Voting deadline passed without reaching the minimum approval count
Executed	Approved fix applied on-chain via governed upgrade
Expired	Approved but the execution window elapsed before execution
Vetoed	Default-admin veto exercised at any point before execution, overriding either path

Templated Auto-Approval

Each vulnerability class - reentrancy, overflow/underflow, access control, oracle manipulation, flash-loan, logic error, storage collision - may have an active fix template registered by governance, each carrying a template hash, description, and running usage/success counters. A newly proposed fix auto-approves if and only if auto-approval is globally enabled and the proposal's vulnerability class has an active template. Auto-approved proposals become executable after a fixed execution timelock (default: 1 hour) plus a bounded execution window (default: 24 hours) before expiring.

Multi-Voter Governance Path

Without an active template, a proposal opens a fixed voting period (default: 24 hours) during which addresses holding a voter role cast a single approve-or-reject vote each. The proposal transitions to approved as soon as a minimum approval count (default: 3) is reached, or is finalized after the voting deadline as approved (if approvals meet the minimum and exceed rejections) or rejected otherwise.

Veto & Execution

A default-admin-held veto function can move any proposal not yet in the executed state - including an auto-approved one - into a vetoed state, recording a reason. Execution itself calls the target's UUPS upgradeToAndCall entrypoint against the approved new implementation; the call is fail-closed, reverting the entire execution if the target lacks the expected upgrade entrypoint, the new implementation has no deployed code, or the upgrade call itself reverts - there is no silent no-op path.

Template Success Tracking

Each fix template tracks a usage count (incremented on every auto-approval that used it) and a success count (incremented only when the resulting fix actually executes). This closes a feedback loop distinct from the approval decision itself: governance can observe, per vulnerability class, how often an auto-approved template's fix was later executed versus vetoed or left to expire, informing whether that template should remain active, be revised, or be disabled without waiting for a fresh incident to force the question.

Prior Art Differentiation

Approach	Speed varies by novelty?	Templated fast-path?	Multi-voter path for novel cases?	Post-approval veto?
Uniform full-vote governance	No	No	Yes	Varies
Uniform auto-approve design	No	Yes (always)	No	Rarely
Vote-only, no post-approval check	No	No	Yes	No
JIL Templated Auto-Approval + Veto Governance	Yes	Yes	Yes	Yes

Patent Claim

Independent Claim 116: A computer-implemented smart contract fix-governance system, comprising: a fix-template registry storing, for each of a plurality of vulnerability classes, an active or inactive fix template; a proposal module configured to receive a fix proposal referencing a target contract, a vulnerability class, and a new implementation, and to automatically approve the proposal upon submission when the referenced vulnerability class has an active fix template, or otherwise open a bounded voting period during which addresses holding a voter role cast approval or rejection votes; an execution timelock configured to require a minimum elapsed time after approval, whether automatic or voted, before the proposal becomes executable; a veto module configured to allow a designated administrative authority to transition any proposal not yet executed, including an automatically-approved proposal, into a vetoed state; and an execution module configured to apply an approved, non-vetoed, non-expired fix by invoking an upgrade entrypoint on the target contract, the invocation failing closed if the entrypoint is absent, the new implementation lacks deployed code, or the upgrade call reverts.