From 0d57118f124ee00ef133f1379cf74e82a2abf07f Mon Sep 17 00:00:00 2001 From: Corey Petty Date: Sun, 19 May 2019 14:24:45 -0400 Subject: [PATCH] added some conclusion --- build/index.html | 6 +++--- ...d7287a5639e08859fa47.js => main.19eada2693bb63ee3209.js} | 4 ++-- ...39e08859fa47.js.map => main.19eada2693bb63ee3209.js.map} | 2 +- ...dd4350738cf1.js => runtime~main.2d16bf3960c132ab8ad8.js} | 2 +- ...8cf1.js.map => runtime~main.2d16bf3960c132ab8ad8.js.map} | 2 +- src/App.jsx | 5 +++-- 6 files changed, 11 insertions(+), 10 deletions(-) rename build/js/{main.d7287a5639e08859fa47.js => main.19eada2693bb63ee3209.js} (69%) rename build/js/{main.d7287a5639e08859fa47.js.map => main.19eada2693bb63ee3209.js.map} (74%) rename build/js/{runtime~main.e6dd4b6bdd4350738cf1.js => runtime~main.2d16bf3960c132ab8ad8.js} (95%) rename build/js/{runtime~main.e6dd4b6bdd4350738cf1.js.map => runtime~main.2d16bf3960c132ab8ad8.js.map} (99%) diff --git a/build/index.html b/build/index.html index 06eb13b..8acf9ea 100644 --- a/build/index.html +++ b/build/index.html @@ -14,7 +14,7 @@
+//# sourceMappingURL=js/vendors.9d13aeb150165ab32cb0.js.map diff --git a/build/js/main.d7287a5639e08859fa47.js b/build/js/main.19eada2693bb63ee3209.js similarity index 69% rename from build/js/main.d7287a5639e08859fa47.js rename to build/js/main.19eada2693bb63ee3209.js index c68882d..f3f1c3c 100644 --- a/build/js/main.d7287a5639e08859fa47.js +++ b/build/js/main.19eada2693bb63ee3209.js @@ -1,2 +1,2 @@ -(window.webpackJsonp=window.webpackJsonp||[]).push([[0],{17:function(e,t,a){},33:function(e,t,a){"use strict";a.r(t);var o=a(0),s=a.n(o),i=a(1),r=a.n(i),n=a(13),h=a.n(n),l=a(18),u=a(3),d=a(19),c=a(16),f=a.n(c),m=a(17),w=a.n(m),v=s()("h2",{},void 0,"Introduction"),p=s()("p",{},void 0,"The Status Network has a utility token, the Status Network Token (SNT). What does that even mean? What utilities does it have and how do their uses affect the rest of the ecosystem? Does it have an impact on valuation? What even is valuation of a utility token?"),b=s()("p",{},void 0,"These questions are hard, and there does not seem to be sufficient academic answers to them, for very good reasons. The technology enabling a “utility token” is new, and transcendent of many older technologies. This consequently means the models used to evaluate the older technologies will never be able to completely describe the newer ones. We, as a community, need to build new ones and evaluate them rigorously."),y=s()("p",{},void 0,"There is currently quite a bit of work being done in this field, but it is mostly for investment firms to make appropriate calls on buying, selling, and holding various project’s tokens. While this is drastically important for growth and project funding, we at Status feel that there are other, less financially motivated reasons to do this work which require a different approach. More specifically, any utility token needs to be able to objectively evaluate various features and utilities of their platform, and how they affect the entirety of their ecosystem. For instance, we need to be able to ask questions like the following: “How can we objectively measure the use of SNT if it gets used in feature X as a function of our user base? Based on that measurement, is its development cost justified, or should we focus on something else?”"),g=s()("p",{},void 0,"We will be launching Status with the following SNT use-cases, as described in the"," ",s()("a",{href:"https://status.im/whitepaper.pdf"},void 0,"whitepaper"),":",s()("ul",{},void 0,s()("li",{},void 0,"Teller Network"),s()("li",{},void 0,"Tribute to Talk"),s()("li",{},void 0,"ENS Usernames"),s()("li",{},void 0,"Sticker Market"),s()("li",{},void 0,"SNT Curated Dapp Store"),s()("li",{},void 0,"Network Incentivization (may not be available at launch)"))),S=s()("p",{},void 0,"Each of these use-cases are run by the SNT token, but in very different ways. This means each will have differing effects on the supply and demand of the token itself. It doesn’t stop there, as Status is an open and permissionless platform for developers to build on and use, which means that anyone can build SNT use-cases that affect the overall supply and demand. But how do we know what effect a utility has? Where do we go to try and evaluate its usefulness?"),R=s()("p",{},void 0,"To this end, we would like to start a blog series detailing some of the research we are doing within Status to objectively evaluate the flow of SNT, the potential effects of our implemented (and upcoming) SNT use cases within Status, and how our potential user growth changes things. This work will encompass traditional economic and portfolio theory, work currently being done in crypto-economics, and novel methodology. That means a part of this endeavor is an attempt to get peer review and evaluation of what we do by you, the community!"),k=s()("p",{},void 0,"Let’s start with the ENS naming system. In Status, for a little SNT, you can register your username on the Ethereum Name System (ENS) so others can find you easily. In order for us to apply models or understand the economics of a use case, we first have to understand what it is, how it works, and how it fits within the Status ecosystem. Let’s start by breaking down how ENS usernames work within Status:",s()("ol",{},void 0,s()("li",{},void 0,"User selects a unique username, ",""),s()("li",{},void 0,"User deposits 10 SNT into the ENS username dapp"),s()("li",{},void 0,"User is granted sole control over the subdomain ","",".stateofus.eth for 1 year"),s()("li",{},void 0,"User is able to get deposited funds after this yearly period, and release the username back into available names."),s()("li",{},void 0,"User is now searchable within Status as ",""," or","",".stateofus.eth outside of the Status app."))),N=s()("p",{},void 0,"The use case and token flow are both relatively simple, but what are the effects on the ecosystem? Let’s first try and model what value this could potentially accrue over time. We can start by picking out the variables in this process to see how things depend on each other. Furthermore, the above values are what we currently use, but in terms of modeling, we should turn those into variables that allow us to see what effect each has on the overall mechanism. This can help inform us (and you) on appropriate choices."),T=s()("h2",{},void 0,"Disucssion of variables"),E=s()("h3",{},void 0,"Number of Users"),U=s()("p",{},void 0,"It is clear that this all depends on how many users Status has in the app. If they are not using Status, then they won’t use the feature. This is our base metric, and we will model it using compounding growth and loss. We can start with a number of users that are using the app, and set additional growth and loss variables (in percentages) that define how this number changes over the next 10 years. This means that every year, we expect a certain percentage change in users based on the numbers of the previous year. Depending on how you set those percentages, the number of users can grow very rapidly! Go ahead and play with the following variables to see how the number of users change over the years."),I=s()("h3",{},void 0,"Conversion rate of users to ENS username"),W=s()("p",{},void 0,"Ok cool. We have our user base locked and loaded for the next 10 years, but not everyone is going to register an ENS username. We can brand it, make it simple, and incentivize people to do it but the reality is that that number will never be 100%. So the number of people that DO decide to register an ENS username is what we want. We get this number by multiplying the total number of users by the adoption conversion rate, which is another variable."),B=s()("p",{},void 0,"Now not all users will keep their usernames. Some people will remove their deposit after the year and bring their SNT back into circulation. Some people will leave Status altogether. If they never manually release their SNT from the ENS username contract, it can be considered locked forever. For this, we will continue to consider them users because from the contract's perspective, they are indestiguishable. We’ll model the people who release their username with another conversion factor. Go ahead and change these variables and see how the following graph changes."),C=s()("h3",{},void 0,"Amount of SNT required to deposit"),D=s()("p",{},void 0,"Now we have the amount of users that will (or have) use(d) this utility. Let’s figure out how that translates to SNT. In order to do that, we have another variable to define: The amount of SNT required to register an ENS username. By multiplying each user by this variable, we can show how much SNT is being locked up every year which effectively takes it out of the circulating supply, i.e."),q=s()("h3",{},void 0,s()(f.a,{displayMode:!0},void 0,"$$N_{\\text{SNT locked}} = N_{\\text{registrations}} * N_{\\text{SNT per registration}}$$")),j=s()("h3",{},void 0,"How to assign value to all of this?"),x=s()("h2",{},void 0,"Thoughts and Conclusions"),G=s()("p",{},void 0,"So what have we learned from all of this? How can we change the model to better fit reality? Are their any actionable conclusions around ENS usernames that come from this information?");var L=Object(l.hot)(class extends i.Component{constructor(){super(...arguments),this.numberUserInputRef=r.a.createRef(),this.userGrowthRateRef=r.a.createRef(),this.userChurnRateRef=r.a.createRef(),this.userbarRef=r.a.createRef(),this.userConversionRef=r.a.createRef(),this.removalRateRef=r.a.createRef(),this.ensUserbarRef=r.a.createRef(),this.amountDepositSntRef=r.a.createRef(),this.lockedSntBarRef=r.a.createRef(),this.sntPriceRef=r.a.createRef(),this.lockedUsdBarRef=r.a.createRef()}componentDidMount(){(new u.b).module(d.a,e=>"viewof numberStatusUsers"===e?new u.a(this.numberUserInputRef.current):"viewof userGrowthRate"===e?new u.a(this.userGrowthRateRef.current):"viewof userChurnRate"===e?new u.a(this.userChurnRateRef.current):"viewof userbar"===e?new u.a(this.userbarRef.current):"viewof percentUsersRegisterName"===e?new u.a(this.userConversionRef.current):"viewof removalRate"===e?new u.a(this.removalRateRef.current):"viewof ensUserbar"===e?new u.a(this.ensUserbarRef.current):"viewof amountDepositSnt"===e?new u.a(this.amountDepositSntRef.current):"viewof lockedSntBar"===e?new u.a(this.lockedSntBarRef.current):"viewof sntPrice"===e?new u.a(this.sntPriceRef.current):"viewof lockedUsdBar"===e?new u.a(this.lockedUsdBarRef.current):null)}render(){return s()("div",{className:"App"},void 0,v,p,b,y,g,S,R,k,N,T,E,U,r.a.createElement("div",{ref:this.numberUserInputRef}),r.a.createElement("div",{ref:this.userGrowthRateRef}),r.a.createElement("div",{ref:this.userChurnRateRef}),r.a.createElement("div",{ref:this.userbarRef,className:w.a.chart}),I,W,B,r.a.createElement("div",{ref:this.userConversionRef}),r.a.createElement("div",{ref:this.removalRateRef}),r.a.createElement("div",{ref:this.ensUserbarRef}),C,D,q,r.a.createElement("div",{ref:this.amountDepositSntRef}),r.a.createElement("div",{ref:this.lockedSntBarRef}),j,r.a.createElement("div",{ref:this.sntPriceRef}),r.a.createElement("div",{ref:this.lockedUsdBarRef}),x,G)}});h.a.render(s()(L,{}),document.getElementById("app"))}},[[33,1,2]]]); -//# sourceMappingURL=main.d7287a5639e08859fa47.js.map \ No newline at end of file +(window.webpackJsonp=window.webpackJsonp||[]).push([[0],{17:function(e,t,a){},33:function(e,t,a){"use strict";a.r(t);var o=a(0),s=a.n(o),i=a(1),r=a.n(i),n=a(13),h=a.n(n),l=a(18),u=a(3),d=a(19),c=a(16),f=a.n(c),m=a(17),v=a.n(m),w=s()("h2",{},void 0,"Introduction"),p=s()("p",{},void 0,"The Status Network has a utility token, the Status Network Token (SNT). What does that even mean? What utilities does it have and how do their uses affect the rest of the ecosystem? Does it have an impact on valuation? What even is valuation of a utility token?"),b=s()("p",{},void 0,"These questions are hard, and there does not seem to be sufficient academic answers to them, for very good reasons. The technology enabling a “utility token” is new, and transcendent of many older technologies. This consequently means the models used to evaluate the older technologies will never be able to completely describe the newer ones. We, as a community, need to build new ones and evaluate them rigorously."),y=s()("p",{},void 0,"There is currently quite a bit of work being done in this field, but it is mostly for investment firms to make appropriate calls on buying, selling, and holding various project’s tokens. While this is drastically important for growth and project funding, we at Status feel that there are other, less financially motivated reasons to do this work which require a different approach. More specifically, any utility token needs to be able to objectively evaluate various features and utilities of their platform, and how they affect the entirety of their ecosystem. For instance, we need to be able to ask questions like the following: “How can we objectively measure the use of SNT if it gets used in feature X as a function of our user base? Based on that measurement, is its development cost justified, or should we focus on something else?”"),g=s()("p",{},void 0,"We will be launching Status with the following SNT use-cases, as described in the"," ",s()("a",{href:"https://status.im/whitepaper.pdf"},void 0,"whitepaper"),":",s()("ul",{},void 0,s()("li",{},void 0,"Teller Network"),s()("li",{},void 0,"Tribute to Talk"),s()("li",{},void 0,"ENS Usernames"),s()("li",{},void 0,"Sticker Market"),s()("li",{},void 0,"SNT Curated Dapp Store"),s()("li",{},void 0,"Network Incentivization (may not be available at launch)"))),S=s()("p",{},void 0,"Each of these use-cases are run by the SNT token, but in very different ways. This means each will have differing effects on the supply and demand of the token itself. It doesn’t stop there, as Status is an open and permissionless platform for developers to build on and use, which means that anyone can build SNT use-cases that affect the overall supply and demand. But how do we know what effect a utility has? Where do we go to try and evaluate its usefulness?"),R=s()("p",{},void 0,"To this end, we would like to start a blog series detailing some of the research we are doing within Status to objectively evaluate the flow of SNT, the potential effects of our implemented (and upcoming) SNT use cases within Status, and how our potential user growth changes things. This work will encompass traditional economic and portfolio theory, work currently being done in crypto-economics, and novel methodology. That means a part of this endeavor is an attempt to get peer review and evaluation of what we do by you, the community!"),k=s()("p",{},void 0,"Let’s start with the ENS naming system. In Status, for a little SNT, you can register your username on the Ethereum Name System (ENS) so others can find you easily. In order for us to apply models or understand the economics of a use case, we first have to understand what it is, how it works, and how it fits within the Status ecosystem. Let’s start by breaking down how ENS usernames work within Status:",s()("ol",{},void 0,s()("li",{},void 0,"User selects a unique username, ",""),s()("li",{},void 0,"User deposits 10 SNT into the ENS username dapp"),s()("li",{},void 0,"User is granted sole control over the subdomain ","",".stateofus.eth for 1 year"),s()("li",{},void 0,"User is able to get deposited funds after this yearly period, and release the username back into available names."),s()("li",{},void 0,"User is now searchable within Status as ",""," or","",".stateofus.eth outside of the Status app."))),N=s()("p",{},void 0,"The use case and token flow are both relatively simple, but what are the effects on the ecosystem? Let’s first try and model what value this could potentially accrue over time. We can start by picking out the variables in this process to see how things depend on each other. Furthermore, the above values are what we currently use, but in terms of modeling, we should turn those into variables that allow us to see what effect each has on the overall mechanism. This can help inform us (and you) on appropriate choices."),T=s()("h2",{},void 0,"Disucssion of variables"),E=s()("h3",{},void 0,"Number of Users"),U=s()("p",{},void 0,"It is clear that this all depends on how many users Status has in the app. If they are not using Status, then they won’t use the feature. This is our base metric, and we will model it using compounding growth and loss. We can start with a number of users that are using the app, and set additional growth and loss variables (in percentages) that define how this number changes over the next 10 years. This means that every year, we expect a certain percentage change in users based on the numbers of the previous year. Depending on how you set those percentages, the number of users can grow very rapidly! Go ahead and play with the following variables to see how the number of users change over the years."),I=s()("h3",{},void 0,"Conversion rate of users to ENS username"),W=s()("p",{},void 0,"Ok cool. We have our user base locked and loaded for the next 10 years, but not everyone is going to register an ENS username. We can brand it, make it simple, and incentivize people to do it but the reality is that that number will never be 100%. So the number of people that DO decide to register an ENS username is what we want. We get this number by multiplying the total number of users by the adoption conversion rate, which is another variable."),B=s()("p",{},void 0,"Now not all users will keep their usernames. Some people will remove their deposit after the year and bring their SNT back into circulation. Some people will leave Status altogether. If they never manually release their SNT from the ENS username contract, it can be considered locked forever. For this, we will continue to consider them users because from the contract's perspective, they are indestiguishable. We’ll model the people who release their username with another conversion factor. Go ahead and change these variables and see how the following graph changes."),C=s()("h3",{},void 0,"Amount of SNT required to deposit"),q=s()("p",{},void 0,"Now we have the amount of users that will (or have) use(d) this utility. Let’s figure out how that translates to SNT. In order to do that, we have another variable to define: The amount of SNT required to register an ENS username. By multiplying each user by this variable, we can show how much SNT is being locked up every year which effectively takes it out of the circulating supply, i.e."),D=s()("p",{},void 0,s()(f.a,{displayMode:!0},void 0,"$$N_{\\text{SNT locked}} = N_{\\text{registrations}} * N_{\\text{SNT per registration}}$$")),j=s()("h3",{},void 0,"How to assign value to all of this?"),x=s()("p",{},void 0,"Having the amount of SNT locked up is quite useful by itself. From there, we can look at the circulating supply and see how this use-case reflects that"),G=s()("h2",{},void 0,"Thoughts and Conclusions"),F=s()("p",{},void 0,"So what have we learned from all of this? How can we change the model to better fit reality? Are their any actionable conclusions around ENS usernames that come from this information?"),H=s()("h3",{},void 0,"Future Improvements"),L=s()("ul",{},void 0,s()("li",{},void 0,"discounted value rate"),s()("li",{},void 0,"probability of failure"),s()("li",{},void 0,"justifications using historical data"),s()("li",{},void 0,"assign variables and create eqations for each"));var M=Object(l.hot)(class extends i.Component{constructor(){super(...arguments),this.numberUserInputRef=r.a.createRef(),this.userGrowthRateRef=r.a.createRef(),this.userChurnRateRef=r.a.createRef(),this.userbarRef=r.a.createRef(),this.userConversionRef=r.a.createRef(),this.removalRateRef=r.a.createRef(),this.ensUserbarRef=r.a.createRef(),this.amountDepositSntRef=r.a.createRef(),this.lockedSntBarRef=r.a.createRef(),this.sntPriceRef=r.a.createRef(),this.lockedUsdBarRef=r.a.createRef()}componentDidMount(){(new u.b).module(d.a,e=>"viewof numberStatusUsers"===e?new u.a(this.numberUserInputRef.current):"viewof userGrowthRate"===e?new u.a(this.userGrowthRateRef.current):"viewof userChurnRate"===e?new u.a(this.userChurnRateRef.current):"viewof userbar"===e?new u.a(this.userbarRef.current):"viewof percentUsersRegisterName"===e?new u.a(this.userConversionRef.current):"viewof removalRate"===e?new u.a(this.removalRateRef.current):"viewof ensUserbar"===e?new u.a(this.ensUserbarRef.current):"viewof amountDepositSnt"===e?new u.a(this.amountDepositSntRef.current):"viewof lockedSntBar"===e?new u.a(this.lockedSntBarRef.current):"viewof sntPrice"===e?new u.a(this.sntPriceRef.current):"viewof lockedUsdBar"===e?new u.a(this.lockedUsdBarRef.current):null)}render(){return s()("div",{className:"App"},void 0,w,p,b,y,g,S,R,k,N,T,E,U,r.a.createElement("div",{ref:this.numberUserInputRef}),r.a.createElement("div",{ref:this.userGrowthRateRef}),r.a.createElement("div",{ref:this.userChurnRateRef}),r.a.createElement("div",{ref:this.userbarRef,className:v.a.chart}),I,W,B,r.a.createElement("div",{ref:this.userConversionRef}),r.a.createElement("div",{ref:this.removalRateRef}),r.a.createElement("div",{ref:this.ensUserbarRef}),C,q,D,r.a.createElement("div",{ref:this.amountDepositSntRef}),r.a.createElement("div",{ref:this.lockedSntBarRef}),j,x,r.a.createElement("div",{ref:this.sntPriceRef}),r.a.createElement("div",{ref:this.lockedUsdBarRef}),G,F,H,L)}});h.a.render(s()(M,{}),document.getElementById("app"))}},[[33,1,2]]]); +//# sourceMappingURL=main.19eada2693bb63ee3209.js.map \ No newline at end of file diff --git a/build/js/main.d7287a5639e08859fa47.js.map b/build/js/main.19eada2693bb63ee3209.js.map similarity index 74% rename from build/js/main.d7287a5639e08859fa47.js.map rename to build/js/main.19eada2693bb63ee3209.js.map index b8a5831..b7c3f13 100644 --- a/build/js/main.d7287a5639e08859fa47.js.map +++ b/build/js/main.19eada2693bb63ee3209.js.map @@ -1 +1 @@ -{"version":3,"sources":["webpack:///./src/App.jsx","webpack:///./src/index.jsx"],"names":["jsx_default","href","latex_default","a","displayMode","hot","Component","[object Object]","super","arguments","this","numberUserInputRef","React","createRef","userGrowthRateRef","userChurnRateRef","userbarRef","userConversionRef","removalRateRef","ensUserbarRef","amountDepositSntRef","lockedSntBarRef","sntPriceRef","lockedUsdBarRef","componentDidMount","Runtime","module","notebook","name","Inspector","current","render","className","_ref","_ref2","_ref3","_ref4","_ref5","_ref6","_ref7","_ref8","_ref9","_ref10","_ref11","_ref12","react_default","createElement","ref","style","chart","_ref13","_ref14","_ref15","_ref16","_ref17","_ref18","_ref19","_ref20","_ref21","ReactDOM","src_App_0","document","getElementById"],"mappings":"qOAyEQA,IAAA,iCACAA,IAAA,yRAMAA,IAAA,obASAA,IAAA,61BAeAA,IAAA,kGAEmB,IACjBA,IAAA,KAAGC,KAAK,yCAAR,gBAHF,IAIED,IAAA,eACEA,IAAA,iCACAA,IAAA,kCACAA,IAAA,gCACAA,IAAA,iCACAA,IAAA,yCACAA,IAAA,+EAGJA,IAAA,meASAA,IAAA,ijBAUAA,IAAA,saAOEA,IAAA,eACEA,IAAA,gEACAA,IAAA,kEACAA,IAAA,4GAIAA,IAAA,oIAIAA,IAAA,2IAMJA,IAAA,2hBAUAA,IAAA,4CACAA,IAAA,oCACAA,IAAA,stBAiBAA,IAAA,6DACAA,IAAA,udASAA,IAAA,6kBAcAA,IAAA,sDACAA,IAAA,2ZAQAA,IAAA,eACEA,IAACE,EAAAC,EAAD,CAAOC,aAAW,QAAlB,EAEI,gGAMNJ,IAAA,wDAGAA,IAAA,6CACAA,IAAA,yMAUOK,oBA9Of,cAAkBC,YAAUC,cAAAC,SAAAC,WAAAC,KAyC1BC,mBAAqBC,IAAMC,YAzCDH,KA2C1BI,kBAAoBF,IAAMC,YA3CAH,KA6C1BK,iBAAmBH,IAAMC,YA7CCH,KA+C1BM,WAAaJ,IAAMC,YA/COH,KAiD1BO,kBAAoBL,IAAMC,YAjDAH,KAmD1BQ,eAAiBN,IAAMC,YAnDGH,KAqD1BS,cAAgBP,IAAMC,YArDIH,KAuD1BU,oBAAsBR,IAAMC,YAvDFH,KAyD1BW,gBAAkBT,IAAMC,YAzDEH,KA2D1BY,YAAcV,IAAMC,YA3DMH,KA6D1Ba,gBAAkBX,IAAMC,YA5DxBW,qBACkB,IAAIC,KACZC,OAAOC,IAAUC,GACV,6BAATA,EACK,IAAIC,IAAUnB,KAAKC,mBAAmBmB,SAElC,0BAATF,EACK,IAAIC,IAAUnB,KAAKI,kBAAkBgB,SAEjC,yBAATF,EACK,IAAIC,IAAUnB,KAAKK,iBAAiBe,SAEhC,mBAATF,EACK,IAAIC,IAAUnB,KAAKM,WAAWc,SAE1B,oCAATF,EACK,IAAIC,IAAUnB,KAAKO,kBAAkBa,SAEjC,uBAATF,EACK,IAAIC,IAAUnB,KAAKQ,eAAeY,SAE9B,sBAATF,EACK,IAAIC,IAAUnB,KAAKS,cAAcW,SAE7B,4BAATF,EACK,IAAIC,IAAUnB,KAAKU,oBAAoBU,SAEnC,wBAATF,EACK,IAAIC,IAAUnB,KAAKW,gBAAgBS,SAE/B,oBAATF,EACK,IAAIC,IAAUnB,KAAKY,YAAYQ,SAE3B,wBAATF,EACK,IAAIC,IAAUnB,KAAKa,gBAAgBO,SAErC,MA0BXC,SACE,OACE/B,IAAA,OAAKgC,UAAU,YAAf,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAiHEC,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKC,qBACfkC,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKI,oBACf+B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKK,mBACf8B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKM,WAAYgB,UAAWgB,IAAMC,QApH9CC,EAAAC,EAAAC,EA0IEP,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKO,oBACf4B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKQ,iBACf2B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKS,gBA5IjBkC,EAAAC,EAAAC,EA6JEV,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKU,sBACfyB,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKW,kBA9JjBmC,EAgKEX,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKY,cACfuB,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKa,kBAjKjBkC,EAAAC,MCpENC,IAAS5B,OAAO/B,IAAC4D,EAAD,IAASC,SAASC,eAAe","file":"js/main.d7287a5639e08859fa47.js","sourcesContent":["import React, { Component } from 'react';\nimport { hot } from 'react-hot-loader/root';\nimport { Runtime, Inspector } from '@observablehq/runtime';\nimport notebook from '@corpetty/test-graph-embed';\nimport Latex from 'react-latex';\nimport style from './App.css';\n\nclass App extends Component {\n componentDidMount() {\n const runtime = new Runtime();\n runtime.module(notebook, name => {\n if (name === 'viewof numberStatusUsers') {\n return new Inspector(this.numberUserInputRef.current);\n }\n if (name === 'viewof userGrowthRate') {\n return new Inspector(this.userGrowthRateRef.current);\n }\n if (name === 'viewof userChurnRate') {\n return new Inspector(this.userChurnRateRef.current);\n }\n if (name === 'viewof userbar') {\n return new Inspector(this.userbarRef.current);\n }\n if (name === 'viewof percentUsersRegisterName') {\n return new Inspector(this.userConversionRef.current);\n }\n if (name === 'viewof removalRate') {\n return new Inspector(this.removalRateRef.current);\n }\n if (name === 'viewof ensUserbar') {\n return new Inspector(this.ensUserbarRef.current);\n }\n if (name === 'viewof amountDepositSnt') {\n return new Inspector(this.amountDepositSntRef.current);\n }\n if (name === 'viewof lockedSntBar') {\n return new Inspector(this.lockedSntBarRef.current);\n }\n if (name === 'viewof sntPrice') {\n return new Inspector(this.sntPriceRef.current);\n }\n if (name === 'viewof lockedUsdBar') {\n return new Inspector(this.lockedUsdBarRef.current);\n }\n return null;\n });\n }\n\n numberUserInputRef = React.createRef();\n\n userGrowthRateRef = React.createRef();\n\n userChurnRateRef = React.createRef();\n\n userbarRef = React.createRef();\n\n userConversionRef = React.createRef();\n\n removalRateRef = React.createRef();\n\n ensUserbarRef = React.createRef();\n\n amountDepositSntRef = React.createRef();\n\n lockedSntBarRef = React.createRef();\n\n sntPriceRef = React.createRef();\n\n lockedUsdBarRef = React.createRef();\n\n render() {\n return (\n
\n

Introduction

\n

\n The Status Network has a utility token, the Status Network Token\n (SNT). What does that even mean? What utilities does it have and how\n do their uses affect the rest of the ecosystem? Does it have an impact\n on valuation? What even is valuation of a utility token?\n

\n

\n These questions are hard, and there does not seem to be sufficient\n academic answers to them, for very good reasons. The technology\n enabling a “utility token” is new, and transcendent of many older\n technologies. This consequently means the models used to evaluate the\n older technologies will never be able to completely describe the newer\n ones. We, as a community, need to build new ones and evaluate them\n rigorously.\n

\n

\n There is currently quite a bit of work being done in this field, but\n it is mostly for investment firms to make appropriate calls on buying,\n selling, and holding various project’s tokens. While this is\n drastically important for growth and project funding, we at Status\n feel that there are other, less financially motivated reasons to do\n this work which require a different approach. More specifically, any\n utility token needs to be able to objectively evaluate various\n features and utilities of their platform, and how they affect the\n entirety of their ecosystem. For instance, we need to be able to ask\n questions like the following: “How can we objectively measure the use\n of SNT if it gets used in feature X as a function of our user base?\n Based on that measurement, is its development cost justified, or\n should we focus on something else?”\n

\n

\n We will be launching Status with the following SNT use-cases, as\n described in the{' '}\n whitepaper:\n

    \n
  • Teller Network
    • \n
  • Tribute to Talk
    • \n
  • ENS Usernames
    • \n
  • Sticker Market
    • \n
  • SNT Curated Dapp Store
    • \n
  • Network Incentivization (may not be available at launch)
    • \n
\n

\n

\n Each of these use-cases are run by the SNT token, but in very\n different ways. This means each will have differing effects on the\n supply and demand of the token itself. It doesn’t stop there, as\n Status is an open and permissionless platform for developers to build\n on and use, which means that anyone can build SNT use-cases that\n affect the overall supply and demand. But how do we know what effect a\n utility has? Where do we go to try and evaluate its usefulness?\n

\n

\n To this end, we would like to start a blog series detailing some of\n the research we are doing within Status to objectively evaluate the\n flow of SNT, the potential effects of our implemented (and upcoming)\n SNT use cases within Status, and how our potential user growth changes\n things. This work will encompass traditional economic and portfolio\n theory, work currently being done in crypto-economics, and novel\n methodology. That means a part of this endeavor is an attempt to get\n peer review and evaluation of what we do by you, the community!\n

\n

\n Let’s start with the ENS naming system. In Status, for a little SNT,\n you can register your username on the Ethereum Name System (ENS) so\n others can find you easily. In order for us to apply models or\n understand the economics of a use case, we first have to understand\n what it is, how it works, and how it fits within the Status ecosystem.\n Let’s start by breaking down how ENS usernames work within Status:\n

    \n
  1. User selects a unique username, {``}
    2. \n
  2. User deposits 10 SNT into the ENS username dapp
    3. \n
  3. \n User is granted sole control over the subdomain {``}\n .stateofus.eth for 1 year\n
    4. \n
  4. \n User is able to get deposited funds after this yearly period, and\n release the username back into available names.\n
    5. \n
  5. \n User is now searchable within Status as {``} or\n {``}.stateofus.eth outside of the Status app.\n
    6. \n
\n

\n

\n The use case and token flow are both relatively simple, but what are\n the effects on the ecosystem? Let’s first try and model what value\n this could potentially accrue over time. We can start by picking out\n the variables in this process to see how things depend on each other.\n Furthermore, the above values are what we currently use, but in terms\n of modeling, we should turn those into variables that allow us to see\n what effect each has on the overall mechanism. This can help inform us\n (and you) on appropriate choices.\n

\n

Disucssion of variables

\n

Number of Users

\n

\n It is clear that this all depends on how many users Status has in the\n app. If they are not using Status, then they won’t use the feature.\n This is our base metric, and we will model it using compounding growth\n and loss. We can start with a number of users that are using the app,\n and set additional growth and loss variables (in percentages) that\n define how this number changes over the next 10 years. This means that\n every year, we expect a certain percentage change in users based on\n the numbers of the previous year. Depending on how you set those\n percentages, the number of users can grow very rapidly! Go ahead and\n play with the following variables to see how the number of users\n change over the years.\n

\n
\n
\n
\n
\n

Conversion rate of users to ENS username

\n

\n Ok cool. We have our user base locked and loaded for the next 10\n years, but not everyone is going to register an ENS username. We can\n brand it, make it simple, and incentivize people to do it but the\n reality is that that number will never be 100%. So the number of\n people that DO decide to register an ENS username is what we want. We\n get this number by multiplying the total number of users by the\n adoption conversion rate, which is another variable.\n

\n

\n Now not all users will keep their usernames. Some people will remove\n their deposit after the year and bring their SNT back into\n circulation. Some people will leave Status altogether. If they never\n manually release their SNT from the ENS username contract, it can be\n considered locked forever. For this, we will continue to consider them\n users because from the contract's perspective, they are\n indestiguishable. We’ll model the people who release their username\n with another conversion factor. Go ahead and change these variables\n and see how the following graph changes.\n

\n
\n
\n
\n

Amount of SNT required to deposit

\n

\n Now we have the amount of users that will (or have) use(d) this\n utility. Let’s figure out how that translates to SNT. In order to do\n that, we have another variable to define: The amount of SNT required\n to register an ENS username. By multiplying each user by this\n variable, we can show how much SNT is being locked up every year which\n effectively takes it out of the circulating supply, i.e.\n

\n

\n \n {\n '$$N_{\\\\text{SNT locked}} = N_{\\\\text{registrations}} * N_{\\\\text{SNT per registration}}$$'\n }\n \n

\n
\n
\n

How to assign value to all of this?

\n
\n
\n

Thoughts and Conclusions

\n

\n So what have we learned from all of this? How can we change the model\n to better fit reality? Are their any actionable conclusions around ENS\n usernames that come from this information?\n

\n
\n );\n }\n}\n\nexport default hot(App);\n","import React from 'react';\nimport ReactDOM from 'react-dom';\nimport App from './App.jsx';\n\nReactDOM.render(, document.getElementById('app'));\n"],"sourceRoot":""} \ No newline at end of file +{"version":3,"sources":["webpack:///./src/App.jsx","webpack:///./src/index.jsx"],"names":["jsx_default","href","latex_default","a","displayMode","hot","Component","[object Object]","super","arguments","this","numberUserInputRef","React","createRef","userGrowthRateRef","userChurnRateRef","userbarRef","userConversionRef","removalRateRef","ensUserbarRef","amountDepositSntRef","lockedSntBarRef","sntPriceRef","lockedUsdBarRef","componentDidMount","Runtime","module","notebook","name","Inspector","current","render","className","_ref","_ref2","_ref3","_ref4","_ref5","_ref6","_ref7","_ref8","_ref9","_ref10","_ref11","_ref12","react_default","createElement","ref","style","chart","_ref13","_ref14","_ref15","_ref16","_ref17","_ref18","_ref19","_ref20","_ref21","_ref22","_ref23","_ref24","ReactDOM","src_App_0","document","getElementById"],"mappings":"qOAyEQA,IAAA,iCACAA,IAAA,yRAMAA,IAAA,obASAA,IAAA,61BAeAA,IAAA,kGAEmB,IACjBA,IAAA,KAAGC,KAAK,yCAAR,gBAHF,IAIED,IAAA,eACEA,IAAA,iCACAA,IAAA,kCACAA,IAAA,gCACAA,IAAA,iCACAA,IAAA,yCACAA,IAAA,+EAGJA,IAAA,meASAA,IAAA,ijBAUAA,IAAA,saAOEA,IAAA,eACEA,IAAA,gEACAA,IAAA,kEACAA,IAAA,4GAIAA,IAAA,oIAIAA,IAAA,2IAMJA,IAAA,2hBAUAA,IAAA,4CACAA,IAAA,oCACAA,IAAA,stBAiBAA,IAAA,6DACAA,IAAA,udASAA,IAAA,6kBAcAA,IAAA,sDACAA,IAAA,2ZAQAA,IAAA,cACEA,IAACE,EAAAC,EAAD,CAAOC,aAAW,QAAlB,EAEI,gGAMNJ,IAAA,wDACAA,IAAA,2KAOAA,IAAA,6CACAA,IAAA,2MAKAA,IAAA,wCACAA,IAAA,eACEA,IAAA,wCACAA,IAAA,yCACAA,IAAA,uDACAA,IAAA,iEAOKK,oBA1Pf,cAAkBC,YAAUC,cAAAC,SAAAC,WAAAC,KAyC1BC,mBAAqBC,IAAMC,YAzCDH,KA2C1BI,kBAAoBF,IAAMC,YA3CAH,KA6C1BK,iBAAmBH,IAAMC,YA7CCH,KA+C1BM,WAAaJ,IAAMC,YA/COH,KAiD1BO,kBAAoBL,IAAMC,YAjDAH,KAmD1BQ,eAAiBN,IAAMC,YAnDGH,KAqD1BS,cAAgBP,IAAMC,YArDIH,KAuD1BU,oBAAsBR,IAAMC,YAvDFH,KAyD1BW,gBAAkBT,IAAMC,YAzDEH,KA2D1BY,YAAcV,IAAMC,YA3DMH,KA6D1Ba,gBAAkBX,IAAMC,YA5DxBW,qBACkB,IAAIC,KACZC,OAAOC,IAAUC,GACV,6BAATA,EACK,IAAIC,IAAUnB,KAAKC,mBAAmBmB,SAElC,0BAATF,EACK,IAAIC,IAAUnB,KAAKI,kBAAkBgB,SAEjC,yBAATF,EACK,IAAIC,IAAUnB,KAAKK,iBAAiBe,SAEhC,mBAATF,EACK,IAAIC,IAAUnB,KAAKM,WAAWc,SAE1B,oCAATF,EACK,IAAIC,IAAUnB,KAAKO,kBAAkBa,SAEjC,uBAATF,EACK,IAAIC,IAAUnB,KAAKQ,eAAeY,SAE9B,sBAATF,EACK,IAAIC,IAAUnB,KAAKS,cAAcW,SAE7B,4BAATF,EACK,IAAIC,IAAUnB,KAAKU,oBAAoBU,SAEnC,wBAATF,EACK,IAAIC,IAAUnB,KAAKW,gBAAgBS,SAE/B,oBAATF,EACK,IAAIC,IAAUnB,KAAKY,YAAYQ,SAE3B,wBAATF,EACK,IAAIC,IAAUnB,KAAKa,gBAAgBO,SAErC,MA0BXC,SACE,OACE/B,IAAA,OAAKgC,UAAU,YAAf,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAiHEC,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKC,qBACfkC,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKI,oBACf+B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKK,mBACf8B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKM,WAAYgB,UAAWgB,IAAMC,QApH9CC,EAAAC,EAAAC,EA0IEP,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKO,oBACf4B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKQ,iBACf2B,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKS,gBA5IjBkC,EAAAC,EAAAC,EA6JEV,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKU,sBACfyB,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKW,kBA9JjBmC,EAAAC,EAqKEZ,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKY,cACfuB,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKa,kBAtKjBmC,EAAAC,EAAAC,EAAAC,MCpENC,IAAS/B,OAAO/B,IAAC+D,EAAD,IAASC,SAASC,eAAe","file":"js/main.19eada2693bb63ee3209.js","sourcesContent":["import React, { Component } from 'react';\nimport { hot } from 'react-hot-loader/root';\nimport { Runtime, Inspector } from '@observablehq/runtime';\nimport notebook from '@corpetty/test-graph-embed';\nimport Latex from 'react-latex';\nimport style from './App.css';\n\nclass App extends Component {\n componentDidMount() {\n const runtime = new Runtime();\n runtime.module(notebook, name => {\n if (name === 'viewof numberStatusUsers') {\n return new Inspector(this.numberUserInputRef.current);\n }\n if (name === 'viewof userGrowthRate') {\n return new Inspector(this.userGrowthRateRef.current);\n }\n if (name === 'viewof userChurnRate') {\n return new Inspector(this.userChurnRateRef.current);\n }\n if (name === 'viewof userbar') {\n return new Inspector(this.userbarRef.current);\n }\n if (name === 'viewof percentUsersRegisterName') {\n return new Inspector(this.userConversionRef.current);\n }\n if (name === 'viewof removalRate') {\n return new Inspector(this.removalRateRef.current);\n }\n if (name === 'viewof ensUserbar') {\n return new Inspector(this.ensUserbarRef.current);\n }\n if (name === 'viewof amountDepositSnt') {\n return new Inspector(this.amountDepositSntRef.current);\n }\n if (name === 'viewof lockedSntBar') {\n return new Inspector(this.lockedSntBarRef.current);\n }\n if (name === 'viewof sntPrice') {\n return new Inspector(this.sntPriceRef.current);\n }\n if (name === 'viewof lockedUsdBar') {\n return new Inspector(this.lockedUsdBarRef.current);\n }\n return null;\n });\n }\n\n numberUserInputRef = React.createRef();\n\n userGrowthRateRef = React.createRef();\n\n userChurnRateRef = React.createRef();\n\n userbarRef = React.createRef();\n\n userConversionRef = React.createRef();\n\n removalRateRef = React.createRef();\n\n ensUserbarRef = React.createRef();\n\n amountDepositSntRef = React.createRef();\n\n lockedSntBarRef = React.createRef();\n\n sntPriceRef = React.createRef();\n\n lockedUsdBarRef = React.createRef();\n\n render() {\n return (\n
\n

Introduction

\n

\n The Status Network has a utility token, the Status Network Token\n (SNT). What does that even mean? What utilities does it have and how\n do their uses affect the rest of the ecosystem? Does it have an impact\n on valuation? What even is valuation of a utility token?\n

\n

\n These questions are hard, and there does not seem to be sufficient\n academic answers to them, for very good reasons. The technology\n enabling a “utility token” is new, and transcendent of many older\n technologies. This consequently means the models used to evaluate the\n older technologies will never be able to completely describe the newer\n ones. We, as a community, need to build new ones and evaluate them\n rigorously.\n

\n

\n There is currently quite a bit of work being done in this field, but\n it is mostly for investment firms to make appropriate calls on buying,\n selling, and holding various project’s tokens. While this is\n drastically important for growth and project funding, we at Status\n feel that there are other, less financially motivated reasons to do\n this work which require a different approach. More specifically, any\n utility token needs to be able to objectively evaluate various\n features and utilities of their platform, and how they affect the\n entirety of their ecosystem. For instance, we need to be able to ask\n questions like the following: “How can we objectively measure the use\n of SNT if it gets used in feature X as a function of our user base?\n Based on that measurement, is its development cost justified, or\n should we focus on something else?”\n

\n

\n We will be launching Status with the following SNT use-cases, as\n described in the{' '}\n whitepaper:\n

    \n
  • Teller Network
    • \n
  • Tribute to Talk
    • \n
  • ENS Usernames
    • \n
  • Sticker Market
    • \n
  • SNT Curated Dapp Store
    • \n
  • Network Incentivization (may not be available at launch)
    • \n
\n

\n

\n Each of these use-cases are run by the SNT token, but in very\n different ways. This means each will have differing effects on the\n supply and demand of the token itself. It doesn’t stop there, as\n Status is an open and permissionless platform for developers to build\n on and use, which means that anyone can build SNT use-cases that\n affect the overall supply and demand. But how do we know what effect a\n utility has? Where do we go to try and evaluate its usefulness?\n

\n

\n To this end, we would like to start a blog series detailing some of\n the research we are doing within Status to objectively evaluate the\n flow of SNT, the potential effects of our implemented (and upcoming)\n SNT use cases within Status, and how our potential user growth changes\n things. This work will encompass traditional economic and portfolio\n theory, work currently being done in crypto-economics, and novel\n methodology. That means a part of this endeavor is an attempt to get\n peer review and evaluation of what we do by you, the community!\n

\n

\n Let’s start with the ENS naming system. In Status, for a little SNT,\n you can register your username on the Ethereum Name System (ENS) so\n others can find you easily. In order for us to apply models or\n understand the economics of a use case, we first have to understand\n what it is, how it works, and how it fits within the Status ecosystem.\n Let’s start by breaking down how ENS usernames work within Status:\n

    \n
  1. User selects a unique username, {``}
    2. \n
  2. User deposits 10 SNT into the ENS username dapp
    3. \n
  3. \n User is granted sole control over the subdomain {``}\n .stateofus.eth for 1 year\n
    4. \n
  4. \n User is able to get deposited funds after this yearly period, and\n release the username back into available names.\n
    5. \n
  5. \n User is now searchable within Status as {``} or\n {``}.stateofus.eth outside of the Status app.\n
    6. \n
\n

\n

\n The use case and token flow are both relatively simple, but what are\n the effects on the ecosystem? Let’s first try and model what value\n this could potentially accrue over time. We can start by picking out\n the variables in this process to see how things depend on each other.\n Furthermore, the above values are what we currently use, but in terms\n of modeling, we should turn those into variables that allow us to see\n what effect each has on the overall mechanism. This can help inform us\n (and you) on appropriate choices.\n

\n

Disucssion of variables

\n

Number of Users

\n

\n It is clear that this all depends on how many users Status has in the\n app. If they are not using Status, then they won’t use the feature.\n This is our base metric, and we will model it using compounding growth\n and loss. We can start with a number of users that are using the app,\n and set additional growth and loss variables (in percentages) that\n define how this number changes over the next 10 years. This means that\n every year, we expect a certain percentage change in users based on\n the numbers of the previous year. Depending on how you set those\n percentages, the number of users can grow very rapidly! Go ahead and\n play with the following variables to see how the number of users\n change over the years.\n

\n
\n
\n
\n
\n

Conversion rate of users to ENS username

\n

\n Ok cool. We have our user base locked and loaded for the next 10\n years, but not everyone is going to register an ENS username. We can\n brand it, make it simple, and incentivize people to do it but the\n reality is that that number will never be 100%. So the number of\n people that DO decide to register an ENS username is what we want. We\n get this number by multiplying the total number of users by the\n adoption conversion rate, which is another variable.\n

\n

\n Now not all users will keep their usernames. Some people will remove\n their deposit after the year and bring their SNT back into\n circulation. Some people will leave Status altogether. If they never\n manually release their SNT from the ENS username contract, it can be\n considered locked forever. For this, we will continue to consider them\n users because from the contract's perspective, they are\n indestiguishable. We’ll model the people who release their username\n with another conversion factor. Go ahead and change these variables\n and see how the following graph changes.\n

\n
\n
\n
\n

Amount of SNT required to deposit

\n

\n Now we have the amount of users that will (or have) use(d) this\n utility. Let’s figure out how that translates to SNT. In order to do\n that, we have another variable to define: The amount of SNT required\n to register an ENS username. By multiplying each user by this\n variable, we can show how much SNT is being locked up every year which\n effectively takes it out of the circulating supply, i.e.\n

\n

\n \n {\n '$$N_{\\\\text{SNT locked}} = N_{\\\\text{registrations}} * N_{\\\\text{SNT per registration}}$$'\n }\n \n

\n
\n
\n

How to assign value to all of this?

\n

\n Having the amount of SNT locked up is quite useful by itself. From\n there, we can look at the circulating supply and see how this use-case\n reflects that\n

\n
\n
\n

Thoughts and Conclusions

\n

\n So what have we learned from all of this? How can we change the model\n to better fit reality? Are their any actionable conclusions around ENS\n usernames that come from this information?\n

\n

Future Improvements

\n
    \n
  • discounted value rate
    • \n
  • probability of failure
    • \n
  • justifications using historical data
    • \n
  • assign variables and create eqations for each
    • \n
\n
\n );\n }\n}\n\nexport default hot(App);\n","import React from 'react';\nimport ReactDOM from 'react-dom';\nimport App from './App.jsx';\n\nReactDOM.render(, document.getElementById('app'));\n"],"sourceRoot":""} \ No newline at end of file diff --git a/build/js/runtime~main.e6dd4b6bdd4350738cf1.js b/build/js/runtime~main.2d16bf3960c132ab8ad8.js similarity index 95% rename from build/js/runtime~main.e6dd4b6bdd4350738cf1.js rename to build/js/runtime~main.2d16bf3960c132ab8ad8.js index 13f2090..96a249e 100644 --- a/build/js/runtime~main.e6dd4b6bdd4350738cf1.js +++ b/build/js/runtime~main.2d16bf3960c132ab8ad8.js @@ -1,2 +1,2 @@ !function(e){function r(r){for(var n,f,i=r[0],l=r[1],a=r[2],c=0,s=[];c

How to assign value to all of this?

- Having the amount of SNT locked up is quite useful by itself. From there, - we can look at the circulating supply and see how this use-case reflects that + Having the amount of SNT locked up is quite useful by itself. From + there, we can look at the circulating supply and see how this use-case + reflects that