ERC-8300: Invariant-First Reserve Receipt Token (IFR-pETH)

ERCs
1

This thread is the discussion venue for a proposed EIP defining the
Invariant-First Reserve Receipt Token (IFR) standard.

Summary

IFR is an ERC-20-compatible primitive for reserve-backed tokens that
enforces solvency as a transaction-validity condition rather than an
external proof-of-reserves report.

Every state transition preserves:

T + F == R address(this).balance >= R

Where:

  • R = accounted reserve (wei)
  • T = outstanding redeemable token supply
  • F = protocol fee slice retained inside the reserve

If any transition would violate either invariant, the transaction
reverts before state is committed.

Motivation

Existing reserve-backed tokens and ETH wrappers share three structural
weaknesses:

  1. Solvency is reported off-chain or informally, not enforced per
    transaction — insolvency can accumulate silently across blocks.
  2. Protocol fees are mixed with user backing without explicit
    attribution, making it impossible for integrators to distinguish
    user-redeemable reserve from protocol-owned reserve.
  3. No standard interface exists for wallets, explorers, or downstream
    protocols to query reserve state, fee attribution, or invariant
    status uniformly.

IFR addresses all three by making the state tuple (R, T, F) explicit,
enforcing both invariants on-chain at every state change, and defining
a canonical view interface. As reserve-backed DeFi primitives grow in
use, the absence of a standard solvency interface creates fragmentation
that IFR resolves.

State Tuple

Variable Description
R Accounted reserve: total ETH the contract considers backing the system
T Outstanding supply: total redeemable receipt tokens in circulation
F Accumulated fees: protocol-owned slice of R

Economic Transitions

Operation R T F
mint(x) R + x T + (x - f) F + f
burn(x) R - (x - f) T - x F + f
sweep(y) R - y T F - y
absorb(y) R + y T F + y

All four transitions preserve T + F == R.

Use Cases

  • DAO treasuries requiring live reserve verification at any block
  • Lending protocol collateral with on-chain solvency guarantees
  • Insurance reserves needing auditable backing per transaction
  • Protocol-owned liquidity where users must verify backing without
    trusting off-chain reports

Interface

The standard defines a canonical view interface including:

  • stateTuple() — returns (R, T, F, address(this).balance)
  • checkInvariant() — returns (holds, accountingDiff, shortfall, surplus)
  • previewMint(grossDeposit) — returns (fee, minted)
  • previewBurn(burnAmount) — returns (fee, released)
  • surplus() — ETH held above accounted reserve
  • userRedeemableBacking() — should equal T
  • protocolFeeBacking() — should equal F

Reference Implementation

A canonical ETH-backed implementation (pETH-IFE-1.0.0) is available
alongside the draft EIP. It has been tested with:

  • Foundry invariant fuzzing across all economic transitions
  • Property-based fuzz tests (mint, burn, transfer, sweep, surplus)
  • Unit tests with exact raw-state assertions for every operation
  • Reentrancy guard verification

Draft EIP

Open Questions for Discussion

  1. Should the fee formula be normative (MUST) or advisory (SHOULD)?
  2. Should surplus absorption be restricted to a treasury role, or
    permissionless?
  3. Should the standard define a minimum MAX_FEE_BPS cap, or leave
    it to implementations?
  4. Are there ERC-20 collateral (non-ETH) considerations that should
    be addressed in the base standard vs. an extension EIP?

Looking forward to feedback on the interface design, fee model,
surplus handling, and any composability concerns from protocol
integrators.

2

I’ve pushed a substantial update to the pETH repository:

Since the earlier draft, I’ve done a deeper hardening pass around invariant correctness, mint/burn accounting, fee behavior, reserve/supply edge cases, deployment checks, and test coverage. The repo now includes broader unit, fuzz, invariant, and gap tests, plus Slither and Mythril passes.

The contract is now in what I’d call a mainnet-candidate state: the core accounting invariant is explicit, deployment configuration is guarded, post-deploy checks are included, and the developer/integrator UX has been cleaned up.

I’d appreciate another round of review, especially around:

  • the T + F == R accounting invariant
  • mint/burn fee math and rounding behavior
  • forced ETH / surplus handling
  • treasury and fee-ratchet assumptions
  • whether the interface is clear enough for integrators

Any feedback before moving toward a final deployment plan would be very welcome.