# Governance & Execution

HOLI governance is deliberately split into **decision** and **execution**. Claimed, non-transferable sHOLI is the voting weight; [Snapshot](https://snapshot.org) records the vote off-chain. The dev Team multisig executes a passed decision on-chain. There is no separate governance token and no on-chain Governor.

## Snapshot decisions

Each proposal uses the sHOLI balance at its declared Snapshot block:

<Md expr="w_i=\operatorname{balanceOf}_{\mathrm{sHOLI}}(i)" />

Cooling receipts have zero weight until their seven-day claim. A proposal must state its exact action, bounds, and Snapshot space. For Treasury actions, it must also name the contract call or Safe transaction that the dev Team multisig is expected to execute.

Snapshot is a social-governance system, not a transaction executor. A passed vote does not automatically move Treasury assets, change a parameter, or upgrade a contract. The multisig must publish the resulting transaction and execute it through the relevant contract authority.

## Two development addresses

| Address | Protocol role | May do | May not do alone |
| --- | --- | --- | --- |
| **Dev Team multisig** | Treasury owner, management-fee recipient, governance executor | Execute approved Treasury operations; approve and execute upgrades | Cast votes for holders; make a Snapshot result execute itself |
| **DEV Deployer** | Technical deployment and upgrade proposer wallet | Deploy and verify a candidate implementation; prepare the upgrade transaction | Move Treasury assets, alter Treasury settings, or switch the proxy implementation |

The development multisig holds the operational authority. The deployer is intentionally not a Treasury operator and must not be able to upgrade the live protocol by itself.

## Upgrade path

A transparent proxy keeps the stable Treasury address that owns HOLI minting authority, assets, and storage. It delegates calls to a separate **implementation** contract containing the code.

1. The DEV Deployer deploys a new implementation address and publishes its source, audit status, and the proposed upgrade calldata.
2. Where the change is governed, sHOLI holders vote on Snapshot.
3. The dev Team multisig verifies the passed proposal and executes `upgradeAndCall` through the proxy's upgrade authority.
4. The proxy begins delegating to the new implementation; its address, HOLI token, balances, and storage remain the same.

Merely deploying a new implementation cannot affect the protocol. The decisive transaction is the proxy upgrade. The production upgrade authority must therefore be owned by the dev Team multisig, or by an upgrade-controller contract that requires the multisig's approval. Assigning `ProxyAdmin.owner()` directly to the DEV Deployer would let that wallet bypass the multisig and is not an acceptable production configuration.

This architecture still carries upgrade risk: a multisig-approved implementation can change privileged behavior. Every upgrade should expose the implementation address, source verification, diff, Snapshot record when applicable, Safe transaction, and execution transaction in the protocol dashboard.