A Badge is an EIP 4973 non-fungible token. The standard is backwards compatible to an ERC721, so the metadata shape will look familiar, and many apps and wallets will recognize it as an ERC721.

You can check out the Badges contract here: 0x7F9279B24D1c36Fa3E517041fdb4E8788dc63D25

Every Badge belongs to a community (at Otterspace, we call communities ‘Rafts’). The Raft that a Badge belongs to can be found in the Badge metadata, with an id and a name.

Every Badge is minted from a ‘Badge Spec’, which is also identified in the Badge metadata via id and name. A Badge Spec could be something like “Otterspace Core Contributor”, from which 12 specific badges have been minted.

When Badge-gating, we expect most communities will want to gate via a Badge Spec. Meaning that anyone holding a Badge from a specific spec is able to access some resource.

Otterspace Badges can expire and be revoked without being burned.

Effectively, this means that a Badge can still be present in someone’s wallet while being inactive. In these cases, the badge should no longer act as a key to access the resource.

You can check whether a Badge is expired by looking at the ExpiresAt date in the Badge spec metadata. All Badges minted from the same spec have the same Expiry date.

Badges can be revoked by the issuer, which renders them inactive but does not burn them. If a Badge has been revoked, it should no longer be used for granting access to a resource. You can check whether a Badge has been revoked by calling the isBadgeValid function.

Rafts (communities) are identified by the token id of an ERC721 token which is airdropped to the community during onboarding. The Raft token metadata also contains the name of the community.

You can check out the Raft contract here: 0xa6773847d3D2c8012C9cF62818b320eE278Ff722

The token id of the community is used within the Otterspace app as part of the url for the community profile page. Check out Otterspace’s community profile page as an example: https://beta.otterspace.xyz/communities/1

A community can have parent and child communities, which we call parent and child Rafts. If a Raft has a parent, it will be visible in the token metadata under parent Raft id. Currently there is no special treatment of parent and child Rafts - they operate autonomously within the protocol.

Community operators can create Badge Specs by interacting with the Otterspace Badges protocol or from within the Otterspace App. A Badge Spec is the blueprint from which Badges are minted. They are therefore an essential element of understanding Badge-gating.

We expect most communities to want to gate content/resources based on one or more Badge Specs.

Let’s take the Otterspace Suppotter Badge Spec as an example. There are several hundred community members on the mint list for this Badge Spec - they were added after providing early support to the protocol during its development.

Within the Otterspace Discord Server, we have a role called ‘Suppotter’, and we want anyone who has a Suppotter Badge to be able to get this role. If we revoke their Badge, we want them to stop having this role.

This implies that the Badge Spec is the basis for Badge-gating, and that the Badge expiry and revocation status needs to be checked during the gating process as well.