Governance

1. Overview

The Governance contract is a timelock governor that controls the InfernoToken contract. After transferOwnership() was called, ALL token parameter changes must go through Governance — there is no backdoor.

• Mandatory delay between proposal creation and execution (default: 48 hours)
• Guardian role can emergency-cancel proposals at any time before execution
• Self-governing: even the timelock delay itself can only be changed through a proposal
• Fully transparent — every proposal and execution is an on-chain event

2. Timelock Mechanics

Every proposal is subject to a mandatory delay before it can be executed. This gives the community time to review and, if necessary, raise concerns.

When a proposal is created, its ETA (Earliest Time of Arrival) is set to block.timestamp + delay. The proposal cannot be executed before this timestamp.

3. Proposal Lifecycle

Every governance proposal follows the same lifecycle. Below is the visual flow:

States Explained

• Pending — Proposal has been created but ETA has not been reached. Cannot be executed yet.
• Executable — ETA has passed. The owner can call execute() to carry out the proposal.
• Executed — The target function has been called successfully. This is a terminal state.
• Cancelled — The proposal was cancelled by the owner or guardian before execution. Terminal state.

4. Roles

The Governance contract defines three distinct roles with clearly separated permissions:

5. What Parameters Can Be Changed

The following functions on InfernoToken (and Governance.setDelay) can only be called through the governance timelock. Protocol parameter changes go through Governance proposals with a 48-hour timelock. The deployed Governance contract’s ownership itself can be transferred directly by its owner, the Treasury Safe (3-of-5), without that delay (tracked as CWA-25). TreasurySafe can also rotate the guardian through untimelocked setGuardian.

6. Creating a Proposal

Use ethers.js (v6) to create a governance proposal. The propose() function takes the target contract address and the encoded calldata:

// Example: Change fee rates to 1.5% sender burn + 0.5% recipient burn + 1% pool fee
const governance = new ethers.Contract(GOV_ADDRESS, GOV_ABI, signer);

// Encode the function call
const iface = new ethers.Interface([
  "function setFeeRates(uint256,uint256,uint256)"
]);
const calldata = iface.encodeFunctionData("setFeeRates", [150, 50, 100]);

// Submit the proposal
const tx = await governance.propose(TOKEN_ADDRESS, calldata);
const receipt = await tx.wait();

// Get the proposal ID from the event
const event = receipt.logs.find(l => l.fragment && l.fragment.name === "ProposalCreated");
console.log("Proposal ID:", event.args.proposalId.toString());
console.log("ETA:", new Date(Number(event.args.eta) * 1000));

7. Executing a Proposal

After the 48-hour delay has passed, the owner can execute the proposal:

// After 48h delay has passed
const tx = await governance.execute(proposalId);
const receipt = await tx.wait();

console.log("Proposal executed in block:", receipt.blockNumber);
// The target function (e.g., setFeeRates) has now been called

If you try to execute before the ETA, the transaction will revert with "too early".

8. Guardian Emergency Cancel

The Guardian role exists as a safety mechanism. A guardian can cancel any pending proposal instantly, without waiting for the timelock delay.

• Designed for emergency response (e.g., a malicious proposal is detected)
• The guardian cannot propose or execute — only cancel
• Cannot undo an already-executed proposal (execution is permanent on-chain)
• The owner can also cancel proposals (they have a superset of permissions)

// Guardian cancels a suspicious proposal
const guardianGovernance = governance.connect(guardianSigner);
const tx = await guardianGovernance.cancel(proposalId);
await tx.wait();

console.log("Proposal", proposalId, "cancelled by guardian");

9. Self-Governance

The setDelay() function has the onlySelf modifier, meaning it can only be called by the Governance contract itself. No external account — not even the owner — can call it directly.

How to Change the Delay

1. Propose a call where the target is the Governance contract itself and the calldata encodes setDelay(newDelay)
2. Wait for the current delay to elapse (48h by default)
3. Execute the proposal — the Governance contract calls itself

// Example: Change delay from 48h to 72h (259200 seconds)
const iface = new ethers.Interface(["function setDelay(uint256)"]);
const calldata = iface.encodeFunctionData("setDelay", [259200]);

// Target is the Governance contract itself
const tx = await governance.propose(GOV_ADDRESS, calldata);
await tx.wait();

// ... wait 48 hours ...

await governance.execute(proposalId);

Mainnet Governance Proposals

Governance proposals submitted on the Ethereum Mainnet deployment (0xc43d48E7FDA576C5022d0670B652A622E8caD041):

Protocol Proposals #11–#21

Protocol Proposals #17–#21 (executed)

Queued by the Treasury Safe (3-of-5) through the 48-hour Governance timelock. All five were executed by the Treasury Safe after their ETA: #17 on 4 October 2026 (block 26121846), #18 on 5 October 2026 (block 26124623), #19 and #20 on 5 October 2026 (block 26124647), #21 on 5 October 2026 (block 26124660); execute transactions are linked in the proposal table above.

Historical Proposals (Sepolia)

Below are the governance proposals that have been submitted on the Sepolia testnet deployment:

Governance Learnings (Sepolia)

• Contract upgrades invalidate pending proposals. When PartnerVault v1 was replaced by v2, Proposal #2 became obsolete. Always cancel outdated proposals before creating new ones for the replacement address.
• Guardian cancel is faster than waiting. Instead of waiting 48h for an outdated proposal to expire, the Guardian can cancel immediately. This prevents accidental execution of proposals targeting deprecated contracts.
• feeExempt must be set before funding. Transferring 40M IFR to PartnerVault v1 before setting feeExempt resulted in a 1.4M IFR fee deduction. On mainnet: always set feeExempt first, fund second.
• Include version info in proposal descriptions. On-chain proposals have no description field — document the target contract version off-chain (GitHub Issue, wiki, CHANGELOG) to avoid confusion between v1/v2 addresses.
• 48h delay is sufficient for testnet operations. The delay provides enough time for review while not blocking rapid iteration. For mainnet, consider increasing to 72h for critical parameter changes.

Current Governance Model

Inferno currently operates through the 3-of-5 Treasury Safe + Governance Timelock. This is a deliberate choice for the early phase of the protocol.

Future: Governance Roadmap

Governance will evolve in clearly defined phases, each building on the trust and battle-testing of the previous one:

1. Current: 3-of-5 Safe + Timelock — Treasury Safe controls Governance. Proposals use the configured delay; owner-only guardian rotation and transferring the deployed Governance contract’s ownership through owner-only setOwner (tracked as CWA-25) are untimelocked, and the guardian can cancel pending proposals.
2. Next: Council tooling and community signer expansion — The existing Safe remains the execution authority. A reviewed voting surface may record Council decisions, while any 4-of-7 expansion follows the separate signer-expansion procedure.
3. Future: Full DAO — Lock-weighted voting (IFRLock balances as voting power). Community proposals. On-chain quorum requirements. Builder tokens grant additional voting rights.

Why Not DAO from Day One?

• Security over speed: Early-stage protocols need fast response to vulnerabilities
• Whale manipulation: Token voting without safeguards enables hostile governance takeovers
• Flash-loan attacks: Without lock-weighted voting, attackers can borrow tokens to swing votes
• Community maturity: DAO governance requires an engaged, informed token holder base
• Iterative decentralization: Gradual transition builds trust and battle-tests each layer

Capability Comparison

Each governance model unlocks different capabilities:

Builder Voting Rights (DAO Phase)

In the DAO phase, voting power will be derived from locked IFR balances (via IFRLock), not freely tradable tokens. This prevents flash-loan governance attacks. Builder tokens earned through the PartnerVault also grant voting rights, ensuring that governance influence reflects real ecosystem contribution.

PartnerVault Governance Features

The PartnerVault contract introduces additional governance-controlled mechanisms beyond basic parameter changes.

AuthorizedCaller Whitelist

By default, only the admin (Governance Timelock) can call recordLockReward(). To enable automated reward recording, governance can whitelist backend wallets via setAuthorizedCaller(address, true). These callers can record lock rewards but cannot change any other parameters.

Algorithmic Emission Throttle

When setIFRLock(address) is configured, the effective reward rate scales down automatically as more IFR is locked globally:

• Lock ratio < 1% → full rewardBps
• Lock ratio ≥ 50% → MIN_REWARD_BPS (500 = 5%)
• Between 1%–50% → linear interpolation

This prevents pool exhaustion in high-adoption scenarios while maintaining attractive rewards during early growth.

Anti-Double-Count

Each (wallet, partnerId) pair can only be rewarded once, enforced by the walletRewardClaimed mapping. This prevents gaming via repeated lock/unlock cycles.

Governance Dashboard

A read-only React dashboard for on-chain governance monitoring is available at apps/governance-dashboard/. Run locally:

cd apps/governance-dashboard && npm run dev

Tabs: Overview (PartnerVault stats, algo throttle curve) • Builders (event-based table) • Timelock Queue (proposals with countdown) • Calldata Generator (encode governance calls).

Phase 4 — Full DAO Roadmap

Draft, not an active voting system. The Council portal is a separate security-gated milestone within this direction, not a replacement for Safe execution. The proposed model below separates Council membership from Forum token weight. It is not an approved production voting rule. Quorum, thresholds, fees and timing below are draft parameters pending ratification and tests.

Proposed voting-weight clarification

• Council: one vote per eligible member in a fixed membership snapshot, independent of token holdings or the number of wallets controlled. Binding Safe execution remains separate.
• Forum: voting weight based on eligible locked IFR at a fixed snapshot, not one vote per lock or wallet. Splitting an amount into multiple locks must not increase its total weight.
• Before ratification: define eligible lock contracts, snapshot and lock-duration requirements, delegation, duplicate-count prevention, quorum and concentration safeguards. No automatic activation follows from this proposal.

Prerequisites for Phase 4

• Minimum 6 months of mainnet operation
• Minimum 1,000 active IFR lockers
• Security audit completed
• Governance Constitution ratified

Token-Voting Mechanism

In full DAO mode, IFR lockers vote on proposals. Proposed Forum voting power = eligible locked IFR at the agreed snapshot (not wallet balance). Final eligibility and safeguards require ratification.

Telegram DAO Layer — Topic Access Control (Phase 2)

Gated Telegram topics enforce on-chain lock requirements via WalletConnect verification on ifrunit.tech. Users connect their wallet, sign once, and the bot whitelists their Telegram account — no manual wallet entry required.

Roadmap

Two-Chamber DAO Design (Phase 4)

Overview

IFR governance will transition to a two-chamber model combining strategic oversight (The Council) with community innovation (The Forum). Both chambers anchor votes on-chain and share the same 48h Timelock for execution.

Interaction Matrix

Smart Contracts (Phase 4)