Skip to main content

Connecting to dapps

This page describes the extension's side of a dapp connection — what your eth_requestAccounts actually triggers. The dapp-side how-to lives in Connect your dapp.

The permission model​

Permissions are per origin, per account. When a dapp first calls eth_requestAccounts (or wallet_requestPermissions explicitly), Core shows a connection screen where the user picks which account to expose to that origin. From then on:

  • Requests from that origin for the approved account resolve without prompting.
  • Other accounts remain invisible — avalanche_getAccounts shows the dapp only what it was granted.
  • The user can revoke the origin at any time from Core's connected-sites list; the dapp sees accountsChanged with an empty array.

Method gating​

The service worker routes every request through permission middleware:

  • Open methods — network reads (eth_call, eth_getBalance, eth_chainId, …) need no permission.
  • Connection-gated methods — anything touching accounts requires the origin to be connected.
  • Approval methods — transactions and signatures additionally open an approval screen per request.

A request to a gated method from an unconnected origin rejects with error 4100.

Domain metadata​

Core records the origin, title, and icon of connecting dapps (avalanche_sendDomainMetadata, sent automatically by the provider) and displays them on approval screens — so what the user sees on a prompt is the site they're actually on, an anchor against spoofing.