Minimal DB Schema on Hasura

[djudjuu]

From https://github.com/ArboreumDev/high-level-planning/issues/11

DB Schema:

users:

1. id
2. type (borrower, guarantor, lender) (enum)
3. User's financial parameters:
4. Max exposure (number)
5. Min Rate of interest (number)
6. role (borrower, lender)

balances

1. owner_id
2. liquid_cash: how much each agent has ready for future investments
3. liquid_guarantor: how much is put aside (in escrow to be used in order to guarantee)

central_risk

data provided from the central source on the individual default risk

1. user_id
2. risk_params
3. last_updated

recommendation_risk

each agent keeps a list of recommendation risks of their neighbours

1. agent_id
2. neighbor_id
3. recommendation_risk [alpha, beta]
4. last_updated

edges

weight

1. head (type id)
2. tail (type id)
3. weight (credit extended from head to tail, type int)

loan_requests

1. borrower_id
2. request_id
3. amount
4. status (processing, awaiting_lender_confirmation, confirmed, rejected)
5. ai_artifacts JSON

loans

1. loan_id
2. interest
3. status (open, success, default)
4. created_at

loan_participants

1. loan_id
2. lender_id
3. lender_amount

payables

1. loan_id
2. payable_type enum ['guarantee', lent, `cash_guarantee']
3. pay_from_user_id
4. pay_to_user_id
5. amount
6. repaid
7. default

[djudjuu]

with this we should be able to

• aquire users
• connect users with each other and build network accordingly
• have users topup/remove cash from and to corpus & from and to guarantor escrow
• create loan-requests [1]
• generate input for the network-risk module (rec_risks & open payments)
• populate the dashboard with 'idle, invested, ready4guarantee, guaranteeing' piechart
• repay loans (or default) and settle balances accordingly
• even have users act as guarantors (keep both cash & corpus investments as escrow)
• represent the corpus model

[1] with different interest rates (even different ones for lenders & guarantors, although that would be represented only indirectly)

[djudjuu]

e.g.

this is fairly complex already, but at least it allows to create and settle loans with all outcomes. the guarantor only required minimal extra complexity, so I put that in as well. lots of the logic is in the payables table, which kind of keeps track where the individual money of all people went. e.g. by filtering for all Query1: payables where status=open & p_type=lent -> we would get the corpus

query2: payables where status=open & p_type=share_guarantee & payToUser=lender_A

-> we would get all the shares in the corpus that lender_A has uses as guarantee

query3: payables where status=open & p_type=cash_guarantee & payToUser=lender_A -> would be all the cash that from lender_A that has been moved to escrow to guarantee the loan and will be returned to them if the loan is paid back