Summary: Otterspace is best understood not as a generic NFT-badge app, but as a protocol for issuing, revoking, expiring, and interpreting non-transferable onchain credentials that communities can use for governance, access control, and role legibility. Its most reusable mechanism is the split between a transferable issuer object called a Raft, reusable Badge Specs that define shared metadata and policy, and individual EIP-4973 account-bound badges minted from those specs. That makes it a useful comparison class for Ethereum Attestation Service, Sign Protocol, Hypercerts, Hats Protocol, and identity/social-graph systems where the real question is not just what credential exists, but who controls issuance, revocation, expiry, and downstream interpretation.
What it does:
Lets a Raft issuer create badge specifications, then mint many non-transferable badges from a shared spec to different holders
Uses EIP-4973-style account-bound tokens so badges are visible onchain and composable with wallets, token gates, and governance tooling without being freely transferable
Supports issuer-side revocation and spec-level expiration so a badge can remain historically visible while no longer granting active access or authority
Lets badge holders burn their own badges, preserving the holder’s ability to dissociate from a credential rather than forcing permanent public attachment
Integrates badges into governance and access systems such as Snapshot, Discord / Telegram token-gating, Guild.xyz, and Safe-related workflows
Exposes contract, API, and subgraph surfaces so developers can build badge-aware applications instead of relying only on Otterspace’s hosted UI
Key claims:
The official intro frames Otterspace as a protocol for non-transferable NFTs representing roles, achievements, status, trust, and experience, which is the cleanest reason to classify it as reputation and authority infrastructure rather than collectible NFT tooling.
The key-concepts docs show that control sits first with the Raft. Because the Raft itself is a transferable ERC-721 issuer object, governance over badge issuance can be transferred at the issuer level even while the badges themselves stay non-transferable.
The Badge Spec abstraction is analytically important because it separates reusable credential design from individual badge issuance. That makes Otterspace closer to a credential factory and policy layer than to one-off soulbound mints.
Otterspace’s relationship to EIP-4973 matters because the underlying standard emphasizes consensual account-bound association plus holder-side unequip / dissociation. Otterspace’s own docs reinforce that holders can burn badges while issuers can revoke them, which creates a more nuanced authority model than simple “soulbound forever” rhetoric.
The revocation and expiration docs reveal an important practical distinction: a badge can remain historically visible yet inactive, meaning Otterspace is not just about proving current membership but about preserving longitudinal role history with an active/inactive policy layer on top.
The Snapshot integration is especially useful for corpus purposes because it shows how badges become governance weights, not just social proof. In practice, the control surface shifts into which badge specs count, how much voting weight each receives, and whether multiple badges stack or only the highest-weight badge matters.
Otterspace is a strong comparison class for EAS and Sign Protocol because it packages attestation-like claims into a badge-and-spec model optimized for membership and permissions, while differing from Hats Protocol by centering on non-transferable credentials rather than explicit programmable role trees.
The system’s likely governance-risk surface is not transferability but issuer custody and downstream interpretation: whoever controls the Raft, badge spec metadata, revocation policy, and integration-side validity checks effectively controls the meaning and usefulness of the credential.
Whitepaper: No canonical standalone Otterspace whitepaper surfaced in this pass. The strongest primary materials were the official docs, integrations docs, contracts repository, and the linked EIP-4973 standard; see ../whitepapers/otterspace-primary-sources-2026-05-10.md.