This document describes a tokenized reserve mechanism. This includes functionality that allow stakeholders to participate in goverance stategies wthin the reserve.
Tokenized vaults store ERC-20 tokens that are represented by shares within vault smart 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, there is a need for standard for how these vaults holding tokenized assets are audited. Applications could use tokenized vaults to store assets while allowing other interseted parties to purpose, restrict and track the events of the vault.
This specification introduces a standard for an on-chain reserve that uses utilizes active stakeholders. Core functionality, which is an extension of ERC-4626, will allow stakehoolder representation in the form of depositing and withdrawing. The record of asset activity, represented by the underlying ERC-20 token, wiil be easily accessible by party.
In a tokenized reserve, stakeholders mint shares from the vault when depositing the underlying token. The goal is to create a reserve similar to a real-world reserve fund used as a contingency for an entity. In the real world an entity agrees on some condition that would justify the use of funds, like when running low on regular funds. In a decentralized environment, an entity could incorporate stakeholders and replicate this mechanism. Assets associated with the reserve, including its origin and destination will vary in decentralized environments, so transparent auditing is needed.
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.
The reserve will account for activity by all participants.
Some criteria created by the owner is REQUIRED to onboard new stakeholders with the underlying asset of the ERC-4626 vault.
Each new proposal is recorded and its information SHOULD be retrievable by a call function.
The REQUIRED information includes the amount and address for a proposal.
A proposal MUST be open before the transfer of any tokens out of the reserve.
A proposalOpen MAY be requested by stakeholders or the owner.
Once opened a stakeholder MUST use proposalDeposit to represent support for the proposal.
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 underlying token MAY be considered to be termed as the reserve token and share token is minted by the ERC-4626 vault. The ERC-4626 standard is used to create shares that represent stakeholder paticitapting in a proposal, thus within 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 stakeholder could not ba able to use the same reserve token for multiple proposals, which could allow shares to be distributed fairly.
Tokenized reserves are made compatible with ERC-20 and ERC-4626.
Tokenized reserves share the same security considerations as ERC-20 and ERC-4626. Including:
asset stored on a contract can be withdrawn by the owner with no restrictions or authorizing party, like requiring an rAuth. Depending on the authorizing implementation, the asset could still be withdrawn by the owner.A RECOMMENDED implementation:
openProposal MUST explictly restrict the transfer of the underlying asset.asset loss.Copyright and related rights waived via CC0.