Grant Application- Dogfooding the Proposal Inverter

  • Project Name: Proposal Inverter (Prime Flow)

  • Team Name:PrimeDAO

  • Payment Address:
    eth mainnet :0x954Ccb8E7828e29246740E29F02efba1de0467BE

- [Level]: :evergreen_tree:-Tree

Proposal Inverter Meta Proposal: PrimeDAO Proposal :robot: For Radicle Grant

*Meta proposal is a proposal where grant reviewers can see all the necessary information such as product reviews, user stories, team accountabilities and involvement scope of each party.

An indication of how your project relates to / integrates into Radicle

We are very excited to collaborate with the Radicle team as Proposal Inverter incorporates the Radicle Drip’s backend mechanism for funneling the funds within the Proposal Inverter. As stated in the Meta-proposal above;

“The proposal inverter inverts the DAO-proposal relationship. Such that, instead of having many proposals for a single DAO, we will have many DAOs for a single proposal. Through a fund funneling mechanism that continuously “drip” funds according to pre-negotiated contracts, the “inverted” proposal will be funded in a semi-automated manner.”

The Drip and Split mechanism have a perfect use case for creating this pre-negotiated fund funneling for allocating funds for proposal contributors as this action requires continuous drip of funds to the common pool then be splitted to different stakeholders. We believe the proposal inverter will be the main catalyst for drips adaption across the DAO space for running collaborative fundings and joint ventures. We are integrating drips into the emerging DAO to DAO ecosystem as a fundamental mechanism that can be further utilized by ecosystem participants.

As one can see the Proposal Inverter and Radicle Drips share common goals and aligned ethos. The “Introduction to Drips” article stated “…(Radicle) believe that sharing funds through Splits has the potential to become a new cultural norm in crypto and a fundamental building block for solving difficult problems like the funding of public goods and promoting more redistributive crypto economics.”, very aligned with what Proposal Inverter envisions to reduce collaborative effort between DAO to DAO relationships and by that it tried to nourish the public goods ecosystem. With this collaboration, we will provide a critical tool to the public goods ecosystem.

The original version of this table can be found in Meta-proposal above. ( Sorry for the image quality, the forum only allows me to have 1 photo.)

Future plans

In the short term our building partner, Token Engineering Commons will be accountable for the marketing, documentation, and communication side of the project. Along with those efforts, PrimeDAO’s pioneer position in the DAO to DAO ecosystem will help our team to integrate Proposal Inverter into this growing D2D ecosystem and make it heavily adopted. Through those efforts, Proposal Inverter would likely become a pivotal tool for DAO to DAO coordination. Regarding our future plans with the Radicle team and drips mechanism, as the community of builders behind the proposal inverter, by integrating drips backend and working around expanding the protocol’s architecture, it will also be a hub for pushing toward utilizing drips as a composable primitive for funding public goods, such as integrating quadratic funding, utilizing the sitting assets in the drip reserves for revenue generation, creating decision-making mechanisms around the that dripped funds, etc.

The development process of the PI will bring a wave of developers towards becoming familiar with the drips infrastructure. There will be a co-promotion process between Radicle and many other DAOs involved in this collaborative effort such as Gitcoin, PrimeDAO, TEC, and Longtail. The collectively joint marketing potential for this process is a very powerful force and will lead to some major disruption across the DAO space.


  • Contact Name: Mert Ozdal

  • Contact Email:

  • Telegram: @mertozdal6

Team Code Repos

Team LinkedIn Profiles (if available)

Alp Ergin:

Shawn Anderson:

Mert Ozdal:

Jeff Emmet (Advisory):


Hey everyone,

Alp here. I wanted to underline that our goal is to arrange a monthly sync with the Radicle team and show/post our improvements before the next milestone, so that, the Radicle team and its community can transparently be involved in the building process of the Proposal Inverter and they will make sure to approve the next level of funding or request work improvement before doing so.
(That’s also embedded in the proposal inverter, a funder can exit anytime if the project doesn’t deliver as expected)

Also regarding the UX journey here is documentation that can provide some detail on the ongoing design;

Looking forward to your questions

1 Like

Hi Mert and Alp! On behalf of the Drips team, I wanted to say that we’re very excited to see your proposal – thank you for submitting it. I love the high-level vision for the Proposal Inverter, and I believe that if your vision is realized it has the potential to help solve DAO coordination challenges and streamline funding for many initiatives and projects that are hard to coordinate today.

In terms of more specific feedback on your proposal, it’s clear that your team has done a lot of great work around the mechanism design and other theoretical aspects of the project.

In addition to that, it would be great to see more high-level detail around the problems that PI is aiming to solve for everyday users (both on the DAO side and the contributor side) and then some rough sketches of what that would look like in action. This might include:

  • User stories and use cases
  • UX wireframes
  • Technical requirements

The first versions of these can just be drafts, but they would be super helpful in building excitement and consensus among stakeholders around what PI will do. The CoolLabs case study is a great start towards this and if you can add some wireframes and user stories I believe that the proposal will be in a good place and it will really help communicate the uniqueness and power of your vision.

The second piece of feedback I have is that your timeline looks pretty ambitious to me in terms of getting all of this built out and deployed by the end of July. As part of your initial scoping work and work on wireframes and user stories, I would strongly suggest that you think about the smallest MVP build you could initially do, and then aim to deploy that first, with successive builds coming in later stages over time. Because I think getting the full version of what you envision deployed by the end of July will be really tough, but getting a MVP deployed by that time is probably reasonable and then looking to expand on that in later phases based on feedback of stakeholders, adoption, funding, etc.

Finally, in terms of the monthly meeting, we’re happy to do it so let’s look to schedule that for sure!

1 Like

Thanks a ton for this awesome feedback @andrewd
This kind of deep analysis from a core member is invaluable!

Just want to say that I second what @andrewd has noted. Getting those three items (user stories/use cases, UX wireframes, and tech requirements) will help a lot. This is the initial investment of time/effort I’d expect from grants, especially larger ones.

I’ll address each of these below:

User stories/use cases + Wireframes

User stories: There is a single example (Alice, Bob, Rachel and Bartu). I think it would beneficial if you really create a fully fleshed out list of possible user stories and use cases (i.e. not just Alice, but others too). Categorize these and speak to how your solution will solve each of their unique problems.

UX wireframes: There are some hints of how things work with diagrams. But, for example, how might the MVP look? How might this look if integrated with Radicle Drips? Painting a picture of short, medium, and long-term look/feel would be great here. As @andrewd said: just some simple drafts are fine here

In your planning doc, you have the milestones below. This seems to point to the ideas above. It seems really close, but could be fleshed out more (using some of the ideas above). Especially before we jump in from milestone 4-onward :slight_smile:

Technical requirements

There is a lot of theoretical work (like here). Do you have some more details on how this will be technically implemented?

I’m actually not the best the review the really weedy specifics (presumably that’s why we want this audited). This is less a sticking point for me, but might help folks like @andrewd get involved in a deeper manner.

Overall, I’m really excited about PI. I think we just want to flesh this out a bit more.


Hi everyone,

This is Ruben I am working together with Bartu on the UX/UI design for the Proposal Inverter. First of all, thank you for your constructive feedforward and we wanted to say that we agree with your concerns. We have just completed creating User Personas and now will be working on further creating some user stories (based on the previously shared cool labs case), linking these with scenarios/use cases, and providing some draft wireframes for the Radicle community.

We think we will have these new drafts for you by the end of next week!

Once again thanks @andrewd @bordumb.

1 Like


Awesome to hear!
And thanks a bunch for the quick response.

Please feel free to just respond here with any useful links, images, text, or other materials once those pieces are ready.

Looking forward to it! :slight_smile:


Hey @bordumb @andrewd ,

As promised we created an extra user story (the contributor)/ scenario and made a wireframe draft for the proposal owner user flow.

Contributor User story/Scenario

Wireframes Proposal Owner flow (drafts) in miro

Please keep in mind that these are drafts and we would love to receive comments and feedforward so we can design better. Looking forward to hearing from you all!

Have a great weekend.


Hi @Ruben

Thanks a bunch for sharing these. These are great and the wireframe definitely helps illustrate what you’re looking to build.

I will start the vote for Milestone 1 ASAP. Keep in mind that the scheduling will be as follows:

  • Milestone 1: if passed, 20% of funds will be dispersed immediately (4,000 USDC). One completed/approved, the remaining 80% will be dispersed upon approval (16,000 USDC)
  • Milestone 2: will only start once Milestone 1 is fully completed. The voting funding process will follow a similar schedule as Milestone 1.
  • Milestone 3: will only start once Milestone 2 is fully completed. The voting funding process will follow a similar schedule as Milestone 1.
  • Milestone 4: will only start once Milestone 3 is fully completed. The voting funding process will follow a similar schedule as Milestone 1.

Let me know if you have any questions in the meantime.


Hi all

First off, apologies for getting back on this late. I’ve left post-mortem notes on some of our processes at bottom. It is apparent that our process broke down a bit here.

Immediate next steps


  • The Grants program’s first wave ended so we are not taking applications right now. Please refer to the community post here for rough timelines on when we will have Wave 2 started; estimating around September.


The main reason we could not reach quorum was due to a few related factors:

Smart contract work
The grant mentioned smart contract work, but it was not apparent from any of the links posted (LinkedIn or GitHub) that anyone on the team has smart contract experience. Perhaps one of the team members is an expert writing smart contracts, but this is not apparent from links provided.

If someone on the team has experience here, please feel free to reapply while calling this expertise out more explicitly. Please remember that we’ve never worked with you. So err on the side of giving more details (links to other in-progress projects or completed products on GitHub for example). As of right now, it reads like “Here is a great looking group of people, but we don’t see any clear and explicit examples showing they can do the technical work involved.”

If no one on the team has experience with smart contract work, I think getting quorum will be extremely difficult here. If this is the case, I’d recommend either recruiting a new team member (and repricing the grant accordingly) or coming back at a later time once some of this expertise is learned/proven out a bit more.

And beyond the smart-contract work, there is really very little to go off technically speaking based on the links provided.

Overall, this was the major sticking point and raised concerns around whether the work could be done at all, on time, and on budget.

Post Mortem

It’s always worth calling out poor or broken processes. So leaving some notes below for anyone interested in improving.

1. Multi-sig communication

We did not manually link to the vote when it started. For future reference, our multi-sig is here.

We did not follow-up on Discourse with a note about the vote being rejected in the Gnosis safe. For reference, the vote was Nonce 24 on the multi-sig above. If I remember correctly, it garnered 2 votes and did not move forward.

Simply put, not having a direct link to the multi-sig on the application is bad.

I do not think this will be solved by saying “we’ll do better next time” because this comes down to human error of not manually linking things. There is always room for human error.

I see us solving this point around voting communications with technology/tooling.

Once we (Grants) adopt Workstreams, we should be able to surface everything from the application to the discussion + voting in one UI. This should get rid of a lot of the manual overhead and make things more seamless and transparent.

2. Feedback

We had some positive feedback on Discourse here, which is why I started the vote.

But dissenting opinions came up on discord and group calls once the vote was actually started. Ultimately, we could not reach quorum and ultimately rejected this grant. I will go into the details of why quorum was not met below.

I want to point out 2 process/tech problems here:

  1. We are not doing a good enough job collecting dissenting opinions; they often come only after a vote is started, rather than before a vote.
  2. Conversations are documented across several tools


For 1:

  • Processes: I understand some of the psychology of expressing positive versus negative feedback (it’s generally harder to publically say “no” about things). So I’m not sure how best to improve the processes here. I’m open to suggestions.
  • Tech/tooling: Having an off-chain mechanism to gauge interest in a proposal could help lighten the overhead of publically stating dissent. Perhaps even letting non-committee members (Core Dev, Community Members, other DAOs/Users, etc.) weigh in would be nice. I can imagine this being a feature of Workstreams where a grant application could have off-chain community polling + finalized on-chain vote/funding. This would not totally solve this issue, but I think it’d at least make it easier for people to show dissent without too much overhead. From there, we could follow-up with request for feedback.

For 2:

  • Tech/tooling: Some of this will be solved by migrating our Grants to Workstreams. It will help us keep more of the discussion + voting all in one place.
  • Processes: With that said, we should do a better job creating a culture of taking note of conversations and not being afraid of voicing dissenting opinions out in the open. Talking about “no” should be as easy as talking about the weather imo.

Hello @bordumb,

Thank you for the detailed feedback. I believe it is also important to give our perspective on the process to find a way toward resolution.

Smart contract work

To begin the discussions, it will be relevant to bring here the story of how we have been communicating with Radicle on multiple fronts throughout the grant process.

To mention a little about the Proposal Inverter; it is initiated as a research project, 8 months ago, in collaboration with Blockscience, Curve Labs, TEC, Longtail Finance and Prime DAO. BlockScience, Curve Labs, and Long Tail Finance as contributor organizations all have expertise in their areas of contribution, from product development to mechanism design specification.

Once we decided to turn the initial research into a product, we reached out to one of the key members of the Radicle team to introduce us to Radicle Drips team to talk about potential integrations.

As our mission is to bring co-funding opportunities and investments to the web3 ecosystem, we decided to always integrate features to Proposal Inverter either with organizations that will co-fund the product (grants) or co-build with us.

In one of our first calls we met with Andrew, with whom we started to build a more serious relationship towards exploring collaboration and seeing the possibility of interest in case we wanted to apply for a grant. We decided to apply for a grant and asked Andrew if he would advise us throughout the process by participating in one of our work sessions once a month to have eyes on our development and product roadmap.

For the last 3 months this has been an ongoing activity, and the next call was supposed to be within these weeks, where we were planning to present the backend spec to complete the second milestone presented on our proposal.

After we applied for a grant, it was communicated with us in such a manner that we, all of the 9 members of the Proposal Inverter team, thought we were going to get the grants based on milestones completed / when they are completed. And we initiated the changes to the MVP spec to integrate Radicle Drips mechanism. Once the mechanism design specs were completed, we shared that with Andrew, then with his advisory we decided to kick start the backend and design phase earlier on (wireframes, user stories, etc)

We started to work with Byterocket Team, our long-time collaborator from different projects such as PrimeDAO and Kolektivo. We started to work closely working with byterocket’s founder Marvin Kruse. You can check Marvin’s linkedin ( and github (marvinkruse (Marvin Kruse) · GitHub)!

Marvin’s involvement has been communicated with Radicle team members. For example, in our latest call with Andrew on July 7, we talked about the development of the technical spec of the product and stated that “ Around mid-next week the spec would be ready.” However, due to the conferences and unexpected events our development has been delayed. And again, we mentioned to the Radicle team that we would present milestone 1 and 2 together to not create a burden on the proposal process. So this made us believe that the trust was established by both teams and everything was going according to the plan.

We understand that the feedback loops with the Radicle team and planning could be updated more openly, but we never had an insight around our team’s technical expertise being a major concern to the Radicle team or that our grant process was rejected. We therefore thought it was enough to communicate with Radicle team members we were directly engaging with, and submit the milestone deliverables as we complete them.

In the end, in fact, our team has finished the tech spec. You can check from here : Proposal Inverter Tech Spec! Also, currently Byterocket and our engineering team are continuing to develop the project contracts.

On top of Byterocket’s team, our Engineering Team currently consists of;

Baran- 8 years in Vodafone as a solution architect lead to a 12 people team (

Sarah- She working with Longtail Finance and DataUnion (SarahKay99 (Sarah Kay) · GitHub)

Nuggan- Working with Token Engineering Commons; one of the core developers of Praise Reward System


“We had some positive feedback on Discourse here, which is why I started the vote.

But dissenting opinions came up on discord and group calls once the vote was actually started. Ultimately, we could not reach quorum and ultimately rejected this grant.”

We have had high-level conversations with the Radicle team since the initial kick-off of the project. We have a group chat that includes core team members to provide a direct communication line and ensure alignment. Moreover, we have had multiple sessions with Andrew, such that we have had serious feedback sessions to make sure Proposal Inverter is aligned with the Radicle community’s needs and Drip functionality.

As you mentioned, we have paid serious attention to the feedback that came from the Radicle community and tried to keep ourselves as accountable as possible. This is why we have been trying to be active on both Discourse and Discord, the only visible channels of the DAO to ensure we address any concern that arises. In relation to Discord, both during and after the grant progress, we have been unable to find any dissenting opinions that you mention, so if you could reference them it would be great. I don’t think there is a need to post all the discord links where Proposal Inverter is mentioned, but going over previous chats where “Proposal Inverter” is mentioned gives a definite clue.

One might actually see an organic use case demand for the Proposal Inverter, apart from the Drip integration, as a multi grant payment flow architecture identified by you. As Andrew mentions, “I agree that joint funding of grants is a super interesting problem. The main project/team I’m aware of that’s working on this is Proposal Inverter.” Discord, managing projects with multiple funders is what the Proposal Inverter is trying to solve, and this again signals an approval of what we are trying to achieve together.

Overall, it is hard to understand how can teams collaborate with the RadicleDAO throughout the grant process when there are positive responses on all public channels, there is an ongoing engagement with core team members that signal towards consent of the continuation of the collaboration, and there is no provided link to track the voting of the fund.

Moreover, the lack of transparency in this process is not only a feedback for RadicleDAO’s process, but also a big risk for projects that make budget plannings and hires accordingly to complete the milestones.

By relying on the fact that our grant would be funded based on milestone completion, we hired two more engineers, and had talks for adding on new team members. The rejection of the grant leaves us with nothing but confusion.

Unironically, Proposal Inverter Could Have Alleviated Some of the Problems We Faced in This Process

1. Adding and Removing Contributors can be transparently viewed by anyone, thus providing the most up to date composition of the team and changes that happen throughout the project’s process.

2. It is transparently visible from the Day1 of the project whether a funder commits to fund the project for the outlined deliverables, and has deposited the funds. Therefore, there wouldn’t have been need to rely on assumptions or unverified signals of commitment to build over the promises of a funder, and face the budgeting uncertainty in the middle of a started project.

3. Not directly a replica of what proceeded here, but if a funder decides to withdraw their funding, the contributors can still have time to secure a time to either a) progress on the initial stage of the project through guaranteed minimum working period or b) the buffer period they set as the duration, say 14 days, within which the funds continue to drip after a funder decides to withdraw. This way, a change in funder’s decision can still give the project team some time to continue progress and perhaps recoup by using the provided time to find new funders.

Suggestions for Moving Forward

We are both people committed to transparency and we personally care about the people in the Radicle team, and it is our hope that we can form a common understanding about how to move forward. Below is what we want to recommend as follow up action steps;

  1. Have a transparent and an open call next week all of us with our engineering team as well to go over the work that was done by the Proposal Inverter team. If we can find a middle ground, perfect. If the requested grant doesn’t make sense to Radicle treasury anymore, at least let’s have that communication clear.

Since we made plans and hirings according to the grant that was expected we would prefer the middle ground but if not, no hard feelings if we communicate transparently and come to a conclusion together.

  1. Anyone from the Radicle team that wants to build an internal structure, please let’s arrange a user review for Proposal Inverter to hear all of your pain points, how you envision the product adding value to the problem you are trying to solve, and let’s pinpoint needs and build this in coordination and collaboratively.

Since day one, we are aiming to build interoperable parts of Proposal Inverter partnering with DAOs and builders, openly, collaboratively, and again with love and respect to all the work that’s being done by those web3 free agents that are trying to bring prosperity to the ecosystem. Our actions represent our values. Our value is to build in open and build with collaboration.

Thank you in advance !

1 Like

Thanks for all the details @Mertozdal

Yes, I agree having this sort of tooling in place would have helped ameliorate a lot of the issues we’ve had.

Regarding a call in the coming weeks:

Yes, let’s try to setup a call in the coming weeks.

I think it’d be good to get as many committee members and a few Core Dev members you’ve chatted with in the past on this call.

Let’s coordinate this in the #primedao space on the Radicle Discord.

I’ve added scheduling link here: LettuceMeet - Easy Group Scheduling

Note: Wave #1 for grants has ended. So we effectively are powerless to vote on your grant. We will still discuss and give feedback, but our hands are tied in terms of voting, approving, or funding until Wave #2 starts. We are aiming to get this done in September.

Regarding dissenting opinions

…we have been unable to find any dissenting opinions that you mention, so if you could reference them it would be great.

The best “written” dissenting opinion I can provide is the rejection on Nonce 24 of the Gnosis Safe here. That rejection is for your grant application.

Unfortunately no other dissenting opinions are written anywhere on Discourse, Discord, or anywhere else.

We started a vote, it did not reach quorum, so I went around and had discussions to understand why we could not reach quorum.

What I have written is a paraphrasing of those discussions.

In the short-term:
We can improve this by making it a policy to add the URL of the multi-sig to Discourse for every vote on a grant. This - as we have seen - can run into human error.

In the long-term:
Having all of the grant process living in one UI should help the most. This would make it fully and automatically transparent (i.e. no human error).

With that said, actually getting people to write down dissenting opinions remains an elusive problem. If you have any suggestions here, I’m open to hearing them.