---
# System prepended metadata

title: eBTC UI Considerations

---

# eBTC UI Considerations

Application Stack

- Docker
- React
- Theme UI
- Web3 React
- Multiple Liquity Node Packages
- Apollo GQL
- TheGraph

## Observations

- Liquity frontend utilizes a lot of custom code for interaction. While this is well documented, there are tools such as typechain that achieve the same goal more cleanly.
- Familiar state management tools are not utilized. State management is largely separate from the app code itself in a separate package.
- State management similarly is its own package.
- Some code in dependencies is quite opaque around, objectively it accomplishes exactly what the Badger SDK does for vaults
- Any changes to support the UI would require the fork and changes across multiple repositories and additional learnings of new tooling

## Gap Analysis

- Trivial changes are removals
    - Bonds
    - Stability Pool
    - Staking
- Technical Documentation / Audits
- Blog / Socials
- Trove Interaction UX
    - Support interest rate displays
    - Call to action for open trove
- Protocol Status Page (Health)

The Liquity UI as a base UI by virtue of eBTC has the majority of what we require. Certain aspects can be removed and some aspects need alterations to improve user or support non existent features in Liquity. 

The biggest gap is creating a protocol status page, however the app has this in a compressed view already.

## Suggestion

Due to the intertwined nature of the many packages it is probably not recommended to fork the original Liquity app. It is a good base visually to build off of for inspiration, however, there are newer tools since the inception of Liquity that can be used to better suit our development. 

It will be beneficial to the implementing team to familiarize themselves with the system, and should - likely - ultimately be a faster development cycle than simply forking the app due to the relatively simple nature of the application. 

The patterns and documentation style utilized in the liquity front end and supporting libraries should be followed as inspiration for quality of code when working on products meant for a finalized release and distribution. 


## Considerations

Certain aspects of user experience that might be worth exploring:

- User transactions history
- Protocol historic analytics
- User trove balance history

These are all 'nice to haves' and present technical challenge and opportunity to provide UX past the bare bones required for a functional app. 

These are also things that would likely be quick to implement in Dune as a temporary stop gap before any custom visual implementation if desired.

eBTC front end may require alternative hosting solutions if the deployment should be done via IPFS or independent hosts. Products such as Fleek may make this easy, although it will incur additional Opex. Worth investigating alternatives or in house upload and (paid) pinning service for IPFS as an example.

A farming or staking page will also possibly need to be considered if there are any plans for liquidity incentivization. 
