Proposal: Make Honey Sticky (Automatic dividend reinvestment vault)

🌿 Proposals
#1

Make Honey Sticky

Proposal Information

Proposal link
Prototype code gist

Proposal description:
I have been working on a smart contract wallet that can automatically reinvest the HNY rewards from an LP farm back into that pool with a single click. I have a proof of concept working, and were I building this for only myself, I’d probably stop in one or two more iterations. But I could easily work on this for another couple of weeks if I wanted to release it for more general use.

For the work I have already done, plus future work estimated to take 5 developer-days over the next 2-4 weeks, in order to produce a product the Hive can safely and happily use, I am proposing payment of 2 HNY.

This work will include:

  • Functional and safe contract wallet with the capability to reinvest (the main feature)
  • Proxy/factory contracts which allow everyone to use this without making xDai sad
  • A very basic UI which one can use to control their wallet
    • The UI will mostly be a construction kit which could be used by someone who is actually good at UIs to integrate it into the existing farm UI. But it will be functional. It’ll essentially be what I would use to manage my own wallet.
  • Potentially, a “tip” mode where some of the rewards can be sent back to the treasury or a different address
  • Test coverage of the project
  • Converting the whole project into a HardHat/Waffle project which can be worked on by multiple devs

Proposal Rationale
The primary rationale for this tool is in the title. I want to make HNY more “sticky”. That is, I want it to be as easy as possible to keep (at least some of) your HNY rewards HNY, and keep them benefiting the community. HNY in the staking contract, unclaimed rewards, doesn’t benefit anyone. HNY reinvested in the pool benefits the individual (more compounding) and the community (our HNY goes immediately to work).

So, for any HNY/xxx farm, we provide a simple experience which allows users to easily reinvest the HNY rewards from the farm back into it, by selling half of the claimed HNY through their pool, providing liquidity with the result, then staking those tokens. This is the power of compounding. Large scale yield farmers do this on mainnet, but it’s not considered worth it for smaller players because of gas prices. But here on xDai this is economical even for very small amounts.

Expected duration or delivery date (if applicable):
I expect to deliver the working stack within 4 weeks. This estimate has some padding applied already, so it might be only half as late as other software projects you’ve seen.

Team Information (For Funding Proposals)

Names, usernames, and/or relevant social links for team members (Twitter, Github, 1Hive Forum, etc.):
This is a solo project by me (currently).
anisoptera: https://github.com/anisoptera

Skills and previous experience in related or similar work:
This is my first smart contract project. I worked on a Bitcoin project quite a long time ago, and I have been programming computers for literally as long as I have memories. And I’m not all that young. :slight_smile:

At this point in the project, all that is left is the boring stuff: writing tests, building a UI, upgradability, scalability, security… You know, the things you probably don’t want left out of something you trust with your money.

Funding Information (For Funding Proposals)

Amount of HNY requested: 2 HNY

Ethereum address where funds shall be transferred: 0x6697267a9B8665c9540060037c8810c5eb980fde

More detailed description of how funds will be handled and used:
I will be using the HNY to provide liquidity on the HNY/WETH and HNY/STAKE pairs, as well as holding some as a voting stake in the community.

8 Likes
#2

Some questions:

What features would this contract wallet have? Will it exclusively be able to provide liquidity and and stake LPs to the farm? Or could it call arbitrary functions on external contracts?

What are the permissions for accessing it, will it just inherit ownable and use isOwner or could there be multiple owners?

Can we see the current contract code?

3 Likes
#3

My initial reaction to calling arbitrary functions is that it seems much more difficult to secure. Is there a use case you have in mind for that? I’m not against it, but my idea for the tool is that it’s a fairly narrow extension of the existing farm contracts. I didn’t want to make something that was hard to show to be secure.

My current implementation just stakes, invests HNY directly (if you have some you’d like to get started with), stakes LP directly if you send them there, and lets you send tokens/“eth” to other addresses.

Currently it just inherits ownable and uses isOwner, but again, I’m interested in the use case for multiple owners. It could save on gas, which is currently cheap but may not be forever (reinvest takes about 1m gas) but how do you handle withdraws? Do we start implementing something multisig?

Sure, it’s ugly but it works: https://gist.github.com/anisoptera/25a26947017cfa038c00d5ab2c475389

As written it has some pretty glaring front-running vulnerabilities if it’s going to transact any meaningful amount through the pool that way. But it works for reinvesting pennies :slight_smile:

Edit: There is more code than is in that gist, I have a JS UI in jsfiddle too. It’s all over the place. Part of the purpose of this proposal is to incentivize me to organize the project in a sensible manner that other devs can work on.

3 Likes
#4

The project in interesting and cool, but I am concerned the proposal price is a little steep. I would be happier with a cost of ~2 HNY. This is also just my opinion though. I would probably be willing to back this proposal for 2 HNY, although I’m not a huge holder.

2 Likes
#5

I think its a good idea, but i’m with @befitsandpiper on this one. 5 HNY seems to be a lot for what needs to be done. 1-2HNY should be enough.

1 Like
#6

2 HNY is fair from a fiat value standpoint. I priced my proposal based on the principle that I should be thinking in terms of the % of the HNY in the pot, and my thinking was that this is probably worth at least 0.1% of the pot, which is actually 7. But then I thought of fiat value there so I backed it off to 5.

For the work as specified in this post, I would be fine with 2 HNY. Future scope creep can be part of a new proposal. If that’s the only blocking issue I’ll change the funding amount.

1 Like
#7

I have updated the proposal with the new price (2 HNY). Thanks for the feedback, looking forward to contributing!

#8

Curious why you would think that it makes sense to value based on the relative percentage of the pool? And why that would be significantly divergent from the value you think it is worth in fiat value?

1 Like
#9

First, I read the monetary policy discussion threads and the impression I got is that we should be distributing the stuff with some “1 HNY=1 HNY” mindset, i.e. how valuable is this thing to our organization as it stands rather than the USD value.

To me it makes sense to value it as a percentage because it’s a force multiplier. This tool enhances every HNY farm. It improves, through compounding, the returns of the individuals, and it allows our pledged HNY farming rewards to be put to work sooner.

Because it’s a force multiplier, I went with multiplicative pricing. We could debate the percentage too, but I think 10 basis points was actually vastly underselling it, if I’m being honest. I think the real value of this tool is at least 1% - ten times that. You can apply such a percentage to any HNY rewards we pledge from the treasury to a farm on a HNY/* pair (in the initial form). This would enhance the impact of those rewards by that percentage.

But there has to be some reward for the hive too, so 0.1% seemed fine.

I checked the fiat value of my estimate for sanity. In fiat value I was actually totally okay with 5 HNY. I estimated 5 developer-days, and were I to quit my day job and go into consulting I would probably charge more than 1 HNY/day (at yesterday’s rates anyway). 7 HNY seemed on the high side, so I trimmed the ask more.

But I wasn’t really asking for the HNY for the fiat value. I don’t plan on taking much of the value out of our community. I was thinking of the voting stake this gives me in the community more than anything else. I would like to provide liquidity, sure, but of course the profit from that is its own reward. More important to me is the voting power, and the incentive that being such a stakeholder brings me to further improve the community.

I’m willing to reduce the amount because I can understand that, judged solely on the work specified here, and considering just the fiat value of the HNY, 2 HNY would be tolerable. I’m new to blockchain dev and asking to be trusted to be paid to write code that handles money. I showed up last week. And so on. There are a lot of factors that should make me willing to sell my work at a discount, and so I’m fine with that.

2 Likes
#11

Thanks for the response man. No need for it to call arbitrary functions, it was just that you referred to it as a contract wallet and typically contract wallets to me have certain features, including calling arbitrary functions.

Can you link me to the inherited SimpleWallet contract? Also do you know how to build a truffle or buidler project and how to write tests and would that be included?

Can you explain how this could save on gas?

1 Like
#12

Oh yeah, I have like no experience so I’m definitely using some terms wrong :slight_smile: I guess “vault” is more appropriate?

SimpleWallet is, well, simple: https://gist.github.com/anisoptera/f603abdb6302e93b322c517812b32621

I don’t know how to build a truffle/buidler project right now - that’s one of the things that I looked at, said “That sounds like work”, and then decided to go see if I could be paid to do the work, because I wouldn’t necessarily be doing it for myself. That and unit tests are included in the proposal under “Making a project that other devs can work on too”.

You could also consider part of the HNY from this proposal to be investing in me as a Blockchain Developer, building my skillset in this particular area. If this is funded, I’ll definitely be contributing more in the future as well, and my contributions will be all the better for me having had this project to cut my teeth on.

Well, if we have, say, 10 people who are together essentially pooling their faucet outputs, and they want to compound daily, we can run reinvest for the pool once instead of ten times a day across all those people. It takes 1m gas whether you’re reinvesting ten cents or ten dollars. In that scenario perhaps the additional overhead necessary to manage the multiple users is outweighed by the savings on the reinvest calls.

#13

Updated the proposal:

I looked into buidler (now HardHat I guess) and Waffle (because I’m using ethers.js) and specified that the deliverable will be in the form of that kind of project.

I also added SimpleWallet and Owned to the original gist and linked it from the first post.

#14

I don’t have enough :honey_pot: to support the proposal but I support this idea :+1:

#15

I think this behaviour would be better off built into the Unipool contract (farming pool) as it would have better UX. No need for user/website to manage a separate contract, and no need for additional transactions to move funds to/from the vault contract.

In the Unipool contract, as well as harvest/getReward() there would be a function reinvest() which would sell the reward for the user, and assign the earnt LP tokens to their account.

Also the idea of having multiple account holders is tricky because then you need to define access to withdrawing from the pool and who gets how much. For the sake of gas savings, at least for the time being, I don’t think it would be an appealing alternative.

Unipool contract: https://github.com/1Hive/unipool/blob/master/contracts/Unipool.sol

4 Likes
#16

I definitely agree the UX would be better if we did it that way. My prototype assumed I wouldn’t be able to modify the underlying contract (as a side benefit it works on any farm using Unipool) but you are absolutely right that it’s way easier not to have to deploy a new contract for everyone, the UI now have to find another contract to get stats, …

I’m up for doing it the right way on our Unipool instance. :slight_smile: I don’t think it’ll be that much more work to do it there.

e: looking at the contract, yeah, probably a lot less actually :slight_smile:

#17

I would spport this for 2 honey

2 Likes
#18

I’ll support this proposal if you don’t mind integrating it into the current Unipool contract. I’ll likely be the one reviewing your work and I’ll tell you now there needs to be tests if we’re to include this in a live deployment. As a Solidity developer tests are often the bulk of the work. Please fork to your personal github and work on it from there.

Also I’d be interested in your thoughts on this 🍯 Honeycomb V2 Brainstorm while you build an understanding of the Unipool contract. It would be great if we could have multi-collateral farms but I’m not currently sure what the best approach would be.

5 Likes
#19

I’m already getting familiar with the Unipool repo (just submitted a minor PR to fix a flaky test). I agree tests are the most important part :slight_smile:

I’ll take a look at that other topic and give it some thought. Thanks!

2 Likes
#20

I like the idea and subsequent discussion below, tried to support but too late :joy: look forward to seeing this merged to live one day!

1 Like
#21

This is finally up for PR: https://github.com/1Hive/unipool/pull/6

4 Likes