Use bytes32 instead of string for token metadata

Question

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.

Thanks!

Answer 1

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:

https://www.linkedin.com/pulse/solidity-smart-contracts-how-gas-greedy-miroslav-nedelchev/

Answer 2

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.