Update ERC-7425: Add missing info

ERCS/erc-7425.md

@@ -13,11 +13,15 @@ requires: 20, 4626
 
 ## Abstract
 
-A proposal for a tokenized reserve mechanism. The reserve allows an audit of on-chain actions of the owner. Using [ERC-4626](../EIPS/eip-4626.md), stakeholders can create shares to show support for actions in the reserve.
+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](./eip-4626.md), stakeholders can create shares to show support for actions in the contract.
 
 ## Motivation
 
-Tokenized reserves are an extension of tokenized vaults. The goal is to create a reserve similar to a real world reserve an entity has as a backup in case regular funds run low. In the real world, an entity will have to meet certain criteria before accessing reserve funds. In a decentralized environment, an entity can incorporate stakeholders into their criteria. This will help entities who participate in decentralized environments to be transparent with stakeholders.
+Tokenized vaults store [ERC-20](./eip-20.md) tokens that are represented by shares within vault contracts. Implementations can follow the [ERC-4626](./eip-4626.md) 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](./eip-4626.md), will provide stakeholders representation by depositing and withdrawing from the vault. The record of transactions for other [ERC-20](./eip-20.md) 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
 
@@ -26,36 +30,37 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 ### Definitions:
 
 	- owner: The creator of the reserve
-	- user: Stakeholders of specific proposals
-	- reserve: The tokenized reserve contract
-	- proposal: Occurs when the owner wants a withdrawal from contract
+	- user: Stakeholders participating in policies
+	- reserve: The assets held on the contract other than underlying token
+	- policies: Created by reserve owners to encourage stakeholder participation
 
 ### Constructor:
 
  	- name: ERC-20 token name
   	- ticker: ERC-20 ticker
    	- asset: ERC-4626 underlying ERC-20 address
-	- rAuth: Primary authorized user
+	- rAuth: Authorized user, for cases utilizing more than one owner/ limiting owner withdrawals
 	- rOwner: Owner of the Reserve
 
 ### Interface
 
 ```solidity
 // SPDX-License-Identifier: CC0-1.0
 
-pragma solidity ^0.8.0;
 import "./ERC4626.sol";
 
 interface TokenReserve is ERC4626{
+
 	/**
-	* @dev Event emitted after a new proposal is created
+	* @dev Event emitted after a new policy is created
 	*/
-	event proposals(
+	event policies(
 	    	address indexed token,
-	    	uint256 indexed proposalNum,
+	    	uint256 indexed policyNum,
 	    	uint256 indexed amount,
 		address recipient
 	);
+
 	/**
 	* @dev Event emitted after a new deposit is made by the owner
 	*/
@@ -65,114 +70,148 @@ interface TokenReserve is ERC4626{
 	    	uint256 indexed time,
 	    	uint256 count
 	);
+
 	/** 
-	* @dev Get time of a deposit made to reserve with depositReserve()
-	* @param count Number matching deposit
+	* @dev Get time a deposit/withdrawal was made by the owner
+	* @param count Number for deposit count
 	* @return block.timestamp format
 	*/
-	function depositTime(uint256 count) external view returns (uint256);
+	function ownerTime(uint256 count) external view returns (uint256)
+
 	/** 
-	* @dev Get amount deposited to reserve with depositReserve() 
-	* @param count Number of deposit
-	* @return uint256 number of any asset that were deposited
+	* @dev Get amount deposited to reserve by owner
+	* @param count Number for deposit count
+	* @param policy The policy number to deposit to
+	* @return uint256 Amount of an asset that was deposited
 	*/
-	function ownerDeposit(uint256 count) external view returns(uint256);
+	function ownerDeposit(uint256 count, uint256 policy) external view returns(uint256)
+
 	/**
-	* @dev Token type deposited to reserve with depositReserve()
-	* - MUST be an address of ERC20 token
-	* @param count Number of deposit
+	* @dev Amount withdrawn for a opened policy by the owner
+	* @param policy The policy number
+	* @return Amount of ERC20
 	*/
-	function tokenDeposit(uint256 count) external view returns(address);
+	function ownerWithdrawals(uint256 policy) external view returns(uint256)
+
 	/**
-	* @dev Amount deposited for shares of proposal by the user
-	* - MUST be an ERC20 address
-	* @param user address of user
-	* @param proposal number of the proposal the user deposited
+	* @dev Token type deposited to reserve by owner
+	* - MUST be an address of ERC20 token
+	* @param count Number of deposit count
+	* @return address Address of ERC20 token
 	*/
-	function userDeposit(address user, uint256 proposal) external view returns(uint256);
+	function tokenDeposit(uint256 count) external view returns(address)
+
 	/**
-	* @dev Token used for given proposal
-	* - MUST be ERC20 address
-	* @param proposal number for requested token
-	* @return token address
+	* @dev Amount deposited to a policy for shares
+	* - MUST be an ERC20 token
+	* @param user Address of user
+	* @param policy The policy number the user deposited to
+	* @return uint256 Amount of ERC20 deposited
 	*/
-	function proposalToken(uint256 proposal) external view returns(address);
+	function userDeposit(address user, uint256 policy) external view returns(uint256)
+
 	/**
-	* @dev Amount withdrawn for given opened proposal
-	*/
-	function proposalWithdrew(uint256 proposal) external view returns(uint256);
+    	* @dev Amount withdrawn from a policy by the user
+	* @param user The address of user
+    	* @param policy The policy number for user withdrawal
+	* @param uint256 Amount of ERC20
+    	*/
+    	function userWithdrawals(address user, uint256 policy) public view returns(uint256)
+
 	/**
-	* @dev Amount received for given closed proposal
+	* @dev Token type withdrawn for an opened policy by the owner
+	* - MUST be ERC20 address
+	* @param policy The policy number for the token used
+	* @return Token ERC20 address
 	*/
-	function proposalDeposited(uint256 proposal) external view returns(uint256);
+	function policyToken(uint256 policy) external view returns(address)
+
 	/**
-	* @dev Make a deposit to a proposal creating new shares with deposit function from ERC-4626
-	* - MUST be opened proposal
-	* - MUST NOT be opened proposal that was closed
-	* NOTE: using the deposit() will cause assets to not be accounted for in a proposal
+	* @dev Make a deposit to a policy creating new shares using deposit function from ERC4626
+	* - MUST be opened policy
+	* - MUST NOT be opened policy that was closed
+	* - SHOULD be only method to deposit to ERC4626 vault
+	* NOTE: using the deposit() will cause assets to not be accounted for in a policy (see Security Considerations section)
 	* @param assets Amount being deposited
 	* @param receiver Address of depositor
-	* @param proposal Number associated proposal
+	* @param policy The number associated policy
+	* @return Amount of shares minted 
 	*/
-	function proposalDeposit(uint256 assets, address receiver, uint256 proposal) external virtual returns(uint256);
+	function policyDeposit(uint256 assets, address receiver, uint256 policy) external virtual returns(uint256)
+
 	/**
-	* @dev Burn shares, receive 1 to 1 value of shares
-	* - MUST have closed proposalNumber
+	* @dev Burn shares, receive 1 to 1 value of shares using withdraw function from ERC4626
 	* - MUST have userDeposit greater than or equal to userWithdrawal
+	* - SHOULD be only method for withdrawing from ERC4626 vault
 	* @param assets Amount being deposited
 	* @param receiver Address of receiver
 	* @param owner Address of token owner
-	* @param proposal Number associated proposal
+	* @param policy Number associated policy
+	* @return Amount of the asset
 	*/
-	function proposalWithdraw(uint256 assets, address receiver, address owner, uint256 proposal)external virtual returns(uint256);
+	function withdrawPolicy(uint256 assets, address receiver, address owner, uint256 policy)external virtual returns(uint256)
+
 	/**
-	* @dev Issue new proposal
-	* - MUST create new proposal number
+	* @dev Issue new policy
+	* - MUST create new policy number
 	* - MUST account for amount withdrawn
-	* - MUST emit proposals event
+	* - MUST be only method to withdraw ERC20 tokens (excluding underlying ERC4626 token)
+	* - MUST be owner
+	* - SHOULD emit policies event
 	* @param token Address of ERC-20 token
 	* @param amount Token amount being withdrawn
 	* @param receiver Address of token recipient
+	* @return The policy number
 	*/
-	function proposalOpen(address token, uint256 amount, address receiver) external virtual returns (uint256);
+	function openPolicy(address token, uint256 amount, address receiver) external virtual returns (uint256)
+
 	/**
-	* @dev Make deposit and/or choose to close an opened proposal
+	* @dev Make a deposit and/or close an opened policy
+	* - MUST be owner
 	* - MUST account for amount received
-	* - MUST be a proposal that is less than or equal to current proposal
-	* - MUST emit proposals event
+	* - SHOULD emit policies event
 	* @param token Address of ERC-20 token
-	* @param proposal Number of desired proposal
+	* @param policy Number of the desired policy
 	* @param amount Token amount being deposited to the reserve
-	* @param close Choose to close the proposal
+	* @param close Choose to close the policy
+	* @return True for closed policy 
 	*/
-	function proposalClose(address token, uint256 proposal, uint256 amount, bool close) external virtual returns (bool);
+	function closePolicy(address token, uint256 policy, uint256 amount, bool close) external virtual returns (bool)
+
 	/**
-	* @dev Optional accounting for tokens deposited by owner
+	* @dev Accounting for tokens deposited by owner
 	* - MUST be reserve owner
-	* - MUST emit depositR event
-	* NOTE: No shares are issued, funds can not be redeemed. Only withdrawn from proposalOpen
-	* @param token Address of ERC-20 token
-	* @param sender Address of where tokens from
-	* @param amount Token amount being deposited
+	* - SHOULD emit depositR event
+	* NOTE: No shares are issued, funds can not be redeemed and no policy is opened. Withdrawnal made with openPolicy function.
+	* @param token Address of ERC-20 token being deposited
+	* @param sender Address of token sender
+	* @param amount Token amount being deposited 
 	*/
-	function depositReserve(address token, address sender, uint256 amount) external virtual;
+	function depositReserve(address token, address sender, uint256 amount) external virtual
 }
 
 ```
 
 ## Rationale
 
-This proposal is designed to be a basic implementation of a reserve fund interface. Other non specified conditions should be addressed on a case by case basis. Each reserve uses [ERC-20](../EIPS/eip-20.md) standard for shares, and [ERC-4626](../EIPS/eip-4626.md) for the creation of shares. The reserve token can be the underlying token in [ERC-4626](../EIPS/eip-4626.md) or the shares that are created when the underlying token is deposited in the vault. 
-[ERC-4626](../EIPS/eip-4626.md) is implemented to the reserve to account for user participation. There needs to be a representation for users participating in a proposal within a reserve. With vaults, the implementor could decide how to treat participation based on users entering the vault. For example, a user could be forced not to use the same tokens in multiple proposals to allow shares to be created fairly. Once the underlying token is deposited into the vault for an open proposal those tokens could not be accessible until the proposal is closed. 
-It is not explicitly enforced that deposited tokens that create shares cannot be withdrawn by the owner of the reserve. On a case by case basis there can be implementions to ensure those tokens are accounted for if needed.  
+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](./eip-20.md) standard for shares, and [ERC-4626](./eip-4626.md) for the creation of shares. The reserve token SHOULD be considered as either the underlying `asset` for the [ERC-4626](./eip-4626.md) vault or the shares that are created when depositing to the vault. 
+[ERC-4626](./eip-4626.md) 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](../EIPS/eip-20.md) and [ERC-4626](../EIPS/eip-4626.md).
+Tokenized reserves are made compatible with [ERC-20](./eip-20.md) and [ERC-4626](./eip-4626.md).
 
 ## Security Considerations
 
-Needs discussion.
+Tokenized reserves share the same security considerations as [ERC-20](./eip-20.md) and [ERC-4626](./eip-4626.md).
+
+1. 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.
 
 ## Copyright