Please use define-fungible-token for tokens. Do not try and implement a token as a data map.
The history of ERC-20 provides more than enough evidence that most developers cannot be relied upon to build bug-free token implementations. The very EIPs linked here say as much – just look at EIP-223’s list of loss leaders.
The Clarity type system will automatically ensure that the supply tokens created with define-fungible-tokencannot inflate if you set a fixed supply, and the Clarity post-condition system ensures that users can prevent unintentional token transfers even if the smart contract is buggy. You cannot get this from a data map.
Wallets can set post-conditions in an allow/deny fashion on any transaction, on any token (fungible or not), and on any sending principal. For example, a transaction can say something like “allow up to 100 $stackaroos to be sent by $jude; allow NFT “foo” to be sent by $friedger; deny all other transfers.” Then, it doesn’t matter what the contract code does – these constraints will always be enforced. If over 100 $stackaroos are sent, or if $friedger tries to send anything else besides the NFT “foo”, or if any other token movements happen (besides the STX transaction fee), then the transaction rolls back.
Post-conditions are a new concept introduced by Clarity – as far as we know, no other blockchain implements them. But, the safety features they offer can only be used if the smart contract implements tokens with the native token types. So please use the native token types – they are there to help you.
Another example in the making! Following up on this, the bZx ERC-20 got hacked for $8 million today. The technical post-mortem is here: https://bzx.network/blog/incident. The underlying cause is:
Every ERC20 token has a transferFrom() function that is responsible for transferring tokens. It was possible to call this function to create and transfer an iToken to yourself, allowing you to artificially increase your balance.
This could not have happened if they used Clarity’s define-fungible-token feature. This is because the associated fungible token function ft-transfer? does not allow you to send tokens to yourself in the first place – the sender and recipient are guaranteed to be distinct if ft-transfer? succeeds. The bZx developers hired two security auditors before launching, and neither of them caught this bug.