# EIP-5749: window.evmproviders Object

Source: https://www.eipsfordesigners.com/standards/EIP-5749
Agent brief: https://www.eipsfordesigners.com/standards/EIP-5749/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-5749
Last reviewed: 2026-05-25
Last updated: 2026-05-25

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Onboarding & Access |
| Journey stages | Discovery & Connection |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-5749 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-5749 |

## UX Impact

Alternative to EIP-6963 using window.evmproviders object — wallets register themselves by name for easy enumeration. Design implications: iterate Object.values(window.evmproviders) to build wallet selection UI, display wallet name, description, and base64 SVG icon for each provider, use snake_case keys as stable identifiers. Design decisions: choose between EIP-5749 vs EIP-6963 (6963 has more adoption), design fallback for wallets only supporting window.ethereum, handle scenario where both standards coexist during transition period.

## Summary

Alternative to EIP-6963 using window.evmproviders object — wallets register themselves by name for easy enumeration.

## For Designers

- You can build a wallet grid from window.evmproviders without hard-coding brand lists.
- Your connect flow can merge 5749 and EIP-6963 discovery for maximum coverage.
- You can remember the user's last wallet key for faster reconnect on return visits.

## Applicability

### When to Use

- Desktop dApps need to list multiple browser extension wallets.
- You want wallet name, description, and base64 SVG icon in the picker.
- You are supporting wallets that register via window.evmproviders.

### When to Avoid

- Mobile-only WalletConnect flows with no injected providers.
- Your target wallets only support EIP-6963 and not evmproviders.
- Single-wallet environments where a picker adds friction without benefit.

## Problems It Solves

### Inconsistent behavior across apps

Impact: high

Old way: Each team reinvents copy and edge cases

New way: Shared standard gives predictable UX patterns

### Users surprised by on-chain rules

Impact: high

Old way: Generic transfer UI fails at submit time

New way: Standard-aware UI sets expectations upfront

### Support burden from opaque errors

Impact: medium

Old way: Raw revert reasons in toasts

New way: Mapped states explain what to do next

## Anti-Patterns

### Hiding standard-imposed restrictions until submit

Severity: critical

Users feel tricked when actions fail at the last step

Instead: Show eligibility and badges before the primary CTA

### Protocol jargon in user-facing copy

Severity: high

Non-technical users cannot consent informedly

Instead: Use outcome language with optional technical disclosure

### No fallback when wallet lacks support

Severity: high

Dead-end flows increase churn

Instead: Explain limitation and offer alternate path or network

## Design Decisions

### How much protocol detail do users see?

Recommendation: Lead with outcomes; tuck identifiers behind review.

Rationale: Users decide on consequences, not function selectors.

### What happens when support is missing?

Recommendation: Block with explanation and fallback path.

Rationale: Silent failure feels like a broken product.

### How do you label restricted assets?

Recommendation: Use persistent badges for non-transferable, locked, or expiring states.

Rationale: Hidden restrictions cause rage-quits at transfer time.

## States to Design

### Ready

Trigger: Prerequisites met.

User need: Understand what happens next.

Design response: Enable primary action with plain-language preview.

### Awaiting signature

Trigger: Wallet prompt open.

User need: Know what they are approving.

Design response: Mirror human-readable summary in app and wallet.

### Pending

Trigger: Transaction submitted.

User need: Confidence it is progressing.

Design response: Show status strip with explorer link.

### Succeeded

Trigger: On-chain confirmation.

User need: See updated ownership or balance.

Design response: Celebrate outcome and show new state clearly.

### Failed or reverted

Trigger: Validation or execution failed.

User need: Fix or retry without guessing.

Design response: Name the failed constraint and offer a concrete next step.

## Vocabulary

- Use "Your balance / Your item" instead of "Token ID / Token contract": Ownership language matches mental models.

- Use "Cannot transfer yet" instead of "Transfer reverted": Explain restriction without EVM vocabulary.

- Use "Confirm in wallet" instead of "Sign transaction": Matches wallet UX users already know.

## What to Prototype First

### Primary happy path

Prove the core user promise before edge cases.

Covers: Success state, Clear outcome copy

- Primary CTA
- Confirmation feedback
- Next step

### Blocked or unsupported state

Users discover limits when wallets or chains lack support.

Covers: Unsupported wallet, Wrong network

- Plain-language reason
- Fallback action

### Failure recovery

Trust breaks when errors look like bugs.

Covers: User rejection, Transaction revert

- Retry path
- Support context

### Advanced disclosure

Power users need technical detail without cluttering the default path.

Covers: Contract address, Token ID, Raw status

- Expandable section
- Copy buttons
- Explorer link

## Mental Model

### Wallet registration

Extensions add themselves to window.evmproviders with a name, icon, and provider object keyed by wallet id.

### Enumeration

Your dApp reads evmproviders to build the picker grid. Merge with EIP-6963 announcements when both exist.

### User selection

The user picks a wallet by name and icon. Never assume the first key in the object is their preference.

### Provider handoff

Connection uses the selected entry provider only. Store the wallet key for faster reconnect on return visits.

### Missing provider

When evmproviders is empty, fall back to EIP-6963 events or WalletConnect without breaking the connect flow.

## Seen in the Wild

- Rabby: Multi-wallet products expect enumeration rather than a single injected provider. (https://rabby.io/)

- Rainbow: Sets expectations for wallet icon quality and naming in pickers. (https://rainbow.me/)

- wagmi: Connection libraries abstract multi-provider discovery for dApp teams. (https://wagmi.sh/)

## On Monad

### Confirmation speed

Ethereum: Multi-step flows can feel slow between signatures

Monad: Sub-second finality tightens feedback loops

Design implication: Prefer inline status over long pending modals on Monad.

### Transaction cost

Ethereum: Gas can discourage exploratory actions

Monad: Lower fees enable lighter-weight interactions

Design implication: Safe to offer preview retries and social actions more freely.

## UX Patterns

### EVM Providers Grid

Wallet picker from window.evmproviders entries.

Components: WalletGrid, ProviderIcon, ProviderName

User flow:

- User clicks Connect
- App reads evmproviders
- Grid shows wallets
- User selects
- Connection proceeds

Mockup registry key: `concept/wallet-discovery` (React UI on the live standard page).

### Dual Discovery Merge

Combine 5749 and EIP-6963 results.

Components: MergedWalletList, DedupeLogic

User flow:

- Listen for 6963 events
- Read evmproviders object
- Merge and dedupe
- Render unified list
- User connects

Mockup registry key: `concept/wallet` (React UI on the live standard page).

## Related Standards

- EIP-6963: Preferred discovery with broader wallet adoption

- EIP-1193: Provider API used after selection

## Technical Notes

EIP-5749 registers wallets on window.evmproviders with snake_case keys. Prefer supporting EIP-6963 in parallel during transition.