Create Proposal in Frontend App using sns-js

Developers
1

Good morning,

Just wondering how I raise an SNS proposal via my frontend for other user to be able to vote on?

I can’t see a function for it in sns-js, if someone could let me know how I access this functionality that would be great.

Kind regards,
James

2

Or am I just over complicating my code and I don’t even need to raise proposals to do things like revalue players etc. Provided I can get a user’s voting power (using sns-js) it would be really easy to just maintain the information of their decisions in my backend and just use the governance canister to get their voting power. For example I have 600 football players in my app, and I want to record a users decision to revalue them up and down. Do I need to raise potentiall 600 proposals each week to revalue players or can I maintain this data structure in my backend canister and just look up VP in the governance canister.

3

Hi!

Let me reply part per part.

sns-js supports making proposals, but not with a nice interface. You have to use the manageNeuron method in the governance canister.

Here’s an example of how we build dummy proposals in nns-dapp to test features.

Then, regarding how to manage the DAO. I’d say that you could create a custom nervous function to manage the value of the players. It’s up to you to make this custom proposal update one or multiple players.

I passed the question along the the NNS team, in case they have a better solution.

I hope that was helpful.

2 Likes
4

A colleague recommended this link to read more on custom (or generic) nervous functions.

5

Thank you. Just for the NNS team, this is the functionality I need in my app in regards to neuron holders and voting (outside of the normal governance proposals).

Player Revaluations: OpenFPL users can each revalue up to 20 of the 600 Premier League players in the app each gameweek (gameweek is defined by the OpenFPL backend). They are also only allowed to vote on a player once per season (season is August to August). Premier League players may be added or removed from this list of players throughout the season. So in the frontend they are presented with a list of players and they either select increase or decrease value. I don’t want to create potentially 1200 proposals each week if possible, potentially 1 to increase and 1 to decrease a players value. I imagine the first user who says this player’s value should increase causes a proposal to be created and all subsequent player value increases for the week just add votes to the same selection. I also want to be able to show the change in a players value history, but I’m assuming since the proposal will execute a function in my backend canister I will just keep track of the changes in the existing backend data structure. I also want the proposal for revaluing a player to auto complete when reaching a certain voting power.

Fixture Data Submissions: OpenFPL uses consensus to populate all the events that happen in Premier League football matches. Users are presented with a view that captures these events and I want to implement the same kind of structure as the player revaluations. The first person to enter fixture data creates a proposal that this is the fixture data for a match. All other submissions that have the identical fixture data just add votes to this proposal, with any matches with differing data creating a new proposal.

Other Proposals: As mentioned above the last area of governance are standard proposals that move a player between Premier League teams, or update a Premier League club’s display colours. Anything that might be required to ensure OpenFPL accurately represents the changing nature of the Premier League’s data. Again I want to ensure that the first time a user adds a proposal for one of these changes, any future proposals are just adding votes to existing proposals.

Thank you for any assistance you can give me.

James

6

The custom proposals are done by each dapp. This is not something DFINITY or the NNS team does, hehe.

Maybe you can contact the OpenChat guys and they might be able to explain you how they did it.

7

I’m more than happy to read through all the docs and go down the custom proposal route but any docs they can point me to to help ensure I’m on the right path then that would be great.

I get they aren’t going to write my code for me lol

8

Hi @jamesbeadle , Lara here from the NNS team.
I am not entirely sure yet whether I understand the detailed functionality that you are looking for as I am not super familiar with how this game works, but if I understand correctly it seems that you have some sort of “voting” that is not necessarily the same as governance voting?

On a high level, I think there are two things that might be helpful:

  1. If you need some functions that can only be triggered by the DAO agreeing on them, then I think the generic proposals are the right solution. The SNS can define and “add” them to governance once and afterwards any neuron can submit such a proposal. Such a proposal can call any method on any canister and therefore implement the logic that you need. Normally you would want to set the cansiter that implements this logic under SNS control. I would recommend specifically this section in the documentation that @lmuntaner has already shared, including having a look at the guidelines.

  2. Your dapp might have some automatic logic that is always run and does not need a specific event / agreement from the DAO to be triggered. For example, if certain information should continuously be updated this might fall under this category. This might also include logic that calls SNS governance to request some information and makes decisions / updates to the state based on this public information. You could just implement this in a cansiter that is SNS DAO controlled. In contrast to 1), maybe you don’t need a proposal to trigger the methods but rather there are some periodic tasks that just always run. It would still be decentralized as upgrading the cansiter and thus changing the logic can only be done by SNS DAO proposal.

Does this maybe help a little?
If you have other questions please let us know!

1 Like
9

Hi Lara,

Thanks for getting back to me. Yes, I am looking for users of the app to be able to vote on things based on their staked $FPL (The DAO’s utility token). But this governance is in a way competitive. So we reward the users for telling us what is happening in real world, the sooner they add the information into OpenFPL the better.

I need to be able to:

  • Rewards users for adding this information, in doing so there will be a mad rush to add governance information for a football fixture. When I have enough votes for verification of a fixtures event data, the ‘proposal’ will close. A lot of people are going to be entering the same data, rather than looking for an existing proposal and voting on it. The fact the user enters it themselves is what ensures the data is accurate as I find consensus among the users data inputs.
  • When a fixture has reached consensus, as in enough users with enough voting power have entered exactly the same data for a fixture, it completes and the user is rewarded.

I understand the generic proposal is possibly the way to go. I already have the backend functions that should be called when consensus is reached. Really the process I’m struggling with is:

  • Ensuring a user either creates a new proposal or just adds votes to the existing proposal if one already exists
  • Potential issues with flooding my SNS with 1200 proposals each week to revalue a player either up or down.
  • Ensuring validation, I understand that the generic proposal will have a validator method (which will be on my OpenFPL backend with the target method). I want to ensure the following for revaluing a player and I’m not sure if this is the place to do it:
  1. Ensure the manager has not revalued this player already this season. Now this is a case of seeing if the manager has voted on a proposal to revalue a player either up or down in a prior gameweek. I’m assuming it would just be easier to store this voting history detail in my backend canister and look it up from validation function.
  2. Ensure the manager has a neuron available to actually submit votes. I think I just get this from sns-js on the frontend and disable the buttons. If they did vote then no votes would be added since they don’t have a neuron so I don’t think this is an issue I need to worry about in the validation method.
  • Auto closing each proposal after the end of each gameweek, I’m assuming when the proposal is raised to change a players value I just set the proposal end date to the end of the gameweek. Does this variable proposal end date cause an issue?

Any help greatly appreciated.

Kind regards,
James

10

Hi Lara,

I’m sort of going in a different direction, rather than use sns-js, it feels like this would all be easier in Motoko on the backend. Please correct me if I’m wrong.

I have created a file to act as an interface to the governance canister, much like I do the ledger canister:

From here I can access this interface:

image

And then when my backend is called for the validator_method_name on ExecuteGenericNervousSystemFunction it can then use this interface to do things like check if the current user has voted on a player etc…

Is this a viable route for me to take?

Kind regards,
James

11

Hi @jamesbeadle,
let me try to unpack some of this

Rewards users for adding this information, in doing so there will be a mad rush to add governance information for a football fixture

I wonder whether you can potentially influence this rush by configuring the cost for proposal submission and the voting rewards. Of course you would still need to handle the race conditions, but it might incentivice users to do what would be beneficial for the game.

  • Ensuring a user either creates a new proposal or just adds votes to the existing proposal if one already exists

I think this is not currently supported by the governance canister as such. On proposal submission it is not e.g., checked whether the same proposal exists and this is not connected to voting. So the decision whether to submit a new proposal or to vote on an existing one needs to happen outside the governance canister.

I want to ensure the following for revaluing a player and I’m not sure if this is the place to do it:

I am afraid I don’t follow all the details of the game. But in general it sounds reasonable to encode such logic about what has already happened in the past in your canister.
I wonder though if this all needs to be in the validator method or if some of it can be in the target method (i.e., some proposals would go through the process but might just not have an effect if they don’t satisfy the conditions that they should).

Ensure the manager has a neuron available to actually submit votes.

so I can mostly talk for the backend: the SNS governance canister enforces that only a neuron can submit a proposal and vote on a proposal. So while I am not quite sure if the buttons would be shown on the frontend, if someone does not have a neuron, then the backend cansiter will not allow them to submit a proposal or vote.

Let me know if I forgot something important

12

From what I understand atm, I think in general it does make sense to implement some of this logic in a backend canister.

I think there might be some open questions wrt what you would want to check in the validator function vs later, but I think this is now also discussed in the other forum thread?

Also, note that some of the governance methods, e.g., calling manage_neuron for some neuron, can only be called by principals that have permissions on the neuron (we call this the neuron’s “controller” or “hot key” in the NNS, in the SNS this is a bit more flexible). So depending on what you need here, I am not sure if this can be done by a canister that does not have priviledges on some of the neurons.

As mentioned I am currently not sure how this discussion overlaps with this one that seems to be a step further. So I suggest we continue on the newer thread except if there is anything missing here that is independent of the new discussion. Does that make sense?

1 Like
13

I want to encourage the valuation of players by neuron holders as this is something fantasy football games as traditionally struggled with and adding a cost barrier will just make the valuations less accurate.

A user is encouraged to value players here:

image
image936×613 133 KB

I feel like I have already started a new thread about areas of this here. It was explained to me i can’t sign the messages on the backend with the caller when interacting with the governance canister so this has solidified my design a bit more. I’m doing the checking for existing proposals in the frontend.

1 Like
14

But thank you Lara for all this information.

1 Like
15

@lara

I think I get what to do. I’m fighting the governance design of the IC and I’m just going to redesign my app to fit the way you’ve set things up. I’m going to drop all the restrictions and I will just have those revaluation buttons raise a proposal. This will make neuron holders sure that a players value change is justified as it will cost them if people don’t vote for the revaluation. I’ll just add another view for the voting of the valuation proposals people have changed.

Thanks for all your help on this!

James