## Abstract

Authors: https://x.com/agusx1211 https://x.com/optimizoor

This ERC defines the specification for "blinks" (blockchain links), which are standard URLs enhanced with blockchain-specific rich media and interactive elements. Blinks are designed to be rendered by wallet extensions, providing users with immediate access to blockchain data and actions within the context of regular web links.

## Motivation

The current landscape of decentralized applications (dapps) presents several challenges to user experience:

1. Context Switching: Users often need to navigate away from their current page to interact with a dapp, disrupting their workflow and attention.
2. Connection Friction: Each dapp typically requires a separate wallet connection process, adding steps and potential confusion.
3. Interface Inconsistency: Different dapps have varied interfaces, requiring users to relearn navigation and interaction patterns for each application.
4. Limited Preview: Users often lack immediate access to relevant blockchain data without fully engaging with a dapp.

Blinks address these issues by:

- Embedding blockchain data and interactions directly within familiar web links
- Allowing users to view critical information (e.g., DAO proposals, NFT images, token prices) without leaving their current context
- Providing a standardized format for presenting blockchain interactions across different dapps
- Enabling quick actions (e.g., token purchases, votes) directly from the link interface

By reducing these friction points, blinks aim to significantly improve the accessibility and usability of blockchain interactions, potentially accelerating the adoption of web3 technologies among a broader user base.

## Specification

### URL Format

Any normal URL can define a blink by including an `eb1ink` GET parameter in the URL. This parameter is only used by the renderer of the blink.

The parameter contents must follow this schema:

eb1ink=[chain_id]:[server_contract]:[instance_data]

1) `chain_id`: Chain ID of the network where the `server_contract` resides.
2) `server_contract`: Contract that renders the contents of the blink.
3) `instance_data`: (Optional) additional data to be passed to the `server_contract`.

> **QUESTION**: Maybe put this data on `<meta>` headers? The renderer would need to fetch every link before rendering, though.

### Server Contract

Blink actions are defined by a server contract. A server contract converts `instance_data` to a list of `actions` that can be rendered alongside the blink.

These actions are obtained by calling the following view function:

function getActions(
  string calldata _url,
  bytes calldata _instanceData
) external view returns (
    uint256 _blinkVersion,
    bytes memory _blinkData
);

The server contract is expected to:

1) Validate that the URL points to a correct "fallback" URL, meaning to a web application that is considered healthy.
2) Return an ABI encoded `blink` as `_blinkData`, alongside its corresponding version.

Server contracts *MAY* be reused by relying on data included in `instanceData`; this could be enabled by selecting among templates or by using `instanceData` to aid the construction of the blink.

> **QUESTION**: Maybe have a way for the renderer to call `getActions` saying "I only support version X, Y, and Z"? That way, a contract could adapt itself to the capabilities of the renderer.

### Rendering

Any platform that renders a link can fetch its corresponding blinks and render them alongside the regular link. This can be done natively by any webpage.

Alternatively, it is expected that wallet extensions will aid with the rendering of blinks until "native support" increases. This can be performed by doing content substitution on the webpage that is originally rendering a normal link.

Rendering styles are not specified; each renderer can interpret the blink metadata as it sees fit.

> **QUESTION**: How do we handle collisions? The webpage should be able to say "don't substitute the blink; I will render it," and what happens if there are multiple extensions attempting to render the blink?

### Fallback URL

It is expected that some users won't have direct access to a blink renderer because they are looking at the link on a platform that doesn't natively integrate them, and they don't have an extension installed either.

To handle this scenario, blinks work as regular URLs when they are not being replaced by their rich media alternatives. The creator of the blink *MUST* ensure that the "normal" link deep-links to a dapp that shows the same content in a relevant way.