Native Governance
Two-chamber token-weighted governance via Telegram — on-chain truth, off-chain voting.
Architecture specification, not a live service. RatVoting, ForumVoting, IFRSpamProtection, the Telegram voting bot and the flows below are proposed Phase 4 components. None is deployed or available for voting today. Current executable governance remains the documented Safe and Governance timelock process.
Superseded parts: the bot executor holding a private key and lock-weighted Council ballots come from the historical March 2026 concept. The current proposed direction has no backend key custody or executor and one vote per eligible Council member; see the Council portal requirements.
What is IFR Native Governance?
This proposal would place community participation where it already happens: Telegram. The planned system is not currently integrated into Telegram groups or channels.
The proposed system would use a hybrid on-chain/off-chain model. Voting would happen off-chain via Telegram reactions and polls, while a future contract could anchor finalized results on-chain.
- No gas costs for voting: IFR is a deflationary token — standard transfers between non-exempt addresses burn tokens. Off-chain voting avoids unnecessary burns.
- Proposed credential: a future ratified policy may use eligible locked IFR as voting weight.
- Proposed chambers: The Council (strategic governance) and The Forum (community innovation).
- Proposed verification: finalized results could be anchored with a Merkle root after the contracts and policy are implemented.
Why Telegram? No extra app to install. No wallet connection friction for voting. The community is already there. Higher participation = better governance.
Architecture
Three-layer design: Presentation (Telegram), Logic (Bot Backend), Truth (Blockchain).
Chamber 1 — The Council
Team governance for strategic decisions, treasury allocation, and partnerships. Only the dev team and multisig signers can create proposals. The community can discuss; under the current proposal, Council ballots are limited to eligible Council members.
Future signer expansion: once community voting is live, the multisig signer set can expand through a security-filtered community process. The planned path is 3-of-5 → 4-of-7 first, then optional 5-of-9 after one stable term. See the Community Signer Expansion Plan.
/council_proposalwith title, description, duration
RatVoting.sol.Planned verification: the design proposes a public verifyVote() function so voters could verify Merkle inclusion after the contract is implemented and deployed.
Chamber 2 — The Forum
Community innovation chamber. Anyone with IFR locked can submit proposals. A 10 IFR spam protection fee is required — refunded on successful consensus, burned if rejected. This reinforces IFR’s deflationary design.
/propose flow in the Community Forum. The 10 IFR deposit mechanism is not live./sign [id] yes.Proposed mechanic: a future, audited and ratified spam-fee design could refund accepted proposals and burn rejected deposits. No proposal-fee contract is deployed today.
How Voting Works
Forum voting is in development and not live; no Forum ballot is open today. The rules below were decided by the owner on 11 October 2026 for the first version (decision register, Lane 8).
- Advisory: Forum results advise the Council; the Council decides. A Forum result never moves funds or executes a contract.
- Voting weight: IFR locked in IFRLock at a snapshot block that is announced before the ballot opens. No delegation; a lock is counted once.
- Signed votes: each vote is a free wallet signature (no transaction) over the ballot id, the chain, the snapshot block, your choice and the hash of the frozen proposal text.
- Changing your vote: your last valid vote before the ballot closes counts.
- Quorum: 10 % of the IFR locked at the snapshot block. Abstentions count towards the quorum, not towards the result.
- Announcements: ballots, snapshot blocks, times and results are posted only by the IFR bot in the Vote topic (t.me/IFR_token/23); nobody else can post there.
- Recount: the full vote set is published so that anyone can recount the result.
How to vote — step by step
For IFR holders who want to vote in the Forum once it is live.
-
1. Lock IFR
Voting weight comes only from IFR locked in IFRLock. Lock on web3.ifrunit.tech. A lock counts for a ballot only if it exists at the snapshot block announced for that ballot; locks made later do not count for it.
-
2. Follow the Vote topic
Join t.me/IFR_token and follow the Vote topic (t.me/IFR_token/23). Only the IFR bot posts there: each ballot with its proposal text, the text hash, the snapshot block and the opening and closing time.
-
3. Read the proposal
Read the frozen proposal text linked in the announcement and check that it matches the published hash. The text cannot change while the ballot is open.
-
4. Sign your vote
On the ballot page, connect your wallet and sign your choice (yes, no or abstain). Signing is free and sends no transaction. You can change your mind until the ballot closes: your last valid vote counts.
In development — not live: open the Forum ballot page using the ballot link from the IFR bot announcement.
-
5. Check the result
After the ballot closes, the bot posts the result in the Vote topic together with the full vote set (signatures, wallets, weights). Anyone can recount it with the published checker. Forum results are advisory: the Council decides.
Bot Architecture
The historical concept proposed a single Node.js bot for both chambers. Its Executor component is superseded: the current direction holds no Council, Safe or protocol-admin key in any backend.
| Component | Function |
|---|---|
| Wallet-Mapper | Encrypted database mapping TelegramUserID to EthereumAddress (one-time free signature) |
| IFR-Reader | Reads IFR Lock Contract via Infura/Alchemy, caches lock balances |
| Reaction-Tracker | Tracks every reaction with timestamp and lock weight of the voter |
| Poll-Manager | Creates native Telegram polls for Council votes, aggregates weighted results |
| Cron: Ranking | Runs daily, calculates top proposals by weighted score (upvotes minus downvotes) |
| Cron: Consensus | Monitors whether a proposal has stayed 10 consecutive days in Top 3 |
| Cron: Finalizer | Submits collected votes on-chain after the signature phase ends |
| Executor | Superseded — no private key or multisig access in the bot; binding execution remains a TreasurySafe proposal plus 48-hour timelock |
Smart Contracts
The historical concept proposed three new contracts. None is approved, audited or scheduled for deployment.
RatVoting.sol Phase 4
Stores Council vote results using a snapshot model. One on-chain transaction per proposal.
finalizeProposal(proposalId, forWeight, againstWeight, merkleRoot)— bot-only, stores the finalized vote resultverifyVote(proposalId, voter, vote, weight, proof)— public view function for Merkle proof verification
ForumVoting.sol Phase 4
Manages binding community votes using an EIP-712 signed-vote model.
submitVotes(proposalId, votes[], signatures[])— iterates over all votes, verifies each signature via ecrecover, checks IFR Lock balance, stores final result on-chain
IFRSpamProtection.sol Phase 4
Manages the 10 IFR proposal fee. Requires approve() from the user before submission.
- Successful consensus → 10 IFR refunded to proposer (incentive for quality proposals)
- Downvoted > 50% → 10 IFR burned permanently (deflationary)
User Journey
Illustrative journey from the historical concept; nothing below is live, and lock-weighted Council voting is superseded by the current proposal:
/connect → Mini-App opens → MetaMask signature (free)./propose “Treasury should fund 10k IFR for community event” → 10 IFR deposited → idea posted./sign 42 yes”FAQ
Why Telegram and not a dedicated voting dApp?
The community lives in Telegram. No extra app to install means higher participation. Governance should meet users where they already are, not force them to a new platform.
Do I need ETH to vote?
No voting is live today. In the proposed design, voting would be off-chain and gas-free; a 10 IFR proposal deposit remains an unapproved proposal.
What determines my voting power?
Not yet ratified. The current proposal is one vote per eligible Council member for Council ballots and eligible locked IFR at a fixed snapshot for the Forum; splitting locks must not increase weight.
When will this launch?
No launch date is set. Phase 4 requires ratified rules, an independent security review and a separate decision; see the decision register. Follow @IFRtoken on X for updates.
How will community multisig signers be selected?
Signer selection is planned as a mixed model: eligibility filter, public nomination, community vote, security review, rotation, and emergency replacement rules. It is not pure whale voting and not pure random selection. Full details: Community Signer Expansion Plan.
Can I verify my vote was counted?
Not today. The planned RatVoting design includes a public verifyVote() view function, but that contract is not deployed and no production vote proof currently exists.
Join the Governance
Get involved in IFR governance today:
📢 Announcements — t.me/IFRtoken
🏛 Council — t.me/IFR_token/21 (team proposals, read-only)
🗳 Vote — t.me/IFR_token/23 (cast your vote)
💬 Community — t.me/IFR_token (discussion & proposals)