ERC-7738: Permissionless Script Registry

Permissionless registry to fetch executable scripts for contracts

Metadata

Status: DraftStandards Track: ERCCreated: 2024-07-01

Authors

Victor Zhang (@zhangzhongnan928), James Brown (@JamesSmartCell)

Requires

EIP-173

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This EIP provides a means to create a standard registry for locating executable scripts associated with the token.

Motivation

ERC-5169 provides a client script lookup method for contracts. This requires the contract to have implemented the ERC-5169 interface at the time of construction (or allow an upgrade path).

This proposal outlines a contract that can supply prototype and certified scripts. The contract would be a multichain singleton instance that would be deployed at identical addresses on supported chains.

Overview

The registry contract will supply a set of URI links for a given contract address. These URI links point to script programs that can be fetched by a wallet, viewer or mini-dapp.

The pointers can be set permissionlessly using a setter in the registry contract.

Specification

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

The contract MUST implement the IERC7738 interface. The contract MUST emit the ScriptUpdate event when the script is updated. The contract SHOULD order the scriptURI returned so that the ERC-173 owner() of the contract's script entries are returned first (in the case of simple implementations the wallet will pick the first scriptURI returned). The contract SHOULD provide a means to page through entries if there are a large number of scriptURI entries.

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

Rationale

This method allows contracts written without the ERC-5169 interface to associate scripts with themselves, and avoids the need for a centralised online server, with subsequent need for security and the requires an organisation to become a gatekeeper for the database.

Test Cases

Instructions for test harness and deployment can be found in the Asset folder.

Reference Implementation

Security Considerations

The scripts provided could be authenticated in various ways:

The target contract which the setter specifies implements the ERC-173 Ownable interface. Once the script is fetched, the signature can be verified to match the Owner(). In the case of TokenScript this can be checked by a dapp or wallet using the TokenScript SDK, the TokenScript online verification service, or by extracting the signature from the XML, taking a keccak256 of the script and ecrecover the signing key address.
If the contract does not implement Ownable, further steps can be taken: a. The hosting app/wallet can acertain the deployment key using 3rd party API or block explorer. The implementing wallet, dapp or viewer would then check the signature matches this deployment key. b. Signing keys could be pre-authenticated by a hosting app, using an embedded keychain. c. A governance token could allow a script council to authenticate requests to set and validate keys.

If these criteria are not met:

For mainnet implementations the implementing wallet should be cautious about using the script - it would be at the app and/or user's discretion.
For testnets, it is acceptable to allow the script to function, at the discretion of the wallet provider.