Security & Audit
Static analysis results, test coverage, reentrancy protections, access control matrix, trust model, and known limitations.
Full internal contract, on-chain, repository and documentation reviews. Independent professional third-party audit remains pending.
1. Slither Security Audit
The initial contract set was analyzed with Slither v0.11.5 and completed its scoped remediation with zero high or critical findings at that time. The current recursive gate covers all 21 production Solidity sources and reports zero unreviewed High signals and zero Critical signals under the pinned toolchain against a reviewed six-entry High baseline.
Current CI baseline: 21 production sources — 0 unreviewed High signals, 6 reviewed High signals explicitly baselined, 0 Critical signals reported by the pinned toolchain. The gate was integrated through PR #77 after exact-head and Main CI passed. The historical initial run recorded 51 detections, 15 fixes and 36 accepted informational or false-positive findings.
- Tool: Slither v0.11.5
- Initial findings: 51
- Fixed: 15
- Accepted (informational / false positives): 36
- Current CI policy: every Critical signal and every new, changed or stale High fingerprint fails closed
- Current reviewed baseline: six signals, including one future V2 hardening item for the unchecked ERC-20 return in
BuybackController.withdrawIFR()
Complementary Mythril Analysis
A separate bounded CI gate uses a hash-locked Python dependency set with Mythril v0.24.8 and setuptools 80.10.2 plus a repository-pinned SHA-256 for the Linux amd64 solc 0.8.28 artifact. It performs bounded symbolic execution of all 17 concrete production contracts. Four complete local runs on 4 September 2026 reported zero signals at any severity and completed in roughly six to seven minutes. The gate was integrated through PR #77 after exact-head and Main CI passed.
The workflow runs for relevant contract/tooling changes, weekly or on manual request, allows two transactions and 30 seconds of symbolic execution per contract, performs no on-chain lookup, and fails closed on hidden compiler/tool errors or any Critical, High or Medium signal. This is complementary evidence, not exhaustive state-space coverage or a professional third-party audit.
Fixes Applied
| Detector | Count | Fix Applied |
|---|---|---|
missing-zero-check |
4 | Added require != address(0) in BuybackVault constructor + setParams |
reentrancy-benign |
2 | Applied CEI (Checks-Effects-Interactions) pattern in BurnReserve |
immutable-states |
5 | Made owner, burnReserve, guardian immutable in BurnReserve, BuybackVault, LiquidityReserve |
unindexed-event |
4 | Added indexed to Pause/Unpause events in BuybackVault, LiquidityReserve |
2. Full Internal Contract Security Audit
The contract set in this recorded review was examined line-by-line across 10 internal check categories: reentrancy, access control, integer overflow, front-running, DoS, centralization, fee edge cases, timelock bypass, feeExempt manipulation, and owner privileges.
Result: 0 FAIL — 20 active WARN (1 fixed) — 81 PASS — Full Report
Scope notice: These are full internal audits and static-analysis records. They do not constitute independent professional certification. A professional third-party audit remains pending, and current source changes require current CI and analysis evidence.
Top Findings (Medium)
| # | Contract | Finding | Status |
|---|---|---|---|
| W1 | Governance | setOwner() bypasses timelock — immediate ownership transfer |
Multisig planned |
| W2 | Governance | Single owner key = single point of failure | ✅ Resolved — TreasurySafe 3-of-5 (20.03.2026) |
| W3 | BuybackVault | setParams has no bounds on burnShareBps, slippageBps, cooldown |
Fix in v3 |
| W4 | BuybackVault | Uniswap swap MEV-vulnerable (sandwich within slippage tolerance) | Flashbots on mainnet |
Community Audit Open
All contracts are open source. Security findings are welcome via private vulnerability reporting.
3. Test Coverage
The repository maintains contract, vault, application, wallet, browser and integration checks. Current exact results are recorded by CI and release preflights. The detailed counts below are a March 2026 internal snapshot, not a current deduplicated repository total.
Historical internal snapshot: 544 recorded checks passed at that review point. Use current CI and release records for current results.
| Test Suite | Tests | Coverage Areas |
|---|---|---|
| InfernoToken | 22 | Deployment, fee math, exemptions, owner functions, edge cases |
| LiquidityReserve | 42 | Lock period, staged withdrawal, pause, period limits, transferOwnership, edge cases |
| Vesting | 21 | Cliff, linear release, access control, pause, constructor, edge cases |
| BuybackVault | 26 | Deposit, buyback split, cooldown, slippage, activation delay, transferOwnership, edge cases |
| BurnReserve | 27 | Deposit, burn, burnAll, tracking, guardian auth, transferOwnership |
| Governance | 36 | Propose, execute, cancel, self-governance, integration |
| IFRLock | 37 | Lock, unlock, re-lock, isLocked, lockType, fee-exempt, pause, multi-user |
| PartnerVault | 95 | Builders, milestones, rewards, vesting, claims, authorizedCaller, anti-double-count, algo throttle, annual cap, bounds |
| FeeRouterV1 | 33 | Deployment, fee charging, voucher discount, voucher validation (isVoucherValid), replay protection, signer rotation, fee collector, access control, pause, receive ETH |
| BuilderRegistry | 27 | Register, remove, update, category validation, access control, views, edge cases |
| VoteAnnouncement | 12 | Deduplication, state detection (new/executable/executed/cancelled), calldata decode, multi-proposal polling |
| AnnouncementBot | 10 | Community link, channel sync, auto-pin, admin guards, topic IDs, no German strings, test commands |
Run the full test suite:
npx hardhat test
Solidity Coverage (solidity-coverage)
Historical coverage was measured with solidity-coverage for the contract subset recorded in March 2026: 99% statements, 91% branches, 98% functions, 99% lines. This is not a current full-repository coverage claim.
| Contract | Stmts | Branch | Funcs | Lines |
|---|---|---|---|---|
| InfernoToken | 100% | 92.86% | 100% | 100% |
| LiquidityReserve | 100% | 86.67% | 100% | 100% |
| Vesting | 96.55% | 69.44% | 88.89% | 97.5% |
| BuybackVault | 100% | 61.76% | 100% | 100% |
| BurnReserve | 100% | 100% | 100% | 100% |
| Governance | 100% | 97.92% | 100% | 100% |
| IFRLock | 100% | 85.71% | 100% | 100% |
| PartnerVault | 98.31% | 84.51% | 100% | 99.33% |
| FeeRouterV1 | 100% | 96% | 100% | 100% |
Full coverage report: COVERAGE_REPORT.md
Internal Security Review — Bootstrap Flow
Date: 13 March 2026 | Scope: BootstrapVaultV3, InfernoToken, FeeRouterV1, Governance/Timelock
Method: Manual internal code review plus the automated-test and coverage snapshot available on 13 March 2026
The 3 low-risk findings are structural design choices, not vulnerabilities:
- Front-running — neutralized by pro-rata distribution and 2 ETH cap
- 100% refund scenario — remaining IFR tokens locked permanently (effectively burned by design)
- Frontend is read-only — no Web3 write calls, users interact directly via Etherscan
This is an internal review, not a professional third-party audit. Full technical report: audit/BOOTSTRAP_SECURITY_REVIEW_13032026.md. A formal audit by an independent firm is planned before Phase 3.
4. Reentrancy Protection
Every contract that performs external calls is protected against reentrancy attacks through one of two mechanisms: OpenZeppelin's ReentrancyGuard modifier or the Checks-Effects-Interactions (CEI) pattern.
| Contract | Protection | Details |
|---|---|---|
| IFRLock | ReentrancyGuard | OpenZeppelin nonReentrant modifier on both lock() and unlock() |
| BurnReserve | CEI Pattern | State updated before external token calls; Checks-Effects-Interactions enforced |
| BuybackVault | CEI Pattern | State updated before external calls; all token operations are the last statement |
| All external token calls are the last operation in their respective functions. | ||
5. Access Control Matrix
The following matrix shows which roles can call which functions on each contract. Owner refers to the contract owner (Governance after ownership transfer), Guardian is the emergency role, Anyone means any external address, and Self means the contract calling itself via a governance proposal.
| Contract | Owner | Guardian | Anyone | Self |
|---|---|---|---|---|
| InfernoToken | setFeeRates, setFeeExempt, setPoolFeeReceiver |
— | transfer, burn |
— |
| LiquidityReserve | withdraw, setMaxWithdraw |
pause, unpause |
— | — |
| Vesting | — | pause, unpause |
release (beneficiary only) |
— |
| BuybackVault | executeBuyback, setParams |
pause, unpause |
depositETH |
— |
| BurnReserve | burn, burnAll, setGuardian |
burn, burnAll |
deposit |
— |
| Governance | propose, execute, cancel, setGuardian, setOwner |
cancel |
— | setDelay |
| IFRLock | — | pause, unpause, setGuardian |
lock, unlock (own tokens) |
— |
6. Trust Model
Inferno is designed so that no admin can make instant changes — all actions require a 48-hour public timelock delay and can be cancelled by the Guardian. Multiple safeguards are layered to protect token holders and ensure transparent governance.
Key principle: No admin can make instant changes. All sensitive operations are gated by a 48-hour timelock via Governance, publicly visible on-chain, and cancellable by the Guardian.
- InfernoToken owned by Governance — all parameter changes (fee rates, exemptions) require a proposal with a 48-hour timelock before execution.
- Team tokens vested — 12-month cliff followed by 36-month linear release. No early access possible.
- Liquidity reserve staged — the 6-month initial lock ended 01.09.2026; all 200M IFR remains held and the contract limits withdrawals to 50M IFR per 90-day period.
- BuybackVault activation delayed — 60-day activation delay before the first buyback can be executed.
- Guardian is emergency-only — the Guardian role can pause contracts and cancel governance proposals, but cannot withdraw funds, execute proposals, or change parameters.
- Builder Vault (40M IFR) governance-locked — cannot be withdrawn directly. Released only through user adoption: when a user locks IFR for a Builder product, a % is automatically paid as reward (vested 6–12 months). If nobody locks, all 40M stay locked permanently.
7. Known Limitations
While the Inferno contracts have been thoroughly tested and analyzed, the following limitations should be understood by users, integrators, and auditors.
| Limitation | Impact | Mitigation |
|---|---|---|
| Slither audit is static analysis only | Does not cover runtime exploits or economic attacks | Professional penetration test recommended as next security milestone |
| Governance owner transferred to TreasurySafe 3-of-5 ✅ (20.03.2026) | Single point of failure resolved — 3-of-5 multisig now controls Governance | Ownership transferred via direct setOwner() on 20.03.2026 (TX). All Safes 3-of-5. LP Reserve under multisig (55%+ of supply under multisig control). DAO governance planned for Phase 5. |
| No formal verification of mathematical properties | Fee calculations and vesting math are test-covered but not formally proven | Extensive unit tests with edge cases provide practical coverage |
| Fee-on-transfer can cause issues with some DeFi protocols | Protocols that don't account for transfer fees may receive fewer tokens than expected | Integrators must use balanceOf checks before and after transfer |
IFRLock requires feeExempt status |
Without fee exemption, unlock() fails due to balance mismatch from transfer fees |
IFRLock is set as fee-exempt during deployment; this must not be revoked |
CommitmentVault and LendingVault rely on token-side feeExempt status |
Removing an exemption while V1 holds funds can make nominal accounting diverge from actual token balances | Mainnet verification at block 25900438 found both exemptions active and both vaults fully covered. A read-only four-hour monitor now fails on a removed exemption or custody deficit, and negative contract regressions cover both vaults. Lending liquid custody is compared with totalAvailable; totalLent is reported as a receivable. V2 must still add balance-diff inflow accounting and runtime guards that fail closed. Technical status |
Recommendation: A professional security audit by a reputable firm (e.g., Trail of Bits, OpenZeppelin, Consensys Diligence) is strongly recommended as the next security milestone.
FeeRouter & Points Backend — Threat Model
FeeRouter Threats
| Attack | Mitigation |
|---|---|
| Voucher Replay | usedNonces[wallet][nonce] = true (on-chain) |
| Expired Voucher | block.timestamp > expiry check |
| Falscher Signer | ECDSA.recover == voucherSigner |
| Discount > Fee | Clamp: max(fee - discount, 0) |
| Arbitrary Adapter | whitelistedAdapters mapping |
| Signer kompromittiert | pause() + setVoucherSigner() via Governance |
| Fee ueber Cap | FEE_CAP_BPS = 25 hard-coded |
Points Backend Threats
| Attack | Mitigation |
|---|---|
| Bot farmt Punkte | Daily limits + rate limiting + SIWE |
| Voucher farming | 1 Voucher/Wallet/Tag + Expiry 7 Tage |
| SIWE Replay | Nonce pro Session, einmalig |
| JWT Faelschung | JWT_SECRET server-only, nie exposed |
| Sybil Wallets | Optional: min IFR Lock als Skin-in-game |
Important: IFR Points are not a token — no transfer value, no tradability, no monetary promise. They only reduce the protocol fee on a single swap.
On-Chain Audit
All values are verifiable on-chain via Etherscan. Contracts are deployed and verified on Ethereum Mainnet.
Contract Ownership
| Contract | Owner | Status |
|---|---|---|
| InfernoToken | Governance (Timelock) | OK |
| IFRLock | admin-Pattern | OK |
| PartnerVault | Governance (Timelock) | OK |
| FeeRouterV1 | Governance (Timelock) | OK |
| LiquidityReserve | Governance (Timelock) | OK |
| BuybackVault | Governance (Timelock) | OK |
| BurnReserve | Governance (Timelock) | OK |
Token Supply Distribution
| Wallet | IFR | % |
|---|---|---|
| LP Reserve Safe (3-of-5) | 400,600,000 | 40.06% |
| BootstrapVaultV3 | 200,000,000 | 20.00% |
| LiquidityReserve | 200,000,000 | 20.00% |
| Vesting (Team, 4 Years) | 150,000,000 | 15.00% |
| PartnerVault | 40,000,000 | 4.00% |
| Treasury Safe | 0 | 0.00% |
| Community Safe | ~7,900,000 | 0.79% |
| Burned (Deflation) | ~2,326,121 | ~0.23% (22.08.2026 snapshot) |
Vesting (Team)
- Balance: 150,000,000 IFR (15%)
- Cliff: 365 days (~March 2027)
- Duration: 1,460 days total (12-month cliff + 36-month linear release)
- Released: 0 IFR
Deflation (Live)
Since deployment, — IFR have been permanently burned (— of total supply). Deflation is provable on-chain.
• Connecting…
Pre-Mainnet Checklist — Completed (05.03.2026): All 17 protocol contracts deployed and verified on Ethereum Mainnet. Ownership transferred to Governance (LiquidityReserve, BuybackVault, BurnReserve). Details: Deployments | Mainnet Checklist
Full Internal Token Security Review — InfernoToken.sol
Date: March 19, 2026 | Type: Full internal security review | Scope: InfernoToken.sol (ERC-20 with fee-on-transfer)
Scope notice: This is an internal engineering audit with public evidence, not an independent professional third-party certification. A professional third-party audit remains pending.
Community review: The OKComputer community audit submitted on 27 July 2026 is preserved unchanged with a separate factual status note in the Open Audit Log.
Overall Assessment
Code quality: Good. Logic: Clean. No exploitable bugs found. Critical risks identified are mitigated by IFR’s Governance architecture (48h Timelock + TreasurySafe 3-of-5).
Findings & Mitigations
| Finding | Severity | IFR Mitigation | Status |
|---|---|---|---|
| Owner Control | Critical | Governance + 48h Timelock + TreasurySafe 3-of-5. No single person can make changes. | Mitigated |
| FeeExempt Logic | High | On-chain transparent, Governance-controlled. Only protocol contracts exempt — no DEX routers or insider wallets. | Mitigated |
| Rounding / Dust | Low | Minimal impact at 9 decimals. Not exploitable in practice. | Accepted |
| Decimals = 9 | Low / Design | Deliberate design choice. Fully compatible with Uniswap V2. | By Design |
Confirmed Strengths
- No Reentrancy Risk — no external calls in
_update() - Real Burn — tokens sent to
address(0), not fake burn - Fee Cap — hardcoded max 5%, cannot be exceeded
- No Mint — supply can only decrease, never increase
- OpenZeppelin v5 — current standard library
Why Critical Findings Are Mitigated
The audit correctly identified that Owner control is a risk in fee-on-transfer tokens. In IFR, this risk is eliminated by architecture:
- The token owner is the Governance Contract — not a person
- All changes require a 48-hour Timelock
- Governance is controlled by TreasurySafe 3-of-5 (5 signers, 3 required)
- Every feeExempt address is on-chain verifiable