JIP-36: Install a Jito DAO Veto Trigger

JIP - Official
1

JIP-36: Install a Jito DAO Veto Trigger

Category: Security & Enforcement

Proposal Type: Standard

Status: OFFICIAL

Abstract

This JIP proposes the deployment of a Veto Trigger mechanism that encodes a single atomic instruction to revoke all Dev Council authorities and return them to the DAO. The Veto Trigger can be activated by Tokenholders via a standard JIP, enabling the DAO to reclaim full control of all delegated programme and parameter authorities in a single transaction. This creates hard, executable power for Tokenholders and provides a clear, credible counterweight to the expanded authority granted to the Dev Council under a Pragmatic Decentralisation framework.

Motivation

The adoption of the new Jito DAO Constitution and the Pragmatic Decentralisation authority framework represents a significant delegation of technical authority to the Dev Council. Programme upgrade authorities, parameter authorities, and the Steward Admin are being transferred to enable the operational tempo required for active stake pool management and protocol upgrades.

The Jito Constitution provides the process: Article IX.4 states that the DAO retains full authority to revoke Dev Council rights at any time via JIP. This JIP provides the mechanism.

Key Terms

Veto Trigger — A viable execution path for the Jito DAO that encodes a pre-defined set of authority transfer instructions. When invoked, it atomically revokes all Dev Council programme and parameter authorities, returning them to the DAO governance wallet.

Atomic Revocation — a single transaction that transfers all specified authorities in one execution, ensuring no partial state where some authorities are revoked and others remain with the Dev Council.

Specification

  1. Transfer Powers to a Two-Hop Squads Architecture

Structure authorities across the DAO and the Dev Council based on a tiered structure that ensures custodial and ossified aspects of the protocol remain with the DAO and transferring authorities required for efficient active management of the protocol to the Dev Council.

DAO governance PDA (spl-governance) holds config_authority over Manager Squads.

Manager Squads (Squads v4) holds config_authority over Dev Council Squads. Operated by trusted agents; membership replaceable by the DAO at any time via JIP.

Dev Council Squads (Squads v4, 12h timelock) holds all Tier 3 and Tier 4 authorities via its vault PDA. Day-to-day operations are subject to timelock.

This chain ensures the DAO can replace Manager membership, then Manager can replace Dev Council membership and recover all authorities, without Dev Council consent.

2. Operational Hardening

Alongside the structural mechanism, the following operational measures are implemented:

  • Dev Council quorum: 4 of 7 (hardened from current 3 of 7).

  • CLI-first transaction construction for all sensitive actions, with human-readable decode before signing.

  • Transaction screening via an independent co-signer service (e.g., Blockaid or Hypernative) for high-risk actions.

  • Dedicated signer machines or hardened signing paths for Dev Council members.

3. Timelock Monitoring

All Dev Council vault transactions are subject to a 12h delay before execution. During this window:

  1. An automated proposal scanner decodes every instruction in the pending proposal.

  2. Critical alerts fire immediately for any instruction touching ProgramData, SetAuthority, config_authority, or transferring authority outside the known set. Alerts go to the Security Council, Foundation, and Governance.

  3. Standard alerts log routine parameter changes and programme upgrades with known buffer hashes for review.

  4. If a critical alert fires, Manager Squads can preemptively rotate Dev Council membership before the malicious proposal executes.

4. Clawback Invocation Path

The Veto Trigger is invoked via a standard JIP:

  1. A Tokenholder submits a JIP proposing to execute the clawback.

  2. The JIP follows the standard governance process: 250,000 JTO proposal threshold, delegate endorsement, 5-day voting period, 1% quorum, simple majority, 2-day cooldown.

  3. Upon execution, the JIP payload rotates Manager Squads membership (if needed) and instructs Manager to rotate Dev Council membership and transfer all delegated authorities to the DAO governance PDA.

  4. The pre-built clawback script is used to construct the transaction payload, ensuring no authorities are missed.

  5. The Dev Council retains no programme or parameter authorities after execution.

5. Post-Invocation State

After the Veto Trigger is invoked:

  • All Tier 3 (Stable Maintenance) and Tier 4 (Active Management) authorities return to the DAO governance PDA.

  • Tier 1 (Custodial) and Tier 2 (Ossified) authorities are unaffected — they already reside with the DAO.

  • The Dev Council multisig continues to exist but holds no on-chain authorities.

  • Any subsequent re-delegation to the Dev Council requires a new JIP.

  • The two-hop architecture remains in place and can be re-used if delegation is re-established.

6. Security Constraints

  • The Dev Council cannot modify its own config_authority. Only Manager Squads can change Dev Council configuration.

  • Manager Squads cannot modify its own config_authority. Only the DAO governance PDA can change Manager configuration.

  • The Dev Council cannot disable or reduce the timelock. Timelock changes require Manager Squads action.

  • The clawback script is maintained and tested with every authority delegation change, stored in the governance tooling repo with version control.

7. Hardening The Veto Trigger

Coordinate with key ecosystem stakeholders to improve this structure and explore the creation of a durable, secure and generalisable solution for the network.

Implementation Path

Trustless (on-chain):

  • Deployment and set up op Manager Squads and Dev Council Squads utilising the two-hop set up described in the specification.

  • Remaining authority transfers

Contributor Execution:

  • No action required

Benefits, Risks & Risk Analysis

Benefits

  • Hard Tokenholder power. Converts the constitutional right to revoke Dev Council authorities (Art IX.4) into a concrete, single-action on-chain mechanism.

  • Credible deterrent. The existence of a pre-encoded, audited revocation path disciplines the Dev Council, the cost of Tokenholder action is minimal.

  • Simplicity. One JIP, one transaction, full revocation. No complex multi-instruction proposal construction.

  • Transparency. The Authority Registry provides a real-time, on-chain record of every authority delegated to the Dev Council.

  • Credible Decentralisation. The Pragmatic Decentralisation framework delegates significant authority to the Dev Council. The Veto Trigger is the structural counterweight that makes this delegation action credibly decentralised.

Risks

  • DAO overreach. This provides a direct power to limit Labs and Foundation influence over the protocol with an executable path for the DAO, therefore measures should be taken to ensure that the trigger is not activated frivolously and ideally remains a perpetual motivation for Jito Labs and Jito Foundation to perform rather than an actively utilised system.

  • Manager Multi-Sig Compromise. The manager multi-sig has the potential to add new seats to the Dev Council that could be malicious and could remove the revocation path for the DAO. The structure will be used seldomly, only for Dev Council composition changes and can therefore be operated with deep cold storage keys. The hardening package of work should consider patterns that limit the possible paths of authorities to the DAO only.

Outcomes

  1. Jito DAO moves to a two hop squads architecture, with a manager multi-sig mediating execution authority over the Dev Council.

  2. Tokenholders hold hard, executable power over all delegated authorities — not just a constitutional right, but a concrete on-chain action.

  3. The Pragmatic Decentralisation framework is structurally complete: authority is delegated for operational efficiency, with a credible and instant revocation path for Tokenholder protection.

Cost Summary & Funding Source

There are no additional costs to the DAO and the new set up can utilise existing infrastructure such as Squads.