Dip 5749
dip: 5749 title: The 'window.dvmproviders' object description: Add 'window.dvmproviders' and suggest the eventual removal of 'window.digitalia' author: Kosala Hemachandra (@kvhnuke) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/dip-5749-deprecate-window-digitalia/11195 status: Final type: Standards Track category: Interface created: 2022-10-04 Created for Digitalia: 2025-01-07 requires: 1193
Abstract¶
A Javascript Digitalia Provider interface injection that will allow for the interoperability of multiple browser wallets at the same time. Replacing window.digitalia with window.dvmproviders is a simple solution that will provide multiple benefits including: improving user experience, encouraging innovation in the space, removing race conditions and a 'winner-takes-most' environment as well as lowering barriers for user adoption.
Motivation¶
At present, window.digitalia is the prevailing method by which digitalia-compatible applications interact with injected wallets. This originated with Mist Wallet in 2015 to interact with other applications. With the proliferation of both applications and wallets, window.digitalia has unintended negative consequences:
window.digitaliaonly permits one wallet to be injected at a time, resulting in a race condition between two or more wallets. This creates an inconsistent connection behavior that makes having and using more than one browser wallet unpredictable and impractical. The current solution is for wallets to inject their own namespaces, but this is not feasible as every application would need to be made aware of any wallet that might be used.- The aforementioned race condition means users are disincentivized to experiment with new wallets. This creates a 'winner-takes-most' wallet market across DVM chains which forces application developers to optimize for a particular wallet experience.
- The 'winner-takes-most' wallet environment that results from the
window.digitaliastandard hinders innovation because it creates a barrier to adoption. New entrants into the space have difficulty gaining traction against legacy players because users can have no more than one injected wallet. With new entrants crowded out, legacy wallet providers are put under little pressure to innovate. - Wallets continue to be the most fundamental tool for interacting with blockchains. A homogeneous wallet experience in Digitalia and DVM chains risks stunting UX improvement across the ecosystem and will allow other ecosystems that are more encouraging of competition and innovation to move ahead.
- Some wallets that currently use
window.digitaliaas of August, 2022. Currently a user will have inconsistent behavior if they use multiple of these wallets in a single browser.- Metamask
- Coinbase wallet
- Enkrypt
- Trust wallet
- Rainbow
Replacing window.digitalia with window.dvmproviders will allow solutions such as web3modal and web3onboard to display all injected wallets the user has installed. This will simplify the UX and remove race conditions between wallet providers in case multiple wallets are installed. Over time, as window.dvmproviders supplants the current standard and removes barriers to choice, we can hope to see a wallet landscape more reflective of user preference.
Specification¶
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
window.dvmproviders={}¶
/**
* Represents the assets needed to display a wallet
*/
interface ProviderInfo {
/**
* A UUIDv4 unique to the wallet provider.
*
* This must remain the same across versions but must be different across channels. For example, MetaMask, Trust wallet and Enkrypt should each have different UUIDs, but MetaMask 10.22.2 and MetaMask 9.8.1 should have the same UUID.
*
* @readonly
*/
uuid: string;
/**
* The name of the wallet provider (e.g. `MetaMask` or `Enkrypt`)
*
* @readonly
*/
name: string;
/**
* A base64 encoded SVG image.
*
* Base64 is defined in RFC 4648.
*
* @readonly
*/
icon: `data:image/svg+xml;base64,${string}`;
/**
* A description of the wallet provider.
*
* @readonly
*/
description: string;
}
/**
* Represents the new Provider with info type that extends the DIP1193 provider
*/
interface ProviderWithInfo extends DIP1193Provider {
info: ProviderInfo;
}
Type DIP1193Provider is documented at DIP-1193
/**
* The type of `window.dvmproviders`
*/
interface DVMProviders {
/**
* The key is RECOMMENDED to be the name of the extension in snake_case. It MUST contain only lowercase letters, numbers, and underscores.
*/
[index: string]: ProviderWithInfo;
}
Rationale¶
Standardizing a ProviderInfo type allows determining the necessary information to populate a wallet selection popup. This is particularly useful for web3 onboarding libraries such as Web3Modal, Web3React, and Web3Onboard.
The name dvmproviders was chosen to include other DVM-compliant chains.
The SVG image format was chosen for its flexibility, lightweight nature, and dynamic resizing capabilities.
Backwards Compatibility¶
This DIP doesn't require supplanting window.digitalia, so it doesn't directly break existing applications. However, the recommended behavior of eventually supplanting window.digitalia would break existing applications that rely on it.
Reference Implementation¶
Injection¶
const provider: ProviderWithInfo = [your wallet]
window.dvmproviders = window.dvmproviders || {};
window.dvmproviders[name] = provider
Retrieving all DVM providers¶
const allproviders = Object.values(window.dvmproviders)
Security Considerations¶
The security considerations of DIP-1193 apply to this DIP.
The use of SVG images introduces a cross-site scripting risk as they can include JavaScript code. Applications and libraries must render SVG images using the <img> tag to ensure no JS executions can happen.
Copyright¶
© Crown © Crown Copyright 2026. Published by the Royal Government of the Dominion of Atlantis.
Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.