# EIP-2255: Wallet Permissions System Source: https://www.eipsfordesigners.com/standards/EIP-2255 Agent brief: https://www.eipsfordesigners.com/standards/EIP-2255/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-2255 Last reviewed: 2026-04-05 Last updated: 2026-04-05 | Field | Value | | --- | --- | | Status | Final | | Chain | both | | Category | Onboarding & Access | | Journey stages | Discovery & Connection | | Detailed guide | Yes | | Official specification | https://eips.ethereum.org/EIPS/eip-2255 | | Discussion search | https://ethereum-magicians.org/search?q=EIP-2255 | ## UX Impact 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'. ## 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. ## For Designers - 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. ## Applicability ### When to Use - 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. ### When to Avoid - 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. ## Problems It Solves ### Connecting wallet exposes everything at once Impact: critical Old way: Click "Connect" and dApp can see all addresses, request any transaction New way: dApp requests specific permissions, user grants only what's needed ### Users can't revoke specific permissions Impact: high Old way: Only option is to fully disconnect, losing all access New way: Granular permission revocation for each capability ### No way to know what a dApp can do Impact: high Old way: Users unsure what they agreed to when connecting New way: Clear permission list shows exactly what dApp can access ### Can't progressively expand trust Impact: medium Old way: Must grant full access upfront or not connect at all New way: Start with "view address", add "sign messages" later ### Apps request more than they need Impact: medium Old way: No incentive to request minimal permissions New way: Permission prompts make over-requesting obvious to users ## Anti-Patterns ### Requesting all permissions upfront Severity: critical Users don't understand why you need everything, reduces trust Instead: Request minimal permissions first, escalate only when needed ### No explanation for why permission is needed Severity: high Users deny requests they don't understand Instead: Provide clear context: "Needed to list your NFT for sale" ### Breaking the app when permission denied Severity: high Users feel forced to grant everything Instead: Gracefully degrade, show what features require the permission ### Not showing current permission state Severity: medium Users forget what they granted, feel out of control Instead: Show active permissions in settings or footer ### Using technical permission names Severity: medium "eth_signTypedData_v4" means nothing to users Instead: Say "Sign messages" with explanation of what that enables ### No way to revoke without full disconnect Severity: medium Users lose all access to revoke one thing Instead: Allow granular permission management in wallet ## UI Components ### PermissionRequestModal Modal showing permission being requested States: requesting, approved, denied, expired Props: permissions[], site, context, onApprove, onDeny ### PermissionBadge Visual indicator of permission type States: view, sign, transact, advanced Props: permissionType, granted, canRevoke ### ConnectedSiteCard Card showing site with its permissions States: connected, limited, full-access Props: site, permissions[], connectedAt, onDisconnect ### PermissionToggle Toggle to grant/revoke specific permission States: granted, revoked, pending, required Props: permission, enabled, onChange, isRequired ### CapabilityExplainer Explains what a permission allows States: collapsed, expanded Props: permission, description, risks, examples ## On Monad ### Permission Check Speed Ethereum: wallet_getPermissions call may have noticeable latency Monad: Fast responses make permission checks feel instant Design implication: Can check permissions inline without loading states ### Transaction Permission Ethereum: eth_sendTransaction permission is high-risk Monad: With reserve balance, even full tx permission has limits Design implication: Can be more flexible with transaction permissions due to reserve safety ### Session-Based Permissions Ethereum: Permissions typically persistent until revoked Monad: With fast finality, time-limited permissions more practical Design implication: Can implement "allow for 1 hour" permission grants ### Permission for Account Abstraction Ethereum: EIP-7702 adds new permission considerations Monad: MONAD-7702 constraints affect what delegated code can do Design implication: May need new permission types for smart wallet features ## Key Takeaways - 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 ## UX Patterns ### Progressive Permission Request Request permissions as needed, not all at once User flow: - 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 Mockup registry key: `concept/typed-data` (React UI on the live standard page). ### Permission Escalation Request additional permissions when needed User flow: - 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 Mockup registry key: `concept/typed-data` (React UI on the live standard page). ### Permission Management Dashboard View and manage all dApp permissions in wallet User flow: - User opens wallet settings - Sees list of connected sites - Each site shows granted permissions - User can revoke individual permissions - Or fully disconnect site Mockup registry key: `concept/typed-data` (React UI on the live standard page). ### Permission Request with Context Explain why each permission is needed User flow: - 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 Mockup registry key: `concept/typed-data` (React UI on the live standard page). ## Technical Notes 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.