Economic Model for Staking Storecoin - v0.1
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Model Overview
2
- This model demonstrates possible token yield outcomes and expected break-even STORE price ranges within the Storecoin Proof of Stake protocol.
3
- dWorkers will be able to join in phases across 2 different stages (Settlement and Platform) - 2020 to 2023
4
- There are multiple dWorkers types (Messagenode, Validator)
5
- These dWorker types have varying costs and functions, which do change from settlement to platform.
6
- This model covers infrastructure costs for cloud and hardware setups separately.
7
8
2 Stages
9
- The settlement stage involves processing transaction sending between wallets only. These are typically ~500byte transactions.
10
- The platform stage involves hosting/processing all regular settlement transactions plus running app logic (compute) for 'data-backed tokenized applications'.
11
- In the platform stage, dWorkers will receive rewards from the base Storecoin protocol block rewards plus rewards denominated within a given tokenized applications minted currency (a 'datacoin' backed by the value of the apps' data).
12
--. Because we have no idea what the revenue value of the tokenized applications will be, it has been excluded from the P&L analysis (so value of app tokens is assumed 0 when checking for dWorker feasibility).
13
14
15
On Platform Stage scalability:
16
The platform technical whitepaper describes how these apps are run. For the sake of modeling, we broke it down to the following:
17
18
1. CPU time -- The length of time an app instance is expected to take to run to completion. The app developer provides an estimate that includes a range (min and max cycles, because depending on the app logic for a specific instance, the execution cycle may vary) and the runtime enforces it by not allowing the app to run longer than estimated (accounting for some buffers.)
19
2. Memory Usage -- The amount of memory required to run the app instance. This is also the range. The runtime provides the requested memory for the duration of app instance.
20
3. Storage -- The amount of data that is stored *after* the app instance is completed. This is the *result* of running the app, which is stored for future reference. All app may store other data during execution as well, which is included in this range.
21
4. Bandwidth -- The amount of bandwidth the app needs when it runs. This may be more than the storage, if the app makes multiple API calls or persists intermediate data during execution.
22
23
Then we modeled various app scenarios -- small "smart contract"-like apps that take very little CPU cycle and store little data to large enterprise-like apps to estimate the infrastructure necessary to support a given throughput.
24
25
How the scalability of the platform will meet the needs of typical cloud computing workloads:
26
27
1. The model projects the necessary infrastructure to run various app types. This includes the size of the hardware, storage, bandwidth, etc. as well as the *cost* of the hardware. This is computed for projected throughput.
28
2. The architecture allows for horizontal scaling. Given the cost to run the infrastructure, the platform may start out with a lower throughput and increase it over time just like multiple phases in the settlement layer.
29
30
The model allows us to forecast the above, so we can plan the platform launch accordingly.
31
32
Block Rewards
33
- Determined based on the % of circulating supply staked and the value of STORE relative to total network costs.
34
- Distributed to dWorkers based on expected potential costs and risks of each dWorker type.
35
- The majority of the block reward is based on stake size, but a small portion is based on bonuses for uptime/staking length/infrastructure setup/voting and a long-term bonus for those that upgrade to platform if/when that happens.
36
- A small portion of the block reward ~7.00% is allocated to various non-dWorker funds, including 2.5% to the Storecoin non-profit.
37
- In the platform stage, dWorkers will receive rewards from the base Storecoin protocol block rewards plus rewards denominated within a given tokenized applications minted currency (a datacoin backed by the value of the apps' data).
38
--. Because we have no idea what the revenue value of the tokenized applications will be, it has been excluded from the break-even analysis (so value of app tokens is assumed 0 when checking for dWorker feasibility).
39
40
Infrastructure
41
- Cloud-only for validators in the Settlement Stage
42
- Hardware-only for validators in the Settlement Stage
43
- Cloud-only for Messagenodes in the Settlement Stage
44
- Hardware-only for Messagenodes in the Settlement Stage
45
46
- Cloud-only for validators in the Platform Stage
47
- Hardware-only for validators in the Platform Stage
48
- Cloud-only for Messagenodes in the Platform Stage
49
- Hardware-only for Messagenodes in the Platform Stage
50
51
Costs, Rewards, and Yield are all annualized.
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...