[Proposal: 16] Polkassembly OpenGov development - Moonbeam

Governance Treasury Proposals
, ,
22

ok I understand, thank you very much for your response @Parambir :raised_hands:

I understand your perspective now, I think it could have been mentioned that way the first time, since from my point of view they seem like costs individually

and not a package

1 Like
23

@turrizt got it!

sure, on our way to fix this up, thank you for clarifying this issue :slight_smile:

1 Like
24

I apologise for not being able to convey it in a clearer manner earlier, thank you! :pray:

25

Hi @jose.crypto,

Could you please help us with understanding the next steps if we have your approval?
We have not had a chance to receive feedback from other treasury council members and await your approval / feedback to proceed

Thank you!

26

I would recommend waiting until you get the approval in comments

internally it is being discussed

Likewise, when the proposal is going to be made on chain, it will be using the last 30d avg price at the moment of the submission, so is ok

27

in the meantime, could you provide the specific links/git commits related to the opengov work for MB and MR

This way it can be evaluated in a better way, both here and the proposal. Thanks
@Parambir

1 Like
28

Sharing links to specific dev/ git commits & attaching them to the proposal as well (this list may not be 100% exhasutive but should help with the details the team is looking for)

(Part 1/3)

  1. feat: changes for deploying moonbeam opengov by This-Is-Prince ¡ Pull Request #453 ¡ polkassembly/polkassembly ¡ GitHub

  2. add removedAtBlock_isNull to moonbeam votes query by alphainfinitus ¡ Pull Request #289 ¡ polkassembly/polkassembly ¡ GitHub

  3. moonbeam open gov ¡ rajdeep7Singh/polkassembly-subsquid@a914650 ¡ GitHub

  4. moonbeam open gov 2 ¡ rajdeep7Singh/polkassembly-subsquid@5402727 ¡ GitHub

  5. ethereum.transact adaptation ¡ rajdeep7Singh/polkassembly-subsquid@fc4906c ¡ GitHub

  6. referenda storage fix ¡ rajdeep7Singh/polkassembly-subsquid@d1c9860 ¡ GitHub

CC: @jose.crypto

29

(Part 2/3)

  1. adding curve data ¡ rajdeep7Singh/polkassembly-subsquid@b4fb3cb ¡ GitHub

  2. fix curveData ¡ rajdeep7Singh/polkassembly-subsquid@d7f2a41 ¡ GitHub

  3. new storage type for open gov referendum ¡ rajdeep7Singh/polkassembly-subsquid@3566185 ¡ GitHub

  4. handle delgated votes and removed votes ¡ rajdeep7Singh/polkassembly-subsquid@12f380e ¡ GitHub

  5. trancknumber and index null checks ¡ rajdeep7Singh/polkassembly-subsquid@311fe46 ¡ GitHub

  6. removing preimage v2 table ¡ rajdeep7Singh/polkassembly-subsquid@e4a1520 ¡ GitHub

30

Part (3/3)

  1. moonriver gov2 ¡ rajdeep7Singh/polkassembly-subsquid@d540fae ¡ GitHub

  2. precompile voteNo fix ¡ rajdeep7Singh/polkassembly-subsquid@2b483d8 ¡ GitHub

31

I appreciate you providing this information and for all the hard work you guys have put into polkassembly.

However, as it relates to the core OpenGov support for Moonbase Alpha, Moonriver and Moonbeam, there are several things I’d like to draw attention to.

Firstly, MR4 was awarded for $12,000 back in March 2023 for OpenGov support for Moonriver and Moonbase Alpha. Given that Polkassembly would have already tackled OpenGov for Kusama, the implementation for Moonriver/Moonbase Alpha would be pretty straightforward.

Of course, there’s the EVM precompile and signature support, but Polkassembly would already have the know how to do this given that Polkassembly already supported all the Moonbeam networks for Gov V1.

Putting bug fixes and enhancements aside, I would imagine that the Moonbeam implementation would have been extremely straightforward given the configuration was highly similar to Moon

So then that brings us to bug fixes and enhancements. Surely some amount of bug fixing would be included in the maintenance fees that the Foundation pays on a quarterly basis.

For the enhancements (eg. the curve data), I would expect that this work would be generally applicable to Polkadot/Kusama and other parachains. I’m not saying that Moonbeam shouldn’t bear some of the costs, but certainly not all of the cost unless I’m misunderstanding.

The Github links above are helpful but it is difficult to tell what was Moonbeam specific vs generic for other parachains. In going through them, it seemed like some were related to the Kusama implementation for example. Others seemed like they were from early 2023 and so I would have thought they’d be covered by MR4.

So I guess similar to some of the other comments, $30K for the core opengov implementation seems quite high to me considering my comments above.

1 Like
32

Hi @aaron.mbf thank you for your response!

I would live to quote one of our previous responses where we clarified this issue in depth.

Urging you again to understand that the migration for all three chains has been quoted at 30,000$. Yes, majority of the work involves us to redo what we have done for Polkadot & Kusama and hence the features are billed at a heavily discounted rate.
As per your current understanding, it seems that we were not able to clear the fact that the 12,000$ charge for moonriver was to split the cost and minimize the load of the development charges on moonriver. It was not the entire cost that the team had to bill for the migration and hence we please request you to revisit the linked message.

In the previous proposal you have mentioned, the costs were already projected as 20,000 and aligned upon before proceeding. This was along with a clear message that total costs are to be considered to be split equally between three chains. We were requested to move $8K with the charges for Moonbeam as the Moonriver treasury would face stress if they bore 100% of moonbase share and hence an 80-20 split was done.

The migration and features are not available for free to teams to ensure that Polkassembly continues to operate with a sustainable model for governance & is not only reliant on the treasury. Hence, any new team that integrates OpenGov is charged a fraction of the total costs at a subsidised rate.

Please note, in no case is either moonbeam, moonriver or moonbase bearing all of the costs as the developments efforts here would be much larger than what is quoted if that were the case.

Additionally majority of the links attached with priority to the custom effort required for moonbeam / mr to ensure you have a chance to visit them (please refer to the titles in case of discrepancy). Please note our OpenGov migration charges include the cost to migrate to subsquid, its integration and reliability as well for OpenGov.

I believe the comments above for 30K$ for OpenGov were clarified but in case we would like to discuss this further please let me know

With regard to maintenance -

future & present upgrades including delegation vs self vote breakdown in voting history, user level voting history & changes in profile information of a user, adding split / abstain as voting options, site maintenance / server costs, AI summary maintenance, search / notifs maintenance & a host of other smaller features that are taken live or will be taken live are covered under these and not billed to the treasury.
No additional charges are taken for custom efforts to handle differences in substrate vs ERC-20 data here.

33

hey @Parambir, it seems that this issue is still present because I still don’t see any OpenGov locks, but I definitely have them

something weird is happening with the voting details graph. when I hover the cursor over it, it starts to flicker and jump. could you please take a look? I use Mozilla Firefox
2023-09-29 203936

34

Hey @turrizt apologies we have not yet been able to close this issue. We will be providing a resolution to point 1 within the next 1-2 working days and the firefox issue seems odd, we should be able to patch that up in the same time as well.

Apologies for the inconvenience on this

1 Like
35

Ok, i went back and reviewed the previous post and I think I understand it now.

  1. At the time, polkassembly had completed the work and based on hours spent, gave a cost of $20K USD for an OpenGov implementation for Moonriver and Moonbase. This was not priced out by network but rather based on number of hours across different aspects and resources according to this chart

  2. An additional cost for Moonbeam was not quoted at this time.

  3. There was a request to take into account the 80/20 rule for the cost of infrastructure that is for the benefit of all 3 networks. Polkassembly computed this by splitting the cost into 2 x 10K USD amounts, one for each network (moonriver and moonbase) and then including 100% of the cost for Moonriver and 20% of the cost for Moonbase. The other 80% for Moonbase to be requested in a later GLMR proposal along with the implementation cost for Moonbeam.

In reviewing these facts, I guess I understand how we arrived here but I must say that the MR4 request did NOT leave me with the impression that there would be an additional 10K USD ask for Moonbeam - that was never stated and if that was indeed known at the time, it would have been much better to present it at that time than 6 months later.

Moreover, although the chart has a note that “costs for each platform can be considered as 50% of the total”, presumably this is because a lot of the work is equally applicable to any Moonbeam environment. For example - 65 hours were spent on “product features”. As Polkassembly was writing the code for the features at the time and this code was to be deployed for both Moonbase Alpha and Moonriver, I guess it seems reasonable that 50% of the cost be applied to both networks. However, it also would seem reasonable that once this is done, there would be $0 cost for Moonbeam since the features have now been implemented for the general moonbeam stack.

The other activities include “OpenGov Deployment” and “technical migrations”. I find it very difficult to accept that after having completed the work for these two initial networks, it would take an equal (in proportion) amount of time to complete these activities for Moonbeam. So basically, the claim is that there were no lessons learned, tasks that were automated, etc that would make the implementation for Moonbeam go more quickly.

Overall, I would have expected a discount to apply similar to the one you mentioned above related to some of the other features:

“Instead of 3x the cost it is roughly around 1.75x the cost for one individual chain in this case.”

So my back of the napkin logic would look something like this. Take the original chart and:

  1. Remove product feature development
  2. Divide all number of hours by 2 since it’s one network and not 2
  3. Give a 50% discount to the remaining activities since it would be much easier to implement for the 3rd network

To arrive at $3,763 for the Moonbeam implementation (instead of $10K USD).

2 Likes
36

Hey @aaron.mbf!

  1. Thank you for spending the time going through everything. We appreciate your understanding and patience
  2. You are correct, the additional cost was not quoted explicitly and we understand the confusion it has caused. We are extremely apologetic for this and will be mindful of not repeating this.

We are shifting our cost structure to what you have mentioned to avoid any confusion and to ensure that we do proceed in a manner which is mutually aligned.

If the team is aligned with the back of the napkin math you have provided we accept the terms and would like to move forward to a proposal stage with it. We will also modify the document to incorporate this after the team’s approval and before it is put on chain.

Based on the learnings, in case of any future development that has a similar coverage, we will ensure we convey the future cost upfront as well.

37

So then we’d be looking at:

  • $8,000 for the remaining owing for Moonbase Alpha which was more or less previously agreed to as part of MR4
  • $3,750 for Moonbeam OpenGov implementation
  • $3,500 for Search and Notifications
  • $3,000 for threshold curves, AI summary, etc

For a total of $18,250?

38

Yes @aaron.mbf that is correct

1 Like
39

Please note @turrizt the OpenGov locks should now be working. Apologies for the trouble

For the Firefox issue can you please confirm it with a video. We are unable to reproduce it.
Please join us at Telegram: Contact @polk_gov to discuss this issue & for any concerns!

Our screen recording is here for your reference - Screen Recording 2023-10-04 at 12.27.10 PM.mov - Google Drive

3 Likes
40

Hey @jose.crypto @aaron.mbf!

In case we are aligned with everything please confirm if we can proceed with submitting the proposal on chain.

The team can make the changes discussed to the documentation and proceed further based on your approval.

41

hey sir, it’s an AYE on my part with the new conditions/changes, however I must reiterate need to wait for the comment of 2 more council members, before of put the proposal on chain, and should use the 30d avg price ( at the moment of the submission on chain) and update this post at that time with the amount of Glmr :raised_hands:

1 Like