{"id":"ERC-5484","name":"Consensual Soulbound Tokens","status":"Final","chain":"both","category":{"id":"identity","name":"Identity & Privacy","description":"Who you are on-chain, and what you choose to reveal"},"journeyStages":[{"id":"approving","name":"Approving & Permissioning","description":"Granting permissions for actions"},{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"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.","hasDetailedContent":true,"content":{"id":"ERC-5484","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.","applicability":{"whenToUse":["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."],"whenToAvoid":["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."]},"designerTakeaways":["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."],"problemsSolved":[{"problem":"Soulbound tokens can be sent without permission","oldWay":"Anyone can mint unwanted credentials/badges to your wallet","newWay":"Must explicitly accept before token binds to you","impact":"critical"},{"problem":"Can't refuse spam soulbound tokens","oldWay":"Wallet polluted with unwanted non-transferable junk","newWay":"Pending state allows rejection before binding","impact":"high"},{"problem":"No ceremony for important credentials","oldWay":"Diploma just appears in wallet, anticlimactic","newWay":"Accept ceremony makes credential meaningful","impact":"medium"},{"problem":"Unclear who can burn soulbound tokens","oldWay":"Stuck with token forever? Can issuer revoke?","newWay":"BurnAuth specifies: issuer-only, owner-only, both, or neither","impact":"medium"},{"problem":"No way to verify consent was given","oldWay":"Can't prove recipient agreed to credential","newWay":"On-chain accept transaction proves consent","impact":"medium"}],"uxPatterns":[{"name":"Credential Acceptance Flow","description":"User explicitly accepts soulbound credential","mockup":"concept/siwe-sign-in","userFlow":["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"]},{"name":"Pending Credentials Inbox","description":"View and manage pending credential offers","mockup":"concept/siwe-sign-in","userFlow":["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"]},{"name":"Burn Authority Explanation","description":"Explain who can burn the soulbound token","mockup":"concept/siwe-sign-in","userFlow":["User reviews credential before accepting","Sees burn authority explanation","Understands implications of each option","Makes informed decision to accept or not"]},{"name":"Bound Credential Display","description":"Show accepted soulbound credential","mockup":"concept/siwe-sign-in","userFlow":["User views accepted credential","Clear soulbound indicator","Shows when it was accepted","Burn option available if auth allows","Warning before burning"]}],"uiComponents":[{"name":"ConsentModal","description":"Modal for accepting soulbound token","states":["reviewing","confirming","accepting","bound"],"props":["credential","issuer","burnAuth","onAccept","onDecline"]},{"name":"PendingCredentialBadge","description":"Badge showing credentials awaiting acceptance","states":["none","few","many"],"props":["count","onClick"]},{"name":"BurnAuthIndicator","description":"Shows who can burn the token","states":["issuer-only","owner-only","both","neither"],"props":["burnAuth","issuer","showDetails"]},{"name":"SoulboundBadge","description":"Visual indicator that token is soulbound","states":["pending","bound","revoked"],"props":["status","tooltip"]},{"name":"CredentialInbox","description":"List of pending credential offers","states":["empty","has-pending","has-spam"],"props":["credentials[]","onAccept","onDecline"]}],"antiPatterns":[{"pattern":"Auto-accepting soulbound tokens","why":"Defeats the entire point of consent","instead":"Always require explicit user action to accept","severity":"critical"},{"pattern":"Not explaining soulbound implications","why":"Users don't realize token is permanent","instead":"Clear warning: \"Cannot be transferred after acceptance\"","severity":"critical"},{"pattern":"Hiding burn authority information","why":"User should know if issuer can revoke","instead":"Prominently show who can burn before acceptance","severity":"high"},{"pattern":"No way to decline unwanted credentials","why":"Spam tokens clutter pending inbox forever","instead":"Easy decline button that hides/rejects token","severity":"high"},{"pattern":"Mixing pending and bound credentials","why":"Unclear which credentials are active","instead":"Separate sections for pending vs bound","severity":"medium"},{"pattern":"Burn without confirmation","why":"Accidental burns can't be undone","instead":"Require confirmation: \"Are you sure? This is permanent\"","severity":"high"}],"onMonad":[{"aspect":"Accept Transaction","ethereum":"Accept tx costs gas, might discourage acceptance","monad":"Low gas makes acceptance friction minimal","designImplication":"Can encourage accepting even minor credentials"},{"aspect":"Consent Verification","ethereum":"Check accept tx on-chain to verify consent","monad":"Fast queries make consent verification easy","designImplication":"Can verify consent in real-time for access control"},{"aspect":"Credential Issuance","ethereum":"Gas limits bulk issuance","monad":"Can issue credentials to many users economically","designImplication":"Event organizers can issue to all attendees cheaply"},{"aspect":"Burn Speed","ethereum":"Burn takes a block, credential lingers briefly","monad":"Sub-second burn means instant revocation","designImplication":"Credentials revoke truly instantly"}],"keyTakeaways":["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"],"technicalNotes":"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."},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-5484","type":"official-spec"},{"label":"Discussion","url":"https://ethereum-magicians.org/search?q=ERC-5484","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-5484","markdown":"https://www.eipsfordesigners.com/standards/ERC-5484/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-5484/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-5484","official":"https://eips.ethereum.org/EIPS/eip-5484","discussion":"https://ethereum-magicians.org/search?q=ERC-5484"},"freshness":{"lastReviewed":"2026-04-05","lastUpdated":"2026-04-05"}}