Tokenomics Deep Dive
Complete breakdown of IFR fee mechanics, deflation model, token allocation, fair launch design, and fee-exempt addresses.
1. Fee-on-Transfer Mechanics
Every standard ERC-20 transfer of IFR triggers an automatic fee mechanism built directly into the token's _update function. This is not an external router or wrapper — the fee logic lives inside the token contract itself, making it impossible to bypass on any DEX or wallet transfer.
Fees are only applied on normal transfers between non-exempt addresses. Minting (from address(0)) and burning (to address(0)) are excluded. If either the sender or the recipient is marked as feeExempt, the entire fee is waived.
Fee Breakdown
| Fee Type | Rate | Basis Points | Destination |
|---|---|---|---|
| Sender Burn | 2.0% | 200 bps |
address(0) — permanently burned |
| Recipient Burn | 0.5% | 50 bps |
address(0) — permanently burned |
| Pool Fee | 1.0% | 100 bps |
poolFeeReceiver — protocol wallet |
| Total | 3.5% | 350 bps |
— |
| Max Cap (governance limit) | 5.0% | 500 bps |
Sum of all three cannot exceed this |
Calculation Example
Sending 10,000 IFR
Contract Logic
The fee mechanism is implemented by overriding OpenZeppelin's _update internal function. All fee calculations use basis points (1 bps = 0.01%) for precision with integer arithmetic.
function _update(address from, address to, uint256 value) internal override {
// Only apply fees on normal transfers (not mint/burn)
// and when neither party is exempt
if (from != address(0) && to != address(0)
&& !feeExempt[from] && !feeExempt[to])
{
uint256 burnSender = (value * senderBurnBps) / 10_000;
uint256 burnRecipient = (value * recipientBurnBps) / 10_000;
uint256 poolFee = (value * poolFeeBps) / 10_000;
uint256 totalBurn = burnSender + burnRecipient;
uint256 netAmount = value - totalBurn - poolFee;
// Net amount to recipient
super._update(from, to, netAmount);
// Pool fee to receiver
super._update(from, poolFeeReceiver, poolFee);
// Burn — tokens go to address(0), totalSupply decreases
super._update(from, address(0), totalBurn);
} else {
super._update(from, to, value);
}
}
Important: If either the sender or the recipient is feeExempt, the entire transfer proceeds without any fees. Both parties must be non-exempt for fees to apply.
2. Deflation Model
Inferno is a purely deflationary token. There is no minting function beyond the initial supply creation in the constructor. Every taxed transfer permanently removes tokens from circulation by sending them to address(0), which decreases totalSupply.
Key Properties
- Initial supply: 1,000,000,000 IFR (1 billion)
- Burn rate per transfer: 2.5% of the transferred amount (2.0% sender burn + 0.5% recipient burn)
- No minting function exists — supply can only decrease, never increase
- Pool fee (1.0%) goes to
poolFeeReceiverand does not reduce supply - Burn rate is volume-dependent, not time-dependent — more trading = faster deflation
Projected Supply Scenarios
The following table illustrates how supply decreases based on cumulative transfer volume. These are simplified examples assuming uniform transfer sizes and no fee-exempt transfers.
| Scenario | Transfer Volume | Approx. Burned | Remaining Supply | % Deflation |
|---|---|---|---|---|
| 1,000 transfers of 10,000 IFR | 10,000,000 IFR | 250,000 IFR | 999,750,000 IFR | 0.025% |
| 10,000 transfers of 10,000 IFR | 100,000,000 IFR | 2,500,000 IFR | 997,500,000 IFR | 0.25% |
| 100,000 transfers of 10,000 IFR | 1,000,000,000 IFR | 25,000,000 IFR | 975,000,000 IFR | 2.5% |
| 1M transfers of 10,000 IFR | 10,000,000,000 IFR | 250,000,000 IFR | 750,000,000 IFR | 25% |
Key Insight: The deflation rate is entirely driven by transfer volume, not by the passage of time. High trading activity on DEXes accelerates token burns. During low-activity periods, the supply remains stable. This creates a natural correlation between usage and scarcity.
Fee Governance
The owner (Governance contract with 48-hour timelock) can adjust the three fee rates via setFeeRates(). The hard cap of 500 bps (5%) is enforced on-chain — the sum of all three rates can never exceed this limit, even through governance action.
function setFeeRates(
uint256 _senderBurnBps,
uint256 _recipientBurnBps,
uint256 _poolFeeBps
) external onlyOwner {
require(_senderBurnBps + _recipientBurnBps + _poolFeeBps <= 500, "fees>5%");
senderBurnBps = _senderBurnBps;
recipientBurnBps = _recipientBurnBps;
poolFeeBps = _poolFeeBps;
}
3. Token Allocation
The total initial supply of 1,000,000,000 IFR is distributed across six categories at deployment. All allocations are executed in the deploy script — there is no ongoing emission or inflation mechanism.
| Category | Percentage | Amount (IFR) | Unlock Schedule |
|---|---|---|---|
| DEX Liquidity | 40% | 400,000,000 | Held by LP Reserve Safe (3-of-5 Gnosis Safe) for governance-controlled LP expansion. Bootstrap LP was created separately by BootstrapVaultV3.finalise() with 100M IFR + 0.030 ETH on 05.06.2026. |
| Liquidity Reserve | 20% | 200,000,000 | Initial timelock ended 01.09.2026. All 200M IFR remains held; current cap is 50M IFR per 90 days and 0 IFR has been withdrawn. NOT used for Bootstrap. |
| Team Vesting | 15% | 150,000,000 | 12-month cliff, 36-month linear vesting. 0 tokens available before March 2027. |
| Treasury | 15% | 150,000,000 | Gnosis Safe multisig. Funded Bootstrap with 144.75M IFR plus a 5.25M IFR top-up. No automatic refill path is deployed. |
| Community & Grants | 6% | 60,000,000 | Community Safe (57.9M received — 1.5M burned + 0.6M pool fee). 50M → Bootstrap. ~7.9M operational reserve. |
| Builder Ecosystem | 4% | 40,000,000 | PartnerVault contract. Partner rewards not active; planned for verified checkout redemptions only. |
Allocation Visualization
Unlock Schedule Details
DEX Liquidity (40% — 400M IFR)
- Held by LP Reserve Safe for governance-controlled LP expansion
- Initial Uniswap V2 LP is already live via BootstrapVaultV3 finalise()
- Reserve additions require explicit governance timing
Liquidity Reserve (20% — 200M IFR)
- The initial smart-contract timelock ended 01.09.2026. All 200M IFR remains held and was NOT used for Bootstrap (Plan B decision, 08.03.2026).
- The contract currently permits at most 50M IFR per 90-day period. Capacity does not transfer automatically or accumulate as an automatic LP addition; 0 IFR has been withdrawn.
- Purpose: supplemental liquidity, market-making, or strategic partnerships
Team Vesting (15% — 150M IFR)
- Locked in the Vesting contract with a 12-month cliff
- After the cliff: linear vesting over 36 months
- Total vesting period: 48 months (4 years)
- Prevents team dumps and aligns long-term incentives
Treasury (15% — 150M IFR)
- Held in Gnosis Safe multisig (
0x5ad6193eD6E1e31ed10977E73e3B609AcBfEcE3b) - 150M IFR funded BootstrapVaultV3 in two Treasury transfers: 144.75M IFR plus a 5.25M IFR top-up
- Remaining balance used for development, operations, and strategic initiatives
- All disbursements require multisig approval
Community & Grants (6% — 60M IFR)
- Sent to Community Safe: 57.9M received after 1.5M burn (2.5%) + 0.6M pool fee (1%) = 2.1M total deducted (EOA not feeExempt)
- 50M allocated to Bootstrap funding via BootstrapVaultV3
- ~7.9M retained as operational reserve (after burn)
Builder Ecosystem (4% — 40M IFR)
- Dedicated pool managed by the PartnerVault contract (Mainnet:
0xc6eb7714bCb035ebc2D4d9ba7B3762ef7B9d4F7D) - Partner rewards are not active. Planned distribution: IFR only for verified checkout redemptions at registered pilot partners, valued in EUR, vested over 6–12 months
- Hard budget per partner; the pool is never refilled
- All allocations vest linearly — no instant dumps
- Builder tokens grant DAO voting rights in Phase 4+
🔒 Builder Vault — Why are the 40M safe?
The 40M IFR in the Builder Vault are not freely available. They can only be released through real usage:
- A user locks IFR for a Builder product
- The Vault automatically pays a % as reward
- Rewards vest linearly over 6–12 months
- No admin can withdraw the 40M directly
- All parameters are controlled by Governance (48h timelock)
Bottom line: If nobody locks IFR, all 40M remain permanently locked in the contract.
Note: BuybackVault and BurnReserve are not genesis allocations. The 1% IFR transfer-pool fee accrued in FeeRouterV1 until Proposal #21 (05.10.2026) and goes to BuybackController since; it is not automatically forwarded to either contract. Bootstrap was funded via Plan B from Treasury + Community Safe — not a standalone genesis bucket.
Bootstrap Event (Plan B — COMPLETED ✅ 05.06.2026)
- Funded via Plan B: Treasury Safe (144.75M initial + 5.25M top-up) + Community Safe (50M) = 200M IFR in BootstrapVaultV3
- Bootstrap period: 07.03.2026 – 05.06.2026 — finalise() executed 05.06.2026 23:51 UTC
- totalETHRaised: 0.030 ETH — LP Token: 0xbE495E9c0d8cc2DCf95570cf95B63c4844dF31A0
- BootstrapVaultV3 contract:
0xf72565C4cDB9575c9D3aEE6B9AE3fDBd7F56e141— FINALIZED — Block 25254575 — TX: 0x949848bd… - Proposal #15 executed 08.06.2026: LP Token feeExempt = true
- Proposal #16 executed 09.06.2026: CommitmentVault P0 = 300,000,000 wei
LP Allocation — Phased Release
| Phase | Amount | Trigger | Mechanism |
|---|---|---|---|
| Phase 1 ✅ | 100M IFR | DONE — finalise() 05.06.2026 23:51 UTC | LP created: 100M IFR + 0.030 ETH → Uniswap V2 LP. 100M IFR reserved for contributor claims. LP Token: 0xbE495E9c…. Team.Finance was disabled; LP remains in BootstrapVaultV3, which exposes no LP withdrawal function. |
| Phase 2 | 100M IFR | Not scheduled; initial reserve lock ended 01.09.2026 | The current 50M-per-90-day cap cannot supply 100M in one period. Any reserve withdrawal needs a Governance proposal + 48h timelock; any cap change and LP action require separate explicit decisions. |
| Phase 3 | 100M IFR | Governance decision (flexible timing) | 3-of-5 Multisig + 48h Timelock. Amount and timing based on market conditions. |
Iron rule: ETH always stays in the LP — never withdrawn by the team.
BuybackVault (protocol contract — not a genesis allocation)
- Accepts ETH for a governed ETH-to-IFR buyback; it does not receive the 1% IFR transfer-pool fee automatically
- Not pre-funded at genesis. Current balance: 0 IFR.
- BuybackController.sol — Deployed 14.04.2026 (0x1e05...F7c):
- 50/50 split: buyback+burn / LP deepening
- Permissionless
execute()with 24h cooldown - Slippage protection (minIFR/minETH parameters)
- Governance wiring: Proposal #13 (feeExempt) executed 16.04.2026, Proposal #14 (native-ETH
feeCollector) executed 18.04.2026. Execution remains trigger-, cooldown- and balance-dependent; since Proposal #21 (05.10.2026) the 1% IFR pool fee goes to BuybackController; the IFR previously held by FeeRouterV1 was recovered to the Treasury Safe on 07.10.2026 (Proposals #22/#23).
BurnReserve (protocol contract — not a genesis allocation)
- Receives IFR only through explicit transfers or buyback execution; it is not the automatic 1% fee receiver
- Not pre-funded at genesis. Current balance: 0 IFR.
- Structured token burning to accelerate deflation
- Burns are executed via governance — transparent and verifiable on-chain
4. Fair Launch Model (CFLM)
Inferno uses a Community Fair Launch Model (CFLM), which guarantees that no individual or group receives preferential access to tokens before public trading begins.
Core Principles
| Principle | Implementation |
|---|---|
| No presale | Zero tokens sold before Uniswap listing |
| No private rounds | No seed, private, or strategic investor allocations |
| No VC allocations | No venture capital or institutional pre-purchase agreements |
| Transparent distribution | All token transfers executed via the public deploy script on-chain |
| Deployer exemption disclosed | The Deployer EOA remains feeExempt = true after executed Proposal #7 (18.03.2026); no revocation proposal is recorded through #16 |
| Team tokens vested | 15% allocation locked for 48 months (12-month cliff + 36-month linear) |
| Liquidity locked | Reserve tokens locked for a minimum of 6 months |
How It Works
- The deploy script mints the entire 1B IFR supply to the deployer
- The deployer distributes tokens to all allocation contracts (Vesting, LiquidityReserve, Treasury, Community wallet)
- 40% is paired with ETH on Uniswap V2, creating the initial liquidity pool
- Executed Proposal #7 set the Deployer EOA
feeExempt = true; the active exemption is publicly disclosed and remains governance-revocable - Ownership of InfernoToken (and all admin functions) is transferred to the Governance contract with its 48-hour timelock
- From this point, no single entity has privileged access to the token
Verification: Every step of the CFLM deployment is fully verifiable on-chain. All contract source code is verified on Etherscan, and the deploy script is open source in the project repository.
5. Fee Exempt Addresses
Certain protocol contracts are marked as feeExempt to ensure that internal protocol operations (vesting releases, reserve unlocks, buyback executions, burns) are not taxed. Without these exemptions, protocol mechanisms would lose tokens to fees on every internal transfer, breaking the intended allocation math.
Exempt Contracts
0xbE495E9c0d8cc2DCf95570cf95B63c4844dF31A0) — Proposal #15 executed 08.06.2026, feeExempt = true.0x6b36687b0cd4386fb14cf565B67D7862110Fed67 — Proposal #7 executed 18.03.2026. The exemption is visible in feeExempt(address) and can be revoked only through Governance.Exemption Rules
- If either the sender or recipient is
feeExempt, the entire transfer is fee-free - Exemptions are set via
setFeeExempt(address, bool)by the owner (Governance contract) - The Deployer EOA is currently exempt under Proposal #7; this is an active disclosed governance-controlled exception, not a revoked historical permission
- Adding or removing exemptions requires a governance proposal with 48-hour timelock
// Setting fee exemption (onlyOwner = Governance contract)
function setFeeExempt(address account, bool exempt) external onlyOwner {
feeExempt[account] = exempt;
emit FeeExemptUpdated(account, exempt);
}
// Fee check in _update:
// Both sender AND recipient must be non-exempt for fees to apply
if (from != address(0) && to != address(0)
&& !feeExempt[from] && !feeExempt[to])
{
// ... apply fees
}
Security Note: The fee exemption mapping is controlled exclusively by the Governance contract (owner). No single EOA can grant or revoke exemptions. Any change requires a proposal, a 48-hour waiting period, and execution — giving the community time to review and react.
6. PartnerVault & Partner Rewards
The Builder Ecosystem Pool (4%, 40M IFR) sits in the PartnerVault contract on Ethereum Mainnet.
Partner rewards are not active: no partner is registered and no reward has been paid
(verified on-chain: totalAllocated, totalRewarded and totalClaimed are 0).
The pool is never refilled.
Decided Model: Verified Checkout Redemptions
From the first pilot partner on, rewards follow one rule: IFR only for a real, seller-confirmed checkout redemption at a registered pilot partner. A lock alone never earns a reward.
| Property | Value |
|---|---|
| Pool Size | 40,000,000 IFR (4% of supply), no refill |
| Trigger | Verified checkout redemption at a registered pilot partner |
| Valuation | EUR per redemption, paid in IFR at the published 7-day TWAP at settlement; no fixed rate |
| Per-Partner Budget | Hard cap (the partner's PartnerVault allocation), set per pilot by Governance |
| Settlement | Per period by Governance proposal (recordMilestone, 48h timelock) |
| Vesting | 180–365 days linear per partner, optional cliff (contract bounds) |
| Pause | Treasury Safe (PartnerVault guardian) |
| Claim | claim() by the partner beneficiary after vesting |
Contract parameters that the model does not use: PartnerVault also contains a lock-triggered
path, recordLockReward, paying lockAmount × rewardBps / 10000
(rewardBps = 1500, contract bounds 500–2500) under a 4,000,000 IFR annual cap
(bounds 1M–10M). The project does not use this path, because a lock can be opened and closed again to farm
rewards. Policy: PARTNER_REWARDS_MODEL_B.md.
7. Bootstrap Pricing (Phase 0)
In the initial bootstrap phase, all pricing is token-denominated. There is no USD pricing, no oracle, and no TWAP — this is a deliberate design decision for a zero-capital launch.
How It Works
| Phase | Pricing Model | Requirements |
|---|---|---|
| Phase 0 (Current) | Product-defined IFR amount (for access while the threshold remains locked and the integration remains available) | No oracle, no USD, fully on-chain |
| Phase 2+ (Future) | USD-based via TWAP + ETH/USD oracle | ≥ 250K USD liquidity, price floor at 40% of launch price |
Why Token-Denominated?
- Zero capital required — no initial liquidity needed for price feeds
- Manipulation-resistant — no oracle to exploit, no flash loan attacks on pricing
- Fully on-chain — the lock amount is a simple
uint256, verifiable by any contract - Automatic adjustment — as IFR price increases, the USD-equivalent cost rises naturally, reducing token emission pressure
Transition to Phase 2: USD-based pricing will only be activated once sufficient DEX liquidity exists (≥ 250K USD). Until then, token-denominated pricing ensures the protocol functions without external dependencies.
8. Protocol Fee & FeeRouter
The FeeRouterV1 contract handles protocol-level fees on IFR swaps. These are separate from the token's built-in transfer fees (2.5% burn + 1% pool fee).
Where the 1% IFR pool fee goes: from Proposal #6 until Proposal #21 the token's poolFeeReceiver was FeeRouterV1.
FeeRouterV1 forwards only native-ETH swap fees and has no IFR withdrawal function; the IFR it held was
recovered to the Treasury Safe on 7 October 2026 by a governed batch (CWA-02). Since Proposal #21 (executed 5 October 2026, block 26,124,660)
pool fees go to BuybackController, where the IFR stays recoverable by Governance via withdrawIFR (the deployed controller is dormant, JUL-08, so nothing is used automatically).
FeeRouterV1 holds 0 IFR since that recovery.
Permanently lost IFR: only CV-01 — 26,418,467.99 IFR in CommitmentVault V1 price-conditioned tranches that can never unlock (not burned; still counted in totalSupply), 2.651% of totalSupply at block 26,151,369 (9 October 2026). The 734,545.07 IFR held by FeeRouterV1 are not lost: they were recovered to the Treasury Safe on 7 October 2026 by a governed batch (CWA-02, Proposals #22 and #23, block 26,143,797) and are unallocated Treasury IFR. FeeRouterV1 holds 0 IFR. Details: Transparency.
Fee Structure
| Parameter | Value | Notes |
|---|---|---|
protocolFeeBps | 5 bps (0.05%) | Default, governance-adjustable |
FEE_CAP_BPS | 25 bps (0.25%) | Hard cap, contract-enforced |
| Fee target | feeCollector = BuybackController | Set via Proposal #14 (18.04.2026) |
Discount Vouchers (IFR Points)
Users earn points through verified actions in the IFR ecosystem. Points can be redeemed for a signed EIP-712 discount voucher, applied against the FeeRouter protocol fee at swap time. A voucher waives that fee up to the current on-chain protocol fee (currently 5 bps, 0.05%); it never reduces the IFR token transfer fee or burn.
| Action | Points |
|---|---|
| Wallet Connect (SIWE) | 10 |
| Complete Wallet Setup Guide | 20 |
| Add IFR Token (Decimals verified) | 20 |
| Complete Lock Guide | 30 |
| Builder Onboarding | 50 |
Voucher status: the points-to-voucher issuer is not live. Under the
deployed FeeRouterV1, discountBps must be less than or equal to the
current 5-bps protocol fee. A larger discount fails validation and reverts instead
of clamping the fee to zero.
Important: IFR Points are not a token. They have no transfer value and no monetary promise. They only reduce the protocol fee on a single swap.
Contract Address (Mainnet)
0x4807B77B2E25cD055DA42B09BA4d0aF9e580C60a
— Etherscan