summary

In this issue I will try to document my implementation process of the needed changes for the DFIP to restart the dToken system

video summary of implemented logic:

I summarized all the implemented logic with additional reasoning in this video:

https://youtu.be/MdlbdXfkuY8

tasks to be done

setup

[x] create pull request
[x] setup IDE (VS Code and prepare compiler locally)
[x] write test

implement

[x] add ProcessTokenLock to dfi code on fork block
[x] add DB entries and access methods for locked Token (ByTokenLockKey, TokenLockUserKey, TokenLockUserValue)
[x] add gov attribute for release ratio (read-only)? Is there a better way to have this?
[x] add Smart_contract address for TokenLock

Loan payback

[x] extract LoanPayback logic into method to reuse in ForceLoanPayback
[x] implement forceLoanpayback: unloop with PaybackWithCollateral
[x] ForceLoanPayback: use balances to pay back loans
[x] ForceLoanPayback: use DUSD collateral directly (burn DUSD for loan)
[x] ForceLoanPayback: swap other crypto collateral to DUSD, the use DUSD for payback. direct pools(How to decide path?! who to swap first? all at once and everyone gets average?)
[x] ForceLoanPayback: swap other crypto collateral to DUSD, the use DUSD for payback. composite swaps

refund futureswaps and cancel auctions

[x] refund all pending FutureSwaps (before payback)
[x] cancel all pending auctions (we force liquidate all)

create new tokens and lock

[x] recreate all loan tokens and pools (correct ascend and descend, add "/locked" to old token)
[x] rename DUSD -> USDD
[x] convert DUSD collateral, loanToken balances and pool reserves
[x] lock USDD collateral
[x] lock LoanToken balances
[x] lock pool reserves
[ ] ? update USDD with new oracle "USDD/USD" ?

new rpc calls

[x] create rpc call to get locked funds per address
[x] create tx to release tranche (parameter ratioToRelease)

continuous handling

[x] TD of old token should lock
[x] dToken split after lock should split balances of lock too
[x] prevent upgradeToken calls on old loantokens (otherwise it bypasses the lock)

finish

[ ] speed checks
[ ] add testcases and scenarios

fixes

[ ] EVM block hash not matching
[x] amount minted misses collateral values (was not considered in current token-split code)
[ ] check if amount minted is correctly handling EVM balances, looks like its missing it too (already production code)

notes from implementation

for payback loans: if not enough assets in account, first use DUSD from collateral directly (burn DUSD to payback loan value, no penalty)
for payback loans if not enough DUSD in collateral: swap other collateral to DUSD (direct pools first, then composites) and burn the DUSD for the loan. swapping happens per coin, all collaterals together so each vault gets the same price.

pseudo code from DFIP definition

On activationblock:

for all vaults:
  payback DUSD loans with collateral
  payback remaining loans with funds from address
  payback remaining loans by swapping collateral (first DUSD, then other collateral)

convert all loanTokens to new version (like stocksplit, but with no change in price or amount, must also affect the DUSD in collateral), new DUSD is called USDD

create native SC to lock funds in tranches, SC knows funds per address
SC keeps track of release-ratio, starting with 10%
initially 100 tranches (with 10% initial ratio, thats 0.9% per tranche)

for all LM positions in dToken-USDD pools:
  remove 90% of position and lock resulting funds directly into the SC

for all LM positions in USDD-DFI, USDC-USDD, USDT-USDD, EUROC-USDD, XCHF-USDD:
  remove 90% of position, lock resulting USDD directly into the SC, credit other resulting asset to owner

for all vaults:
  withdraw 90% of USDD collateral into SC (for vault owner address)

for all loantoken balances (=dTokens and USDD):
  lock 90% of balances into SC

extend Transferdomain:

any transfer EVM->DVM of old dToken or DUSD results in:
  SC.releaseRatio in new dToken/USDD is credited to targetaddress
  1-SC.releaseRatio in new dToken/USDD is locked in SC for targetaddress

extend stocksplit logic to update SC too (so future dToken splits are reflected in the SC)
implement SC-releaseTranche-tx (only allowed by foundation members):

on releaseTrancheTx:
  for all entries in SC:
     credit according tranche part of funds to address
     update SC.releaseratio accordingly

parameters to update after activation:

//deactivate DUSD loops:
"v0/vaults/dusd-vault/enabled": "false",

//remove old stab fee:
"v0/poolpairs/17/token_a_fee_pct": "0",
"v0/poolpairs/101/token_b_fee_pct": "0",
"v0/poolpairs/102/token_b_fee_pct": "0",
"v0/poolpairs/218/token_b_fee_pct": "0",
"v0/poolpairs/236/token_b_fee_pct": "0",

//activate new system-wide USDD fee

"v0/token/<usdd_id>/dex_in_fee_pct": "0.05",
"v0/token/<usdd_id>/dex_out_fee_pct": "0.05",

learnings

need to be careful with forced swaps of collateral. specially with dTokens with low liquidity-> likely necessary to use payback with DUSD

kuegi / ain

Implementing the dToken restart #9