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

Important !

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 tools
agoric-sdk - Unit test tools ...and probably more stuff that I can't think of at the moment

This 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

sequenceDiagram
    participant user as institutionalUser
    participant int as dapp-inter
    participant vs as vStorage
    participant vf as vaultFactory

    user ->> int: connect keplr
    int ->> vs: query = list of institutional managers and the white-list
    vs -->> int: [manager0, manager1]
    Note over int, int: find which managers the user is whitelisted 
    int ->> int: display retail AND institutional managers
    int ->> int: display all vaults belonging to the user
    int -->> user: page loaded
    user ->> int: Click "open vault" for institutional manager
    int ->> int: calculate prevOfferId 
    Note over int,int: Inst users can send offers using continuing invitations
    Note over int,int: e.g {address}-manager-{managerIndex}-{?iteration}
    int ->> vf: Send vault offer
    Note over int, vf: offer = {invitationSpec = {source = continuing, prevOfferId, makeVaultInvitation}}
    vf -->> int: success

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.

anilhelvaci / agoric-sdk

Analysis Milestone: 1 #4