Executed

Proposal to Pause Selected Transact Verifiers for a Security Upgrade


Proposal ID

753568...7442

Proposed

Jun 25th, 2026

Result details
Final Votes

Quorum

15.95M of 9.12M

Majority support

Yes

For

15.95M

Against

0

Abstain

0

Actions

Type

Address

Details

Custom

0x0d75...0748

disableTransactVerifier(..)

Custom

Account

0x0d75...0748

Method

disableTransactVerifier(..)

Custom

0x0d75...0748

disableTransactVerifier(..)

Custom

Account

0x0d75...0748

Method

disableTransactVerifier(..)

Custom

0x0d75...0748

disableTransactVerifier(..)

Custom

Account

0x0d75...0748

Method

disableTransactVerifier(..)

Custom

0x0d75...0748

disableTransactVerifier(..)

Custom

Account

0x0d75...0748

Method

disableTransactVerifier(..)

Proposal

Background

Security remains the highest priority for the Mystiko network. As the protocol continues to evolve, certain upgrade procedures require reducing the active transaction surface before new security improvements are introduced. To support a safer upgrade process, this proposal seeks community approval to disable selected transact verifier combinations.

## Proposed Solution

To prepare for the security upgrade, we propose pausing the following transact verifier combinations:

- transact 1x1

- transact 1x2

- transact 2x0

- transact 2x1

- transact 2x2

These verifier combinations will be disabled before the upgrade is carried out. The pause is intended to be a controlled safety measure that limits affected transact paths during the upgrade window while keeping the scope of the change clearly defined.

Key Benefits

- Reducing Upgrade Risk: Disabling the selected transact paths before the upgrade reduces the active surface area during a sensitive protocol maintenance period.

- Protecting User Funds and Network Integrity: A controlled pause helps prevent unexpected behavior while security-sensitive changes are prepared and deployed.

- Maintaining Governance Oversight: The change will be executed through the Mystiko governance process, ensuring that the community has visibility and control over the upgrade preparation.

- Providing a Reversible Safety Measure: The pause is not intended to permanently remove these transact capabilities. The affected verifier combinations can be re-enabled through a follow-up governance action after the security upgrade has been completed and verified.

## Implementation Details

The proposal will disable the selected transact verifiers in the Mystiko verifier pool. The intended governance actions are:

- disableTransactVerifier(1, 1)

- disableTransactVerifier(1, 2)

- disableTransactVerifier(2, 0)

- disableTransactVerifier(2, 1)

- disableTransactVerifier(2, 2)

After execution, transact requests that rely on these disabled verifier combinations will no longer be accepted by the protocol until the relevant verifiers are enabled again. Transact verifier combinations outside the scope of this proposal are not intended to be changed.

Withdraw Impact

This pause does not disable the transact 1x0 verifier, so the regular single-input withdraw path remains available. Transact paths that rely on the disabled verifier combinations, including 2x0, will be paused until they are re-enabled through governance.

Community Vote

We recognize the importance of community input in shaping secure protocol operations. The XZK community can cast their votes to decide whether this pause should be applied as part of the security upgrade process. By approving this proposal, the community supports a cautious and transparent path toward strengthening the Mystiko ecosystem.

Note

*This proposal is a safety measure for the security upgrade. Re-enabling the paused transact verifier combinations should be handled through a separate governance action after the upgrade is completed and reviewed.

Final Votes

Quorum

15.95M of 9.12M

Majority support

Yes

For

15.95M

Against

0

Abstain

0

Final Votes
Status

Thu Jun 25, 11:58 am

Draft created

Thu Jun 25, 01:51 pm

Published onchain

Fri Jun 26, 01:51 pm

Voting period started

Fri Jul 3, 01:51 pm

Voting period ended

Fri Jul 3, 02:20 pm

Proposal queued

Fri Jul 3, 04:01 pm

Proposal executed