We have been issuing a token using a basic erc20 token contract from https://ethereum.org/token An exchange that we wanted to list our token, asked for a collateral as they see the burnFrom() function could harm token owners. Why would this function be harmful? You can only use this function when you got allowance from the wallet owner. Plus, why is this code in the basic erc20 contract on the ethereum.org domain, if it is potentially harmful?

Does anyone has an answer to this question?


It's hard to say what someone else's concern could be without being in the room. I wonder if the "burn" talking-point is an example of more general concerns.

The linked code is a "minimal example" in a tutorial. It contains burn() and burnFrom() functions that are not part of the ERC20 standard. https://eips.ethereum.org/EIPS/eip-20. Those are both red flags for code that's supposed to be carefully constructed and well-understood.

Nothing in ERC20 forbids extension of the basic interface, so technically it is not a violation of the rules to add functions. If I were cross-examining your technical team, I would question why you need those functions to see if you have carefully considered answers, and if not, question why you have unnecessary code in your contract.

Exchanges have been burned by non-conforming ERC20 contracts that failed to observe subtleties in the spec. The README for the spec itself refers to two well-crafted implementations which begs the question: why are you using a minimal example from a tutorial?

It's not that it's a year old or using an old compiler, in my opinion. Afterall, bytecode is meant to work forever. However, since it is merely a tutorial, what assurances have you received that the code has been subjected to meticulous scrutiny? In the case that there is no assurance, no publicly available audit or quality assurance report, then have you engaged anyone to review it for you? You can see where that would be leading. What is your process, why is that way, how deep is the team's knowledge and why should we trust their thinking?

If you are presenting a copy/paste job from a tutorial and seem unaware of the possible implications, that speaks volumes about the potential for oversight in the token contract itself, and also in the broader scope of the contracts that use it. Tokens are generally useless unless coupled with a line-of-business app which will potentially have access to destructive processes that may or may not have a worthwhile purpose.

Exchanges are not in the quality-assurance business. It's not their job to review your code. It's your job to assure them that all risks are professionally and satisfactorily addressed.

Again, we may never know exactly what they are thinking. The foregoing is not meant to sound excessively critical. My intention is to convey some insight into how this may look from a risk-averse perspective.

Hope it helps.


"Harmful" is a rather subjective term. With a little bit of imagination I might imagine why someone doesn't like if his allowed tokens are burned instead of transferred even if it is explicitly allowed by the contract. Maybe they don't even know the token can be burned.

I don't see anything wrong with the code per se. I would just personally probably want to check for zero burns (the code allows it but what's the point).

The code is using Solidity version 0.4.22 which is already a year old (2018-04-16). This means the code is also probably about a year old (or maybe even older if someone has just updated the version number). I personally wouldn't want to use code which is that old - the environment is changing fast and the language evolves fast. I suggest you look into other alternatives which keep their code up to date (for example OpenZeppelin).


One particular problem with the implementation of ethereum.org site is that both transferFrom and burnFrom use the same mapping allowance to authorize a third party. For example you can authorize someone to transfer your tokens, but this person instead delete them.

The code in ethereum.org site is mostly for educational purposes. I do not remember it having been audited for example. Usually the recommended answer for smart contracts is to use OpenZeppelin libraries.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.