FundingRecord extension

[bigscoop]

Hi @timmolter

Somehow I don't understand how one should implement getting of different transactions in exchanges.

There are at least 2 types of them:

• Movements:

  • External deposit
  • External withdrawal
  • Internal deposit (transfer between accounts on the same exchange)
  • Internal withdrawal (transfer between accounts on the same exchange)
  • Sub-account withdrawal
  • Sub-account deposit
  • Wallet transfer (transfer within same account from one wallet type to another, e.g. spot -> margin)
  • etc

• Ledger Changes:

  • Airdrop
  • Trading fees
  • Staking rewards
  • Funding interest
  • Realised profit
  • Realised loss
  • etc

Some of the types are implemented in FundingRecord, some not. Imho, there are several options:

1. We leave everything as FundingRecord and just add more types. All movements can be queried by calling AccountService#getFundingHistory().
   That would mean that new fields will be added to FundingRecord - e.g. sender, receiver for movements (will be always null however for ledger changes).
   Also, that could overload the AccountService#getFundingHistory() with logic, cause some exchanges deliver this records in own endpoints (deposits, withdrawals, transfers), so potentially one call to AccountService#getFundingHistory() can lead to several REST-calls to exchange.

2. We split the types logically into movements and ledger changes. E.g. add new dto for Ledger Changes and leave FundingRecord exclusively for movements.
   That can potentially break some existing logic, cause there are non-movement types implemented already in FundingRecord (e.g. REALISED_LOSS, REALISED_PROFIT)

3. We split the types even more fine-grained, e.g. deposits, withdrawals, sub-account transfers, transfers, wallet transfers.
   That doesn't break existing logic, but rather adds new, partly duplicating existing functionality.
   Also will need plenty of new methods in general interfaces, and they'll remain unimplemented for a while.

What do you think?