[Proposal: 16] Polkassembly OpenGov development - Moonbeam

Governance Treasury Proposals
, ,
13

hey @Parambir, Thanks for your proposal!

I respect and understand the significant contributions that Polkassembly makes to the ecosystem, so please don’t get me wrong. If I’m mistaken, please feel free to correct me.

regarding the costs, I don’t entirely agree. for example, OpenGov in Moonbase doesn’t seem to be as actively used, and I believe a discount would be appropriate.

concerning the Moonbeam migration to OpenGov, my understanding is that most of the work has already been carried out in Polkadot / Kusama / Moonriver. given that the process seems largely automated with only a few adjustments remaining, I question the fairness of charging the full amount.

IMO, many of these features and their associated costs have already been addressed by Polkadot / Kusama treasury. since these features were implemented there, it feels like you’re making tweaks rather than developing from scratch.

therefore, I believe that it might not be entirely fair to Moonbeam treasury to bear the costs associated with Notifications / Alerts / AI, especially when they potentially could be covered by the Polkadot / Kusama treasury

2 Likes
14

Even if it’s not being used, we need it for testing purposes i think.

15

I fully understand the purpose of Moonbase, and I didn’t say it wasn’t used

16

I also believe you are a very inteligent person.

17

please follow the forum guidelines and stay on topic: https://forum.moonbeam.network/t/faq-guidelines/5

2 Likes
18

Hey @jose.crypto @turrizt,

Addressing your concerns below

  1. Cost for Notifications, AI Summary, & other features -

Polkadot Treasury helps us subside the costs for any developments we offer for other teams. After figuring out the infrastructure, we split the costs billed to the treasury vs billed based on the business we are able to generate by selling our services to teams.

By charging a fraction of our costs to the treasury, we ensure we have a sustainable model where payments are done as per usage by partner teams and we can work on projects without the fear of them of having insufficient funds (we work on a retroactive funding model). It also ensures that the costs to scale deployments beyond Polkadot & Kusama are paid by the teams and not by Polkadot / Kusama.

Any custom deployments or deployments for partner chains are not funded by the treasury as of yet as we believe that would cause immense stress on the Polkadot Treasury and chains should pay for services they use.

Why do we need to charge slightly higher for Moonbeam, Moonriver & Moonbase - In summary, the backend is different for all of these.
Moonbeam moonriver are evm chains, the precompile data (votes/delegation) have to be handled separately which is not required for substrate based chains.

  1. How is cost split between Moonbeam, Moonriver and Moonbase?

Please note that even though we show that the cost is split equally across chains, the effort to make the same is evaluated first and billing is calculated. Then it is equally divided across the three.

For notifications & super search for example, the cost per chain is $2K per chain. For Moonbeam, Moonbase & Moonriver the total cost charges is $3.5K which ensures that teams are not being charges unfairly. These funds include lifelong maintenance of these features and future upgrades to Slack & Element alerts which are yet being developed.

With regard to the OpenGov transition cost, we had projected a $30K cost, which includes transitioning everything to OpenGov, voting features, technical and interface upgrades bundled in one. The cost is not 10K$ for Moonriver, Moonbase & Moonbeam each but rather a $30K package for all three chains, their reliability and upgrade.

It could not be billed upfront & together as we would have to charge Moonriver treasury roughly $25K and Moonbeam treasury $5K when we talk about just enabling it for Moonbeam after completing the development for Moonriver.

It also includes efforts required for showing delegated votes in vote history for proposals and managing ERC 20 based voting. We have to do custom development that originally was not done for substrate based chains.

2 Likes
19

Thank you for the detailed answer!

I have some feedback on the UI:

  1. when I try to unlock my OpenGov funds, I see:
    “You currently have no referenda locks”

2023-09-24 132126
2023-09-24 1321261594×406 17.7 KB

this doesn’t seem right:

2023-09-24 132003

  1. Is it possible to move the “Settings” button to a more visible and easily accessible location? for example, next to the “Search” icon at the top of the page? I believe this could enhance navigation and the overall user experience

2023-09-24 133136

2023-09-24 133350

  1. could you clarify whether the list of events in the “Upcoming Events” list is clickable? ideally, user should be able to click on any event from this list and be redirected to it
    2023-09-24 131404
    2023-09-24 1314041613×717 111 KB

It might also be more intuitive if new events were displayed from top to bottom, instead of from bottom to top as it currently are

please check the “News” section It seems there’s an issue as the news from 2021/2022 is displayed there

  1. when a user has already delegated a specific track to a delegate, they are unable to vote. however, Polkassembly displays an unclear error. It would be better if it notified the user that they cannot vote because they’ve delegated their voting power for that track

2023-09-24 132442
2023-09-24 132442414×614 13.9 KB

20

Thank you for this detailed feedback @turrizt!

Point 1 - Being checked now & will be fixed in the next few hours. also, making a better interface for this

Point 2- Yes yes! We are due to take this live super soon, early this week mostly!

Point 3 - Ser, could you please check this once again or share your browser name. It is sorted in descending order and clickable for me already.

Screenshot 2023-09-24 at 11.30.43 PM
Screenshot 2023-09-24 at 11.30.43 PM1920×830 90.8 KB

Events also seem to be working for me

Point 4 - Fixing this rightaway, should be live this week

Really grateful for your feedback & feel free to share any adhoc feedback to feedback.polkassembly.io
We would love to take all your opinions and deliver the best experience

If this were on Polkassembly platform, we would be tipping you for it as well :wink:
Feature being worked on!

1 Like
21

oh, awesome thanks for the quick response, really appreciate it! :heart:

I’m using Mozilla Firefox. I just checked, and it seems that the news has been updated, but the list of events still starts from July ( In your screenshot, it also starts from July. It seems to me that the latest news should be displayed at the top of the list)

what I mean is that the list isn’t clickable. yes, I can click on the calendar and select a date, but it would probably be more convenient if we could click on a specific event from the list

1 Like
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.