💡 Integration with cosponsor discussion

[Ryun1]

Area

Proposal Pillar

Is there new design needed?

Yes

What?

• Cosponsor is a crowd sourcing mechanism for governance action deposits

Why?

• Allowing proposers without 100k ada to submit proposals as governance actions via GovTool would drastically lower bar to entry.

How?

• discuss here

(Optional) User Story with acceptance criteria

No response

[m-i-k-e]

We should look at creating documentation for this, and other API stuff. That way, it would open it up for others to help debug, etc.

[Ryun1]

The current backend API for this seems to require the wallet signed payload
This is probably a blocker for tooling integrations

For a first step, maybe it makes sense to keep the wallet signed auth for the POST endpoints, but we can drop it for the GET endpoints?
What are you thoughts on this @nebojsact

[nebojsact]

@Ryun1 it looks like it already work on this way and data are available for get
Example
Proposals
Action types
If you have some specific api on your mind, just send me a link to check it directly.
Cheers!

[Quantumplation]

Hello!

Just chiming in to express my interest in this API for our catalyst funded "Cosponsor" project.

Cosponsor will allow users to crowdsource the 100k deposit requirement for proposals, and as such, we need users to be able to select draft governance actions ("Proposals" in your nomenclature) to "cosponsor".

We don't want to duplicate a bunch of work related to authoring, commenting on, editing, etc. proposals, so ideally we can query a list of proposals from govtools and potentially other sources.

Additionally, I have another request, that is perhaps better as another ticket.

To protect this from abuse, as funds are committed to the smart contract, they need to specify the exact details / hash of the proposal and metadata they are cosponsoring. This means that if the contents of the proposal change, it invalidates this hash, and the proposal can't be submitted.

Therefore, we'd like to suggest an additional step in the lifecycle of proposals on your platform; ideally, the author would be able to signal the proposal is in it's "final draft", or something similar, at which point the resulting details could be considered final for things like Cosponsor, to avoid invalidating user deposits spuriously. It'd be sufficient if this is a "soft immutability", i.e. allow the user to walk that back, but just display a warning that external systems might have started depending on these details, for example.

[m-i-k-e]

@Quantumplation Very interesting idea, and I think it would be popular.

Several questions:

1. Do you know the mechanism whereby people would be able to contribute to the 100,000 ada? How would that work?
2. GovTool calculates a hash of the metadata when the proposal is submitted on-chain, not when it's submitted as a proposal. We would have to figure a way of dealing with the hash, probably outside of GovTool.
3. We would have to think about how the writer or proposer of the Action gets to know when it's funded
4. Solve how the funds get into GovTool, or otherwise are associated with the proposed Action
5. I wonder if the deposit needs to be exactly 100,000? Would it be possible to overcollect or over pay?

[Quantumplation]

Hello; You can see a sketch of the idea here:

https://github.com/SundaeSwap-finance/cosponsor

1. They would deposit funds into a smart contract, and then those funds could be aggregated, or spent to create the proposal with the correct details and anchor.
2. What I'm suggesting is add an additional (optional) step in the workflow, after a bunch of discussion and editing, where the author can flag the proposal as "final" or "seeking funding" or something similar; This would be a soft lock on the proposal, preventing edits unless you clicked through a warning, but would allow people to calculate the expected hash of the metadata etc.
3. The way it would work is that the proposal would end up submitted through cosponsor, rather than through govtools; so you would monitor on-chain events for governance actions appearing on-chain, and then match them against existing proposals by metadata hash.
4. The funds don't get into GovTool at all
5. I believe the deposit needs to be exact, but the design of our dApp handles this.

[Ryun1]

Okay I think there are two topics here;
a) Allowing querying of proposal forum data
b) Integration of the forum with co-sponsor

a) I believe is already possible, as shown by @nebojsact 's comment
I think we can do some work to document the API, so tools can interface with this as needed
the Strapi instance does generate API docs
But we dont link to this anywhere in the docs
Lets move this discussion to #3138

for b) is more so what @Quantumplation is asking
I think some integration would be super valuable, for proposal forum users,
but it will require some design and building, happy to ideate here

There is probably two approaches

• Cosposor reads GovTool proposals, and allows submission on that platform (not sure if it has a user interface)
• Cosponsor integration in GovTool forum

For Cosponsor integration in GovTool forum;
I believe it makes the most sense that at proposal creation time users are given an option to link to a cosponsor
Then during the lifetime of the proposal, everyone can see a link to cosponsor page (or something?)
Then when the user goes to submit the proposal, GovTool will have to be aware of if sponsorship is complete
and then build the transaction accordingly

From the cosponsor side, how do you see these interactions working? @Quantumplation
is there plans for a API, to serve data on sponsorships, or would GovTool need to index chain?