ERC-7837: Diffusive Tokens

A fungible token that mints new tokens on transfer, charges a per-token native fee, and enforces a capped supply.

Metadata
Status: DraftStandards Track: ERCCreated: 2024-12-07
Authors
James Savechives (@jamesavechives)
Links
GitHub pageDiscussion on Ethereum Magicians

Abstract

This ERC proposes a standard for a new type of fungible token, called Diffusive Tokens (DIFF). Unlike traditional ERC-20 tokens, transferring DIFF tokens does not decrease the sender’s balance. Instead, it mints new tokens directly to the recipient, increasing the total supply on every transfer action. A fixed native currency fee is charged per token transferred, and this fee is paid by the sender to the contract owner. The supply growth is limited by a maximum supply set by the owner. Token holders can also burn their tokens to reduce the total supply. These features enable a controlled, incentivized token distribution model that merges fungibility with a built-in economic mechanism.

Motivation

Traditional ERC-20 tokens maintain a constant total supply and simply redistribute balances on transfers. While this model is widespread, certain use cases benefit from a token design that continuously expands supply during transfers, simulating a controlled "diffusion" of value. The Diffusive Token model may be suitable for representing claims on real-world goods (e.g., a product batch like iPhone 15 units), digital goods, or controlled asset distributions where initial token distribution and ongoing availability need to be managed differently.

This model also includes a native currency fee per token transferred, incentivizing careful, value-driven transfers and providing a revenue stream for the token’s issuer. The maximum supply cap prevents unbounded inflation, ensuring long-term scarcity. The ability for owners to burn tokens to redeem underlying goods or services directly maps on-chain assets to real-world redemptions.

Use Cases:

  • Real-World Asset Backing: A manufacturer can issue DIFF tokens representing a batch of products (e.g., iPhones). Each token can be redeemed (burned) for one physical item.

  • Fee-Driven Incentives: The transfer fee ensures that infinite minting by constant transferring is economically disincentivized. The fee also supports the token issuer or provides a funding mechanism.

Specification

Terminology

  • Diffusive Token: A fungible token unit that is minted on transfers.
  • Max Supply: The maximum total supply the token can reach.
  • Transfer Fee: A fee in native blockchain currency (e.g., ETH) that must be paid by the sender for each token transferred. The total fee = transferFee * amount.
  • Burn: The action of destroying tokens, reducing both the holder’s balance and the total supply.

Data Structures

  • Total Supply and Max Supply:

    

    • 

  • 

    Transfer Fee:
    

    

    The owner sets and updates transferFee and maxSupply.
    

    • 



Token Semantics


    

  1. 

    Minting on Transfer
When a transfer occurs from A to B:
    

      

    • A does not lose any tokens.
      • 

    • B receives newly minted tokens (increasing their balance and totalSupply).
      • 

    • The totalSupply increases by the transferred amount, but must not exceed maxSupply.
      • 

    

    2. 

  2. 

    Fixed Transfer Fee in Native Currency
Each transfer requires the sender to pay transferFee * amount in the native currency. If msg.value is insufficient, the transaction reverts.
    

    3. 

  3. 

    Maximum Supply
If a transfer would cause totalSupply + amount > maxSupply, it must revert.
    

    4. 

  4. 

    Burning Tokens
Token holders can burn tokens to:
    

      

    • Reduce their balance by the burned amount.
      • 

    • Decrease totalSupply by the burned amount.
      • 

    

    This can map to redeeming underlying goods or simply deflating the token.
    

    5. 



Interface


The DIFF standard aligns partially with ERC-20, but redefines certain behaviors:


Core Functions:


    

  • 

    function balanceOf(address account) external view returns (uint256);
    

    • 

  • 

    function transfer(address to, uint256 amount) external payable returns (bool);
    

      

    • Modified behavior: Mints amount tokens to to, requires msg.value >= transferFee * amount.
      • 

    

    • 

  • 

    function burn(uint256 amount) external;
    

      

    • Reduces sender’s balance and totalSupply.
      • 

    

    • 



Administration Functions (Owner Only):


    

  • 

    function setMaxSupply(uint256 newMax) external;
    

    • 

  • 

    function setTransferFee(uint256 newFee) external;
    

    • 

  • 

    function withdrawFees(address payable recipient) external;
    

      

    • Withdraws accumulated native currency fees.
      • 

    

    • 



Optional Approval Interface (For Compatibility):


    

  • 

    function approve(address spender, uint256 amount) external returns (bool);
    

    • 

  • 

    function transferFrom(address from, address to, uint256 amount) external payable returns (bool);
    

      

    • Modified behavior: Similar to transfer, but uses allowance and still mints tokens to to rather than redistributing from from.
      • 

    

    • 



Events


    

  • 

    event Transfer(address indexed from, address indexed to, uint256 amount);
    

    Emitted when tokens are minted to to via a transfer call.
    

    • 

  • 

    event Burn(address indexed burner, uint256 amount);
    

    Emitted when amount of tokens are burned from an address.
    

    • 

  • 

    event FeeUpdated(uint256 newFee);
    

    Emitted when the owner updates the transferFee.
    

    • 

  • 

    event MaxSupplyUpdated(uint256 newMaxSupply);
    

    Emitted when the owner updates maxSupply.
    

    • 



Compliance with ERC-20


The DIFF standard implements the ERC-20 interface but significantly alters the transfer and transferFrom semantics:


    

  • Fungibility: Each token unit is identical and divisible as in ERC-20.
    • 

  • Balances and Transfers: The balanceOf function works as normal. However, transfer and transferFrom no longer redistribute tokens. Instead, they mint new tokens (up to maxSupply).
    • 

  • Approvals: The approve and transferFrom functions remain, but their logic is unconventional since the sender’s balance is never reduced by transfers.
    • 



While the DIFF standard can be seen as ERC-20 compatible at the interface level, the underlying economics differ substantially.


Rationale


Design Decisions:


    

  • 

    Unlimited Minting vs. Max Supply: Allowing minting on every transfer provides a “diffusive” spread of tokens. The maxSupply prevents uncontrolled inflation.
    

    • 

  • 

    Burn Mechanism: Enables redemption or deflation as tokens are taken out of circulation.
    

    • 

  • 

    Owner Controls: The owner (e.g., issuer) can adjust fees and max supply, maintaining flexibility as market conditions change.
    

    • 



Backwards Compatibility


The DIFF standard is interface-compatible with ERC-20 but not behaviorally identical. Any system integrating DIFF tokens should understand the difference in minting on transfer.


    

  • Wallets and Exchanges: Most ERC-20 compatible tools can display balances and initiate transfers. However, the unusual economics (mint on transfer) may confuse users and pricing mechanisms.
    • 

  • Allowances and TransferFrom: Still implemented for interoperability, but the expected logic (debiting from balance) does not apply.
    • 



Test Cases


    

  1. 

    Initial Conditions:
    

      

    • Deploy contract with maxSupply = 1,000,000 DIFF, transferFee = 0.001 ETH.
      • 

    • totalSupply = 0.
      • 

    • Owner sets parameters and verifies via maxSupply() and transferFee() getters.
      • 

    

    2. 

  2. 

    Minting on Transfer:
    

      

    • User A calls transfer(B, 100) with msg.value = 0.1 ETH (assuming transferFee = 0.001 ETH).
      • 

    • Check balances[B] == 100, totalSupply == 100.
      • 

    • Check that the contract now holds 0.1 ETH from the fee.
      • 

    

    3. 

  3. 

    Exceeding Max Supply:
    

      

    • If totalSupply = 999,950 and someone tries to transfer 100 tokens, causing totalSupply to exceed 1,000,000, the transaction reverts.
      • 

    

    4. 

  4. 

    Burning Tokens:
    

      

    • User B calls burn(50).
      • 

    • Check balances[B] == 50, totalSupply == 50 less than before.
      • 

    • Burn event emitted.
      • 

    

    5. 

  5. 

    Updating Fee and Withdrawing Funds:
    

      

    • Owner calls setTransferFee(0.002 ETH).
      • 

    • FeeUpdated event emitted.
      • 

    • Owner calls withdrawFees(ownerAddress).
      • 

    • Check that ownerAddress receives accumulated fees.
      • 

    

    6. 



Reference Implementation


A reference implementation is provided under the asset folder in the EIPs repository. The implementation includes:


    

  • A basic contract implementing the DIFF standard.
    • 





    

  • Interfaces and helper contracts for testing and demonstration purposes.
    • 



Security Considerations


    

  • Reentrancy: Handle fee transfers using the Checks-Effects-Interactions pattern. Consider ReentrancyGuard from OpenZeppelin to prevent reentrant calls.
    • 

  • Overflow/Underflow: Solidity 0.8.x guards against this by default.
    • 

  • Contract Balance Management: Ensure enough native currency is sent to cover fees. Revert on insufficient fees.
    • 

  • Access Control: Only the owner can update transferFee and maxSupply. Use proper onlyOwner modifiers.
    • 



Copyright


Copyright and related rights waived via CC0.