Multi Injected Provider Discovery

Multi Injected Provider Discovery

Abstract

This proposal defines a browser event-based discovery mechanism for multiple injected Core Blockchain wallet providers.

It avoids contention over the legacy window.core global and enables decentralized applications (dApps) to discover and select independently injected wallet providers.

The mechanism is adapted from Ethereum EIP-6963, using Core-specific event names and a Core-native provider interface.

CIP-6963 additionally supports decentralized and remotely hosted wallet icons through Data URIs, HTTPS, and IPFS.

Provider discovery does not grant access to user accounts or private keys.

Motivation

When multiple browser wallets write to window.core, injection order may determine which wallet becomes accessible.

Delayed injection, overwriting, or nonstandard wallet-specific globals make wallet selection unreliable.

Core Blockchain applications need a discovery protocol that:

1. Allows multiple wallets to coexist.
2. Avoids shared global namespace collisions.
3. Allows users to select their preferred wallet.
4. Supports both legacy and modern wallet integrations.
5. Supports decentralized wallet metadata and icons.
6. Remains independent from Ethereum wallet discovery.

Specification

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described in RFC 2119 and RFC 8174.

Definitions

Wallet Provider: Software that manages Core Blockchain accounts and facilitates signing and transaction operations.

Decentralized Application (dApp): An application that communicates with Core Blockchain through wallet providers.

Provider Discovery Library: Software that discovers and manages available wallet providers.

Provider: A JavaScript object exposing the Core Blockchain wallet request interface.

Provider Metadata

Each wallet announcement MUST include the following metadata:

interface CIP6963ProviderInfo {
  uuid: string;
  name: string;
  icon: string;
  rdns: string;
}

The properties have the following meanings:

• uuid: A UUID version 4 identifier distinguishing provider instances within the page lifetime.
• name: A human-readable wallet name.
• icon: A URI identifying the wallet icon.
• rdns: A stable reverse-DNS wallet implementation identifier.

Additional metadata MAY be included.

Applications MUST ignore unrecognized properties without failing provider discovery.

UUID

The uuid property MUST be a valid UUIDv4.

Wallets MUST retain the same UUID when announcing the same provider instance repeatedly during the lifetime of a webpage.

Separate provider instances MUST use distinct UUIDs.

Name

The name property MUST contain a human-readable wallet name suitable for displaying in wallet selection interfaces.

Reverse DNS

The rdns property MUST use reverse-DNS notation.

Example:

com.example.corewallet

Wallet providers SHOULD use a domain under their control.

Applications MUST NOT treat the RDNS value as cryptographic proof of wallet identity.

Images / Icons

The icon property MUST contain a URI referencing an image representing the wallet provider.

Unlike Ethereum EIP-6963, which requires Data URIs, CIP-6963 extends icon support to HTTPS and IPFS.

Supported URI Schemes

Conforming CIP-6963 discovery implementations MUST recognize the following URI schemes:

Scheme	Description
data:	Embedded image data
https:	Remotely hosted image
ipfs:	IPFS content-addressed image

The http: scheme MUST NOT be used for remote wallet icons.

Examples:

// Embedded WebP
icon: "data:image/webp;base64,..."

// HTTPS-hosted JPEG XL
icon: "https://wallet.example/icon.jxl"

// IPFS-hosted WebP
icon: "ipfs://bafy.../icon.webp"

// HTTPS-hosted PNG
icon: "https://wallet.example/icon.png"

// Embedded SVG
icon: "data:image/svg+xml,..."

Supported Image Formats

CIP-6963 recommends the following formats:

Format	MIME Type	Priority
WebP	image/webp	Preferred
JPEG XL	image/jxl	Preferred where supported
PNG	image/png	Acceptable
SVG	image/svg+xml	Acceptable

Wallet providers SHOULD prefer WebP or JPEG XL for efficient compression and image quality.

Applications MUST support WebP and PNG decoding in environments where these formats are available.

Applications SHOULD support JPEG XL when the runtime provides a compatible decoder.

Applications MUST NOT assume that every browser supports JPEG XL natively.

Applications supporting SVG MUST render SVG images in a non-script-executing image context, such as an HTML <img> element.

SVG markup MUST NOT be inserted directly into the webpage DOM as executable inline markup.

Wallet icons SHOULD be square and have a minimum resolution of 96 × 96 pixels.

IPFS Icon Resolution

Applications MUST recognize ipfs:// as a valid wallet icon URI scheme.

Applications MAY resolve IPFS resources through:

1. A native IPFS client.
2. An embedded IPFS resolver.
3. A configurable HTTPS IPFS gateway.

For example:

ipfs://bafy.../wallet.webp

May be resolved through a gateway such as:

https://ipf.sk/ipfs/bafy.../wallet.webp

The exact gateway URL structure depends on the configured resolver.

Applications SHOULD allow the IPFS gateway to be configured.

Applications SHOULD prefer native content-addressed resolution when available.

When content integrity is important, applications SHOULD verify the retrieved resource against its IPFS CID.

Applications MUST validate IPFS identifiers and paths before constructing gateway requests.

Icon Security and Privacy

Applications MUST validate icon URI schemes before loading resources.

Applications MUST NOT execute scripts contained in image resources.

Applications SHOULD enforce reasonable image size and decoding limits.

Applications SHOULD cache successfully retrieved icons.

Applications SHOULD provide a fallback icon when loading or decoding fails.

Remote icon requests can expose user IP addresses and browsing activity to external servers.

Applications SHOULD avoid automatically fetching remote wallet icons before user interaction when doing so could compromise privacy.

Wallet providers SHOULD offer an embedded icon or another privacy-preserving fallback when practical.

Provider Interface

The provider MUST expose a request interface capable of communicating with the Core Blockchain wallet.

interface CoreProvider {
  request(args: {
    method: string;
    params?: unknown[] | object;
  }): Promise<unknown>;

  on(
    event: string,
    listener: (...args: unknown[]) => void
  ): void;

  removeListener(
    event: string,
    listener: (...args: unknown[]) => void
  ): void;
}

CIP-6963 defines discovery rather than the complete Core Blockchain RPC protocol.

Account access, transaction signing, network identification, and transaction submission MUST follow the applicable Core provider API specifications.

Provider Detail

Each wallet announcement MUST contain an info object and a provider object.

interface CIP6963ProviderDetail {
  info: CIP6963ProviderInfo;
  provider: CoreProvider;
}

The info property contains wallet metadata.

The provider property contains the JavaScript provider interface.

Wallets SHOULD freeze announcement metadata using Object.freeze() to reduce accidental modifications.

Window Events

CIP-6963 defines two browser events:

cip6963:announceProvider
cip6963:requestProvider

These events MUST be dispatched and observed through the webpage's window object.

Announce Provider

Wallets MUST announce themselves using a CustomEvent named:

cip6963:announceProvider

The event's detail property MUST contain a CIP6963ProviderDetail object.

interface CIP6963AnnounceProviderEvent
  extends CustomEvent<CIP6963ProviderDetail> {
  readonly type: "cip6963:announceProvider";
}

Request Provider

Applications MUST request wallet discovery by dispatching:

cip6963:requestProvider

This event MUST be a standard JavaScript Event.

interface CIP6963RequestProviderEvent
  extends Event {
  readonly type: "cip6963:requestProvider";
}

Wallets MUST listen for this event and announce their providers when requested.

Wallets MUST also announce themselves after their injected page script becomes ready.

Applications MUST register an announcement listener before dispatching a discovery request.

Applications SHOULD retain the listener throughout the webpage lifetime.

Wallet Implementation Example

const provider = createCoreProvider();

const info = Object.freeze({
  uuid: crypto.randomUUID(),
  name: "Example Core Wallet",
  icon: "ipfs://bafy.../wallet.webp",
  rdns: "com.example.corewallet"
});

const detail = Object.freeze({
  info,
  provider
});

function announceProvider() {
  window.dispatchEvent(
    new CustomEvent(
      "cip6963:announceProvider",
      { detail }
    )
  );
}

window.addEventListener(
  "cip6963:requestProvider",
  announceProvider
);

announceProvider();

The createCoreProvider() function is wallet-defined and represents the implementation of the Core provider API.

dApp Implementation Example

const providers = new Map();

window.addEventListener(
  "cip6963:announceProvider",
  (event) => {
    const { info, provider } = event.detail;

    if (
      !info ||
      typeof provider?.request !== "function"
    ) {
      return;
    }

    providers.set(info.uuid, {
      info,
      provider
    });

    renderWalletChoices([
      ...providers.values()
    ]);
  }
);

window.dispatchEvent(
  new Event("cip6963:requestProvider")
);

The renderWalletChoices() function is implemented by the dApp.

Applications SHOULD display discovered wallets in a user-selectable interface.

Applications MUST NOT automatically request account access merely because a provider was discovered.

Legacy Global Namespace

Wallet providers MAY expose:

window.core

This namespace exists for compatibility with legacy Core Blockchain applications.

CIP-6963 discovery MUST NOT depend on the presence of window.core.

Wallets MUST NOT overwrite another wallet's provider as part of CIP-6963 discovery.

Applications SHOULD prefer CIP-6963 discovery.

Applications MAY use window.core as a fallback when no CIP-6963 provider is discovered.

This proposal does not define a shared mutable registry under window.core.

Ethereum Compatibility

Wallets supporting both Core Blockchain and Ethereum MAY expose both discovery interfaces:

cip6963:announceProvider
cip6963:requestProvider

And:

eip6963:announceProvider
eip6963:requestProvider

Core-native providers MUST use the CIP-6963 discovery events.

Ethereum providers SHOULD continue following EIP-6963.

Applications MUST NOT assume that an Ethereum provider is compatible with Core Blockchain solely because both expose a request() method.

Rationale

Event-based discovery avoids collisions between independent browser extensions.

The paired request and announcement events allow discovery regardless of whether the wallet or application initializes first.

UUIDs distinguish provider instances.

Reverse-DNS identifiers offer continuity between sessions but are self-attested.

The cip6963 event prefix identifies the Core Blockchain discovery protocol and avoids ambiguity with Ethereum EIP-6963.

Supporting HTTPS and IPFS icons allows decentralized applications and wallet providers to use externally hosted or content-addressed assets.

WebP and JPEG XL are recommended for compression efficiency, while PNG and SVG remain available for compatibility.

Backwards Compatibility

CIP-6963 does not require removal of existing window.core injection.

Existing applications MAY continue using that global.

Wallets supporting both legacy injection and CIP-6963 SHOULD expose equivalent underlying provider functionality.

Applications SHOULD prefer event-based discovery to avoid namespace collisions.

The extended icon URI specification is not identical to Ethereum EIP-6963. Applications implementing only EIP-6963 icon rules may not accept HTTPS or IPFS icon URIs.

Test Cases

1. A wallet announces itself at page load and reannounces after a discovery request.
2. A wallet retains the same UUID for repeated announcements of the same provider instance.
3. Two wallets announce independently without overwriting window.core.
4. A dApp initialized after a wallet discovers it through cip6963:requestProvider.
5. Duplicate announcements do not create duplicate wallet entries.
6. A Data URI WebP icon is accepted.
7. An HTTPS WebP icon is accepted.
8. An HTTPS JPEG XL icon is recognized and displayed when supported.
9. An IPFS icon is resolved through a configured IPFS resolver or gateway.
10. PNG and SVG icons are accepted.
11. Unsupported or invalid icon resources result in a fallback icon.
12. Remote HTTP icon URLs are rejected.
13. Malformed or suspicious provider metadata does not automatically establish trust.
14. Discovery does not grant account access.
15. An application without CIP-6963 support may continue using a legacy window.core provider.
16. Ethereum and Core wallet discovery events operate independently.

Implementation

Wallet extensions SHOULD implement CIP-6963 discovery in a page-injected script.

Privileged wallet operations SHOULD be relayed to the extension's secure background process.

Private keys MUST NOT be exposed to webpage JavaScript.

Wallet providers MUST enforce account permissions independently from discovery.

Applications SHOULD support user selection between multiple discovered wallets.

Applications MAY integrate IPFS resolvers, including configurable gateways such as https://ipf.sk/, to retrieve decentralized wallet icons.

Security Considerations

Provider Impersonation

Page scripts and malicious extensions may spoof wallet names, icons, RDNS identifiers, and provider objects.

Applications MUST NOT use RDNS alone as proof of wallet authenticity.

Provider Object Manipulation

Wallet providers SHOULD protect announcement metadata against accidental mutation.

Freezing metadata does not make an untrusted webpage environment secure.

Icon Security

Applications MUST validate icon URI schemes.

Applications MUST NOT execute scripts from SVG resources.

Applications SHOULD enforce resource-size limits and handle malformed image data safely.

Remote Resource Privacy

Fetching remote icons can reveal user network information to external servers.

Applications SHOULD minimize unnecessary requests and SHOULD consider privacy-preserving loading strategies.

IPFS Resolution

Applications SHOULD validate IPFS CIDs and resource paths.

Applications SHOULD use trusted gateways or native IPFS resolution.

Applications SHOULD verify content integrity when feasible.

Browser Fingerprinting

Wallet discovery can reveal which wallet extensions are installed.

Wallet providers MAY introduce privacy controls or user-consent mechanisms for announcements, provided that they remain compatible with the discovery protocol.

Account Permissions

Provider discovery MUST NOT imply account authorization.

Account access, signing, and transaction operations MUST require the permissions defined by the applicable Core provider API.

References

• Ethereum EIP-6963
• Ethereum EIP-1193
• CIP-98
• CIP-99
• CIP-100
• CIP-712
• RFC 2119
• RFC 8174
• RFC 2397
• IPFS Documentation

Copyright

Copyright and related rights waived via CC0.