Open anilhelvaci opened 1 month ago
@anilhelvaci re: 1 - yes. both. EC should be able to create a new retail or institutional vault type of an existing collateral type
re: 2 - yes
re: 3 - no
Re: enabling institutional vaults first then retail - this works. There is more business value in delivering institutional vaults than retail vaults
Context
As a result of our analysis in #1 #2 #3, we have come to a point where we need guidance on some questions effecting the end product. This issue contains those questions and the context that surrounds them.
Open Questions
1. Is it possible to have more than one retail vault manager?
In other words, for a given and already accepted collateral type, is it safe to assume that all incoming new vault managers will be of type institutional or can EC choose to create a new retail vault manager?
I believe the answer to this question is most likely "yes". See #3
2. Can EC add new accounts to the whitelist for a particular vault manager?
Adding new accounts to an existing institutional vault manager can be done. However, it will (probably) go through EC so it will result having its own user flow. Do we want this?
3. Can EC remove accounts from the whitelist for a particular vault manager?
I am not sure how this can be done but I think this would make sense when we think about the possibility business relationships coming to an end with certain institutions. Should we work on solving this problem?
Splitting the work
When writing this section, we assume the answer to the question 1 above is "yes".
Currently all structure surrounding inter protocol assumes vault managers are indexed by their collateral type. This structure includes;
dapp-inter
FE@agoric/synthetic-chain
agoric-sdk
- SwingSet test toolsagoric-sdk
- Unit test tools ...and probably more stuff that I can't think of at the momentThis situation indicates that there's a considerable amount of effort that HAS to go into making sure we adjust all the effected parts are updated and works as expected. So we suggest we split the work into multiple iterations, see what each iteration includes below. Please note that all iteration will come with their e2e implementation. Meaning iteration one will have the FE changes relating to its features etc.
Iteration One: Enable only institutional vault managers first
The idea behind this iterations is to make sure we ship the intended features first (partially - retails not shipped yet at this point) and then focus on the complexity of enabling multiple retail vault managers. This way we can make sure we do most of the ground work for enabling multiple vault managers per one collateral type while avoiding the complexity that comes with ensuring our changes do not break rest of the system.
Sample FE flow for iteration one
Iteration Two: Enable retails vault managers
At this point we will already be solved the complexity of enabling multiple vault managers for a collateral type so we can focus on making sure we support all the tooling around inter protocol vaults across the
agoric-sdk
.