Skip to main content

Overview

Introduction

The AVM Web Provider is an interface that bridges the gap between clients (e.g. dApps) and providers (e.g. wallets), allowing clients to connect and interact with providers in a standardized way.

The AVM Web Provider works towards achieving two main goals:

  1. Creating a common interface between clients and providers.
  2. Allowing clients to choose what provider to use.

How it works

Traditionally, web-based provider inject script into a web page's document and "hijack" a property on the global object. This can be problematic as browser extensions are loaded in the web page in an unpredictable and unstable order, so for a user that uses multiple providers this will cause the last provider loaded to re-initialize the global property that was already initialized by another provider.

In order to prevent provider collisions, the client emits an event and instantiates an event listener. The provider listens to the client's incoming events and upon receiving an event, emits an event in response. This forms an event concurrency loop.

Since the client code and provider code aren’t guaranteed to run in a particular order, the events are designed to handle such race conditions.

Both clients and providers use the window.dispatchEvent function to emit events, and use the window.addEventListener function to observe events.

note

Browser extension providers MUST take advantage of the content scripts that will allow the provider access to the window object.

The AVM Web Provider leverages the EventTarget API as a transport layer to deliver messages and allows clients and web-based providers to securely communicate without interfering with other providers.