Hifi Improvement Proposal (HIP) 1

Proposals
1

Note: There are no Requirements and KPIs sections in this proposal, contradicting the guide we previously provided to the community. The reason is simple: we don’t ask for funding and have no other requirements, and it’s hard to have KPIs due to the nature of this HIP.

Summary (TL;DR)

The first HIP introduces several technical improvements to enhance the user experience, software updates to stay updated regarding the package dependencies Hifi v1 relies on, and a new license to protect us from unauthorized forks.

Background

Hifi v1 has been running smoothly on mainnet for a few months now, and this has given us the necessary time to slightly change the architecture of the protocol, and iterate on the user experience.

This proposal is the result of these iterations.

Problem

There aren’t any real problems with the current version of the protocol, but there are quite a few things we could iterate on and improve.

A low-severity bug was recently found in the protocol, a contract which is currently upgradeable doesn’t need to be and the user experience could be improved regarding the vault logic as well as the transactions when interacting with the protocol.

The community has also mentioned at several occasions that the fully open-source nature of the codebase wasn’t necessarily appreciated due to the possibility of another project copying our code.

Solution

What follows are the key elements of our proposal.

Make Fintroller non-upgradable

When we wrote the very first version of the protocol, we were unsure whether the Fintroller will end up holding users’ money as well, on top of the deposits made in the BalanceSheet.

To act precautionarily, we made it upgradeable. But now it’s clear that the Fintroller is not holding any value - it’s just a permissions controller. If there’s a bug in it, we can just redeploy a new version and reset the permissions to the original values.

Finally, and most importantly, it’s just much easier to maintain the Fintroller as a non-upgradeable contract because it contains many structs, and structs cannot be edited when upgrading.

Fix low-severity bug in Repay Borrow event

A low-severity bug was recently found by one of our engineers in the Hifi v1 protocol and this release brings a fix for it. The bug is low-severity and doesn’t impact users’ holdings. The above linked GitHub issue gives more context, but the bug is simply that two function parameters were in the wrong order.

Rearchitect underlying backed hTokens

This logic has been removed from the balance sheet and placed in the hToken implementation. Depositing underlying in the hTokens makes for a better UX for end users and not creating underlying-backed vaults solves an issue related to volatile cryptos like WBTC not being usable as “underlying” for hTokens.

Update the Software License

We propose to change the current license (LGPL) to the Business Source License 1.1 (BUSL-1.1) which restricts unauthorized commercialization of our codebase until June 1 2024 after which the license will be changed to the GNU General Public License v3.0 (GPL) or a later version of it.

This will prevent unauthorized forks of the Hifi protocol and allow the Hifi DAO to benefit from the strong foundations the core team has built in the past couple of years.

Upgrade to Solidity v0.8.12

This new version of Solidity improves the JavaScript / Wasm binary and fixes several bugs. It also offers a partial migration to Typescript.

Upgrade to latest versions of PRBMath

The leading advanced fixed-point math library which we have created has had several small updates in the past few months.

Add support for EIP-2612: Signature token approvals

This is a major upgrade for the user experience of our protocol. Users can now authorize the spending of their tokens in the same transaction as the actual spending of their tokens.

This is a first step towards an eventual deployment on the Ethereum mainnet where the gas fees are significantly higher and where this will really help users save money and make the general transaction flow smoother.

Conclusion

We think this proposal is the right step forward after releasing Hifi v1 on mainnet a few months ago. It greatly improves the user experience, especially for new users. It protects the codebase from unauthorized forks and fixes certain issues regarding the protocol architecture.

As this is the first HIP, we will give some time to community members to withdraw their tokens on top of the time required to discuss and debate this proposal.

14 Likes
2

Having the non-upgradable Fintroller smart-contract, updates, and upgrades to stay on top of everything overall ensures security while enhancing the user experience.

7 Likes
3

Is the plan to implement the proposal and move to vote prior to issuing new borrowing/lending? What is the target timeframe for proposal review prior to moving to vote?

4

By the way, I really appreciate the BUSL-1.1 upgrade proposal and the protection it provides the community.

4 Likes
5

In my opinion, it will depend on what is discussed here.

6

I think this is a perfect example, of where I feel like @Skyvault played a role in Hifi’s proposal to upgrade to a business license.

I was in the other camp and he stuck to his guns, in an effort to prevent an opportunity for a fork.

Here’s a perfect example I felt like I was right in defending hifi’s existing license and he felt he was right and ultimately I guess consensus fell with him and it makes sense.

2 Likes
7

The licensing is necessary to prevent forks and continue working towards the mission of Hifi. Having established governance, we now need to plan ahead to take steps forward as a DAO.

1 Like
8

These are all fair upgrades. I’ve been an an open source license advocate from the start where competitors can copy and then the market determines who the winner is, but I understand the reasoning they are doing it this way. Open source license would potentially allow a competitor to swoop in and steal marketshare from HiFi and that would hurt everybody who is a believer and token holder. There is zero benefit to an open source license other than altruism and tons of downside. Business license has changed my opinion on the matter as it protects the community and the work the devs have done and I value that greatly.

5 Likes
9

The way these are presented to us, it seems like it’s one vote on the collective elements that are listed here. Will these items be listed individually for voting, or will it be a binary vote for the entire wrapped proposal together?

2 Likes
10

It will be a binary vote given it’s one proposal.

1 Like
11

if it were to fail, then it would make sense to

A) Revamp proposal accordingly to what community agrees are the ones that will get passed unanimously.
B) Separate items out and then vote individually on them

2 Likes
12

I feel like it passes with flying colors. Everything on there makes logical sense to me. How do others feel about it overall?

3 Likes
13

I think the proposal is ok. I don’t really understand the complexity of the upgrades but it does look good and supporting for the community and the project.

3 Likes
14

I didn’t know about this Licence before, and I love the fact that it has specific parameters required for Hifi’s needs.

Has explained in the source of BUSL-1.1, parameters are:

  • Restrictions on usage – Making this ‘non Open Source’
  • A change date – End date of the restricting parameter
  • Open Source Licence – The licence that will take over once the change date is reached.

As an advocate of Open Source, this all makes much sense to me and @max did a really good job explaining that above, reassuring me about their end goal with the source code.

So, you have my full support for sure about all improvements :clap:t2:

6 Likes
15

there’s a lot of ‘big brain’ stuff in this proposal, so it’s more of a ‘i trust in max’ thing for me, that said, maybe we can have bi-weekly discussions around some of these topics.

6 Likes
16

i think these are all valid improvements. will vote in favour.

3 Likes
17

similar. agreed Doyin.

2 Likes
18

These are great,I will say “Yes”.

2 Likes
19

Fully agree. It is one of those scenarios where I value the teams judgement and opinion on this one.

5 Likes
20

Would you be willing to participate in one of those community calls?

1 Like