CommitmentVault
Voluntary Token Lock with self-chosen unlock condition
1. What is CommitmentVault?
CommitmentVault is a smart contract that irrevocably locks IFR tokens until a self-chosen condition is met. Unlike IFRLock (product access), CommitmentVault serves as a Proof of Commitment — an on-chain signal that a holder believes in the project long-term.
| IFRLock | CommitmentVault | |
|---|---|---|
| Unlock | Anytime | Only when condition is met |
| Purpose | Product Access | Proof of Commitment |
| For | All Users | Contributor, Team, Partner |
| Reward | Premium Access | Community Trust |
Why irrevocable? The smart contract enforces the condition — no human can break the lock. The community can verify every lock on-chain. Code is law.
2. Condition Types
Only time locks are offered. CommitmentVault V1 defined four condition types, but its deployed contract cannot evaluate a price: price-conditioned tranches (B and D) can never unlock, and C unlocks only through its time condition. The lock widget therefore offers only A) Time Only; price types are disabled. New time locks go to CommitmentVault V2, fee-exempt since Governance proposal #17 (executed 4 October 2026). The affected Mainnet tranches and the compensation proposal are documented in CV-01.
A) TIME ONLY
Formula: unlock_time = T
Example: “Unlock on 01/01/2027”
Ideal for: Team, Partner, Diamond Hands
B) PRICE ONLY — V1 design, disabled (never unlocks on V1)
Formula: unlock_price = P0 × Multiplier
Example: “Unlock when IFR ≥ P0 × 10”
Status: not offered; existing V1 tranches of this type can never unlock (CV-01).
C) TIME OR PRICE — V1 design, disabled (unlocks only by time on V1)
Formula: unlock_time = T OR unlock_price = P0 × M
Example: “06/01/2027 OR when P0 × 50”
Status: not offered; existing V1 tranches of this type unlock after their time condition.
D) TIME AND PRICE — V1 design, disabled (never unlocks on V1)
Formula: unlock_time = T AND unlock_price = P0 × M
Example: “After 01/01/2027 AND P0 × 100”
Status: not offered; existing V1 tranches of this type can never unlock (CV-01).
V1 design note: Conditions are checked at execution. unlock() re-evaluates the configured condition. markConditionMet() records when the condition was observed and starts the 30-day public-unlock timer, but it does not bypass the condition check if a price condition later falls below its target.
Mainnet status (V1): the deployed V1 cannot evaluate price conditions; its price check always reads zero. As a result:
TIME_ONLYandTIME_OR_PRICEtranches unlock after their time condition.PRICE_ONLYandTIME_AND_PRICEtranches cannot unlock.
The affected tranches and the compensation proposal are recorded in CV-01.
3. Contributor Configuration
Original design (not live): the 100M Contributor tokens were planned as 10 equal tranches, each with a price condition (Type B: PRICE ONLY). Price conditions cannot unlock on V1, so this design is not used; see the Mainnet record below.
| Tranche | Amount | Condition (Price) |
|---|---|---|
| 1 | 10M IFR | P0 × 2 |
| 2 | 10M IFR | P0 × 5 |
| 3 | 10M IFR | P0 × 10 |
| 4 | 10M IFR | P0 × 25 |
| 5 | 10M IFR | P0 × 50 |
| 6 | 10M IFR | P0 × 100 |
| 7 | 10M IFR | P0 × 250 |
| 8 | 10M IFR | P0 × 500 |
| 9 | 10M IFR | P0 × 1,000 |
| 10 | 10M IFR | P0 × 5,000 |
Canonical basis: P0 is 300,000,000 wei per IFR. A 10× price condition therefore evaluates against 3,000,000,000 wei per IFR; any fiat conversion is external and time-dependent.
The table above is the original design. The tranches actually locked on Mainnet differ from it; the Mainnet record, with every tranche and its status, is in CV-01.
4. For All Stakeholders
100M IFR in 10 tranches. A separate LendingVault offer can earn IFR interest only after borrowing is activated and used; mainnet borrowing is currently disabled and no loan interest has accrued.
After Vesting Cliff (March 2027). Strongest Proof of Commitment — team tokens remain locked until condition is met.
“Committed IFR Partner” badge on website. Visible proof of long-term commitment.
Diamond Hands proof on-chain. Anyone can voluntarily lock tokens in the CommitmentVault.
5. Auto-Unlock
When a condition is met and the owner does not call unlock() within 30 days, anyone can call the function for that wallet.
- Tokens ALWAYS go to the original wallet —
unlock()cannot send them to the caller or any other address. This does not protect a compromised wallet: whoever controls that wallet controls the tokens once they arrive, and can callunlock()as the owner once the condition is met. - It only helps once a condition is met: it cannot release V1 PRICE_ONLY or TIME_AND_PRICE tranches, whose condition is never met (CV-01), and it cannot recover lost private keys, because tokens always return to the same wallet
- The 30-day grace period gives the owner enough time to act
6. Why is this good for IFR?
- Tokens out of circulation = less sell pressure — Locked tokens cannot be sold, reducing the available supply.
- Trust provable on-chain — Not just promises, but mathematically verifiable. Anyone can read the contract.
- Price tranches (original design, not available) — The original idea tied releases to project success. Deployed V1 cannot evaluate a price, so this benefit does not exist; price conditions are disabled and only time locks are offered.
Frequently Asked Questions
Can someone steal my locked tokens?
Not through the vault. unlock() ALWAYS sends to the original wallet, and the smart contract has no function that could send locked tokens to a different address. If that wallet itself is compromised, the attacker can unlock the tokens once the condition is met and move them out of the wallet; the vault cannot prevent that.
What if I lose access?
If you lose access to your wallet, nobody can recover the tokens: unlock() always pays the original wallet. Auto-Unlock only lets anyone trigger the release 30 days after a met condition (for example a passed unlock date); the tokens still arrive in that same wallet.
Is CommitmentVault live?
Yes. CommitmentVault V1 is deployed on Ethereum Mainnet and feeExempt is active. Its price check never returns a price, so PRICE_ONLY and TIME_AND_PRICE tranches can never unlock, while TIME_OR_PRICE tranches still unlock by their time condition (CV-01). The self-service widget below therefore creates time-only locks, and new time locks go to CommitmentVault V2 (0x8efae0C85ad6d44C731cAEDA1cBC275904Fc7c8F, time only), which is fee-exempt since Governance proposal #17 (executed 4 October 2026, block 26121846). The lock button enables only after the widget confirms feeExempt(V2) on-chain; existing V1 tranches remain visible and unlock through V1. Price-based locks are disabled.
Why CommitmentVault Is Critical After Bootstrap
At Bootstrap finalisation, the LP was created with 0.030 ETH and 100M IFR. Proposal #16 set P0 to 300,000,000 wei per IFR.
- 100M claims IFR were distributed to 3 contributors
- Immediate selling would pressure a thin pool
With CommitmentVault:
- Contributors buy IFR first, then lock 50% of their current IFR balance
- Current operational mode: 10 TIME_ONLY tranches, 30-day unlock
- Remaining 50% is reserved for LendingVault offers
- As of 29.06.2026, C2 has executed the first 50% contributor lock: 20,156,940.952845656 IFR in 10 TIME_ONLY tranches, unlock date 29.07.2026 UTC
UX improvement tracked: The current 10-tranche split is intentionally transparent but requires one approval plus one wallet confirmation per tranche. A future batch-lock path should reduce this to one approval plus one split-lock transaction. Because the current vault locks msg.sender, a helper contract cannot safely batch on behalf of a user unless the vault adds a native lockBatch/lockSplit function or an explicit lockFor design.
Operational Fee-Exemption Invariant
CommitmentVault V1 records nominal IFR amounts and relies on its InfernoToken feeExempt status remaining active. At Ethereum Mainnet block 25900438, the exemption was active and the vault held 47,952,476.871794375 IFR, exactly matching totalLocked; the accounting difference was 0 IFR.
Current status: no live accounting deficit was observed. A read-only check runs every four hours and fails if the exemption is removed or custody falls below accounting; negative regressions cover the resulting deposit and withdrawal failure. A future V2 must still combine balance-diff inflow accounting with runtime exemption guards that fail closed before affected outgoing transfers. Technical status and monitor details.
Lock Your IFR
V1 stays deployed on Ethereum Mainnet and still accepts direct calls (for example from Etherscan or a script). A price-conditioned lock created there can never unlock: the IFR stay trapped permanently. This widget never sends new locks to V1. Existing V1 tranches stay listed below and unlock through V1.