Upcoming Querio SNS decentralization sale

Governance
,
23

Your logo is very similar to Origyn’s logo, do you think that’s a problem?

1 Like
24

image
They have the low calorie dust

1 Like
25

Thanks @borovan for highlighting this!

While both logos are square, they feature distinct designs, color distributions, and elements, including the pixelation effect on Querio’s logo.

Recently, we had a discussion with Silvia from Origyn about the logo similarity, particularly regarding the potential confusion it might create on CoinMarketCap

Therefore, we’ve requested an official opinion from CoinMarketCap and will provide an update as soon as we receive their feedback.

Additionally, a DAO motion will be initiated post-SNS to further debate on this topic.

2 Likes
26

We are excited to follow up on our recent post: Querio has now open-sourced the following components:

3 Likes
27

I think one is an O and the other is a Q. Great minds think alike.

1 Like
28

Hi Querio team,

Thanks a lot for participating in the SNS office hours this week!

As promised I would like to get back to you with some follow-up answers.

Question 1: How to create a neuron with dfx (that can then be used on CLI to submit the NNS proposal to get an SNS)?

There is actually one easy solution that was mentioned by an NNS engineer and that I missed during the office hours: you can stake a neuron in any way, for example using the NNS frontend dapp and then just add your dfx principal as a hot key to the neuron. Since a hot key has the permissions to submit a proposal in the name of the neuron, the dfx principal should then be able to do this. You can find the dfx command to do so here in the developer documentation.

Question 2: What is the limit on the sns init file and is there a reliable way to test this locally? / Is there a message limit that could be hit if there are a lot of initial neurons?

  • The actual limits are a bit hard to evaluate for two reasons:

      1. the content of the init file is converted to different formats and sent in messages together with additional information.
      1. the content of the init file is sent over different message channels with different limits.

  • In detail, in the proposal’s submission is an ingress message with limit 3.5MB, where the content of the init file is sent together with other information defining the proposal. If an NNS proposal to create an SNS is adopted, the NNS governance canister asks the SNS-W canister to create the SNS canisters. This is an inter-canister call on the same subnet with a current limit of 10MB. This message not only has the content of the init file, but in addition information about the neurons’ fund which requires additional space. Finally, the SNS-W creates the SNS governance canister with the initial neurons. This is a cross-net message with the limit 2MB. This message contains, in addition to the init file information, the WASM of the SNS governance canister.
    In general the 3.5MB and 10MB were intermediate measures to allow for WASM installations, but there might be better solutions for this going forward which will allow decreasing these values again. So ideally one should assume a 2MB limit everywhere in the longer term.

  • Currently, there is no limit enforced on the NNS governance on the size of the contents of the init file, including the number of initial neurons. We acknowledge that this is not ideal and suggest adding a limit on the number of initial neurons that is on the more conservative side (with the goal that if the proposal can be made, then with high likelihood no limits would be hit later in the process).

  • What can you do next?

    • You could try to decrease the number of initial neurons, e.g., by giving fewer neurons to the principals.
    • You could try to estimate the size of the different messages and whether you would be close to the theoretical limits. If you go ahead with the proposal and one of the steps still hits the message limit, the SNS launch would fail and the dapp’s control would be given back to the registered principals. You could then try again.
    • You could build a custom canister that will be given under SNS control, which owns a few initial neurons and can later distribute neurons by splitting them into more neurons. One thing to be careful about here: this would mean that right at the time when the SNS is launched, these initial neurons are not yet in the hands of their final owners. This shifts the voting power distribution right after launch and therefore could be a risk.

We hope this is helpful and are happy to try to help if you should have any additional questions.
Happy weekend!

4 Likes
29

Hi @lara,

Thank you for your detailed answer. We are glad to see that our SNS init file is around 190KB, well within the 2MB threshold.

However, we are currently encountering an issue. When using the new parameter “neurons_fund_participation,” we receive the following error:

Invalid configuration in 'sns_init.yaml': Unable to convert the configuration file to a proposal:
Failed to convert CreateServiceNervousSystem proposal to SnsInitPayload:
Error: neurons_fund_participation must not be specified until Matched Funding is enabled.

Here are more details:

Looking forward to your guidance on this.

1 Like
30

It seems that the latest version of your sns_init.yaml file causes a different issue, namely, I was getting the following output from ./sns init-config-file validate:

Invalid configuration in "sns_init.yaml": Unable to convert configuration file to proposal: Error: The following PrincipalIds have a dissolve_delay_seconds configured greater than the allowed max_dissolve_delay_seconds (31557600): [...]

This is because Voting.MaximumVotingPowerBonuses.DissolveDelay.duration was set to 1 year, while some of the neurons specified in the same file had a dissolve beyond 1 year.

This is however an orthogonal issue to the original one you’ve asked about. The error neurons_fund_participation must not be specified until Matched Funding is enabled indicates that the version of sns is too old. Please try to always use the version specified in the sns-testing repo’s main branch: https://github.com/dfinity/sns-testing/blob/main/settings.sh#L29C19-L29C59

So for your current work, please download the sns CLI tool from here.

3 Likes
31

Hi @andreea,

We’ve released a new version of the SNS Tokenomics Analyzer which supports matched funding and the latest version of the SNS init config file. The Tokenomics Google Sheet won’t be updated to support matched funding and can be considered deprecated.

3 Likes
32

Thank you @aterga for the insightful feedback and guidance on resolving the issue. We have followed your advice and are now using the SNS CLI tool from the recommended source.

3 Likes
33

Thanks for the update @domwoe! We’re now using the new version of the SNS Tokenomics Analyzer. Appreciate the heads up about the Google Sheet deprecation.

34

Great!

I’ve got a couple more questions :slight_smile:

Are you using a tool like UserGeek to be able to provide some usage metrics of Querio?

Furthermore, do you have instructions for the community to create reproducible builds? Otherwise, the community wouldn’t be able to verify proposals that upgrade your application.

1 Like
35

Thank you for your detailed answer. We are glad to see that our SNS init file is around 190KB, well within the 2MB threshold.

Note that this alone might not be a guarantee that it will work. One concrete example: when the SNS is created by SNS-W, then there is a message from SNS-W to the SNS subnet, with a limit of 2MB, that does not directly include the init file, but rather some of the information from the init file (the information about all initial neurons) and in addition the Wasm of the SNS governance.
So to have a good estimate, you would have to guess how much space all this information takes up, in the format that it has at the time of the message (which is not the init file format anymore)

1 Like
36

@domwoe, regarding analytics, we initially used Google Analytics but, considering community concerns about using a Google tool, we’ve decided to remove it. We’re now in the process of transitioning to a decentralized alternative like UserGeek, which we plan to implement soon (a couple of days).

As for reproducible builds, bellow are the links providing details on the environment that should be used:

These resources should help the community in verifying proposals that upgrade Querio.

37

It’s hard for people to replicate this environment. A better approach is to provide a reproducible environment with a docker file or similar.

You can check the docs for more information: Creating reproducible canister builds | Internet Computer or look at examples like OpenChat.

1 Like
38

Hi @lara,

Thank you for pointing this out. As we’ve already initiated the proposal, we’re closely monitoring the process and are aware that dApp’s control would be given back to the registered principals, in case any message limit is encountered at the SNS launch. Hopefully all will go as expected.

39

We’re excited to share that we’ve made significant progress towards decentralization with the creation of a proposal for the launch of the Querio SNS.

Your ongoing support is greatly appreciated in this journey!

3 Likes
40

Great suggestion @domwoe. We’ve now included instructions for reproducing builds with Docker, making the process more accessible:

3 Likes
41

Do you have an idea on when you will submit your proposal?

1 Like
42

Our proposal has already been successfully executed.

The Querio SNS decentralization sale is set to start in just 8 hours, and you can participate here.

3 Likes