From 14dfef42be993876f7ab3f21359c2ff4ca46588f Mon Sep 17 00:00:00 2001
From: Corey Petty
Date: Fri, 31 May 2019 15:37:10 -0400
Subject: [PATCH] removed initial cost, spelling
---
.gitignore | 1 +
build/css/main.css | 0
build/index.html | 234 -------------
build/js/main.fd217d89d43fb9fb4e15.js | 2 -
build/js/main.fd217d89d43fb9fb4e15.js.map | 1 -
build/js/runtime~main.29734087575106c76a9f.js | 2 -
.../runtime~main.d26192c48fdcce4d50bb.js.map | 1 -
report.20190530.200053.9760.0.001.json | 331 ++++++++++++++++++
report.20190530.200259.10397.0.001.json | 331 ++++++++++++++++++
report.20190531.095458.26842.0.001.json | 331 ++++++++++++++++++
report.20190531.095500.26942.0.001.json | 331 ++++++++++++++++++
src/App.jsx | 117 ++++---
12 files changed, 1388 insertions(+), 294 deletions(-)
delete mode 100644 build/css/main.css
delete mode 100644 build/index.html
delete mode 100644 build/js/main.fd217d89d43fb9fb4e15.js
delete mode 100644 build/js/main.fd217d89d43fb9fb4e15.js.map
delete mode 100644 build/js/runtime~main.29734087575106c76a9f.js
delete mode 100644 build/js/runtime~main.d26192c48fdcce4d50bb.js.map
create mode 100644 report.20190530.200053.9760.0.001.json
create mode 100644 report.20190530.200259.10397.0.001.json
create mode 100644 report.20190531.095458.26842.0.001.json
create mode 100644 report.20190531.095500.26942.0.001.json
diff --git a/.gitignore b/.gitignore
index 3f4b087..668e2ed 100644
--- a/.gitignore
+++ b/.gitignore
@@ -23,3 +23,4 @@ package-lock.json
# Editor/IDE
.idea
packages/api/etc/
+build/*
\ No newline at end of file
diff --git a/build/css/main.css b/build/css/main.css
deleted file mode 100644
index e69de29..0000000
diff --git a/build/index.html b/build/index.html
deleted file mode 100644
index 5723286..0000000
--- a/build/index.html
+++ /dev/null
@@ -1,234 +0,0 @@
-
-
-
-
-
-
- Webpack react boilerplate
-
-
-
-
-
-
-
-
diff --git a/build/js/main.fd217d89d43fb9fb4e15.js b/build/js/main.fd217d89d43fb9fb4e15.js
deleted file mode 100644
index f249d22..0000000
--- a/build/js/main.fd217d89d43fb9fb4e15.js
+++ /dev/null
@@ -1,2 +0,0 @@
-(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?"),k=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!"),R=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."),C=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."),D=s()("h3",{},void 0,"Amount of SNT required to deposit"),B=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."),j=s()("p",{},void 0,s()(f.a,{displayMode:!0},void 0,"$$N_{\\text{SNT locked}} = N_{\\text{registrations}} * N_{\\text{SNT per registration}}$$")),q=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 affects its availability. It is also interesting to see how this maps to real world assets by look at the current price of SNT in US Dollars (USD). Since most evaluation mechanism use a market capitalization (cap) metric to compare different networks and tokens, mapping each use-case , and eventually the whole network, allows us to see how much they contribute to a given market cap."),A=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?"),H=s()("p",{},void 0,"As stated previously, this particular use-case and work done the groundwork to build more complex models of the SNT use-cases. It also helps introduce the concept of how different variables affect growth and impact over time. If you plan to follow this series and work, we suggest making sure you understand each step along the way because all of this can get complicated fast."),F=s()("p",{},void 0,"You have probably noticed that the default values for each variable is not justified anywhere. This is a problem that we plan to face by using historical data to make justified default values. Right now, we have a toolset to see what happens when we change variables, but not",s()("em",{},void 0," what those variables should be based in reality.")," These workbooks are living documents that will change over time to include such work."),L=s()("h3",{},void 0,"Call to Action"),O=s()("p",{},void 0,"Our goal is to continuously improve these methods and create more work not only around ENS usernames, but with the entire SNT ecosystem. This means we would love to get feedback from you, the community. If we have done something incorrectly, or you know of some way to better model various aspects herein, please join the discussion. We will be posting all of these articles in [DISCUSS WHERE WE WANT THIS TO LIVE]."),M=s()("h3",{},void 0,"Future Improvements"),P=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 equations for each"));var $=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,k,R,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,C,r.a.createElement("div",{ref:this.userConversionRef}),r.a.createElement("div",{ref:this.removalRateRef}),r.a.createElement("div",{ref:this.ensUserbarRef}),D,B,j,r.a.createElement("div",{ref:this.amountDepositSntRef}),r.a.createElement("div",{ref:this.lockedSntBarRef}),q,x,r.a.createElement("div",{ref:this.sntPriceRef}),r.a.createElement("div",{ref:this.lockedUsdBarRef}),A,G,H,F,L,O,M,P)}});h.a.render(s()($,{}),document.getElementById("app"))}},[[33,1,2]]]);
-//# sourceMappingURL=main.fd217d89d43fb9fb4e15.js.map
\ No newline at end of file
diff --git a/build/js/main.fd217d89d43fb9fb4e15.js.map b/build/js/main.fd217d89d43fb9fb4e15.js.map
deleted file mode 100644
index 648fca5..0000000
--- a/build/js/main.fd217d89d43fb9fb4e15.js.map
+++ /dev/null
@@ -1 +0,0 @@
-{"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","_ref25","_ref26","_ref27","_ref28","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,+hBAYAA,IAAA,6CACAA,IAAA,2MAKAA,IAAA,6YAQAA,IAAA,oSAKEA,IAAA,oEALF,4FASAA,IAAA,mCACAA,IAAA,mbAQAA,IAAA,wCACAA,IAAA,eACEA,IAAA,wCACAA,IAAA,yCACAA,IAAA,uDACAA,IAAA,kEAOKK,oBAzRf,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,EA0KEZ,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKY,cACfuB,EAAA1C,EAAA2C,cAAA,OAAKC,IAAKrC,KAAKa,kBA3KjBmC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,EAAAC,MCpENC,IAASnC,OAAO/B,IAACmE,EAAD,IAASC,SAASC,eAAe","file":"js/main.fd217d89d43fb9fb4e15.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
User selects a unique username, {``}
\n
User deposits 10 SNT into the ENS username dapp
\n
\n User is granted sole control over the subdomain {``}\n .stateofus.eth for 1 year\n
\n
\n User is able to get deposited funds after this yearly period, and\n release the username back into available names.\n
\n
\n User is now searchable within Status as {``} or\n {``}.stateofus.eth outside of the Status app.\n
\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 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 affects its availability. It is also interesting to see how this maps\n to real world assets by look at the current price of SNT in US Dollars\n (USD). Since most evaluation mechanism use a market capitalization\n (cap) metric to compare different networks and tokens, mapping each\n use-case , and eventually the whole network, allows us to see how much\n they contribute to a given market cap.\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
\n As stated previously, this particular use-case and work done the\n groundwork to build more complex models of the SNT use-cases. It also\n helps introduce the concept of how different variables affect growth\n and impact over time. If you plan to follow this series and work, we\n suggest making sure you understand each step along the way because all\n of this can get complicated fast.\n
\n
\n You have probably noticed that the default values for each variable is\n not justified anywhere. This is a problem that we plan to face by\n using historical data to make justified default values. Right now, we\n have a toolset to see what happens when we change variables, but not\n what those variables should be based in reality. These\n workbooks are living documents that will change over time to include\n such work.\n
\n
Call to Action
\n
\n Our goal is to continuously improve these methods and create more work\n not only around ENS usernames, but with the entire SNT ecosystem. This\n means we would love to get feedback from you, the community. If we\n have done something incorrectly, or you know of some way to better\n model various aspects herein, please join the discussion. We will be\n posting all of these articles in [DISCUSS WHERE WE WANT THIS TO LIVE].\n
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.
+ academic answers to them. 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.
There is currently quite a bit of work being done in this field, but
it is mostly for investment firms to make appropriate capital
allocation decisions among a diversified portfolio of cryptoassets.
While this is drastically important for growth and project funding,
- there is great lack of research on capital and resource allocation
- inside of a single network. 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 difference in the rate users use
- feature X in Status and its respective impact on the ecosystem?”
+ there is a lack of research on capital and resource allocation inside
+ of a single network. More specifically, any utility token needs to be
+ able to objectively evaluate various features and utilities of their
+ platform, and how they affect their ecosystem. For instance, we need
+ to be able to ask questions like:
+
+ “How can we objectively measure the difference in the rate users use
+ feature X in Status and its respective impact on the ecosystem?”
+
We will be launching Status with the following SNT use-cases, as
@@ -111,14 +112,14 @@ class App extends Component {
ENS Usernames
Sticker Market
SNT Curated Dapp Store
-
Network Incentivization (may not be available at launch)
-
Liquid Funding (may not be avaialble at launch)
-
User Acquisition Engine (will not be available at launch)
+
Liquid Funding (may not be available at launch)
+
Network Incentivization (launching after V1)
+
User Acquisition Engine (launching after V1)
- Each of these use-cases leverage the SNT token, but in very different
- ways. For instance, some will lock up large amounts, some will
+ Each of these features leverage the SNT token, but in very different
+ ways. For instance, some features will require staking, some will
actually burn the token, and some will incentivize sending and
receiving. This means each will have differing effects on the supply
and demand of the token itself, and will need to be modeled
@@ -129,14 +130,14 @@ class App extends Component {
do we go to try and evaluate its usefulness?
- 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
- value flows 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 finance 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!
+ To this end, we are starting a blog series detailing some of the
+ research we are doing within Status to objectively evaluate the value
+ flows of SNT, the potential effects of our implemented (and upcoming)
+ SNT use cases within Status, and how our potential user growth impacts
+ SNT. This work will encompass traditional economic and finance 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!
@@ -218,7 +219,7 @@ class App extends Component {
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
+ indistinguishable. 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.
@@ -263,24 +264,27 @@ class App extends Component {
use to figure out how much present value a known future cash flow is
worth. In other words, how to presently evaluate the amount of money
you know will come in the future. Once you have the discount rate, you
- can calculate the Net Present Value, which is given by the
- following formula:
+ can calculate the Net Present Value (NPV), which is given by
+ the following formula:
where $$t$$ is the number of time periods (10 in this
article),
$$R_t$$
- is the cashflow of that particular time period , and{' '}
- $$i$$ is the discount rate. The concept of discounting
- future value has been around for along time. The earliest known
- reference was in the 6th century BCE{' '}
+ is the net cashflow of that particular time period , and{' '}
+ $$i$$ is the discount rate. There is also a potential
+ for including the initial cost ($$t=0$$) of the
+ project. We are purposely not including this as Status absorbs the
+ investment cost for the network. There are quite a few subtle
+ arguments here around things like hurdle rates, payback periods, etc,
+ but we defer them and their potential utility to a future article.
+ Anyway, the concept of discounting future value has been around for a
+ long time. The earliest known reference was in the 6th century BCE{' '}
Proverbs of Ahiqar
@@ -310,8 +314,10 @@ class App extends Component {
- and all of this gets summed together to give you the following Net
- Present Value of ENS Usernames within Status:
+ and all of this gets summed together to give you the NPV of ENS
+ Usernames within Status. To be more explicit, the NPV is the present
+ value of something based on a projection into the future. Based on the
+ values chosen above, we arrive at an NPV of:
@@ -322,7 +328,7 @@ class App extends Component {
usernames are in a single value. This value will become more useful as
we build out other models for other use cases so we can compare them
and see relative differences. Eventually, we will be able to see the
- relatively impact a given utility within Status has within the entire
+ relative impact a given utility within Status has within the entire
ecosystem.
Example Scenario Analysis
@@ -330,27 +336,26 @@ class App extends Component {
It is also useful to look at how this number changes as we tweak the
input variables to see their impact. As an example, let's look at
what happens if we are able to do something to increase the number
- Status users who actualy register an ENS username (actually currently
- in the works). This is an example of the question we postuated in the
+ Status users who actually register an ENS username (actually currently
+ in the works). This is an example of the question we postulated in the
beginning of this article. The default value is 50%, which leads to a
- Net Present Utility Value of $8,527,197.00 (holding all default values
- constant).
+ NPV of $8,577,197.00 (holding all default values constant).
What happens if we're able to increase this number, say, to 75%?
- Keeping all other variables equal, this change alone changes the Net
- Present Utility Value to $12,815,797.00, which is a 50.3% growth and
- would constitute a linear relationship.
+ Keeping all other variables equal, this change alone changes the NPV
+ to $12,865,797.00, which is a 50.3% growth and would constitute a
+ linear relationship.
As another example, let's look at what happens if we increase our
- yearly growth rate, going from 300% per year to 350% per year. holding
+ yearly growth rate, going from 300% per year to 350% per year. Holding
everything else constant, with a 350% growth rate per year, we come to
- Net Present Utility Value of $24,157,021.00, a 183% growth and would
- constitue a superlinear relatinoship due to the effects of compounding
- growth. Based on these two simple examples, it is clear we should
- spend more time on user acquisition and continuious growth over
- increasing ENS username conversion rates (OR BOTH!).
+ NPV of $24,207,021.00 which is a 183% growth and would constitute a
+ superlinear relationship due to the effects of compounding growth.
+ Based on these two simple examples, it is clear we should spend more
+ time on user acquisition and continuous growth over increasing ENS
+ username conversion rates (OR BOTH!).
As you can see, by making models of our SNT use-cases, we can start to
@@ -372,7 +377,9 @@ class App extends Component {
helps introduce the concept of how different variables affect growth
and impact over time. If you plan to follow this series and work, we
suggest making sure you understand each step along the way because all
- of this can get complicated fast.
+ of this can get complicated fast. At the very least, we hope you have
+ been able to grasp a little of what goes on behind the scenes at
+ Status.
You have probably noticed that the default values for each variable is
@@ -394,11 +401,13 @@ class App extends Component {
our discuss and linking around
the internet in relevant places.
-
Future Improvements
+
Future Improvements and Articles
probability of failure
justifications using historical data
assign variables and create equations for each
+
discussion around initial cost, hurdle rates, payback periods