Gov1 Social Contracts -> OpenGov Transition - Should there be a system?

Governance
1

YieldBay recently submitted Referenda 97 to the treasury, requesting payment for the development of polkadot’s yield farming dashboard.

For details please see our delivery report.

This work was approved by the council as motion #355 under gov1, but the proposal is currently failing with only 29% in favor.

The changes introduced with OpenGov left a few proposals like our own in the shadow realm.

The reason I’m writing this post is because some of these proposal including our own were passed under Gov1 by the council.

And there was a social contract to pay for the final milestones AFTER delivery.

Now we’ve delivered the promised work, but proposals like ours are currently being denied the payment for the same under OpenGov.

Since info for reimbursement wasn’t stored on-chain, there aren’t any special provisions for proposals like ours under the new OpenGov system… this means if the proposal doesn’t pass, we need to pay the development cost out of our pockets.

I believe we should respect everyone’s right to vote as they please and feel that they do not owe any explanation for their voting decision.

However, if builders acting in good faith are left at loss due to the recent change without a notice period, I believe it sets a bad precedent.

I personally believe it’s IMPERATIVE to attract and retain teams that act in good faith and try to contribute to a flourishing DOT economy.

And an event like this can be discouraging, even severely damaging for builders.

Link to our proposal: https://polkadot.polkassembly.io/referenda/97

1 Like
2

I can definitely agree that if the council originally approved some multi-milestone proposal, that generally OpenGov should approve paying out successful completion of that work.

In this case, it seems the payout will cover the entirety of the approved proposal as milestone 2 + 3 were the last things noted on the overall proposal.

However, speaking hypothetically, I don’t think all such contracts should fit into being legacy supported. For example, previous support for reoccurring infrastructure projects from the council should not imply that these projects will perpetually be approved by OpenGov. Similarly, there are maybe some projects which have extremely long timelines, and many milestones, and these should be re-evaluated by OpenGov. Finally, there may also projects which council has approved, which token holders may not find valuable.

In general I might loosely suggest the following:

  • We as token holders should mostly support the teams which have been approved by council and do good work for the next year (till June 2024), as we transition from Gov v1 to OpenGov.
  • Teams which have milestones or projects which extend beyond a year should create a signaling proposal through OpenGov to at least see if there are any clear outstanding dissent for the proposals.
  • If there are projects or teams which are getting shut down by OpenGov, when council has previously given support, we should call on previous council members to write an updated response on why token holders should support the proposal, or why their perspective has changed since their last commitment. Conversation can continue from there.

One last note is that I do not think the forum would benefit from having many posts which are “support my proposal #X”. In generally, I think we should ban such posts where there is no discussion around the proposal, just begging. (cc @Remy_Parity @rhee)

Clearly, this post does have a relevant topic to discuss, but you can see how others might read this differently.

P.S. I have submitted an AYE vote for your proposal.

2 Likes
3

Thanks for your comment, Shawn. I completely agree with your thought process.

I think one year is enough time for teams to figure out alternative strategies/plans and create a mitigation strategy for funding.

One last note is that I do not think the forum would benefit from having many posts which are “support my proposal #X”. In generally, I think we should ban such posts where there is no discussion around the proposal, just begging.

Clearly, this post does have a relevant topic to discuss, but you can see how others might read this differently.

I’ve changed the topic to better represent the topic of discussion. Thank you for the feedback :heart:

P.S. I have submitted an AYE vote for your proposal.

Thank you, it means the world!

1 Like
4

Adding on: maybe a “notice period” track could be added for proposals that fit such “if-else” logic?

I do understand however that the cost of developing this might not be justified given its temporary nature.

Maybe an off-chain label to mark such proposals for the voters to identify them and easily make their decisions could be helpful?

5

Love your ideas and feedback, especially this part:

And of course “support my proposal #X” related topics will be warned & deleted (instead of insta-ban).

In that sense, @batman please remove all the emotional wordings from your contents and give us a summary of the key metrics/deliverables your dashboard has been contributing so far for the sake of Polkadot Ecosystem, so that the audience can clearly see what brought you here to highlight about your proposal, thanks in advance.

1 Like
6

Yeah, I agree that this situation is probably temporary in nature, and better handled using some manual work than building superfluous details on chain.

7

Thanks for the comment @rhee - I’ve updated the post to include a link to our detailed delivery report and removed emotional parts from the same.

Please let me know if there’s any other changes you’d recommend for the same.

2 Likes
8

@shawntabrizi - I think that’s a good point, If theres no actual ‘discussion’ taking place within the post then it’s safe to say that it’ll be deleted or at minimum ask them to revise it so it includes a relevant discussion point.

9

Following up on this, recently there have been a couple of discussions/proposals put forth by the community that highlight the need for more flexible funding mechanisms.

Namely:

  1. Teddy DAO & Polkadot: A New Way to Leverage Charitable Giving in Web3
  2. Incentive Pools - A novel model for results-based treasury funding to unlock growth for the Polkadot network.

The Teddy DAO proposal seeks a DOT loan to pay for their expenses using staking rewards.

The Incentive Pools proposal suggests a commission based funding solution to align incentives of the builders with the treasury.

Of course, commission based funding requires a good deal of scrutiny due to the subjectivity of what metrics to incentivize, how to verify them, etc. so I’ll refrain from discussing it in this post.

But I do believe that the need for a “pre-approved” funding track could greatly help with predictability for the following use-cases:

  1. Recurring Payments
  2. Multi-Milestone Payments

How it might work

  • Proposer submits a request to the treasury under OpenGov with a “payment_type” argument (one_time, recurring(until_time), multi_milestone(num_of_milestone)) - there can be a max cap for until_time (1 year probably) and num_of_milestone (6 milestones)

  • OpenGov approves/rejects proposal

  • Post the initial execution when the proposer submits a follow up request for payment of milestones/reimbursement of costs, the payment request could be fast-tracked with a “pre-approved” track, with a shorter decision period and maybe a lower threshold?

Keen to hear your thoughts on this.

10

@batman a lot of what you wrote seems to line up with some of the ideas A Better Treasury System, do you agree?

11

@shawntabrizi Thanks for sharing this!

Yes. It’s precisely inline with my thoughts.

Seems that the discussion has been up for about a year now, curious if it’s something that’s still under consideration/development?

On a tangential note, I really like the idea for a reputation system and a user-friendly mobile app with customizable notifications.

Not sure if someone has built/is building this, so thinking out loud here.

A team’s reputation for any given “category” (e.g. DeFi Infra, DeFi App, Dev tooling, Gaming Infra, etc.) could be broken down into the following variables IMO:

  1. Team Reliability %

    • 100 * no. of projects shipped successfully / (no. of failed projects + no. of projects shipped successfully)
    • Failed projects = Projects abandoned prior to completing the promised work

  2. Average Project Quality Score

    • Quality of shipment can be measured across 2 metrics with public ratings (e.g. 1 = poor, 2 = fair, 3 = good, 4 = excellent, 5 = world class):
      1. User/dev experience
      2. Robustness

  3. Total funding received by team from treasury till date

I do believe that it’s important that the reputation score is displayed alongside the “Category” Benchmark, for how people vote about the project quality could greatly vary between different types of projects.

Would love to know what you think about the reputation logic.

I’d be happy to draw up some mockups and build a PoC over the coming weeks.