HALTED | GIVfi Working Group Proposal

Goals :bulb:

GIVfi aims to allow Projects, Donors and Investors on Giveth to easily tap into the power of DeFi and generate passive yield for public goods and projects on the Giveth platform.

Our goal is to make it easy and safe for projects and donors to get into DeFi, maximise their funding with minimal effort, and create sustainable income streams for Giveth.

GIVfi will feature two products, GIVsavings and GIVdaoments. GIVsavings is focused on allowing projects to earn yield on their idle donations. GIVsavings also allows donors to donate directly to a project’s GIVsavings. GIVdaoments will allow impact investors to deposit their own funds into on-chain endaoments which earn yield and distribute that yield to projects on the platform. Depositors into GIVdaoments keep their principal and donate the yield.

Both GIVsavings and GIVdaoments implement performance fees on yield earned and will provide passive revenue to the Giveth DAO.

Team and Resources :trophy:

@mitch - Lead, Product Manager & Documentation

@Cherik and @alireza7612 - Front-End Development

Kurt - Smart Contract Development

@mateodaza - Subgraph Development

@Tossynee - Design

@maryam.jafarymehr - User Testing

@Griff - Product Advisor

@amin - Subgraph & Smart Contract Advisor

Communications & Marketing - TBD

Duration :hourglass_flowing_sand:

Our immediate goal is to deliver the GIVsavings MVP which could be expected as early as mid Q3 2023. However our full vision of GIVfi, including multi-chain & multi-vault GIVsavings, GIVdaoments and scaling product growth could take up to 2 years to fully achieve.

Initial 3 Month Deliverables & Budgeting

The DAO will have the opportunity to vote on which budget and corresponding deliverables the WG will focus on for the next 3 months. There are three options:

  • Grow - Increase the current scope and budget.
  • Sustain - Maintain the current scope and budget.
  • Shrink - Reduce the current scope and budget.

Grow :arrow_up:

Task :white_check_mark: Deliverable :mailbox_with_mail: Expected Cost :moneybag:
Research on GIVdaoments technical implementation Technical Specification of GIVdaoments
Professional Auditing Professional Audit of GIVsavings smart contracts $50,000
Development of GIVsavings MVP Test deployment on the Giveth staging website
User Testing Begin user testing of GIVsavings MVP
Launch communications prep Communications Strategy for GIVsavings launch
Documentation First draft of user documentation for GIVsavings
Salary Costs $16,500
*10% Budget Buffer $1,650
Total $68,150

Sustain :arrow_right:

Task :white_check_mark: Deliverable :mailbox_with_mail: Expected Cost :moneybag:
Development of GIVsavings MVP Test deployment on the Giveth staging website
User Testing Begin user testing of GIVsavings MVP
Launch communications prep Communications Strategy for GIVsavings launch
Documentation First draft of user documentation for GIVsavings
Informal Audit Informal Audit of GIVsavings contracts from Giveth Galaxy friends
Salary Costs $13,000
*10% Budget Buffer $1,300
Total $14,300

Shrink :arrow_down:

Task :white_check_mark: Deliverable :mailbox_with_mail: Expected Cost :moneybag:
Development of GIVsavings MVP Test deployment on the Giveth staging website
User Testing Begin user testing of GIVsavings MVP
Informal Audit Informal Audit of GIVsavings contracts from Giveth Galaxy friends
Salary Costs $11,000
*10% Budget Buffer $1,100
Total $12,100

*Budget Buffers are included for any unexpected costs from operations, only if a portion or all of it is spent will another, proportionate, budget buffer be requested in the subsequent budget.

Approval Process

This WGP will remain available and open for Advice Process for 7 days, after which it will move to a Snapshot vote to decide the approved budget and scope.


Thanks Mitch for this proposal, some really interesting ideas. I have just a few questions.

How exactly doest this work? Where does the yield come from?
What’s in there for the depositor?

How much would these two features add complexity to the existing product, and what are we doing to avoid confusion with regular donating?
I’m worried about adding more options alongside GIVbacks, Referrals, Boosting would make things even more complex and harder to understand, unless we deeply rethink of how and what we prioritise on the screen.

1 Like

Right now we’re ideating the technical parts but for GIVdaoments it could work something like rDAI or Index Coop’s gtcETH. Where the yield and principal can be separated the the yield can be split across multiple recipients. For non-ETH products we might use a modified vault contract and tokenize the yield earned and split those tokens up to many non-profits.

This is an early spec we worked on that has more details of our ideas around GIVfi:

In terms of your concerns for complexity I would definitely agree that Giveth is very complex and as you said to me recently we do need to put more thought into the product design and make this intelligent and easy to understand.

Right now we are over half-way in development of GIVsavings MVP, we might expect a launch as early as 4 months from now. Work on GIVdaoments then will depend on how the DAO chooses to prioritize GIVfi over our current products.


I was under the impression that the original idea of GIVfi was to replace having some sort of burn mechanism. That the yield being leveraged from GIVfi would be used to buy GIV from the open market and send it to the GIVgarden. This would ensure a healthier token price without the need for burning tokens.

I don’t see that this is the current spec for GIVfi but maybe Im missing some details. Is there a reason that this mechanism was cut from the spec?

Also, why is GIVfi not a product under the GIVeconomy working group but rather its own working group?

Hmm, I’m eager to hear the answer to Ashley’s questions. (Especially, whether there are any plans for lifting the GIVtoken up from the depths of the crash, if even possible at this point?)

Also, I’m curious if you have any projections of the minimum passive revenue, and/or what amount of users/performance need to be processed in order to generate some reasonable minimum. Will this be deployed on more than just one chain? Curious to hear more of your thoughts on this. I like the potential of this wg.

Yes! There is still an intention at some point to use our revenue from GIVfi to buyback GIV tokens. Whether it goes in the GIVgarden or used for some other purpose such as DAO-owned liquidity is yet to be determined.

Right now it is not as much a priority to buyback GIV as it is important for us to gain revenue to cover our operational costs, so that is why there is no explicit mention of buying back GIV at this point.

To your second point, since we are trying to be more product focused it would make sense that GIVfi is managed independently from GIVeconomy, this allows us to do more efficient work with a tighter team of individuals and tighter KPI tracking and budget approval. Also at this point it doesn’t really have any relation to the GIV token.

@NikolaCreatrix to your point, yes GIVfi will be multi-chain at some point, the MVP however will focus on just one asset on just one chain and we will progressively add more down the road.


I vote for Shrink version at this point, and then decide on endowment feature later.

1 Like

I did some quick math to help understand how we might collect fees based on some assumptions of monthly donations and the percentage that projects might deposit of the total monthly donations

We compound these donations over the period of one year and find out how much interest would be accrued and how much of that interest would go to the Giveth DAO.

At our current rate of monthly donations I can’t say that GIVsavings will be a game changer.

We would need to scale monthly donations at a magnitude of 10-20x to be anywhere near effective.


Snapshot vote is up!

@mitch - I have one more question… What is the current list of eligible GIVfi tokens?

GIVfi will only work with a limited amount of tokens, to start only ETH on Optimism will be available, with USDC and DAI as probably other candidates in the future, as well as other chains.

1 Like

Thanks Mitch! and thank you for all of the work that you have put into this so far. I know it has been in the pipeline for months now.

I voted No on the snapshot vote and I want to give my reasoning here:

  • I think that this feature adds more complexity to our platform. We will need to communicate to project owners (many of which are not crypto savvy) how it works and teach them how to convert as well as bridge their donations. Project owners have expressed that they are already confused about basic off-ramping procedures and I think this will only confuse them even more.

  • It encourages project owners to sell their GIV or convert it into other tokens in order to benefit from yields when we should really be encouraging them to convert their donations into GIV and provide liquidity to earn rewards.

  • Looking at the numbers above, the revenue that this feature will bring to Giveth doesn’t seem significant enough to warrant the resources needed to build, maintain, and communicate it. I think that we should not just focus on ways to bring revenue to Giveth but to also focus on creating a healthy token price which would result in less need for revenue. I think that we can explore methods to raise the token price and revitalize our economy - we even have positions where we could maybe be leveraging our current yields to this advantage.

  • It seems that future roadmap items (GIVdaoments) overlap with some of the other efforts that Giveth has planned for the future. Gurves is intended to allow impact investors to deposit the funds, earn yields, and support projects. I don’t see how having both is beneficial.


I definitely respect your decision and agree with a few of your points.

However, I have to point out that this is actually a bit of broken logic:

This is setting the intention that projects receive their donations mostly or entirely in GIV, which I don’t think at its core is an attractive offer for projects. If this is the case, regardless of GIVfi or not, projects need to sell their GIV for other things, such as funding their actual goals. GIV, I believe, is a feature made for creating donor incentives, not for projects. Projects however are openly allowed to participate in most aspects, and we welcome those who do.

The second point of providing liquidity is not quite right either. Staking GIV alone actually does little for the price of GIV nor does it make the token more liquid. The only benefit of staking and locking GIV is that it isn’t sold. This does not improve the price of the token, nor does it make it easier to trade on the market.

We used to have ways for users to provide liquidity and that was in the form of the ETH/GIV, xDAI/GIV GIVfarms but that proved to be an expensive endeavour and likely hurt us more than helped us in terms of supporting the GIV price.


I really think GIVFi is cool, and I love the win/win for projects & for Giveth where both earn a yield on idle donations. I don’t think it’s THAT complicated to explain - it’s basically staking rewards… or something akin to a savings account in the MVP.

I’m a little disappointed about the revenue numbers with our current stats, but I think this emphasizes the point that’s floating all around our team… “We need to focus on marketing for Giveth to increase our user based of projects & donors… and in particular, we need more donations to run through the platform.”

Getting out of the strategy call w/ @MoeNick @Griff & @mitch this morning, Giveth really needs revenue to make it through this bear market, and need to save our development bandwidth to support on external, revenue-generating projects through GM.

Revenue generated through GM should then be spent on increasing Giveth marketing & going hard on increasing adoption. We should scale back on Giveth products, except those that support our marketing goals & help get more donors. Those are:

  • QF: opportunity to onboard more donors & get lots of marketing from projects throughout rounds
  • Referral program: opportunity to onboard more donors through referrals

I voted “No” in Snapshot for GIVFi because I think it’s in our best interest to pause work on this product, and revisit next quarter.

A lot of work went into it already, and we shouldn’t let that go to waste… but I think GIVFi isn’t high on the priority list right now, and while we’re pulling our dev team apart with GM, we should rally our remaining resources around things that will be the most high impact now.

I really don’t like voting No on this, but I think it makes the most sense right now. Happy to hear any arguments against this.

1 Like

An update on the Snapshot:

It appears the DAO has voted NO on this proposal, so our work on GIVfi will stop for now…