walletbeat

UNBLOCK CRYPTO | EIP6963

The way web3 frontends originally interacted with the MetaMask browser extension was by looking for a global JavaScript variable at `window.ethereum` or `window.web3.currentProvider` that adheres to the EIP-1193 standard.

As more wallet browser extensions and “in-app browsers” hit the market, they copied this convention and even set the `isMetaMask` flag to `true` so that existing frontends with MetaMask buttons could find them. Hence the conflict and confusion that continues to this day 🦊⚔️🥸

The solution is to adopt EIP-6963 which uses JavaScript events instead of global variables to introduce EIP-1193 objects to the frontend.

In other words – @opensea, get your act together and support EIP-6963 already!!

This is the browser user-agent wars all over again.
Ever wondered why Chrome actually declares itself as "Mozilla/AppleWebKit/Gecko/Chrome/Safari"?

One criterion for browser-based wallets listed on /walletbeat is whether they implement EIP-6963. This ensures a healthy, competitive, interoperable wallet ecosystem.

Wannabe contributor for /walletbeat.

Censorship resistance requires privacy.

The history of browser user-agents: https://humanwhocodes.com/blog/2010/01/12/history-of-the-user-agent-string/

Of course, wallets are half of the challenge. The other half is frontend adoption of EIP-6963.
Until frontends catch up, EIP-6963-compliant wallets may still be stuck also implementing window.ethereum for a while longer.

My goodness, it's crazy how long these have gotten.