I would like to present a draft EIP introducing Diffusive Tokens, a new variant of fungible tokens. In this model, every transfer mints new tokens directly to the recipient without reducing the sender’s balance. The approach includes:
Per-Token Native Fee: Each token transferred incurs a fee in the native currency (e.g., ETH), discouraging frivolous minting.
Capped Max Supply: While transfers increase total supply, the total is capped to maintain a form of scarcity.
Burn Mechanism: Token holders can burn their tokens, reducing total supply and potentially enabling real-world redemption processes.
This design differs from traditional ERC-20 tokens and may find use cases in real-world asset tokenization, controlled distribution, or unique economic experiments.
I invite feedback, questions, and discussions on the viability, security, and potential applications of Diffusive Tokens. Your insights will help refine the standard and guide its evolution.
This just seems like a token contract with an unlimited and permissionless mint functionality. This seems extremely insecure. Why do we need this?
Without a check on existing balance what’s to stop someone from backrunning a contract deployment and then just calling transfer(SOME_ADDRESS, maxSupply) and then preventing the contract from being used by anyone else ever since any new transfers would have supply exceed the max?
- **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.
I understand how the transfer tax is supposed to prevent inflation by making it economically inefficient but if tokens are fungible at a certain point value from a redemption becomes worth more than whatever the value of the transfer tax is, especially if the fee is static and there’s basically an exponential increase in a users’ balance every time they pay it, and since tokens are fungible how does a redeemer prevent what’s basically a sybil attack?
@jamesavechives Thx for the interesting topic. Can you elaborate more on the use cases?
Also besides the issues mentioned by 0xTraub, IMO the administrative functions do not belong to the standard as they are not key for interoperability. The same wrt data structures - they can be implemented differently.
What is rather missing is the maxSupply() function in the interface as it is crucially impacting the ability to execute.
What is the point of having transfer() when no transfer is made at all? Is it only called in order to be close to ERC20 std.? IMHO such naming is misleading.