ERC-1761: Scoped Approval Interface


Metadata
Status: StagnantStandards Track: ERCCreated: 2019-02-18
Authors
Witek Radomski (witek@enjin.io), Andrew Cooke (ac0dem0nk3y@gmail.com), James Therien (james@enjin.io), Eric Binet (eric@enjin.io)
Requires

Simple Summary


A standard interface to permit restricted approval in token contracts by defining "scopes" of one or more Token IDs.

Abstract


This interface is designed for use with token contracts that have an "ID" domain, such as ERC-1155 or ERC-721. This enables restricted approval of one or more Token IDs to a specific "scope". When considering a smart contract managing tokens from multiple different domains, it makes sense to limit approvals to those domains. Scoped approval is a generalization of this idea. Implementors can define scopes as needed.

Sample use cases for scopes:

  • A company may represent its fleet of vehicles on the blockchain and it could create a scope for each regional office.
  • Game developers could share an ERC-1155 contract where each developer manages tokens under a specified scope.
  • Tokens of different value could be split into separate scopes. High-value tokens could be kept in smaller separate scopes while low-value tokens might be kept in a shared scope. Users would approve the entire low-value token scope to a third-party smart contract, exchange, or other application without concern about losing their high-value tokens in the event of a problem.

Motivation


It may be desired to restrict approval in some applications. Restricted approval can prevent losses in cases where users do not audit the contracts they're approving. No standard API is supplied to manage scopes as this is implementation specific. Some implementations may opt to offer a fixed number of scopes, or assign a specific set of scopes to certain types. Other implementations may open up scope configuration to its users and offer methods to create scopes and assign IDs to them.

Specification


Scope Metadata JSON Schema


This schema allows for localization. {id} and {locale} should be replaced with the appropriate values by clients.


Localization

Metadata localization should be standardized to increase presentation uniformity across all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a localization attribute, its content may be used to provide localized values for fields that need it. The localization attribute should be a sub-object with three attributes: uri, default and locales. If the string {locale} exists in any URI, it MUST be replaced with the chosen locale by all client software.

Rationale


The initial design was proposed as an extension to ERC-1155: Discussion Thread - Comment 1. After some discussion: Comment 2 and suggestions by the community to implement this approval mechanism in an external contract Comment 3, it was decided that as an interface standard, this design would allow many different token standards such as ERC-721 and ERC-1155 to implement scoped approvals without forcing the system into all implementations of the tokens.

Metadata JSON

The Scope Metadata JSON Schema was added in order to support human-readable scope names and descriptions in more than one language.

References


Standards

Implementations

Articles & Discussions

Copyright


Copyright and related rights waived via CC0.