docs(application): application for web3 open jurisdiction stack

[0xlyd]

Project Abstract

The scope of this project is to resolve issues related to grants and treasuries management by understanding the specific jurisdiction needs of the ecosystem and creating a technical stack that mitigates those problems.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @0xlyd:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks for the very detailed application. I have a few smaller questions: Could you already specify which tech you will use for the POC (e.g., substrate or ink!)? Also, will it come with a simple UI or CLI tool? Do you already know where you want to publish the paper, if so feel free to specify this.

[0xlyd]

thanks @Noc2 for the quick revert appreciated 🙌 getting back to your questions

Could you already specify which tech you will use for the POC (e.g., substrate or ink!)?

Gut feeling says Substrate pallets but we do not want to exclude the idea that in the future we may propose some smart contract based functionality especially given the evolution that Ink! is having. But for now I can state that 95% of the work would be around pallets.

Also, will it come with a simple UI or CLI tool?

We aim to build a simple UI, eventually these are all functionalities and use cases that need to be accessible also to not strictly devs. We are trying to think "ahead" and make sure that this can be usable even for non-technical folks.

Do you already know where you want to publish the paper, if so feel free to specify this.

Considering the scope of our research, which has implications across Web3 and not only for the Dotsama ecosystem, we will submit the paper to prominent crypto outlets such as Messari, Coindesk, and Cointelegraph.

Let me know if there is anything else that we could help with!

[Noc2]

Thanks for the quick reply here. Could you integrate this into the milestone and update the application accordingly? Regarding substrate or ink! it would already help if you say you will use one or the other as part of the application. This way, we know, for example, that you are not going to use Michelson and deploy it on Tezos. Just to give a random example here ;-) Also, you can always create an amendment later. So theoretically it would already help if you mention substrate and create an amendment in case you want to switch to ink!, which we highly likely would approve.

[0xlyd]

Thanks again @Noc2 very impressed by how quick these iterations are :)

Just pushed those integrations we understand that observation. We just didn't want to exclude anything a priori but all good if we are always free to propose amendments as we hear user feedback 🔝

Kindly let us know if you need anything else on our end 🤝

[Noc2]

Thanks for the update. I'm happy to go ahead with it and share it with the rest of the team.

[keeganquigley]

Thanks for the application @0xlyd very interesting and fascinating read. Two questions:

• Can you go ahead and remove 0d. and 0e. from milestone 1 since they are null?
• Can you elaborate on how human oracles would work and how they would be incentivized?

[keeganquigley]

I would disagree with the statement in line 46, as the Web3 Foundation Grants Program is off-chain and therefore a different process. Paying grantees per milestone helps to avoid this.

[0xlyd]

Definitely the current approach brings a greater level of flexibility to address such issues but we feel that's not enough long term. In our first informal chats we asked around if a system of on-chain escrow and dispute resolution would be beneficial to improve the current process. It's a complex topic as we all know and this is why it's part of the research milestone.

Our main point around this is the current lack of a contractual agreement and jurisdiction between Web3 Foundation and the recipients of funds. This can lead to milestones that have been paid but not completely delivered (close an eye) or where the expectation and delivery differ substantially. This is normal when subjective KPIs are involved.

A secondary, but important point, mostly from the recipient point of view is the absolute trust that they need to place on the Web3 Foundation. De facto, Web3 Foundation unilaterally makes the final decision whether a milestone is considered completed or not and there is no appeal to it. What if the recipient is right and the Web3 Foundation is wrong?

What we would like to do is exploring the above topics, engaging with both sides and eventually propose a technical solution that absorbs these requirements

[keeganquigley]

Thanks @0xlyd what I was getting at here is that I don't think you can lump them all into one category. W3F grant funds don't come from the treasury, unlike treasury proposals and bounties. Therefore a "grant released by the Web3 Foundation" doesn't fall under treasury management. It's a separate source of funding altogether.

The majority of your proposal focuses on the treasury, and personally this is where I'd like to see the focus of this research. I definitely think these are needed tools for the treasury, but I'm not so sure when it comes to the W3F grants program. The long term goal is to move the grants program entirely on-chain, but until that happens, the grants committee will remain in control and some trust in W3F will be needed.

I'm no legal expert, but I do agree with the overall need for decentralized arbitration. I hope we can eventually further decentralize the grants program, similar to how the Polkadot council was dissolved and control was handed over to the larger fellowship and community.

For now, I'd love to see a PoC proposed and built for the treasury, so that when it does come time to move on-chain, we can utilize it.

[0xlyd]

@keeganquigley thanks for expanding your point, appreciated 🙏 .

I can see it better now from W3F point's of view and why you would like us to focus exclusively on the treasury.

The reason why we would still like to include grants in the scope of our research is because we feel that it may help in creating a more flexible stack for future needs. We can't be sure that W3F will eventually adopt 100% of the stack of the treasury or if it would need something customized.

Just a closing note on this. While creating this proposal for example we also thought about DAO treasuries that are called so but are not generally completely on-chain like Polkadot's. They are sort of an hybrid.

What we would like to do (just for the architecture part, the POC would be a functioning component/module) is to envision a system that's flexible enough to tackle on-chain, off-chain and hybrid approaches. If we do focus only on the current Polkadot Treasury needs it will absorb those requirements but may not be able to accommodate other needs.

If your counterpoint is "but those other needs will come from oranges not apples, don't worry about that and just deliver the best for apples" it's a fair argument. My thought on this is that eventually we are talking about fruits (to stay in the analogy 😛 ) and how work aims to be "generic enough", but if you strongly advise against this we will amend the proposal accordingly 🤝

[keeganquigley]

Thanks @0xlyd for defending your position. Thanks also for your point on hybrid DAOs, as our ecosystem typically doesn't use tools like Snapshot for the most part since our governance is all on-chain. I also agree with your assessment that we currently can't be sure of what the future of the W3F grants program will look like.

I think as long as the distinctions are made clear, the research could overall be beneficial for the community.

[keeganquigley]

I want to clarify here that the W3F Grants Program is completely separate from treasury proposals. Can you specify whether you are referring to treasury proposals and bounties here?

[0xlyd]

The discussion guide sample is regarding treasury proposals indeed 🙏 but just to be clear we would like to explore also grants flow of the Web3 Foundation (and others) to understand all the nuances.

Eventually the common abstraction between all these is the movement of funds from a common pot for a common good through a public initiative. We are interested in making this process as bulletproof as possible

[keeganquigley]

Thanks @0xlyd perhaps this is just a matter of confusing terminology. For example, I wouldn't call a successful treasury proposal a "grant". But maybe that's just me. Also bounties and child-bounties are just as important to explore as referendums.

Being that the W3F grants program is currently off-chain, comparing it with treasury proposals is kind of like comparing apples & oranges at this point. For example we do have contractual agreements with grantees, as well as terms & conditions, a contributor license agreement (CLA), private grants, etc. Essentially our program has some legal frameworks that the treasury might not have. I think this might create different considerations for each.

The W3F grants program also has a smaller scope. We mainly fund software and research, whereas the treasury has an expanded scope and can fund other things such as events and education initiatives. I see the treasury as more of a decentralized, open pot of "public funds".

It may seem pedantic, but in my mind the terminology is very important, as it could potentially distort the data if the participants are confused as to what you are referring to. The complexity of our ecosystem requires the need for explicit terms. If you could update your application to distinguish the difference between the areas of research I think this would help to avoid confusion. Perhaps you could split up the survey into two; one for the treasury and one for the grants program.

[0xlyd]

Perfect @keeganquigley we are totally aligned on this, thanks for sending inputs proactively on how we can improve the proposal 🙏

I'll just wait for your feedback on the other main point and then amend the proposal accordingly: either by splitting the scope of research as suggested here or by focusing in building a solution only for the treasury 🤝

[keeganquigley]

Thanks for your thorough answer @0xlyd sounds good! Feel free to ping me when I should take another look.

[semuelle]

Thanks for the interesting application, @0xlyd. I agree with what Keegan and David are saying. But also, I think it doesn't make sense to approve M2 for 50k if the feature set is completely unknown. Might be better to make this a follow-up grant.

FYI, we had an interesting grant application related to treasuries and proposals that ultimately didn't stick. Might be worth reaching out to the teams involved.

[0xlyd]

Thanks @keeganquigley for the thorough analysis, appreciated 🙏

• Can you go ahead and remove 0d. and 0e. from milestone 1 since they are null?

100%, this was a misunderstanding from my end. I thought they had to be there in any case. We'll update the PR

• Can you elaborate on how human oracles would work and how they would be incentivized?

Human oracles' activity will be paid by a fee. Let's imagine that the Court Registry has 30-40 specialized Courts in each subject matter. One Court could be around Substrate and the panel may have technical experts that are senior engineers. The Court will have a base fee higher compared to one that doesn't need that level of seniority.

How much should the fee be, should it be increased/decreased based on priority or number of people involved etc. all these will be details on which we would like to engage during the interview phase.

As a side note here. In the past, we built an ODR that embedded game theory in order to subsidize fees as much as possible. The issue with this type of approach is that it may work for micro claims but it won't scale for increasingly complex disputes, where it's not a matter of a binary decision but probably the oracles need to check scope of work, agreements etc.

[0xlyd]

Thanks @semuelle for your comment and for bringing these points up

I think it doesn't make sense to approve M2 for 50k if the feature set is completely unknown. Might be better to make this a follow-up grant.

Initially we were oriented into making a research only proposal but on a second thought the feature set is not completely unknown. We do know that a neutral third party should be there in between Web3 Foundation and the recipient of funds (in the example of grants program). This will likely take shape of a Court Registry that we envisioned as POC.

The real "juice" of our work will be in the architecture, us or any other team will be able to create follow up grants for subsequent deliveries based on it. If we exclude this part, at the end of this work we would have a non-actionable plan but just some data points from where people should start.

Eventually this is why we decided to create an end-to-end proposal despite some details that will be clear only after M1 (but that will be included in M2)

FYI, we had an interesting grant application related to treasuries and proposals that ultimately didn't stick. Might be worth reaching out to the teams involved.

Thanks for sharing 🤝. I skimmed through the proposal, it was an interesting read (I'll read it more thoroughly over the weekend). One major difference I noticed is the following: anything we will be researching, proposing, doing would not imply any major change of mechanics or breaking changes that wouldn't be retrocompatible or future proof.

In their proposal they were envisioning changes to the voting system in order to increase participation. We do not want to change current mechanics of current steps but rather inserting new components into the flow (such as escrow and dispute resolution) to make it more bulletproof.

So ours is not a "visionary" proposal trying to change the system for the better but rather the addition of some technical components 🤓

[0xlyd]

Just leaving an update here for the entire team (and whoever is interested in this proposal). We received the insights and suggestions (thanks especially to @keeganquigley for the great convo so far 🙏 )

We'll be making the proposal more accurate by Wed 19 and following up on the relevant threads.

Thanks all for the smooth collaboration so far 🔝

[0xlyd]

Hey @keeganquigley 👋 hope all is good on your end.

Just pushed some amendments following up our conversations.

"Changelog"

• added a bit more clarity throughout the proposal around the fact that we would like to focus on treasury proposals but a secondary attention to grants will be given
• split the example discussion guides
• minor fixes here and there

Looking forward to your feedback! 🤝

[Noc2]

Thanks for the updates. I'm still happy to go ahead with it.

[keeganquigley]

Thanks for the changes @0xlyd looks great, and I definitely think this project is worth exploring and that the data would be useful. I used to act as a guardian for the Aragon Court system built on Ethereum back in 2018, which this project reminded me of. So I've always found digital courts to be fascinating.

That being said, during our internal call today we discussed that 80k is usually above the norm for a research grant. Therefore I tend to agree with @semuelle that perhaps it would be better to reduce the scope and have M2 as a follow-up grant?

You mentioned a possible go/no-go situation (in terms of feasibility) in your application; what happens if this becomes the case after M1? Would you still want to go forward with M2 and publish the paper regardless?

[0xlyd]

@keeganquigley thanks appreciated the quick reply! That's quite interesting 😎 : Aragon Courts is definitely a product that we know quite well :). Your experience will definitely help us with our scope of work, looking forward to have chats about it.

As per your questions:

[...] 80k is usually above the norm for a research grant. Therefore I tend to agree with @semuelle that perhaps it would be better to reduce the scope and have M2 as a follow-up grant?

We understand your point of view, we thought about this before sending the proposal. We really would like to be able to include technical scope within this first proposal without splitting research and tech for a couple of reasons:

1. we currently have tech bandwidth to support the design of the infrastructure/stack and the POC (we may later too, but we can't be sure about it)
2. we would like to avoid a situation (as community) where we have just a research in our hands because it's hard to find again a team so vertical on legal tech like ours

[...] what happens if this becomes the case after M1? Would you still want to go forward with M2 and publish the paper regardless?

Great point 🤝 . The rationale behind that is the following: we suspect that reasons behind a "no-go" could be temporary (e.g. the community doesn't want to include this system as of now but would like in the future). If that's the case we would still like to "wrap up" this first scope of work with a demonstrative build that follows M1 📦 (basically how to take M1 and shape it into reality). This will allow us, or any other team, to have a clear input for development. Without M2 we would leave future builders quite clueless on how to move this forward would a no-go become a go decision at a later stage.

Hope this clarifies a bit of the rationale. I am glad these were brought up as both were things that we discussed internally before coming up with the proposal 🙏

[keeganquigley]

@0xlyd thanks for your thorough answers. Good points, and I agree that it would be valuable to see a working prototype in action. I'm happy to go ahead with it, and looking forward to seeing the results!

[0xlyd]

@semuelle just checking in as I see that yours is the only missing approval. I think both me and Keegan moved the conversation ahead on some of your points and hopefully those were addressed. Let me know if you have any further questions/doubts 🙏

[github-actions]

The applicant has requested the discussion of the application to happen in a private chat room.

[Noc2]

@0xlyd Sebastian is currently OOO (as well as some other members of the team). I pinged everyone again this morning. Sorry for the delay. I also only now noticed that you requested a private discussion. I will create the chat room.

[0xlyd]

@Noc2 thanks for the update David, appreciated 🙏.

Re the chat room it's fine we can move ahead even here, we initially thought we would move faster with an IM channel but you were super responsive/reactive here on GH. We don't have preferences here or privately both ways are fine 🤝

[semuelle]

Some things I noticed skimming the changes and comments:

• Software should be under an open source license, not CC.
• Are you not planning to have the paper peer-reviewed?
• Are you sure you want to make M2 dependent on the article being published? Depending on the venue, this may take some time?

Regarding M2 and follow-up grants: I understand it would be nice to have certainty, but I also think it would be worth having a discussion about the results of M1 and the resulting POC architecture.

[0xlyd]

@semuelle welcome back thanks for the prompt reply appreciated so that we move forward 🙏

Regarding your questions replies inline below

Software should be under an open source license, not CC.

Fair point we have updated the proposal 🤝

Are you not planning to have the paper peer-reviewed?

Just to avoid confusion we are aiming at publishing a non-academic paper. The aim is to analyze thoroughly the use case, which we believe applies to the wider blockchain ecosystem, and publish it across web3 media outlets (e.g. Messari).

Are you sure you want to make M2 dependent on the article being published? Depending on the venue, this may take some time?

Thanks for bringing this up, we are fine with waiting. Eventually given that is not going to be an academic paper we think, given the importance of the use case, that some tier-1 media outlet will be interested in our research

Regarding M2 and follow-up grants: I understand it would be nice to have certainty, but I also think it would be worth having a discussion about the results of M1 and the resulting POC architecture.

Agreed. We discussed this previously especially with @keeganquigley (ref). Our point of view is that the actual delivery is M1 + M2, the reason we have split them serially is because of the different team/costs allocated but we consider both equally important to be delivered. This also allows us to have a discussion regarding the findings of the research before we move ahead with anything technical.

The output of M1 (research/validation/analysis) + M2 (architecture) packaged is what eventually anyone in the future would need to build further the system. Any follow on grants, ours or from other teams, should be based on this work that we will finalize together so we will definitely have a chance to engage with each other to make sure that we reach this goal.

[semuelle]

just checking in as I see that yours is the only missing approval.

Just to clarify: Level 3 grants require five approvals, mine would only be the third. That being said, I think there is still an argument for separating M2 into a separate grant. First, M1 would be Level 2, requiring only one more approval. Second, it would give us and others time to study the results of M1 and its implications for M2. Third, M2 itself should probably be separated into multiple milestones. For example, I think it would make more sense to publish the infrastructure document before submitting the POC.

In any case, I will again ping the rest of the committee.

[dsm-w3f]

@0xlyd thank you for the application.

After reading the application document and the comments in this PR, I agree with the comments that an incremental delivery would be adequate in this case. There are two main deliverables, the research and the PoC (or MVP), and many risks involved in signing these two as a research grant. There is no technical definition for what the PoC (or MVP) will be. The adequate template for the PoC (or MVP) is the one for a software development grant, which includes the details needed for specifying the software and in this way, we can evaluate them after. With the current specification, you could deliver anything and we will not be able to evaluate it. So, for me, this is enough for a no-go from our side. Additionally, a PoC in my understanding is something very small, just to test the concepts, maybe you mean MVP instead of PoC, which is more compatible with the amount asked for developing it (50k).

Furthermore, previous research grants showed to be possible to deliver good research at a 30K budget. The 20 interviews target is a bit high in my opinion, maybe you could make fewer interviews, add the paper as a deliverable of M1 and deliver something complete, i.e., the research as a first grant. This would bring confidence for a follow-up grant to develop the MVP.

Having mixed software and research scope together in only one grant brings us high uncertainty about the scope of what will be produced. In this state, I will not support this grant. Let me know if you change the approach for the grant.

[0xlyd]

Apologies for the delay on our end but I had to discuss this internally before getting back to you 🙏

We are still evaluating some implications on our end of moving this ahead as we were clear not doing this as a pure research but I see that seem to be the only option now. In order to make a more informed decision we would need a bit more information from your end.

Level 3 grants require five approvals, mine would only be the third

@semuelle just for us to understand the flow better. We read that Level 3 grants would require five approvals. But then it seems like at each iteration one more person gets looped in (incrementally to reach the threshold) with a different point of view and perspectives. It looks almost like we need to get 5 approvals basically one by one instead of proposing this to a committee of n reviewers (out of which we need to get approval of 5) that discusses this internally and then gets back to us with uniform feedback.

One example? We discussed for a few weeks about M1 + M2, but now we reach a point where there is a "no-go" for tying up research and development together. Wasn't this clear from the beginning? Mine is not an argument I would like to understand the process better so that we are more efficient and we avoid losses of time on both ends 🙏

Third, M2 itself should probably be separated into multiple milestones. For example, I think it would make more sense to publish the infrastructure document before submitting the POC

Agreed, we went with the logic of putting things together in order to reduce overhead as much as we could but definitely we could further breakdown as you suggest 👍

@dsm-w3f thanks for contributing to the discussion 🤝

Additionally, a PoC in my understanding is something very small, just to test the concepts, maybe you mean MVP instead of PoC, which is more compatible with the amount asked for developing it (50k)

We meant PoC, I personally don't see how we could deliver an MVP that tackles such a complex problem with 50k USD. So this may be another blocker. We are expecting that in order to deliver this successfully we would need to involve team members with high seniority (+8 yrs of exp.). Not only in tech but also on the legal side.

Maybe you could give us a bit of guidance on how you see possible delivering an MVP with that budget? I don't know if there is a delivery that you are aware of that is close to this scope of work. That may be helpful to further re-elaborate the proposal 🙏

The 20 interviews target is a bit high in my opinion, maybe you could make fewer interviews, add the paper as a deliverable of M1 and deliver something complete, i.e., the research as a first grant

Noted on this. It's a good input, we'll think this through. For now we are still convinced that 20 is a good threshold to aim at. Eventually this is not user research in terms of usability, it's much wider. We need to understand all possible uses cases of a complex problem with quite a few different stakeholders. We are not sure that we would get enough broad exposure to the problem with the usual optimal number of interviews (ref)

This would bring confidence for a follow-up grant to develop the MVP

Understood we see your point. The reason why we structured in this way was to commit to building at least the "kickoff" of this endevour. Whereas by splitting we may not be available to follow up on the research and this would be a missed opportunity for the ecosystem if no one else picks this up but I guess that we or you can't do much about this problem 🙏

Next steps:

• @dsm-w3f I am looking forward to your thoughts re seniority, budget (I don't know if there is a public reference for hourly rates etc.) and MVP
• @semuelle if there is a way we could optimize the process that would be great otherwise we'll keep doing back and forth as we have done so far

With these two pieces of info we should be able to make a decision either of closing this PR or reducing its scope to just M1 as suggested by the committee ✅

[dsm-w3f]

@0xlyd thank you for the answer. Just for notice, I think your proposal is very interesting, and would be nice to have it in the ecosystem. However, my comments are based on the structure of the proposal, which I think would lead to problems in the deliveries and evaluation. Answering your questions.

Maybe you could give us a bit of guidance on how you see possible delivering an MVP with that budget?

My comment about the 50k budget is based on other grant proposals that we had before that could deliver good work within this budget. You can take a look at the approved applications here: https://github.com/w3f/Grants-Program/pulls?q=is%3Apr+is%3Amerged

Furthermore, regarding the usage of senior developers, I agree that you need at least one, the CTO. However, if you plan to hire only Sr. developers maybe you need a higher budget. Efficient companies use the pyramid model, in which you have fewer senior developers and more junior ones. Another option to hire a team that fits the budget is to use people from locations like LATAM and Southeast Asia, which has very good professionals at an affordable price. These choices are up to you.

Regarding the number of interviews, I understood that you are interviewing for requirements elicitation and validation and not for usability tests. I doubt that the assumptions and affirmations from the link provided are valid in the context of the requirements engineering. This magical number of interviews can vary from field to field, see ref here. My concern is practical as well, the last grant that proposed to do interviews did less than expected because of the availability and difficulty to find people that accept to be interviewed. What is your plan if this happens?

[semuelle]

if there is a way we could optimize the process that would be great otherwise we'll keep doing back and forth as we have done so far

Sorry for the late reply, @0xlyd. Each committee member reviews applications on their own schedule, meaning they could overlap or be sequential. One reviewer asking for a specific change is not a requirement for continuation of the review, but rather an invitation for discussion. It is up to the applicant to adopt change suggestions from individual reviewers. No reviewer would make suggestions that would make the application less likely to succeed, but I understand that this can be challenging, especially for a Level 3 application.

In your case, Diogo and I made similar/the same suggestion and Keegan previously agreed, so it seems to me that incorporating the suggestion would put you at four approvals.

Hope that helps. Let me know if you have any further questions, or feel free to ping me on Matrix (@sebastian:web3.foundation).

[0xlyd]

Hi everyone 👋 just leaving an update here as it's been a few days. Thanks @dsm-w3f and @semuelle for the further comments and clarifications.

We have been discussing internally on how to make this possible in a sustainable way for us but it doesn't look like there is a way due to the seniority of our team.

I'll be updating on our final conclusions by the end of this week, apologies for the delay 🙏

[dsm-w3f]

@0xlyd let us know if you find alternative options for this grant application to discuss.

[takahser]

@0xlyd apologies for the delay here. I appreciate you tackling this highly relevant issue around dispute resolution for Web3 treasuries and grants.

However, I recommend narrowing the initial scope to focus specifically on M1. Extending this milestone to include some initial findings would be useful as well.

The approval for milestone 2 in the form of a follow-up grant can then depend on the demonstrated usefulness of the research results. If the findings are convincing, a follow-up grant would likely be supported. Basically, I want to ensure the research phase provides a solid basis before approving further development.

To conclude, I'd be more than happy to support a project like this, and think the problem area you're looking into has great potential value for the ecosystem. Also, feel free to have a look at my inline comments.

[takahser]

When a grant is released by the Web3 Foundation, Polkadot, or Kusama Treasury, there is currently no recourse if the recipient fails to deliver or if there is a disagreement between the issuer and recipient regarding KPIs or Service Level Agreements.

As already mentioned by @keeganquigley, there is actually a recourse mechanism within the W3F Grants' Program, as we do not support any upfront payment. I think clarifying this would help avoid any confusion.

read this thread

Very interesting read. I was just wondering if you engaged in this discussion as well? Alternatively, I was wondering if you could lead me to some resources where your team engaged in discussion with the community, for example on the polkadot forum or on X.

[takahser]

I think it's a good idea to anonymize certain data here. Could you explain how this would be decided and who'd be the decision maker?

[takahser]

Suggested change

	Throughout the discussion guide we aim to leverage NPS and similar metrics to be able to extract readable graphs that can inform the subsequent development of the stack and also to be publicly available references for the community of the work done.
	Throughout the discussion guide we aim to leverage NPS (Net Promoter Score) and similar metrics to be able to extract readable graphs that can inform the subsequent development of the stack and also to be publicly available references for the community of the work done.

I just thought it'd be easier to read if this acronym would be explained at its first appearance (rather than 2nd).

[takahser]

Suggested change

	While we anticipate observing a higher level of dissatisfaction in proposals and grants that involve subjective KPIs, we will be judicious in selecting relevant interviewees, adhering to the principle of diminishing returns. Ensuring compliance with legal and ethical standards, we will consider utilising a variation of the Net Promoter Score (NPS) to gauge dissatisfaction with the outcomes.
	While we anticipate observing a higher level of dissatisfaction in proposals and grants that involve subjective KPIs, we will be judicious in selecting relevant interviewees, adhering to the principle of diminishing returns. Ensuring compliance with legal and ethical standards, we will consider utilising a variation of the NPS to gauge dissatisfaction with the outcomes.

[takahser]

The community will have access to all recorded interviews

Will these interviews be anonymized? Regarding the example questions, I'd assume you're referring to treasury proposals rather than the grants program here, as for us (W3F Grants) it's a matter of compliance with the regulators, hence it doesn't make any sense to question it imho.

[takahser]

Could you give some specific examples, such as discussions/threads/blog articles/podcasts/conferences you've contributed to?

[takahser]

What format/tech are you going to use to write the paper - latex? Or some kind of binary format?

[takahser]

Suggested change

| 1 | **Research** | We will conduct research on a minimum of 10 past proposals and 10 grants, ecosystem prizes and future initiatives to gather some information around jurisdiction needs of the ecosystem. We think this sample should be enough to make informed decisions and make sure that the future technical delivery is supported by data.We will extract common data points, abstracting away the details, on which we will engage with stakeholders in the subsequent activity |

| 1 | **Research** | We will conduct research on a minimum of 10 past proposals and 10 grants, ecosystem prizes and future initiatives to gather some information around jurisdiction needs of the ecosystem. We think this sample should be enough to make informed decisions and make sure that the future technical delivery is supported by data. We will extract common data points, abstracting away the details, on which we will engage with stakeholders in the subsequent activity |

[takahser]

Suggested change

| 2 | **Interviews** | We will run a minimum of 20 interviews of about 45 minutes with relevant stakeholders, giving priority to the engagement around treasury proposals but also touching on the grants processes. All the interviews will be following a discussion guide format that aims at understanding the needs that need to be solved by the open jurisdiction stack.Examples of data points we will extract through those interviews are given in the section _The methodology that will be applied._ |

| 2 | **Interviews** | We will run a minimum of 20 interviews of about 45 minutes with relevant stakeholders, giving priority to the engagement around treasury proposals but also touching on the grants processes. All the interviews will be following a discussion guide format that aims at understanding the needs that need to be solved by the open jurisdiction stack. Examples of data points we will extract through those interviews are given in the section _The methodology that will be applied._ |

[takahser]

Suggested change

	| **0c** | **Methodology** | We will provide a brief documentation of the methodology and process used for the researchThis builds up on the previous milestone. |
	| **0c** | **Methodology** | We will provide a brief documentation of the methodology and process used for the research. This builds up on the previous milestone. |

[semuelle]

pinging @0xlyd

[0xlyd]

Just leaving a quick update. We did discuss internally, I apologize I didn't find time to update everyone I'll be doing so within the end of this week 🙏

[0xlyd]

Here I am thank you for your patience, and we apologize for the delay 😇 . As mentioned earlier, we took some extra time to discuss this matter with our wider network to determine how to proceed within your boundaries.

After careful consideration, we have concluded that it is not feasible to proceed with the proposal. The main reason is that we believe we would end up shouldering the costs for ensuring a meaningful delivery. Unfortunately, we cannot sustain these costs ourselves, as there wouldn't be any direct or immediate benefit for Jur and its ecosystem and community.

In determining the number of interviews, our objective was to collect sufficient feedback to ensure a reasonable level of certainty regarding product-market fit. Given the significance of this vertical and its impact on treasuries and allocated value, it is important in our view to establish a methodology that has an increased chance of delivering products with market fit 🎯

With just 20 interviews, we would have collected feedback from less than half of the parachains on Polkadot alone. According to the information available on parachains.info (which lists a total of 193 projects), our estimated number of interviews would have allowed us to gather feedback from ~10% of all projects in the ecosystem. We considered this to be a reasonable minimum for obtaining meaningful insights about the problem and evaluating the suitability of a potential solution.

Considering the target audience, we believe that reducing the number of interviews (as suggested) would not make the project effective. It would force us to rely on assumptions instead of gaining a genuine understanding of the problem and its use cases. This approach increases the risk, later on, of developing a proof of concept (POC) or minimum viable product (MVP) in unexplored directions, potentially resulting in an unusable deliverable 📦.

Likewise, we are hesitant to engage junior staff to cut costs (as suggested), given the complexity of the subject matter. The problem at hand directly impacts treasuries and has the potential to affect the entire allocated value, amounting to millions of dollars in annual spending. We believe that a team of senior engineers and legal tech professionals should be involved.

We also considered taking on the research costs ourselves, in collaboration with W3F. However, we carefully evaluated the implications for the subsequent POC grant and how the discussion surrounding it would unfold. Taking into account similar processes with other grants, we concluded that several weeks of meaningful discussion would be necessary before approving a budget for the POC or MVP. We fully understand the need for Web3 Foundation to allocate capital wisely in the face of uncertainty. However, at this time, our priority is to focus on activities that generate growth and metrics for the Jur Network, rather than ecosystem activities that only cover a portion of the costs.

Thanks again to everyone involved in the discussion nonetheless 🙏

[takahser]

@0xlyd

Thank you for getting back with a thoughtful response.
I understand your reasoning for deciding not to proceed with the grant application in its current form.
Based on your assessment, I will go ahead and close this proposal. You are welcome to apply for a grant again in the future should you have a different idea. We're happy to re-open this PR in case you reconsider and would like to amend the proposal. Also, I want to wish you good luck with the project!

[semuelle]

@0xlyd, I am sad to see that we couldn't find a path forward. But I understand your reasoning and I appreciate the thorough and level-headed explanation.

As takahser said, you are welcome back anytime!

[0xlyd]

Thanks @takahser and @semuelle for stopping by to share your thoughts 🙏 I am glad that you could see our perspective it helps a lot to know that there is a deep understanding of the above topics (and their implications)

We'll definitely keep this in the back burner and re-surface it in case we see a feasible way 👀 .

Any team/person looking to work on such topics, feel free to reach us out anytime!