\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 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 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\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\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\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 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