include build files for embedding
This commit is contained in:
parent
6c200e82ed
commit
211512807a
|
|
@ -20,10 +20,6 @@ yarn-debug.log*
|
|||
yarn-error.log*
|
||||
yarn.lock*
|
||||
package-lock.json
|
||||
/build/bundle.js
|
||||
/build/index.html
|
||||
/build*
|
||||
/build/*
|
||||
# Editor/IDE
|
||||
.idea
|
||||
packages/api/etc/
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
|
|
@ -0,0 +1,2 @@
|
|||
!function(e){function r(r){for(var n,f,i=r[0],l=r[1],a=r[2],c=0,s=[];c<i.length;c++)f=i[c],o[f]&&s.push(o[f][0]),o[f]=0;for(n in l)Object.prototype.hasOwnProperty.call(l,n)&&(e[n]=l[n]);for(p&&p(r);s.length;)s.shift()();return u.push.apply(u,a||[]),t()}function t(){for(var e,r=0;r<u.length;r++){for(var t=u[r],n=!0,i=1;i<t.length;i++){var l=t[i];0!==o[l]&&(n=!1)}n&&(u.splice(r--,1),e=f(f.s=t[0]))}return e}var n={},o={1:0},u=[];function f(r){if(n[r])return n[r].exports;var t=n[r]={i:r,l:!1,exports:{}};return e[r].call(t.exports,t,t.exports,f),t.l=!0,t.exports}f.m=e,f.c=n,f.d=function(e,r,t){f.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},f.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.t=function(e,r){if(1&r&&(e=f(e)),8&r)return e;if(4&r&&"object"==typeof e&&e&&e.__esModule)return e;var t=Object.create(null);if(f.r(t),Object.defineProperty(t,"default",{enumerable:!0,value:e}),2&r&&"string"!=typeof e)for(var n in e)f.d(t,n,function(r){return e[r]}.bind(null,n));return t},f.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(r,"a",r),r},f.o=function(e,r){return Object.prototype.hasOwnProperty.call(e,r)},f.p="";var i=window.webpackJsonp=window.webpackJsonp||[],l=i.push.bind(i);i.push=r,i=i.slice();for(var a=0;a<i.length;a++)r(i[a]);var p=l;t()}([]);
|
||||
//# sourceMappingURL=runtime~main.e6dd4b6bdd4350738cf1.js.map
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
147
src/App.jsx
147
src/App.jsx
|
|
@ -71,6 +71,103 @@ class App extends Component {
|
|||
render() {
|
||||
return (
|
||||
<div className="App">
|
||||
<h2>Introduction</h2>
|
||||
<p>
|
||||
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?
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
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?”
|
||||
</p>
|
||||
<p>
|
||||
We will be launching Status with the following SNT use-cases, as
|
||||
described in the{' '}
|
||||
<a href="https://status.im/whitepaper.pdf">whitepaper</a>:
|
||||
<ul>
|
||||
<li>Teller Network</li>
|
||||
<li>Tribute to Talk</li>
|
||||
<li>ENS Usernames</li>
|
||||
<li>Sticker Market</li>
|
||||
<li>SNT Curated Dapp Store</li>
|
||||
<li>Network Incentivization (may not be available at launch)</li>
|
||||
</ul>
|
||||
</p>
|
||||
<p>
|
||||
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?
|
||||
</p>
|
||||
<p>
|
||||
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!
|
||||
</p>
|
||||
<p>
|
||||
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:
|
||||
<ol>
|
||||
<li>User selects a unique username, {`<username>`}</li>
|
||||
<li>User deposits 10 SNT into the ENS username dapp</li>
|
||||
<li>
|
||||
User is granted sole control over the subdomain {`<username>`}
|
||||
.stateofus.eth for 1 year
|
||||
</li>
|
||||
<li>
|
||||
User is able to get deposited funds after this yearly period, and
|
||||
release the username back into available names.
|
||||
</li>
|
||||
<li>
|
||||
User is now searchable within Status as {`<username>`} or
|
||||
{`<username>`}.stateofus.eth outside of the Status app.
|
||||
</li>
|
||||
</ol>
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<h2>Disucssion of variables</h2>
|
||||
<h3>Number of Users</h3>
|
||||
<p>
|
||||
|
|
@ -103,37 +200,55 @@ class App extends Component {
|
|||
<p>
|
||||
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 and [DESCRIBE
|
||||
WHAT HAPPENS TO THIS SNT]. We’ll model this with another conversion
|
||||
factor, which represents the number of people who renew their username
|
||||
every year. Go ahead and change these variables and see how the
|
||||
following graph changes
|
||||
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.
|
||||
</p>
|
||||
<div ref={this.userConversionRef} />
|
||||
<div ref={this.removalRateRef} />
|
||||
<div ref={this.ensUserbarRef} />
|
||||
<h3>Amount of SNT to deposit and renewal time</h3>
|
||||
<h3>Amount of SNT required to deposit</h3>
|
||||
<p>
|
||||
Now we have the amount of users that have (or will) used this utility.
|
||||
Let’s figure out how that translates to SNT. In order to do that, we
|
||||
have two more variables to define: The amount of SNT required to
|
||||
register an ENS username, and the time this money is locked up. By
|
||||
multiplying each user by these two variables, we can show how much SNT
|
||||
is being locked up every year which effectively takes it out of the
|
||||
circulating supply, i.e.
|
||||
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.
|
||||
</p>
|
||||
<h3>
|
||||
<p>
|
||||
<Latex displayMode>
|
||||
{
|
||||
'$$N_{\\text{SNT locked}} = N_{\\text{registrations}} * N_{\\text{amount per snt reg}}$$'
|
||||
'$$N_{\\text{SNT locked}} = N_{\\text{registrations}} * N_{\\text{SNT per registration}}$$'
|
||||
}
|
||||
</Latex>
|
||||
</h3>
|
||||
</p>
|
||||
<div ref={this.amountDepositSntRef} />
|
||||
<div ref={this.lockedSntBarRef} />
|
||||
<h3>How to assign value to all of this?</h3>
|
||||
<p>
|
||||
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
|
||||
</p>
|
||||
<div ref={this.sntPriceRef} />
|
||||
<div ref={this.lockedUsdBarRef} />
|
||||
<h2>Thoughts and Conclusions</h2>
|
||||
<p>
|
||||
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?
|
||||
</p>
|
||||
<h3>Future Improvements</h3>
|
||||
<ul>
|
||||
<li>discounted value rate</li>
|
||||
<li>probability of failure</li>
|
||||
<li>justifications using historical data</li>
|
||||
<li>assign variables and create eqations for each</li>
|
||||
</ul>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue