Community Update #2
Upgradability Refactor
As we began thinking about how hardforks are currently managed within Mina and how verification keys of contracts are bricked, requiring the owner of the contracts to update them though a signature, we realised that our current design wouldn’t work.
As our user vaults were their own zkapps, we would have been dependent on users upgrading their VKs in order to interact with those vaults. The system requires autonomous and timely liquidations to ensure peg stability, which means that if users didn’t upgrade then it could catastrophic to the zkusd protocol, as their vaults could become undercollateralised, without the ability to liquidate them.
Therefore, we redesigned the state management, effectively absorbing all contract logic into our engine contract while still utilising the users token accounts for tracking the state, and locking down any interaction with the token account through our engine account only.
UI
The UI is making good progress, hopefully will have this done relatively soon and will be able to move on to thinking about a very early devnet deployment to allow for alpha testing.
Integration Tests
We are still working on integration testing, most of the abstractions necessary for parallel transaction proving and processing have been completed which will pave the way for an extensive test suite. We are hoping to make significant progress on this over the next couple of weeks.
Part of the integration tests have been developing a financial risk modelling tool that helps us understand how the protocol will hold up in times of extreme price drop events across a number of different risk parameters. Such as scale of the system and how aggressive our users positions are. This has been enlightening, and there is still a lot of work to look at how the protocol recovers in the event of bad debt. We will probably spend some time on this towards the end of feb.