DAO Badges as Non-transferable Tokens

Since the publication of Decentralized Society by Weyl, Ohlhaver and Buterin, soulbound tokens (SBTs) have become one of the most discussed topics within the Ethereum community. Futures have been imagined, sparks have flown and flags planted in the ground.

As one of the projects contributing to a non-transferable token standard since before the publication of the DeSoc article, we want to join the discussion by clearing up some misconceptions and explaining why we have chosen non-transferable NFTs for the Otterspace DAO badges. For more background on the problem we are solving with the Otterspace protocol, check out this article.

“What the heck are soulbound tokens? Even after reading the paper, I still don’t know” - Kate Sills

The misconceptions with soulbound tokens start with the fact that they are not a clearly defined thing, but a collection of ideas tied to a highly expressive term that invites people to imagine and interpret. The term ‘soulbound’ is itself problematic, as it conjures images of permanently tying some fact or object to the deepest places in your being.

Discussing a specific token standard, protocol and use case allows us to have a more concrete conversation about the risks and utility to the community. In part 1, I’ll dive into some misconceptions around the non-transferable token standard we’re working on at Otterspace, and in part 2, I’ll explain why we chose to use an NFT for the Otterspace badges.

Part 1 - Misconceptions around non-transferable tokens

One common critique we’ve heard of non-transferable tokens is that they can be used to non-consensually and permanently tie public information to your account. For example, someone could doxx me by dropping an SBT with my home address to my account. The difference between SBTs and ERC-721 NFTs is that with a 721 I can transfer that token out of the account after someone airdrops it to me and with an SBT I can’t.

The protocol we’re working on alleviates this concern in two ways: tokens can be burned by the holder and they cannot be airdropped. By enabling burnability of the tokens, the account holder is able to disassociate themselves from the token and any information held within. Burning a non-transferable token has the same effect as transferring an ERC-721 - the history of the token in the wallet is still available on-chain, but the token itself can be disassociated from the account. 

We recently added a ‘mint with permission’ function to the Otterspace protocol. This ensures that the tokens are never airdropped to accounts, but only minted (‘claimed’) by the ultimate holder with permission from the issuer. In practice this means that we have better protection against non-consensual airdropping than the widely used ERC-721 standard.

Privacy concerns are a moot point since the token holder has themselves minted the token and its associated information publicly to their wallet. The Otterspace protocol is designed to serve communities in the context of issuing public badges similar to scout badges, medals and in-game awards. In this context, publicity is a feature, not a bug.

Second scary thing: key rotation

Any long-term user of blockchains knows that regularly changing your account is important to maintain security. A common critique of SBTs is that since they are non-transferable, they make it impossible for users to start using a new account, or recover their tokens if their account is hacked.

It is indeed true that one of the key features of the token is that it does not include the ‘transfer from’ and ‘transfer to’ functions contained in ERC-721s. Without these functions, the tokens cannot be freely traded, and marketplaces like OpenSea are able to recognise them as a different kind of object than a digital work of art, for example. Without tradeability, the tokens can be used as a reliable signal of information about an individual.

“... because NFTs are tradeable items, another big part of the answer inevitably becomes that NFTs are about signaling wealth. If someone shows you that they have an NFT that is obtainable by doing X, you can't tell whether they did X themselves or whether they just paid someone else to do X.” (Buterin, Jan 2022)

Removing the transfer functions from the primitive does not make reassignment of tokens between wallets impossible. The process of verifying and executing a legitimate transfer is not defined in the standard, but is left open to the implementer to design for their use case. In the case of the Otterspace protocol, we are experimenting with community and social verification to manage the token reassignment process, for example. This allows communities using Otterspace to maintain the integrity of the token collection while supporting key rotation and recovery.

Why do we even need a new standard?

In the next section we’ll discuss the Otterspace protocol use case and why we’ve chosen to work with a non-transferable NFT instead of a different tool like a verifiable credential. But assuming non-transferable NFTs are in fact useful, why create a new standard instead of simply modifying the existing standards by removing transfer functions?

By creating a new standard, we enable wallets and dApps to recognize the fact that these tokens are fundamentally different from tradeable NFTs which may be bought and sold on marketplaces and airdropped to friends. As a result, the tokens can be displayed appropriately by applications. 

Removing the transfer function from an ERC-721 token means that interfaces assume transfer is possible - when transfer is attempted, it simply fails. This is a hack and not an acceptable user experience.

Part 2 - Choosing non-transferable NFTs for DAO badges

The Otterspace protocol makes it easy for DAOs to issue badges to members for a wide variety of use cases. The most common ones we have seen are: DAO or guild membership, role, level, awards, completion of tasks, tenure and event participation. You can check out the full story of the problems we are solving and why the model of badges is useful in our blog posts here (part 1) (part 2).

What are badges

In order to delve into why we have chosen non-transferable NFTs for the Otterspace badges, we first need to understand what badges are and what problems they need to solve.

Communities and societies have used badges to represent achievement, reputation, affiliation and recognition for centuries in the form of tattoos, coats of arms, military awards, scout badges, laptop stickers, trophies etc. If we look at the history of badges, we can distill some common themes:

  • Badges are earned, not bought.
  • Badges are granted by and associated with an organization.
  • Badges are simple – objects with a name.
  • What gives a badge meaning is the granting organization and circumstances under which it is granted.
  • Reputation is not explicit, but implicit through the process of attaining the badge.
  • Badges are often worn or displayed by the holder as a social signal.

Badges need to be public

We decided that Otterspace Badges should be public by default, as one important purpose is for the holder to signal affiliation, status and reputation. We can see this behavior play out in several real-world examples.

Scouts proudly wear the badges they have collected and earned on their jackets or sashes in order to signal their affiliation, identity and status. In the context of web3, individuals collect POAPs as a way to signal their status in the community by showing the history of conferences and events they have attended. In Discord communities, members use roles to indicate their level in the community.

By putting badges on-chain as NFTs, individuals can showcase them in their wallets as a collection of digital trophies, affiliations and achievements. In the Otterspace protocol, each badge is associated with the organization that issued it, and voluntarily claimed (minted) by the eligible individual.

Badges need to be interoperable with dApps

One of the biggest advantages to using NFTs for the Otterspace Badges is that they become immediately interoperable - easy to integrate - with other dApps. Tokens are already an accepted model for governance, access and membership. 

By making badges tokens, DAOs can easily use them in their Snapshot governance strategies, enable token-gating via existing apps like Guild.xyz and Collab.land, and devolve powers and permissions to holders of badges. By using tokens, we take advantage of the composable nature of web3 and enable quick integrations to expand the range of user experiences. 

A related advantage of keeping badges on-chain is that they can be issued without permission based on on-chain data. This is a use-case DAOs are particularly interested in, as it would enable them to create an objective set of on-chain requirements for earning a badge, and enable DAO members to mint themselves a badge once they meet those requirements.

A note on affordability and convenience

One of the arguments for keeping badges off-chain is the cost of minting each badge. With the improvements afforded by L2s and Optimistic rollups, we are confident that affordability will not present a barrier to adoption. As Vitalik Buterin mentioned in his recent article, sometimes blockchains are just a really convenient place to store stuff.

🔰🔰🔰

It’s an exciting time to be working in web3 as we’re experiencing this shift towards applications less driven by profit and speculation. At Otterspace, we believe in the potential of DAOs to make the next generation of the internet community-owned and governed. Through our work with DAOs we have learned that badges are an important missing cornerstone, and are excited to bring these to life via non-transferable tokens. 

We hope this article has quashed some concerns around non-transferable tokens and shed light on the potential this technology affords. We’re keen to keep healthy discussion going so we can improve the design of standards and protocols to make them abuse-resistant. 

Follow us on Twitter to join the conversation! 🦦🚀

Subscribe to Otterspace
Receive the latest updates directly to your inbox.
Verification
This entry has been permanently stored onchain and signed by its creator.