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-token cannot 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.