Oops, our bad: Social token symbols should not be unique

Roll was the first protocol minting social tokens at scale for creators on Ethereum. To date, we created over 500 social token communities. This taught us how to design tokens well. As a result, we take many "micro-decisions" that might not be obvious to people on the outside.

One of the early decisions that the first version of the Roll smart contracts (v1) enforced was the uniqueness of token symbol. This made sense - 

  • we wanted each community to be uniquely identifiable by their symbol
  • prevent spammers or scammers
  • claim valuable namespace on our platform

There are precedents - think of ENS (Ethereum name system) - vitalik.eth cannot be registered by someone else.

However, over time we learned this was the wrong approach, and ultimately hurt the protocol's network effects. You should not be able to squat (hoard) token symbols.

On each blockchain, the contract address alone should identify your token. There can be app-level designs that are helpful to guide users to the right token (think of the original Twitter-style blue checkmark to identify "real" accounts vetted by a human), but this should not be enforced at the protocol layer.

People want to own their brand and a social token symbol is a powerful way to express this. The relationship creators and their communities feel towards their token is more intimate than a username on a social platform, which also runs into the same problem.

Real story - we had minted a BEN token for Ben, and then we lost out on being able to create a social token for the Blockchain Education Network (BEN) because of this constraint.

As we build newer protocols for social tokens, we don't enforce token symbol constraints at the smart contract level. Instead, higher level abstractions of the contracts, including our DApps, will include features to steer users in the right direction.