Over the years, the openness of wallets has been used for everything from genuine airdrops to spam and malicious attacks. Most recently we saw an attack that left thousands of accounts tarnished after being sent funds from a Tornado Cash wallet.

This is exactly why we programmed consent into the fundamental building block of Otterspace Badges – a non-transferable token (NTT) protocol that binds a token to an account, our take on the now-very-popular “SoulBound Tokens” (SBT), coined by Vitalik Buterin and further expanded by Puja Ohhlaver & Glen Weyl in their paper around Decentralized Society. We did this by building consent into the EIP-4973 standard itself.

While there are many misconceptions around SBTs / NTTs which we have previously covered, in this post we want to share our approach to building fully consensual minting mechanics that are baked into the very core of the protocol.

What is consent, really? It can be thought of as giving permission for something to happen or establishing an agreement to do something. There are generally two cases of how a token might land in an account:

1. It is minted into existence from a contract to an account

2. It is transferred from one account to another

Within the context of an NTT, the second case is irrelevant as it is restricted. In the world of smart contract programming, a transfer is nothing but a remapping of balances of two parties involved in a single unit of transaction. A contract can be made non-transferable by restricting this remapping.

In the case of minting a token into existence, ERC721 models allow for tokens to be minted from a smart contract to any account. Our goal with EIP4973 was to add consent into this mechanism, while also ensuring maximum backward compatibility with ERC721 to allow for easy recognition by wallets, indexers, and dApps. This has proven to be an interesting challenge, as the ERC721 specification allows you to mint a token to an account without the holder’s consent.

EIP712 defines a standard API for Web3 Providers (like wallets) to generate signatures over human-readable data where the signature can be verified either by a Smart Contract on the Ethereum Blockchain or completely off-chain.

In the case of Otterspace Badges, we knew we needed the account holder to consent to receive the token, but we also needed the Badge issuer to consent to the account receiving the Badge. In other words, we had to build a model that required the consent of both parties before a Badge could be minted to an account.

This process begins with the Badge issuer consenting to an account receiving the Badge.

Here is an example of how that would look: After designing a Badge Spec with a unique token URI, Linas wants to issue a Badge to Jeong. They consent to Jeong minting the Badge by signing using EIP712. Jeong can now mint the Badge to their wallet by signing a transaction, which is another form of giving consent.

Another way of thinking about this process is that Linas has signed to add Jeong’s address to an allowlist for minting the Badge. This is Linas’ way of giving consent. Jeong then consents to receive the Badge by minting it to their wallet.

This process begins with the Badge claimer consenting to receive the Badge to their account.

For example, after designing a Badge Spec with a unique token URI, Linas invites community members to request the Badge. Jeong signs a transaction using EIP712  to request the Badge. This is their way of providing consent to receive the Badge. Linas can now give their consent by minting the Badge to Jeong’s wallet.

Another way of thinking about this process is that Jeong has consented by adding their wallet to the Badge request list. Linas then approves the request by minting the Badge to Jeong’s wallet.

We believe that the holder of a token should have the authority to fully dissociate from it. While ERC721 implicitly allows this through the transfer function, EIP4973 supports this via a function called ‘unequip’. The holder of an EIP4973 token is able to burn the token from their account via the unequip function. This ensures that a token holder has not only consented to receive the token but also continuously consents to it staying in their account.

** **

As builders in Web3, it is our responsibility to design protocols to be abuse-resistant. This is especially true in the case of non-transferable tokens, which make possible new dynamics and forms of misuse. Since the publication of the Decentralized Society paper earlier this year, the Ethereum community has responded with a wealth of feedback and ideas. We are excited to share how we have addressed these concerns within the EIP4973 primitive itself, and we invite the builders of other primitives to think deeply about the topic of consent as well. As we saw with the Tornado Cash incident, consent is a topic that concerns all types of token transactions, not just the soulbound kind.

If you’re interested in using Otterspace Badges to introduce non-financial dynamics into your community, head to otterspace.xyz and step into the Otterverse.

Over the years, the openness of wallets has been used for everything from genuine airdrops to spam and malicious attacks. Most recently we saw an attack that left thousands of accounts tarnished after being sent funds from a Tornado Cash wallet.

This is exactly why we programmed consent into the fundamental building block of Otterspace Badges – a non-transferable token (NTT) protocol that binds a token to an account, our take on the now-very-popular “SoulBound Tokens” (SBT), coined by Vitalik Buterin and further expanded by Puja Ohhlaver & Glen Weyl in their paper around Decentralized Society. We did this by building consent into the EIP-4973 standard itself.

While there are many misconceptions around SBTs / NTTs which we have previously covered, in this post we want to share our approach to building fully consensual minting mechanics that are baked into the very core of the protocol.

What is consent, really? It can be thought of as giving permission for something to happen or establishing an agreement to do something. There are generally two cases of how a token might land in an account:

1. It is minted into existence from a contract to an account

2. It is transferred from one account to another

Within the context of an NTT, the second case is irrelevant as it is restricted. In the world of smart contract programming, a transfer is nothing but a remapping of balances of two parties involved in a single unit of transaction. A contract can be made non-transferable by restricting this remapping.

In the case of minting a token into existence, ERC721 models allow for tokens to be minted from a smart contract to any account. Our goal with EIP4973 was to add consent into this mechanism, while also ensuring maximum backward compatibility with ERC721 to allow for easy recognition by wallets, indexers, and dApps. This has proven to be an interesting challenge, as the ERC721 specification allows you to mint a token to an account without the holder’s consent.

EIP712 defines a standard API for Web3 Providers (like wallets) to generate signatures over human-readable data where the signature can be verified either by a Smart Contract on the Ethereum Blockchain or completely off-chain.

In the case of Otterspace Badges, we knew we needed the account holder to consent to receive the token, but we also needed the Badge issuer to consent to the account receiving the Badge. In other words, we had to build a model that required the consent of both parties before a Badge could be minted to an account.

This process begins with the Badge issuer consenting to an account receiving the Badge.

Here is an example of how that would look: After designing a Badge Spec with a unique token URI, Linas wants to issue a Badge to Jeong. They consent to Jeong minting the Badge by signing using EIP712. Jeong can now mint the Badge to their wallet by signing a transaction, which is another form of giving consent.

Another way of thinking about this process is that Linas has signed to add Jeong’s address to an allowlist for minting the Badge. This is Linas’ way of giving consent. Jeong then consents to receive the Badge by minting it to their wallet.

This process begins with the Badge claimer consenting to receive the Badge to their account.

For example, after designing a Badge Spec with a unique token URI, Linas invites community members to request the Badge. Jeong signs a transaction using EIP712  to request the Badge. This is their way of providing consent to receive the Badge. Linas can now give their consent by minting the Badge to Jeong’s wallet.

Another way of thinking about this process is that Jeong has consented by adding their wallet to the Badge request list. Linas then approves the request by minting the Badge to Jeong’s wallet.

We believe that the holder of a token should have the authority to fully dissociate from it. While ERC721 implicitly allows this through the transfer function, EIP4973 supports this via a function called ‘unequip’. The holder of an EIP4973 token is able to burn the token from their account via the unequip function. This ensures that a token holder has not only consented to receive the token but also continuously consents to it staying in their account.

** **

As builders in Web3, it is our responsibility to design protocols to be abuse-resistant. This is especially true in the case of non-transferable tokens, which make possible new dynamics and forms of misuse. Since the publication of the Decentralized Society paper earlier this year, the Ethereum community has responded with a wealth of feedback and ideas. We are excited to share how we have addressed these concerns within the EIP4973 primitive itself, and we invite the builders of other primitives to think deeply about the topic of consent as well. As we saw with the Tornado Cash incident, consent is a topic that concerns all types of token transactions, not just the soulbound kind.

If you’re interested in using Otterspace Badges to introduce non-financial dynamics into your community, head to otterspace.xyz and step into the Otterverse.