ERC-7425: Tokenized Reserve

Transparent reserve fund on-chain with stakeholder participation.

Metadata

Status: DraftStandards Track: ERCCreated: 2023-06-30

Authors

Jimmy Debe (@jimstir)

Requires

EIP-20, EIP-4626

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This specification explains a tokenized reserve mechanism standard. Current smart contracts record transactions and are made public. The reserve will implement added functionality allowing stakeholders proactively to audit a contract. Using ERC-4626, stakeholders can create shares to show support for actions in the contract.

Motivation

Tokenized vaults store ERC-20 tokens that are represented by shares within vault contracts. Implementations can follow the ERC-4626 standard to provide basic functionality for depositing, withdrawing, and reading balances for a vault. As tokenization becomes increasingly popular, applications should use a form of tokenized vaults to store assets and allow all parties to track performance.

This specification introduces a standard for an on-chain reserve that uses tokenized vaults to represent reserve stakeholders. Core functionality, which is an extension of ERC-4626, will provide stakeholders representation by depositing and withdrawing from the vault. The record of transactions for other ERC-20 assets should be easily accessible to any party for auditing.

In a tokenized reserve, stakeholders are represented by minting shares from the vault. The goal is to create a reserve similar to a real-world reserve fund used as a contingency for an entity. In most cases, an entity would follow criteria like running low on regular funds, to utilize the reserve fund. In a decentralized environment, an entity should incorporate stakeholders as criteria. Assets associated with the reserve as well as its origin will vary in decentralized environments, so transparent auditing is needed.

Specification

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.

Definitions:

Constructor:

Interface

Rationale

This proposed standard is designed to be a core implementation of a tokenized reserve interface. Other non-specified conditions should be addressed on a case-by-case basis. Each reserve uses ERC-20 standard for shares, and ERC-4626 for the creation of shares. The reserve token SHOULD be considered as either the underlying asset for the ERC-4626 vault or the shares that are created when depositing to the vault. ERC-4626 is used to create a transparent creation of stakeholders of the reserve. There MUST be a representation of interested parties in the reserve. The implementer can decide how to treat representation based on users entering and leaving the vault. For example, a user could be forced not to use the same tokens in multiple policies to allow shares to be distributed fairly.

Backwards Compatibility

Tokenized reserves are made compatible with ERC-20 and ERC-4626.

Security Considerations

Tokenized reserves share the same security considerations as ERC-20 and ERC-4626.

Assests withdrawn by owner are not secured by vaults.

Stakeholders SHOULD be aware that the underlying asset can be withdrawn by the owner with no restrictions or authorizing party, like requiring an rAuth. Depending on the authorizing implementation, asset may still be withdrawn by the owner.

A RECOMMENDED implementation:

The openPolicy MUST explictly restrict the transfer of the underlying asset.
If the underlying asset is apart of the reserve and not the vault, the reserve MUST provide a method to avoid user asset loss.