# RIDs vs Minimal Implementation
## Questions
Should claimable shares be reflected in totalSupply? yes if the shares are "participating"

Should vaults which return zero for any request ALWAYS return 0 for ALL time? YES

Should hooks be forced to revert on rid=0? Where? No

Can rid=0 be transferrable? Less restrictive if possible

How to handle underlying ERC-4626 methods vs claim methods? Optional but defined for how to use.

## Properties of an RID
RID = 0 is reserved for implementations which do not support transferability and are purely account based.

The below assumes RIDs != 0.

RIDs are not necessarily unique, there may be multiple owners associated with a single RID.

Deposit Requests associated with RIDs:
* are discriminated by both the RID and owner (except where RID = 0 in which case owner is the only discriminator)
* MUST be fungible with other requests of the same RID
* MUST Transition from Pending to Claimable at the same pro rata rate as any other deposit with the same rid shares
* MUST reveive the same conversion rate upon Claim as any other deposit with the same RID
* different RIDs MAY transition to Claimable at different exchange rates and times with no ordering or correlation enforced in any way

## Interfaces
| RIDs | Minimal |
| -------- | -------- |
| `requestDeposit(uint256 assets, address receiver, address sender, bytes calldata data) external returns (uint256 rid);` | `requestDeposit(uint256 assets, address operator) external;` |
| `pendingDepositRequest(uint256 rid, address owner) external view returns (uint256 pendingAssets);` | `pendingDepositRequest(address operator) external view returns (uint256 assets);` |
| `claimDeposit(uint256 rid, address receiver, address owner) external returns (uint256 shares)`| None, alias for "deposit max" in some cases |
|`function claimableDepositRequest(uint256 rid, address owner) external view returns (uint256 claimableAssets);` | None, alias for maxDeposit in some cases |

## Features Unlocked by RID model
Nonzero RIDs may be fully ERC-721 OR ERC-1155 compatible:
- Unlocks additional programmability such as smart contract ownership, transferrable ownership, using Requests as collateral and creating secondary market liquidity for Requests
- opportunity for a canonical ecosystem-wide wrapper NFT and semi-FT contract

The calldata parameter also allows for relayers to operate Requests AND Claims on behalf of a user via the almost-final Endorsement standard [ERC-5453](https://ethereum-magicians.org/t/erc-5453-endorsement-standard/10355/11)

## Opportunity Cost of RID model relative to Minimal model
- The base case RID=0 is identical to the Minimal model with requests fully discriminated by address
- interface fragmentation
- introduces a claimableRequest boilerplate alias for maxDeposit/Redeem
- introduces a claim boilerplate alias for depositMax/redeemMax
- adds some implementation complexity around the data argument or the actual request, but otherwise takes the same parameters

## (Draft Idea) Revisiting Request Cancellation
Complex enough to still be added to another ERC extension

Properties of a cancellation:
- asynchronous, effectively a different class of request
- may not fully undo the current pending amount
- of the amount that is cancellable, must be all-or nothing, no partial cancellation fulfillment
- cancellation readiness is signalled by pendingDeposit = 0
- add a "claimCancelDeposit" function who must become callable once pendingDeposit = 0

- how to define the interaction of a cancellation with new requests? Does it matter whether it is in the same RID or not? Idea is that new deposit requests MUST revert if they would receive the same RID as a pending cancellation