1. Look at https://github.com/Badger-Finance/ebtc/tree/main/packages/contracts/tests
2. Refactor/Adjust
3. Adjust according to SC changes as we progress thru eBTC
4. Model and plot

All these points can be separate tickets

This will allow us to run the same variant multiple times.
This can also be useful of running the same actions in sim vs on real forknet contracts to verify behavior

Depends on #50

ID-based troves is a pretty major interface change that touches a huge % of the tests.
A large chunk need to be rewritten to support.

We should get this done and use it as a base for adding any of the new features.

As per this comment, further integration tests can be developed. On hold until WP security review and merge of feature.

Log output of sim for export and visualization

no rush, it's just a parameter

Dependent on

• #90
• #51

depends on: #49

Summary

Evaluate the eBTC UI application stack for best development and maintenance experience. Initial analysis of the existing UI repository has been documented here.

Initial Application Stack

• React
• Ethers JS
• Jest

Web3 Provider Library

Investigate the trade offs on familiarity and ease of use / features between:

• Web3 React
• Wagmi

Initial cursory previews of the two options shows good documentation and potential ease of use for quick development to be leveraged by utilizing Wagmi. However, given the development team Web3 React may be more familiar.

However, it should be noted Wagmi contains several out of the box hooks to facilitate much of what was done manually using Web3 React and thus has the potential to reduce time to development of main features.

Contract Interactions

Investigate the trade offs on familiarity and ease of use / features between:

• Typechain
• Wagmi

Typechain has been the backbone for development in previous projects in conjunction with multicall providers from another package. The typing provided by the library is quite good and ensures mistakes or issues in development are caught early.

Wagmi has similar functionality as well as included batch call management and typing. It may be an option that encompasses all the requirements - however the practicality of its usage should be investigated. It is likely Wagmi may be the choice to fulfill both requirements.

It should be noted that this decision will likely have a very minor impact on the UI as a whole as the design of the application is such that eBTC will utilize an SDK with potentially a different set of tools. This decision should be made assuming niche, non SDK supported, contract interactions - if any come to mind.

Requirements

• Investigate the above open questions regarding the application stack
• Provide a short synopsis on the decision and reasoning

The UI will be broken due to some of our interface changes, and we're moving to a separate UI repo as per Jintao's doc.
So, we don't want UI-related test failures to stop CI from working

Depends on #25

Depends on #13

• badger
• defisaver
• instadapp

Help us define a fee share model that makes sense for them

Change the Chainlink and Tellor oracles to the appropriate BTC/ETH or ETH/BTC feeds along with any other necessary price feed checks and infrastructure.

take logger output from Log -> CSV -> Chart

• extend it to be able to export CSV and charts

standardize / figure out what to log and how

depends on #42

For example:

• Linting
• Slither

• Define initial specs of the Frontend (Plan to start from scratch? Adapt from Liquity? Stack?)
• Preliminary wire-frames
• Preliminary guidelines
• User stories
• Development preliminary timelines

We are confident we don't want origination fee.

Need to evaluate removing the code vs simply setting to 0.

I'd go for setting to zero unless it's a big saver.

Depends on #17 and #18