# ERC-5484: Consensual Soulbound Tokens

Source: https://www.eipsfordesigners.com/standards/ERC-5484
Agent brief: https://www.eipsfordesigners.com/standards/ERC-5484/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-5484
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Identity & Privacy |
| Journey stages | Approving & Permissioning, Asset Management |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-5484 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-5484 |

## UX Impact

Soulbound tokens require recipient consent before minting and have predetermined burn rules (issuer-only, owner-only, both, neither). Design implications: show consent flow before accepting SBT, display burn authority clearly, add 'Request Burn' action where applicable. Design decisions: how to present burn authority — affects user understanding of permanence, recovery options if keys lost.

## Summary

ERC-5484 creates soulbound tokens that require consent before binding. Unlike tokens that are pushed to your wallet, you must explicitly accept these credentials before they become non-transferable and permanently attached to your identity.

## For Designers

- You can design UI that delivers must explicitly accept before token binds to you.
- You can design UI that delivers pending state allows rejection before binding.
- You can design UI that delivers accept ceremony makes credential meaningful.

## Applicability

### When to Use

- Your product addresses: soulbound tokens can be sent without permission.
- Your product must handle: can't refuse spam soulbound tokens.
- The flow should deliver: must explicitly accept before token binds to you.
- You are designing a credential acceptance flow experience with visible states and recovery paths.

### When to Avoid

- Always require explicit user action to accept.
- Clear warning: "Cannot be transferred after acceptance".
- Prominently show who can burn before acceptance.
- The product has no sign-in, attestation, or identity verification step.

## Problems It Solves

### Soulbound tokens can be sent without permission

Impact: critical

Old way: Anyone can mint unwanted credentials/badges to your wallet

New way: Must explicitly accept before token binds to you

### Can't refuse spam soulbound tokens

Impact: high

Old way: Wallet polluted with unwanted non-transferable junk

New way: Pending state allows rejection before binding

### No ceremony for important credentials

Impact: medium

Old way: Diploma just appears in wallet, anticlimactic

New way: Accept ceremony makes credential meaningful

### Unclear who can burn soulbound tokens

Impact: medium

Old way: Stuck with token forever? Can issuer revoke?

New way: BurnAuth specifies: issuer-only, owner-only, both, or neither

### No way to verify consent was given

Impact: medium

Old way: Can't prove recipient agreed to credential

New way: On-chain accept transaction proves consent

## Anti-Patterns

### Auto-accepting soulbound tokens

Severity: critical

Defeats the entire point of consent

Instead: Always require explicit user action to accept

### Not explaining soulbound implications

Severity: critical

Users don't realize token is permanent

Instead: Clear warning: "Cannot be transferred after acceptance"

### Hiding burn authority information

Severity: high

User should know if issuer can revoke

Instead: Prominently show who can burn before acceptance

### No way to decline unwanted credentials

Severity: high

Spam tokens clutter pending inbox forever

Instead: Easy decline button that hides/rejects token

### Burn without confirmation

Severity: high

Accidental burns can't be undone

Instead: Require confirmation: "Are you sure? This is permanent"

### Mixing pending and bound credentials

Severity: medium

Unclear which credentials are active

Instead: Separate sections for pending vs bound

## UI Components

### ConsentModal

Modal for accepting soulbound token
States: reviewing, confirming, accepting, bound
Props: credential, issuer, burnAuth, onAccept, onDecline

### PendingCredentialBadge

Badge showing credentials awaiting acceptance
States: none, few, many
Props: count, onClick

### BurnAuthIndicator

Shows who can burn the token
States: issuer-only, owner-only, both, neither
Props: burnAuth, issuer, showDetails

### SoulboundBadge

Visual indicator that token is soulbound
States: pending, bound, revoked
Props: status, tooltip

### CredentialInbox

List of pending credential offers
States: empty, has-pending, has-spam
Props: credentials[], onAccept, onDecline

## On Monad

### Accept Transaction

Ethereum: Accept tx costs gas, might discourage acceptance

Monad: Low gas makes acceptance friction minimal

Design implication: Can encourage accepting even minor credentials

### Consent Verification

Ethereum: Check accept tx on-chain to verify consent

Monad: Fast queries make consent verification easy

Design implication: Can verify consent in real-time for access control

### Credential Issuance

Ethereum: Gas limits bulk issuance

Monad: Can issue credentials to many users economically

Design implication: Event organizers can issue to all attendees cheaply

### Burn Speed

Ethereum: Burn takes a block, credential lingers briefly

Monad: Sub-second burn means instant revocation

Design implication: Credentials revoke truly instantly

## Key Takeaways

- ERC-5484 = soulbound tokens WITH consent
- Must accept before token binds to wallet
- Always show burn authority before acceptance
- Separate pending from bound credentials in UI
- Make decline easy to avoid credential spam

## UX Patterns

### Credential Acceptance Flow

User explicitly accepts soulbound credential

User flow:

- Issuer mints credential to user (pending state)
- User receives notification of pending credential
- Reviews credential details and binding terms
- Understands burn authority (who can revoke)
- Explicitly accepts to bind
- Credential becomes non-transferable

Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page).

### Pending Credentials Inbox

View and manage pending credential offers

User flow:

- User opens pending credentials
- Sees list of credentials waiting for acceptance
- Unknown issuers flagged as potential spam
- Can accept legitimate credentials
- Can decline unwanted ones
- Declined tokens never bind

Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page).

### Burn Authority Explanation

Explain who can burn the soulbound token

User flow:

- User reviews credential before accepting
- Sees burn authority explanation
- Understands implications of each option
- Makes informed decision to accept or not

Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page).

### Bound Credential Display

Show accepted soulbound credential

User flow:

- User views accepted credential
- Clear soulbound indicator
- Shows when it was accepted
- Burn option available if auth allows
- Warning before burning

Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page).

## Technical Notes

ERC-5484 extends ERC-5192 (minimal soulbound) with consent mechanism. BurnAuth enum: IssuerOnly, OwnerOnly, Both, Neither. Token starts in pending state, becomes bound after acceptPendingToken(). Events: Issued(address, uint256, BurnAuth), TokenBound(address, uint256). Issuer can set any BurnAuth when minting.