{"id":"EIP-2255","name":"Wallet Permissions System","status":"Final","chain":"both","category":{"id":"onboarding","name":"Onboarding & Access","description":"Getting users into web3 without friction"},"journeyStages":[{"id":"discovery","name":"Discovery & Connection","description":"Finding and connecting wallet to dApp"}],"uxImpact":"Users grant permissions once upfront instead of approving every action individually — OAuth-style consent for Web3. Design implications: design permission request screens showing all requested capabilities (eth_accounts, signing methods) in human-readable form, allow users to selectively reject individual permissions, show current granted permissions in settings, design permission expiration and revocation flows. Design decisions: balance between requesting minimal permissions (more prompts) vs bundled permissions (fewer prompts, more trust required), decide when to request additional permissions mid-session, consider showing permission-specific UI caveats like 'requires signTypedData_v3 support'.","hasDetailedContent":true,"content":{"id":"EIP-2255","summary":"EIP-2255 introduces granular wallet permissions so users can grant specific access (\"view my address\") instead of all-or-nothing. This enables progressive trust building where dApps request only what they need, when they need it.","applicability":{"whenToUse":["Your product addresses: connecting wallet exposes everything at once.","Your users can't revoke specific permissions.","The flow should deliver: dApp requests specific permissions, user grants only what's needed.","You are designing a progressive permission request experience with visible states and recovery paths."],"whenToAvoid":["Request minimal permissions first, escalate only when needed.","Provide clear context: \"Needed to list your NFT for sale\".","Gracefully degrade, show what features require the permission.","Wallet or chain support is fixed and users cannot choose providers."]},"designerTakeaways":["You can design UI that delivers dApp requests specific permissions.","You can design UI that delivers granular permission revocation for each capability.","You can clear permission list shows exactly what dApp can access in the interface."],"problemsSolved":[{"problem":"Connecting wallet exposes everything at once","oldWay":"Click \"Connect\" and dApp can see all addresses, request any transaction","newWay":"dApp requests specific permissions, user grants only what's needed","impact":"critical"},{"problem":"Users can't revoke specific permissions","oldWay":"Only option is to fully disconnect, losing all access","newWay":"Granular permission revocation for each capability","impact":"high"},{"problem":"No way to know what a dApp can do","oldWay":"Users unsure what they agreed to when connecting","newWay":"Clear permission list shows exactly what dApp can access","impact":"high"},{"problem":"Can't progressively expand trust","oldWay":"Must grant full access upfront or not connect at all","newWay":"Start with \"view address\", add \"sign messages\" later","impact":"medium"},{"problem":"Apps request more than they need","oldWay":"No incentive to request minimal permissions","newWay":"Permission prompts make over-requesting obvious to users","impact":"medium"}],"uxPatterns":[{"name":"Progressive Permission Request","description":"Request permissions as needed, not all at once","mockup":"concept/typed-data","userFlow":["User clicks Connect","Wallet shows minimal permission request","User understands exactly what's being asked","User approves minimal access","Later: dApp requests signing permission when needed","User can approve/deny each escalation"]},{"name":"Permission Escalation","description":"Request additional permissions when needed","mockup":"concept/typed-data","userFlow":["User tries to list NFT","dApp detects signing permission needed","Permission request explains why it's needed","User sees existing permissions for context","User grants additional permission","Action proceeds"]},{"name":"Permission Management Dashboard","description":"View and manage all dApp permissions in wallet","mockup":"concept/typed-data","userFlow":["User opens wallet settings","Sees list of connected sites","Each site shows granted permissions","User can revoke individual permissions","Or fully disconnect site"]},{"name":"Permission Request with Context","description":"Explain why each permission is needed","mockup":"concept/typed-data","userFlow":["Permission needed for user action","Wallet shows what permission does","dApp provides context (why needed)","User can learn more if unsure","Informed decision to grant or deny"]}],"uiComponents":[{"name":"PermissionRequestModal","description":"Modal showing permission being requested","states":["requesting","approved","denied","expired"],"props":["permissions[]","site","context","onApprove","onDeny"]},{"name":"PermissionBadge","description":"Visual indicator of permission type","states":["view","sign","transact","advanced"],"props":["permissionType","granted","canRevoke"]},{"name":"ConnectedSiteCard","description":"Card showing site with its permissions","states":["connected","limited","full-access"],"props":["site","permissions[]","connectedAt","onDisconnect"]},{"name":"PermissionToggle","description":"Toggle to grant/revoke specific permission","states":["granted","revoked","pending","required"],"props":["permission","enabled","onChange","isRequired"]},{"name":"CapabilityExplainer","description":"Explains what a permission allows","states":["collapsed","expanded"],"props":["permission","description","risks","examples"]}],"antiPatterns":[{"pattern":"Requesting all permissions upfront","why":"Users don't understand why you need everything, reduces trust","instead":"Request minimal permissions first, escalate only when needed","severity":"critical"},{"pattern":"No explanation for why permission is needed","why":"Users deny requests they don't understand","instead":"Provide clear context: \"Needed to list your NFT for sale\"","severity":"high"},{"pattern":"Breaking the app when permission denied","why":"Users feel forced to grant everything","instead":"Gracefully degrade, show what features require the permission","severity":"high"},{"pattern":"Not showing current permission state","why":"Users forget what they granted, feel out of control","instead":"Show active permissions in settings or footer","severity":"medium"},{"pattern":"Using technical permission names","why":"\"eth_signTypedData_v4\" means nothing to users","instead":"Say \"Sign messages\" with explanation of what that enables","severity":"medium"},{"pattern":"No way to revoke without full disconnect","why":"Users lose all access to revoke one thing","instead":"Allow granular permission management in wallet","severity":"medium"}],"onMonad":[{"aspect":"Permission Check Speed","ethereum":"wallet_getPermissions call may have noticeable latency","monad":"Fast responses make permission checks feel instant","designImplication":"Can check permissions inline without loading states"},{"aspect":"Transaction Permission","ethereum":"eth_sendTransaction permission is high-risk","monad":"With reserve balance, even full tx permission has limits","designImplication":"Can be more flexible with transaction permissions due to reserve safety"},{"aspect":"Session-Based Permissions","ethereum":"Permissions typically persistent until revoked","monad":"With fast finality, time-limited permissions more practical","designImplication":"Can implement \"allow for 1 hour\" permission grants"},{"aspect":"Permission for Account Abstraction","ethereum":"EIP-7702 adds new permission considerations","monad":"MONAD-7702 constraints affect what delegated code can do","designImplication":"May need new permission types for smart wallet features"}],"keyTakeaways":["Request only permissions you need right now","Explain WHY each permission is needed in context","Let users revoke individual permissions without disconnecting","Use human language: \"View address\" not \"eth_accounts\"","Gracefully handle denied permissions"],"technicalNotes":"EIP-2255 uses wallet_requestPermissions and wallet_getPermissions RPC methods. Permissions are capabilities like eth_accounts, eth_sign, eth_signTypedData_v4, eth_sendTransaction. Each permission can be restricted (e.g., specific addresses, caveats). MetaMask and other wallets implement varying subsets."},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-2255","type":"official-spec"},{"label":"Discussion","url":"https://ethereum-magicians.org/search?q=EIP-2255","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-2255","markdown":"https://www.eipsfordesigners.com/standards/EIP-2255/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-2255/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-2255","official":"https://eips.ethereum.org/EIPS/eip-2255","discussion":"https://ethereum-magicians.org/search?q=EIP-2255"},"freshness":{"lastReviewed":"2026-04-05","lastUpdated":"2026-04-05"}}