Next Monday at 3 PM CET, I’ll be hosting a live stream on YouTube dedicated to answering your questions. Be sure to join, or feel free to ask me anything here.
A typo regarding the treasury tokens in the white paper was pointed out on Twitter, which I have now corrected (PR). Consequently, I updated the PDF link in the post, as the website build with Docusaurus, generates a unique hash for each file update.
Fun fact: One of the first reviewers of the white paper before it was published was my dad. Although he doesn’t speak English, he translated the entire document into French using ChatGPT so he could review it. In doing so, he spotted a typo in the Outgoing section, ensuring that the percentages in that chapter add up correctly.
I’ve just shortened the description field in the SNS YAML file. It feels like a more concise yet still descriptive text works better.
Juno is a blockchain-as-a-service platform that empowers developers to build decentralized apps efficiently. It offers a comprehensive toolkit to scaffold secure and efficient projects.
I randomly noticed that my description update was automatically reflected on the dashboard. Did you update the description in the SNS Tokenomics Analyzer manually, or does the dashboard automatically crawl for updates in the repos? Either way, pretty cool!
The dashboard URL I provided above includes the link to https://github.com/junobuild/sns/blob/main/sns_init.yaml in the URL, so whenever you reload the dashboard page, it will reload the data from that sns_init.yaml file.
Following an input on X/Twitter, I lowered the minimum participation for the SNS from 10 to 1 ICP.
As a result and to comply with the NNS requirement that the minimum participation must be large enough ‘to ensure that participants will end up with enough SNS tokens to form 5 SNS neurons,’ I also lowered the minimum number of tokens that can be staked in a neuron from 100 to 10.
I’ll be going live in a bit less than one hour for this week’s Juno Live stream on YouTube at 3 PM CET. Looking forward to answering your questions about the SNS.
In addition to this topic, we’ll start exploring a unique way to implement SSR for HTML pages using Juno’s Serverless Functions. Spoiler alert: we won’t be using http_request_update.
The total supply of JUNOBUILD tokens at genesis is 100 million. Over time, the supply will increase if more tokens are minted and decrease if tokens are burned.
What are the burn mechanics with the Juno DAO? I did not see that in the whitepaper unless i missed it because it is on another page.
I would say, similar to the IC, by swapping and converting tokens into cycles—what I inderictly meant by “Swapping for Computation Power” in the “Token Purpose” chapter — as well as transaction fees or failed proposals. Happy to hear any additional ideas!
Ah I’ve read that section but did not link it to the burn mechanics.
If junobuild is used to buy cycles, that would mean Junobuild needs to be converted to ICP and then buy cycles? ICP then gets burned and how does the junobuild token gets burned?
The fees on transactions/payments related to the junobuild token is a good one but a bit vague at the moment because there is no clear percentage of how much will be used to burn the junobuild token.
3 years seems fair to break-even but is their a rough estimate on how much inflation you expecting each year?
Not sure the DAO can help with the burning after the purchase and it would require alot of proposals. You add for example a small percentage ontop of the price for buying compute power compared to the actual cycles purchase, the additional percentage can then be burned instead of keeping it in the treasury.