I'm writing a contract for an ERC-20 token, and I've been trying to optimize for gas (since the fees are ridiculous at the moment).

I was wondering if instead of using a string, I could use a bytes32 for the token metadata, and if it would still be able to read the name on etherscan, and anywhere else my token might be registered.

I would be changing from this:

string public constant name = ".....";
string public constant symbol = "...";
string public version = "1.0";

to this:

bytes32 public constant name = bytes32(".....");
bytes32 public constant name = bytes32("...");
bytes32 public version = bytes32("1.0");

I've already tested the two versions, and the second one does save on a lot of gas. Just wondering if I'll run into issues later because of this.


  • it is a pain to process tokens that are not standard. Use the standard please, otherwise we might skip your token from listing in explorer services or any other data collecting services. At the end, you are going to lose exposure to potential customers – Nulik Feb 3 at 16:27
  • This would only reduce the deploy time costs (provided nobody is checking these things on chain). So this optimization might not even be worth it in the end. – hrkrshnn Feb 3 at 21:23
  • @Nulik Can you link where I could find the specifications to make it "standard"? I haven't seen anything enforcing the "string" instead of "bytes32" so I want to make sure I'm not making other similar errors. – zbys Feb 4 at 0:17
  • 1
  • 1
    @Nulik By checking I mean, contracts aren't probably trying to do transactions like contract.name(). Of course, front-ends are going to check this and run into issues. Just to be clear, I'm against this proposal, and was trying to say that the gas savings is only going to be one time and might not be worth the hassle in the end. – hrkrshnn Feb 4 at 20:33

Yes, definitely working with bytes32 instead of string will bring less transaction costs, because string has dynamic size. I find it similar to arrays in solidity where for example if you work with fixed size array it's always cheaper than working with dynamic size array. If you're interested in more gas costs savings you can check the following article where I described and compared gas costs in other scenarios in smart contracts:


  • I'll check it out, thanks! – zbys Feb 3 at 14:32

The ERC-20 spec says you need to have an accessor function name() and symbol(). However, you can internally store them as bytes32 to save gas. Accessors would to the conversion from bytes32 to string in fly. It would be a clever optimisation, in fact.

  • From templates that I've seen, they don't have accessors but instead just have the stored variables as public constants. Would this still work? Or do I need to implement both accessor functions? – zbys Feb 3 at 14:33
  • Checking the EOS contract, it seems like etherscan doesn't convert from bytes32 to string, so the accessor might be a good call (etherscan.io/address/…) – zbys Feb 3 at 14:45
  • Solidity does not really have public variables. Those public variables just have an accessor function automatically generated for them. It would be the same if you wrote the function with the same name by hand that just returns the variable. – Mikko Ohtamaa Feb 3 at 21:05
  • But if I don't write the accessor that does the conversion, it would be returned as bytes32 and not string right? – zbys Feb 4 at 0:09
  • You should not declare the bytes32 variable as public in the first place. – Mikko Ohtamaa Feb 4 at 9:43

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.