Make our Giveth.IO dApp more resilient before GivEconomy deploy

So… first things first, will be great to get the dashboard on live soon. I heard that it’s almost ready to go, needing testing on staging and Carlos is working on setting up emails.

Next, @WhyldWanderer had a meeting training the verification team today, I think the best way forward is to have this team also be responsible for reviewing new projects that get added. Maybe even having it as a weekly or every-other-week hack session? Could be put on the calendar to allow for others to join & support.

And then, this is what I think we should do:

  • Projects are added w default status “unlisted”
  • We add something to the frontend so the user is informed immediately when adding their project
  • Project review/verification team has a weekly hack session to review projects on the DApp and list them
  • Add feature to automatically list projects if they are not reviewed for 2 weeks (or we can make it a month, if that’s better).

This is good because:

  • It ensures that projects on Giveth are not violating terms & conditions… we don’t end up having projects like “KILL ALL THE BABIES” showing up all over the DApp from Trolls or malicious parties
  • It protects us from human error / inefficiencies in our centralized review method
  • It informs the user (fairly) how their project will appear

Everyone is in the know, everyone is treated fairly, and Giveth maintains professionalism.

1 Like

I am a strong advocate of projects being listed by default.

  • Its very disheartening to create a project and then try to look for it and not find it on the DApp. People have been creating duplicate projects because they cannot find theirs.

  • Project owners are getting confused between applying for verification and getting listed. They are filling out the application thinking that they are applying to get listed. We now have ‘verified’ projects that are not listed.

  • Innocent until proven guilty is much better than penalizing good projects.

  • According to the roadmap, we will have a flagging feature in the future that allows us as well as users report a project.

  • We now have team and will soon have a dashboard and streamlined process that will allow us to unlist any projects that don’t meet the requirements. Also, we are notified in the #givethio-event-log channel any time a new project is created so it shouldnt be too hard to keep up with unlisting.


I have oscillated between camps on this issue. I see there’s a lot of immediate confusion created by the implementation of this system because we hadn’t thought of how to effectively communicate this to users. We’re now scrambling to find resolutions in real time which kinda sucks and creates tension as the amount of frustrated project owners pile up…

I see the justice in making projects automatically listed and that would alleviate much of the confusion from users trying to make projects.

Reflecting however on how other open platforms (namely digital marketplaces) deal with these sorts of things. I do see very commonly a review process before ‘listings’ go live that protects buyers (or donors) from scams and protects the organization from the legal implications of hosting a potentially malicious entity.

I can think right away of adding the notifications on the high 5 page and somewhere at the beginning of the create a project flow about this “review” process.

I would also remove the project created email from the user flow to remove the notification overhead.

I’m open to either solution but I would make those suggestions if majority rules for projects stay unlisted upon creation.

That being said we need to implement something quickly!


Following the discussion today in the DEV call we have to decide on a course of action for project status’ upon creation.

What should be the default status of a project upon creation?

  • Listed
  • Unlisted
  • Abstain

0 voters

I’m sticking with my original vote for projects to receive their URL so they can share it, and wait for approval to be listed.

I think the decision to start unlisted is a good one, it’s the implementation that is falling short.

If the message that pops up says “Your project has been submitted for review, you can check your status [here] and share your link now to begin soliciting donations”

And an email is sent that says this, along with a map on the User Guide that shows the steps:


  1. Create Project (you will receive a link that can be shared, but your project will not show up until you…)
  2. Share the link with your community to raise funds
  3. Get Listed (make sure your project meets these criteria to be listed on
  4. Receive even more Donations!


  1. Fill out this form…
  2. Attend a call or introduce yourself in the #verification-channel on Discord…


I want to share some of my thoughts and feelings around this decision while keeping focus on the goals and mission of Giveth and the Future of Giving that we are building.

Being steward of the community support working group puts me very close to users - helping with onboarding, project creation, verification, hand-holding and really getting to see where users are struggling while using the application. Since we have implemented the listed/unlisted system and projects start as unlisted upon creation, users have been very confused… If the process is not intuitive enough for the average user, it doesn’t matter how awesome our dashboard is or how on top of the process the team is. So I think the key is that we clearly communicate to the user of what to expect and how to proceed and if we need to make adjustments to mediate user confusion, we should do so.

Keeping in mind that Giveth’s first ‘Value’ is decentralization, by having a ‘review system’ in place at the very first step after project creation, we become a centralized platform. In the future, project curation will take the place of project verification, giving all users the power to verify projects using GIV tokens. How will listing/unlisting be taken into consideration once we have implemented project curation? How will we decentralize listing/unlisting in the future? I realize a lot of these details will be worked out as we go and we dont have a clearly defined way of how we plan to implement this process. However, these are things to keep in mind as we make these decisions and move toward being a completely decentralized community.


I think that if we are to decide to have projects listed by default it would be important to also immediately implement:

  • a system of “flagging” (so that, in a decentralized way, projects can be brought to the attention of admins by any user)
  • a disclaimer on unreviewed projects saying “this project is pending review and has not yet been found to agree with out terms of use” (or something like that)
  • a clause in our terms of use protecting us against the implications of “bad” projects
  • an organized system for our reviewers to review new projects

I think Ashley you have a really good handle on the user’s needs. My main concern with immediately listing the projects is the implications of having malicious, violent or otherwise harmful projects getting listed on the DApp right away, but if we add in the above, I think we’re covered.

Even still, I voted abstain… would love to see more discussion.


I fully appreciate your position Ashley, and have been on that side of this fence most of the time, holding the decentralized/uncensored view of all projects showing immediately and only removing those found to violate the Terms of Use.

My mind was changed at the advent of the token economy and seeing the ‘bad actors’ popping up so frequently - it felt like we made it TOO easy to create a project and thus to create a fraudulent project.

Re Flagging:
It was my understanding that the listed/unlisted curation process is a temporary one, because it really can’t continue to be a manual process for very long. Once we have “flagging” implemented the need for starting out unlisted would also go away, but I understood that to be further out in the roadmap.

Re Unreviewed Disclaimer
This is another viable option, and I can see possible variants as well - perhaps we limit them from the default view, and you have to go to the Search Bar and choose “New/Unreviewed Projects” to accept the disclaimer and then see them.

Re Terms of Use Clause
It’s quite well covered by the Terms of Use already.

Organized Review System
It would be very nice to have a Transparent review system where anyone can go see the list of projects created, listed, verified and Trace-able in the future. Maybe in the future we can explore using Kleros’ Token Curated Registry (TCR) Service to go wide on the Decentralization and engage with ecosystem partners more; this is what CLR Fund uses.

I Haven’t changed my vote yet; but with a few tweaks like how/where they show up in the Project list you can probably get me there. I do want a clear process with easy instructions for project owners on how to create, list, verify and trace projects.

1 Like