This issue describes some limitations of the design point chosen for the fungible token standard.
Custom transfer logic is not supported, since no calls are made to the admin contract. Thus, token implementations will struggle to implement the following features:
Token blacklists or whitelists. For examples, see here.
Circuit-breaking or transfer amount limits. For examples, see here.
Custom burn logic is not supported.
Many applications may wish to maintain some invariant related to the total supply. For instance, a wMina token contract's admin would have a mechanism to lock or release Mina in return for minting or burning wMina. This would currently be implemented by the wMina admin contract having a method which calls burn on behalf of the user. However, this would only maintain the invariant wMina supply >= locked Mina, rather than strict equality.
This type of invariant is generally of interest to any token representing a share of some wrapped assets.
Custom balanceOf logic is not supported:
Rebasable (like stEth) tokens may be difficult to implement. For more examples, see here.
Impact
Certain token applications may be limited, or lead to more complicated user implementations.
Recommendation
Consider enabling additional admin hooks. To allow most tokens to operate without as many hooks, a flag could be added which turns on or off individual admin hooks.
If constraint or usability limitations prevent this, consider documenting some of the limitations clearly in the standard. Providing example workarounds for some of the above applications may also help developers avoid creating their own overly-complicated solutions.
This issue describes some limitations of the design point chosen for the fungible token standard.
Custom transfer logic is not supported, since no calls are made to the admin contract. Thus, token implementations will struggle to implement the following features:
Custom burn logic is not supported. Many applications may wish to maintain some invariant related to the total supply. For instance, a wMina token contract's admin would have a mechanism to lock or release Mina in return for minting or burning wMina. This would currently be implemented by the wMina admin contract having a method which calls burn on behalf of the user. However, this would only maintain the invariant wMina supply >= locked Mina, rather than strict equality.
This type of invariant is generally of interest to any token representing a share of some wrapped assets.
Custom balanceOf logic is not supported:
Rebasable (like stEth) tokens may be difficult to implement. For more examples, see here.
Impact
Certain token applications may be limited, or lead to more complicated user implementations.
Recommendation
Consider enabling additional admin hooks. To allow most tokens to operate without as many hooks, a flag could be added which turns on or off individual admin hooks. If constraint or usability limitations prevent this, consider documenting some of the limitations clearly in the standard. Providing example workarounds for some of the above applications may also help developers avoid creating their own overly-complicated solutions.