> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tiprotocol.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance

> Ti starts with a small number of signers and hands decision-making power to TIP holders as the ecosystem grows. At every stage, changes stay slow and their content public.

Governance is a commitment that sets out who can change what, and when. Ti starts with a structure in which a small number of signers decide quickly and accountably, and it hands decision-making power to TIP holders as the ecosystem grows. At every stage, Ti keeps changes slow and their content public.

***

## 1. The current structure

Today, all administrative rights over the TIP token and the seven vesting contracts sit with a single Governance Safe. The Governance Safe is a 2-of-3 multisig wallet whose three signers are the CEO, CFO and CTO; any two of them must sign to execute (Safe v1.4.1).<sup>[30](https://docs.tiprotocol.io/appendix/references.md#ref-30)</sup> The Governance Safe does not call administrative functions directly. It calls them only through the AccessManager permission contract, OpenZeppelin AccessManager.<sup>[31](https://docs.tiprotocol.io/appendix/references.md#ref-31)</sup> For each administrative function, the AccessManager defines which role may use it and how long the call must wait before execution.

| Decision | Who | How long it waits |
| - | - | - |
| Granting and revoking roles, changing the admin, changing delays, replacing the AccessManager | Governance Safe (2-of-3) | 7 days after scheduling |
| Revoking, changing a beneficiary, burning, migrating to a new vesting version, returning non-TIP tokens, re-enabling a switched-off feature | Governance Safe (2-of-3) | 72 hours after scheduling |
| Setting the TGE, registering schedules, modifying terms before a schedule starts, extending a schedule after it starts | Governance Safe (2-of-3) | Immediate |
| Freezing and unfreezing addresses and schedules, designating protected addresses | Governance Safe (2-of-3) | Immediate (each freeze lasts at most 72 hours) |
| Switching off features, permanent seal | Governance Safe (2-of-3) | Immediate (only in the direction of reducing powers) |

A decision with a delay is first scheduled on the blockchain and can be executed only after the set time has passed. Scheduled operations are public, so anyone can see what is set to change and when, and they can be cancelled before execution. The Liquidity operations Safe and the Marketing operations Safe have the same signers but hold no administrative rights, and the wallet used for deployment holds no rights at all.

***

## 2. Phased transition

<ol><li>Phase 1Now**Multisig operation**<ul><li>Governance Safe 2-of-3 holds every role</li><li>7-day delay on permissions, 72 hours on fund actions</li><li>Every scheduled action is public on-chain</li></ul></li><li>Phase 2**Holder voting**<ul><li>TIP holders vote by signature</li><li>Passed proposals executed by the Safe after the delay</li></ul></li><li>Phase 3**On-chain governance**<ul><li>Results executed by contracts after the delay</li><li>Safe keeps emergency response only</li></ul></li></ol>View figure full size

**Figure 33.** Governance moves from multisig operation through holder voting to on-chain governance; Phase 1 is in effect now.

**Phase 1: Multisig operation (now).** Preparing for listing and running early operations require fast decisions and clear accountability. In this phase, the Governance Safe holds all rights, but decisions that expand rights and decisions involving funds carry a time delay and are made public.

**Phase 2: Holder voting.** Once TIP is listed and the holder base grows, matters that affect the whole ecosystem, such as the use of the ecosystem fund, the addition of new chains and stablecoins, and the protocol fee, are decided by a vote of TIP holders. Votes are cast by signature, weighted by TIP holdings at a snapshot block, and cost no gas. The Governance Safe executes approved proposals after a time delay and publishes the execution transaction together with the proposal.

**Phase 3: On-chain governance.** In this phase, contracts execute vote results directly instead of people carrying them out. The admin role in the AccessManager moves to a governance contract that acts only on vote results, and the Governance Safe keeps only the powers needed for emergency response, such as freezes and cancelling scheduled operations. Moving the admin role is itself subject to the 7-day delay.

The conditions for moving from one phase to the next (holder distribution, verification of the voting tools, participation rate and so on) and the detailed rules of each phase (proposal eligibility, quorum, approval threshold, voting period) will be published before that phase begins.

***

## 3. How a proposal is processed

From Phase 2 onward, proposals are processed in the following order.

**1. Proposal**

A holder who meets the proposal requirements, or the Foundation, publishes the proposal and what it will execute.

**2. Discussion**

For a set period, the community reviews the proposal and suggests amendments.

**3. Vote**

A snapshot block is fixed, and votes are weighted by TIP holdings at that block. TIP bought after the snapshot block carries no voting power on that proposal.

**4. Scheduling**

What an approved proposal will execute is scheduled in the AccessManager. The scheduled operation must match what the vote approved, and anyone can compare the two.

**5. Execution**

Once the time delay has passed, the proposal is executed, and the hash of the execution transaction is recorded on the proposal.

***

## 4. What a vote can decide

* Major uses of the ecosystem fund and the Ecosystem allocation
* The addition of new chains, new stablecoins and new bridges
* The introduction, rate, cap and allocation ratio of the protocol fee
* Tier criteria for holder benefits
* Whether to permanently seal the compliance freeze function and vesting contract functions
* Changes to the governance rules themselves

***

## 5. What governance cannot change

No vote and no combination of signers can do what the code prevents. No more TIP can be minted, the token contract cannot be upgraded or replaced, and no one can pause all transfers or add a transfer fee. The vesting contracts have no function that sends TIP to an administrator, so allocated tokens cannot be taken out. A started schedule cannot be shortened, and a share that has already been released cannot be reduced. Governance decides only what lies within these limits.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.