feature: tracking cross chain loans

[FidelVe]

Design document for cross chain collateral feature

Introduction

This document describes the design of adding support for tracking cross chain collateral.

Technical Overview

For tracking cross chain collateral, we need the user to provide the wallet (and chain) they want to track.

Once we have that information we can call the getAccountPositions method on the Balanced DEX contract by providing the cross chain address like in the following example:

Request:

curl -X POST --data '{"jsonrpc":"2.0","method":"icx_call","id":604,"params":{"to":"cx66d4d90f5f113eba575bf793570135f9b10cece1","dataType":"call", "data":{"method":"getAccountPositions", "params": {"_owner": "injective-1/inj1u465vcdvdz9w2vn9znsnxlq208wcdcgxm5kxqz"}}}}' https://ctz.solidwallet.io/api/v3 | jq

Response:

{
  "jsonrpc": "2.0",
  "result": {
    "address": "injective-1/inj1u465vcdvdz9w2vn9znsnxlq208wcdcgxm5kxqz",
    "assets": {
      "bnUSD": "0x0",
      "sICX": "0x0"
    },
    "collateral": "0x0",
    "created": "0x620afae99e014",
    "holdings": {
      "INJ": {
        "INJ": "0x1b93f3df11a8000",
        "bnUSD": "0x14b53dca9e82f8b8"
      },
      ...
    },
    "pos_id": "0x1b80",
    "ratio": "0x0",
    "standing": "Zero",
    "standings": {
      "INJ": {
        "collateral": "0x1061d4f3b5e3c5afb",
        "collateral_in_USD": "0x26a971725b56fb80",
        "ratio": "0x19e8eefc01e1a894",
        "standing": "Mining",
        "total_debt": "0x8c649e96189efe5d",
        "total_debt_in_USD": "0x14b53dca9e82f8b8"
      },
      ...
    },
    "total_debt": "0x0"
  },
  "id": 604
}

holdings.inj.bnusd is equal to standings.inj.total_debt_in_USD which is the amount of loan in USD

standings.collateral is the amount of collateral in ICX and standings.total_debt is the amount of loan in ICX.

Discovery and Design exploration

Before implementing the feature the following questions need to be answered:

• are we moving from a "season" based design to a "continuous" design? (i.e. xpgo dashboard will run continuosly instead of running by seasons as we are doing now), This has a big impact on the schema and database design. Latest discussions on the subject are leaning towards a continuous design.

• how do we handle the case where the user has multiple wallets on the same chain? (e.g multiple wallet on BSC chain) Do we allow the user to track multiple wallets on the same chain?

• Can the user remove a wallet from tracking?

• once a wallet is added from which point in time do we start tracking the wallet? (e.g. from the moment the wallet is added or from the moment the wallet has a position on the DEX)

@R0bi7 @FezBox @DavidFBD please provide your input in these questions

[R0bi7]

In terms of overall design I would say the following:

1. I would keep season based approach because it enables us to efficiently track from start to end date. Continous approach introduces a lot of data aggregation and querying, in majority for "obsolete/inactive" users. On the other side, I would introduce main page through which users can navigate to seasons. Also season based approach keep things exciting.
2. I would introduce "continous" tasks like for example linking your socials or registering to the first season task.
3. Initially I would alow only linking of single wallet in order to reduce workscope and complexity, but should consider multiple wallet linking feature for the future.
4. I am not sure why would user remove wallet from tracking, but I see no reason to disallow it.
5. I would start tracking from the moment wallet is added (accounting current state).

[FezBox]

I would like to see one instance that stays permanent.

We should be rolling all different instant users once done to the permanent instant.

Otherwise we are paying users and then saying goodbye. Feels like a waste.

Overall goal, repetitive daily tasks.

[FidelVe]

implemented here

https://github.com/icon-community/xp-icon-community-backend/pull/23