Frequently Asked Questions

Inferno ($IFR) is an ERC-20 utility token on Ethereum Mainnet with a fixed genesis supply of 1,000,000,000 tokens and 9 decimals. There is no mint function — supply can only decrease. Every transfer permanently burns 2.5% (2% sender-side + 0.5% recipient-side) and routes 1% to a pool fee receiver. This makes IFR structurally deflationary: the more it is used, the scarcer it becomes.

Fixed genesis supply: 1,000,000,000 IFR distributed across 6 buckets at deployment:

• 40% DEX Liquidity (400M) — Uniswap V2 LP
• 20% LiquidityReserve (200M) — locked until 01.09.2026
• 15% Team Vesting (150M) — 12-month cliff, 36-month linear vesting
• 15% Treasury Safe (150M) — Gnosis Safe multisig
• 6% Community & Grants (60M) — community initiatives
• 4% BuilderVault (40M) — builder ecosystem rewards

See Tokenomics for the full breakdown.

No — and this is one of the strongest guarantees in the protocol. There is no mint() function in the InfernoToken contract. No admin, no governance proposal, no upgrade can ever create new IFR tokens. The genesis supply is the maximum that will ever exist. This is verified in the open-source code and confirmed by Slither static analysis.

Example: Alice sends 10,000 IFR to Bob.

• Sender burn (2.0%): 200 IFR burned from Alice's amount
• Recipient burn (0.5%): 50 IFR burned from remaining amount
• Pool fee (1.0%): 100 IFR sent to the pool fee receiver
• Bob receives: 9,650 IFR
• Total burned: 250 IFR (permanently removed from supply)

The fee is percentage-based, so as supply shrinks, each burn removes fewer absolute tokens. This creates asymptotic deflation — the burn rate slows exponentially.

Burning permanently destroys tokens by sending them to the zero address. They can never be recovered. This reduces total supply.

Locking moves tokens into the IFRLock smart contract where they are held as a verifiable commitment. Locked tokens remain owned by the user and can be unlocked at any time. Locking reduces circulating supply but not total supply.

Both mechanisms reduce available supply, but only burning is permanent.

Practically impossible. Burns are percentage-based: 2.5% of 1 billion is 25 million, but 2.5% of 1 million is only 25,000. The burn rate slows exponentially (asymptotic behaviour). Additionally: locked tokens do not move (no burn), the Vesting contract holds 150M locked for years, the LiquidityReserve holds 200M locked, and Governance can reduce fee rates if needed. The ecosystem is self-regulating.

IFR uses 9 decimals as a deliberate design choice. This provides sufficient precision for fee calculations and lock amounts while keeping numbers more human-readable. One IFR equals 1,000,000,000 base units (1e9). All integrations must use parseUnits(amount, 9) instead of the typical 18 decimals.

The LiquidityReserve (200M IFR) is locked until 01.09.2026. After that date, the LP tokens can be withdrawn by the owner (Governance contract) for LP expansion. The reserve uses rate limits to prevent sudden large withdrawals. See Transparency for on-chain verification.

Yes. The protocol has undergone multiple layers of security analysis:

• External AI Security Audit (March 19, 2026): Independent analysis of InfernoToken.sol — 2 critical/high findings identified and mitigated by Governance architecture (48h Timelock + TreasurySafe 3-of-5). No exploitable bugs found. Full report
• Slither static analysis: 0 high/critical findings across all contracts
• Claude security audit: 0 FAIL, 12 WARN, 78 PASS
• ChatGPT audit V4: 7/7 areas PASS
• 544 automated tests (367 contract + 77 app + 100 vault) with 99% statement coverage and 91% branch coverage
• App security review: 20/25 findings fixed, 5 documented
• Internal Security Review (March 2026): Bootstrap flow — 11/14 secure, 3/14 low risk, 0 critical

All 17 on-chain components are deployed and verified on Ethereum Mainnet. A professional third-party audit (Code4rena, Sherlock, or Cyfrin) is planned for Phase 2.

All 17 on-chain components are verified on Etherscan with source code visible. Visit each contract address on etherscan.io, click the “Contract” tab, then “Read Contract” to inspect state. The main token address is 0x77e99917Eca8539c62F509ED1193ac36580A6e7B. All addresses are listed on the Deployment page.

The Guardian role can cancel any pending governance proposal before execution. During the 48-hour window: (1) the proposal is publicly visible on-chain, (2) anyone can monitor it via Etherscan or the Governance Dashboard, (3) the Guardian can call cancel(proposalId) to permanently prevent execution, (4) after cancellation, a new corrected proposal must be submitted with a fresh 48-hour delay.

The project has a Responsible Disclosure policy documented in SECURITY.md. Critical bugs should be reported privately via GitHub Security Advisory. The Guardian can pause contracts and cancel governance proposals in emergencies. The patch process follows a documented 6-step procedure with severity classification.

The IFRLock contract uses OpenZeppelin's ReentrancyGuard and Pausable patterns. Your locked tokens cannot be accessed by any admin, team member, or governance action. The contract is fee-exempt, so the exact amount you lock is the exact amount you get back when unlocking. Only your wallet can call unlock(). There is no upgrade proxy — contracts are immutable once deployed.

The Guardian is a separate role from the owner, designed for emergency response. The Guardian can: cancel any pending governance proposal before execution, and pause contracts via the Pausable pattern. The Guardian cannot: create proposals, execute proposals, or access user funds. It is a safety mechanism, not an admin backdoor. The Guardian address is transferable via the Vesting contract's transferGuardian() function.

No. All 17 deployed protocol contracts are immutable — there is no proxy pattern, no UUPS, no transparent proxy. Once deployed, the bytecode cannot be changed. This means no rug-pull via contract upgrade is possible. The trade-off is that bugs cannot be patched in-place, but this is a deliberate security decision: immutability over convenience.

The exception are the Treasury Safe and Community Safe, which use the Gnosis Safe proxy architecture. Gnosis Safe is a battle-tested, audited multisig standard — any upgrade requires explicit multisig consensus and is publicly verifiable on-chain. This is not a protocol risk but an industry-standard operational security pattern.

The Governance contract is a custom timelock governor. The owner creates proposals containing encoded function calls on target contracts. Each proposal must wait the full delay period (default 48 hours) before execution. This gives the community time to review and the Guardian time to cancel if needed. The contract uses propose(target, data) and execute(proposalId).

All three Gnosis Safes (Treasury, Community, LP Reserve) operate as 3-of-5 multisigs with 5 active signers (A.K., M.G., A.M., Y.K., A.P.) since 15.03.2026. Treasury Safe: 0x5ad6193eD6E1e31ed10977E73e3B609AcBfEcE3b. Signer details are documented in the Multisig Policy. All multisig transactions are publicly visible on Safe.

Governance can change: fee rates (sender burn, recipient burn, pool fee), fee exemptions, the pool fee receiver, guardian address, timelock delay, PartnerVault parameters (reward rate, emission cap, authorized callers), and FeeRouter parameters (protocol fee, voucher signer, fee collector). All changes require the full timelock delay.

Immutable by design: the total supply (no mint function), 9-decimal precision, the maximum fee cap (5% hardcoded), the FeeRouter fee cap (0.25% hardcoded), and the token name/symbol. No governance proposal, no admin action, and no upgrade can modify these.

Token-weighted voting is vulnerable to whale manipulation and flash-loan attacks where someone borrows millions of tokens, votes, and returns them in the same transaction. Inferno takes a phased approach: Phase 0 (single EOA), Phase 1–3 (multisig with increasing signers), Phase 4 (full DAO with safeguards). Security before ideology.

Phase 0 (done): Genesis — 1-of-2
Phase 2a (done): Expanded to 1-of-3
Phase 2b (done): 2-of-4 — 14.03.2026
Phase 2c (done): 2-of-5 — 15.03.2026
Phase 2d (active): 3-of-5 — 5 independent signers on all 3 Safes (Treasury, Community, LP Reserve) since 15.03.2026
Phase 4: Full DAO governance with token-weighted voting + safeguards

See DAO Governance for the detailed plan.

IFR governance uses a two-chamber model:

Chamber 1 — The Council: Strategic decisions by Gnosis Safe Signers. Proposals go through a 48h Timelock before execution.
Chamber 2 — The Forum: Community innovation layer. Any IFR holder can submit proposals (10 IFR spam protection fee). 1 locked IFR = 1 vote. No gas required for voting — only for execution.

This is a Phase 4 feature, planned after LP is live and the ecosystem is built. See Governance for the full concept.

Any wallet with locked IFR tokens can vote in The Forum (Chamber 2). Council votes (Chamber 1) are restricted to Gnosis Safe Signers only.

To participate:
• Lock IFR via the Lock Mechanism
• Verify your wallet at ifrunit.tech/wiki/verify.html to unlock the Vote topic in Telegram
• Use /verify in the IFR Telegram community to start

1. Send /verify to the IFR Telegram bot in @IFR_token
2. You receive a one-time verification code (expires in 10 minutes)
3. Open ifrunit.tech/wiki/verify.html
4. Connect MetaMask + enter the code + sign with your wallet
5. The bot confirms your tier and unlocks your topic access

This uses cryptographic signatures (EIP-191) — your private key never leaves your device.

🔑 Signer: Gnosis Safe owners → Core Dev + Council + Vote + Dev & Builder topics
🗳️ Voter: Any wallet with locked IFR > 0 → Vote topic
🔨 Builder: Registered in BuilderRegistry.sol → Vote + Dev & Builder topics
👤 Community: Verified wallet → General access

Use /mystatus in Telegram to check your current tier and access level.

The Bootstrap is a 90-day community liquidity event powered by the BootstrapVaultV3 smart contract. Anyone can contribute ETH (0.01–2 ETH per wallet). All collected ETH is paired with ~200M IFR to create the Uniswap V2 liquidity pool. No team ETH is used. The process is fully trustless and permissionless.

Minimum: 0.01 ETH per transaction. Maximum: 2 ETH total per wallet (hardcoded in the smart contract). The per-wallet cap prevents whale domination and ensures fair distribution. These limits are immutable — they cannot be changed after deployment.

Any Ethereum wallet that supports direct contract interaction: MetaMask, Rabby, Rainbow, Coinbase Wallet, or any WalletConnect-compatible wallet. Make sure you are connected to Ethereum Mainnet and have enough ETH for the contribution plus gas fees (~$2–5 at normal gas prices).

If the Bootstrap is not finalised within the 90-day window, a 30-day grace period begins. After the grace period expires, any contributor can call refund() to get their ETH back. This is fully permissionless — no admin action needed. The refund function is a V3 improvement specifically designed for contributor protection.

Anyone. The finalise() function is permissionless — any wallet can call it once the minimum ETH threshold is met. The function creates the Uniswap V2 LP pair, adds all ETH + IFR as liquidity, and locks the LP tokens. No admin intervention required.

After finalisation, LP tokens will be locked for a minimum of 12 months via Team.Finance or a similar LP lock provider. This prevents the team from pulling liquidity (rug-pull protection). The lock transaction is publicly verifiable on Etherscan.

Trading begins the moment finalise() is called and the Uniswap V2 LP is created. Before that, IFR cannot be traded on any DEX. The BootstrapVaultV3 is already funded with ~200M IFR (11.03.2026) and fee-exempt (Proposals #4+#5 executed). The 90-day contribution window must complete before finalisation.

The BootstrapVaultV3 was funded on 11.03.2026 with ~200M IFR from the Treasury Safe (150M) and Community Safe (50M). This is the “Plan B” approach because the original LiquidityReserve is locked until 01.09.2026 and cannot be used. BootstrapVaultV3 is fee-exempt since Governance Proposal #4 execution (11.03.2026). See 🔥 Bootstrap Event for full details.

No. The BootstrapVaultV3 contract has no admin withdraw function for contributed ETH. LP tokens are locked after finalisation. The team cannot pull liquidity at any point. The finalise() function is permissionless — anyone can trigger it. The contract code is verified and open-source on Etherscan.

No. The team allocation (15%, 150M IFR) is locked in the Vesting contract with a 12-month cliff and 36-month linear vesting. Zero tokens are available to the team for the first 12 months. After the cliff, tokens release gradually over the remaining 24 months. The Vesting contract is on-chain and verified — the schedule cannot be accelerated.

All treasury wallets are publicly documented with Etherscan links. The Treasury Safe (0x5ad6193eD6E1e31ed10977E73e3B609AcBfEcE3b) and Community Safe (0xaC5687547B2B21d80F8fd345B51e608d476667C7) are Gnosis Safe multisigs with all transactions visible on-chain. The Transparency Report provides 8 on-chain verification checks.

No. Inferno follows the Community Fair Launch Model (CFLM): no presale, no ICO, no venture capital, no seed round, no private sale. All tokens are distributed at deployment with transparent allocation. The Bootstrap Event is a community liquidity event — contributors provide ETH, which is paired with IFR to create the Uniswap V2 LP. After finalisation, contributors call claim() to receive their pro-rata IFR share.

Verification checklist:

• All 17 on-chain components verified on Etherscan — read the source code
• Full repository open-source at GitHub
• 544 automated tests, 99% coverage
• No mint function — verify in contract source
• All wallet addresses publicly documented
• Governance timelock — all changes visible 48h in advance
• No hidden admin functions — Slither confirms

Anonymous team? — Pseudonymous but consistent identity across platforms.
Closed source? — No, 100% open-source, all contracts verified.
Mint function? — No, structurally impossible.
Admin withdraw? — No admin can access user funds or Bootstrap ETH.
Upgradeable proxy? — No, all contracts immutable.
Unlocked liquidity? — LP will be locked 12+ months.
Unrealistic promises? — No price predictions, no “moon” language, utility-only narrative.

15% of the total supply (150,000,000 IFR) is allocated to the team, held in the Vesting contract. This is a standard allocation for a community-first project — many projects allocate 20–30% to the team. The allocation is fully transparent and on-chain verifiable.

No. The Vesting contract enforces a 12-month cliff: zero tokens are available for the first 12 months after deployment (March 2026 → March 2027). After the cliff, tokens vest linearly over 24 additional months. The team can only claim what has vested. The schedule is enforced by immutable smart contract code.

The Vesting contract (0x2694Bc84e8D5251E9E4Ecd4B2Ae3f866d6106271) holds 150M IFR. It calculates the vested amount based on block timestamps: vestedAmount = totalAllocation * (elapsed - cliffDuration) / vestingDuration. The beneficiary can only call release() to claim what has vested. The cliff, vesting duration, and beneficiary are set at deployment and cannot be changed. See Vesting Schedule for details.

The Community Safe (0xaC5687547B2B21d80F8fd345B51e608d476667C7) holds the 6% Community & Grants allocation (60M IFR). It funds: community initiatives, developer grants, bug bounties, marketing, and Bootstrap funding (50M IFR contributed to BootstrapVaultV3). All transactions are visible on the Safe interface.

This is an intentional self-restriction as a trust signal. The team vesting schedule means roughly 10M IFR becomes available in the first 9 months after the cliff ends. This demonstrates long-term commitment: the team earns alongside the community over 36 months, not upfront. If the project fails, the team loses too.

Phase 1: Foundation — smart contracts, testing, testnet deployment
Phase 2: Mainnet — deployment, verification, LP creation
Phase 3: Growth — Bootstrap event, builder onboarding, community expansion
Phase 4: Decentralization — multisig governance, DAO transition
Phase 5: Scaling — L2 expansion, cross-chain bridges, guarded automation

See Roadmap for the full breakdown.

DAO governance is Phase 4, planned after the multisig governance phases are stable. There is no fixed date — the transition happens when: the multisig has operated successfully for 6+ months, sufficient community participation exists, and anti-manipulation safeguards (voting escrow, quorum thresholds, time-weighted voting) are implemented and tested.

The planned model uses lock-weighted voting: only locked IFR counts for governance power. This prevents flash-loan attacks (you cannot borrow, vote, and return in one transaction). Additional safeguards include: quorum requirements, minimum proposal thresholds, voting escrow (longer locks = more weight), and the 48-hour timelock on execution. See DAO Governance for the full concept.

When a user locks IFR for a builder's product, the builder earns a percentage from the Builder Ecosystem Pool (40M IFR). The reward rate has hard bounds of 5–25% (governance target 10–20%). Rewards vest over 6–12 months. The system is designed so builder rewards are always less than user locks, creating net deflation.

Yes. The official channels are:

• X / Twitter: @IFRtoken
• Telegram Announcements: t.me/IFRtoken (read-only)
• Telegram Community: t.me/IFR_token
• GitHub: github.com/NeaBouli/inferno

Be cautious of impersonators. The only official links are listed on the main website. Inferno will never DM you first or ask for private keys.

Cross-chain expansion is Phase 5, planned after Ethereum governance is fully decentralized. Potential targets include Arbitrum, Optimism, and Base. However, the fee-on-transfer mechanism requires careful bridging design — standard bridges do not support deflationary tokens out of the box. This is not a near-term priority.

To submit a proposal in The Forum (Chamber 2), 10 IFR are required as a spam protection fee. This prevents low-quality or spam proposals.

• If the proposal reaches consensus (top 3 after voting period), the 10 IFR are refunded.
• If the proposal is downvoted below 50%, the IFR are burned — adding deflationary pressure.

This creates an economic incentive to submit quality proposals. The mechanism is implemented in IFRSpamProtection.sol (Phase 4).

DAO governance (Phase 4) is planned after:

• ✅ LP is live (after Bootstrap closes June 5, 2026)
• ✅ Ecosystem is built (Builder Registry active, community established)
• ✅ Multisig governance has operated successfully

The three new contracts needed — RatVoting.sol, ForumVoting.sol, and IFRSpamProtection.sol — are designed and planned. BuilderRegistry.sol (Phase 3) is already complete with 27 tests passing.

Supply: No. The token supply is fixed at 1,000,000,000 IFR — there is no mint() function. This cannot be changed by governance or anyone else.

Burn rate: The 2.5% burn rate can be adjusted by governance, but only within hard bounds defined in the contracts. The maximum fee cap is 5% (hardcoded). No parameter can be changed instantly — all changes require the 48h Timelock, giving the community time to review.

BuilderRegistry.sol is an on-chain registry of verified IFR builders and integration partners. It is controlled exclusively by Governance (Timelock) and supports 4 categories: Creator, Integration, Tooling, and DAO.

Registered builders gain:
• Access to the Dev & Builder Telegram topic
• Eligibility for Creator Rewards via the PartnerVault contract
• On-chain verification status

To apply: ifrunit.tech/wiki/integration.html
Current status: Contract complete (27 tests), Sepolia deploy pending (Phase 3).

Call the read-only function on the IFRLock contract:

const ifrLock = new ethers.Contract(
  "0x769928aBDfc949D0718d8766a1C2d7dBb63954Eb",
  ["function isLocked(address,uint256) view returns (bool)"],
  provider
);
const hasLock = await ifrLock.isLocked(walletAddress, ethers.utils.parseUnits("1000", 9));
// true if wallet has >= 1000 IFR locked

This is a single on-chain call. No API keys, no user databases, no privacy concerns.

ABIs are available in two locations:

• /abi/ directory in the GitHub repository (JSON files)
• Etherscan “Contract” → “ABI” tab for each verified contract

For the IFRLock contract, the key functions are: lock(uint256, string), unlock(), isLocked(address, uint256), and lockedBalance(address).

Fee-exempt addresses (verified on-chain as of March 2026):

• IFRLock: 0x769928aBDfc949D0718d8766a1C2d7dBb63954Eb
• LiquidityReserve: 0xdc0309804803b3A105154f6073061E3185018f64
• BuybackVault: 0x670D293e3D65f96171c10DdC8d88B96b0570F812
• BurnReserve: 0xaA1496133B6c274190A2113410B501C5802b6fCF
• PartnerVault: 0xc6eb7714bCb035ebc2D4d9ba7B3762ef7B9d4F7D
• Vesting: 0x2694Bc84e8D5251E9E4Ecd4B2Ae3f866d6106271

BootstrapVaultV3: fee-exempt since Proposal #4 (executed 11.03.2026)
• FeeRouterV1: fee-exempt since Proposal #5 (executed 11.03.2026)

• Smart contracts: Solidity 0.8.20, Hardhat v2, OpenZeppelin v5, ethers v5
• Testing: Chai v4, 544 tests (367 contract + 77 app + 100 vault), Slither static analysis
• Frontend apps: React 18, Vite, TypeScript, Tailwind CSS
• Backend apps: Express.js, Prisma, SQLite, SIWE authentication
• Infrastructure: GitHub Pages (docs), Railway (AI Copilot), Alchemy (RPC)

Fork the repository, create a feature branch, and submit a pull request. Read the Contributing Guide for coding standards, commit message conventions (feat:, fix:, docs:, test:), and the PR template. All contributions must include tests where applicable. The project uses CJS-only (Hardhat v2 requirement).

The FeeRouter (0x4807B77B2E25cD055DA42B09BA4d0aF9e580C60a) processes protocol fees on IFR swaps. Default fee: 0.05% (5 bps), hard cap: 0.25% (25 bps). It supports EIP-712 signed vouchers for fee discounts (earned through IFR Points). The contract has pause functionality, replay protection, and governance-controlled parameters. See Fee Design.

The IFR Benefits Network lets any business — online or offline — offer discounts and premium access to customers who have IFR tokens locked. It connects IFR lockers with builder businesses through on-chain verification. No crypto knowledge is required on the merchant side.

Three steps:

1. The merchant opens their business link and clicks “Start Verification” — a QR code appears
2. The customer scans the QR code, connects their wallet, and signs a message (no app installation needed)
3. The system checks on-chain if the customer has enough IFR locked. If yes: APPROVED (green screen). The merchant clicks “Redeem”.

The verification is single-use and expires after 60 seconds — screenshots and videos cannot be reused.

The backend generates a unique session with a random challenge string. The customer signs this challenge with their wallet (proving ownership without revealing private keys). The backend verifies: (1) the signature is valid for the challenge, (2) the recovered wallet address has sufficient IFR locked on-chain. This is a standard Web3 authentication pattern — no tokens are transferred during verification.

No. The merchant sees a simple web interface: “Start Verification” button, QR code, and green/red result screen. They never interact with wallets, blockchains, or smart contracts. The entire crypto layer is abstracted away. The merchant only needs a browser and an internet connection. See Business Onboarding for the setup guide.

1. Read the Business Onboarding guide
2. Set your lock threshold tiers (e.g., 1000 IFR = 10% discount)
3. Register through the builder onboarding process
4. After approval, a governance proposal adds you to the PartnerVault
5. You start earning Creator Rewards when users lock IFR for your product

Builders register through the onboarding process. Allocations are KPI- and lock-based, governed by Governance proposals. There are no fixed tier thresholds — all allocations are milestone-based and vested.

Ethereum was chosen for maximum security, decentralization, and composability. The fee-on-transfer mechanism relies on EVM _update() hooks that work best on Ethereum L1. Multi-chain expansion is Phase 5 — first the protocol must be stable and governance decentralized on one chain before bridging to others.

The name references Dante Alighieri's “Inferno” (first part of the Divine Comedy). Like in Dante's vision, fire purifies what passes through it. With every IFR transaction, 2.5% burns permanently — what remains is purer, scarcer, stronger. The fire metaphor represents the deflationary mechanism at the heart of the protocol.

Yes — but differently from other locked tokens. The 40M IFR in the Builder Vault (PartnerVault contract) cannot be withdrawn directly by anyone, including the team.

They can only flow out through real user adoption: when a user locks IFR for a Builder product, a percentage is automatically released as a reward for that Builder, then vests linearly over 6–12 months.

If no users ever lock IFR, all 40M remain locked in the contract permanently. This makes the Builder Vault a pure adoption incentive — not a team treasury. All parameters (reward rate, emission cap, vesting period) are controlled by Governance with a 48-hour timelock.

After the Bootstrap Event finalises and the Uniswap V2 LP is created, IFR will be tradeable on Uniswap V2 (Ethereum Mainnet). Set slippage to at least 4% (3.5% fee + AMM slippage). Always verify the official contract address: 0x77e99917Eca8539c62F509ED1193ac36580A6e7B. Do not trust links from DMs or unofficial channels.

Official links only:

• Website: ifrunit.tech
• GitHub: github.com/NeaBouli/inferno
• X / Twitter: @IFRtoken
• Telegram: t.me/IFRtoken (Announcements) | t.me/IFR_token (Community)
• Token: Etherscan

Warning: Inferno will never DM you first, never ask for private keys, never offer “guaranteed returns”, and never request you to send tokens to any address. If someone claims to be from the Inferno team and contacts you first, it is a scam.

3 safety layers protect the protocol: 1) CommitmentVault prevents contributors from dumping their IFR claims. 2) LendingVault creates organic buy pressure as builders repay IFR loans. 3) LP Reserve Safe (400.6M IFR, Gnosis 3-of-5) adds liquidity at price milestones only. The system grows organically regardless of initial ETH raised.

Yes. finalise() is permissionless — anyone can call it after June 5, 2026. Whatever ETH was raised sets P0. The safety net (CommitmentVault + LendingVault) protects against low initial liquidity.

P0 = Total ETH raised / 100,000,000 IFR. It is the initial IFR price after Bootstrap. All CommitmentVault tranches are relative to P0 (P0×2, P0×10, P0×5000). P0 is IMMUTABLE once set in CommitmentVault.

The token owner is the Governance Contract — not a single person. All changes require: (1) A public governance proposal, (2) 48-hour timelock (community can review), (3) Execution by TreasurySafe (3-of-5 Gnosis Safe). No individual can change fees unilaterally. The fee cap is hardcoded at max 5% and cannot be exceeded even by governance.

All fee-exempt addresses are public and on-chain verifiable. Only protocol contracts are exempt: Vesting, BurnReserve, BootstrapVaultV3, TreasurySafe, CommunitySafe, and Deployer (legacy). No DEX routers or insider wallets have exemptions. Any exemption change requires Governance approval with a 48-hour timelock. You can verify all exempt addresses on Etherscan.

9 decimals is a deliberate design choice. It provides sufficient precision while keeping token amounts readable. IFR is fully compatible with Uniswap V2 and all standard DEX interfaces. Some wallet display tools may show different formatting — always verify on Etherscan.