Skip to content

Commit

Permalink
Replaced Remote Images with Local
Browse files Browse the repository at this point in the history
Downloaded all images being pulled from the old site and are now being called locally.
  • Loading branch information
Veightor committed Jul 30, 2024
1 parent 48b6b5f commit 4a85a29
Show file tree
Hide file tree
Showing 6 changed files with 150 additions and 0 deletions.
96 changes: 96 additions & 0 deletions docs/blog/canonical/Team_Arctika_Recommendation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
**To survive, the 0L Network needs to solve two problems. We need**:
1. Abundant capital for security, and
2. Abundant capital for recruiting talent.


And if possible, we should solve these problems in a fashion that does not worsen the inequality between members of the community.
## Much More Capital Is Needed


The crypto headwinds are significant: Regulatory pressure, fraud, scammers and a macro economic environment that favors the bears. If the network wants to survive the next decade, without any inflation, it needs to reserve a large portion of the network capital for future purposes. We will need to provision a greater amount than our peers who have inflation. We are of the opinion that the proportion should be as close to 80% / 20% as possible (the math resembles that of venture fund economics). While we strived for that goal, we weren't able to reach that number without massive disruption to multiple user groups. We finally arrived at a 70/30 ratio (70% for growth and ecosystem; 30% held by community members today), which gets us functionally close to the original goal, without system wide disruption of stakeholders.
## How much is necessary for the Infrastructure Escrow Fund (IEF)?


We can estimate that, in order to attract validators, the network will have to pay each validator US$4\-5k per month (this is consistent with what validators are paid in mature networks with smoothly operating software). In our interviews with professional validators, we arrived at $4,200 as our baseline. See the data in the table, below
![](../../images/Screenshot-2023-10-24-at-15.41.46-1024x558.png)
The Team agrees that we need to provision for another 7 years of network operations. We’re roughly three years into the network’s life cycle at this point in time (1 year in testnet, followed by almost 2 years since Genesis). Altogether, we should make it through at least the first 10 years of the network.


Of course, translating a token with no market value into monthly USD amounts requires some assumptions about value. We must take a conservative approach on market cap, for "all weather conditions". Despite what we’ve seen with some of our peer networks, we can't reasonably say that the base case for networks is a valuation of $1B\+ over the next 7 years. Likewise a network worth less than $50M for many years likely leads to extinction. So, the calculations we made assumed a $100M market cap, from which a token value could be extrapolated; this seemed like a reasonable base\-case (which could be substantiated further).
At that intersection: 100 validators earning $4,200 per month over 7 years, with a network on average worth $100m, the result is approx 35% of network capital needs to be pre\-diluted for sufficient safety.
![](../../images/Screenshot-2023-10-24-at-15.35.30-1024x623.png)
### Over\-allocation


The formula above, and our approach to erring on the side of more rewards, may lead to over\-allocation of OPEX instead of CAPEX type activities; so there must be a provision for over allocation (i.e. if the network is persistently worth more than $100M).
#### Policy for Over Allocation


The IEF is designed to continue with the V5 policy, that overspending can be burnt: i.e. reclaimed capital. The burn can optionally be "recycled" by validators by sending to an algorithmic matching contract, which distributes to Donor Directed wallets (aka community wallets) which have received the most donations (biased for most recent donations). We recommend this policy continue, such that over\-allocation to OPEX and infrastructure, doesn't penalize growth capital (CAPEX). This is compatible with the Proof\-of\-Fee design where, for example, every epoch there can be a consistent drawdown from infra\-escrow, and only the net is paid to validators, and the overallocation is burnt per the policy above.
## Who can contribute?


Some category of participants need to pay for these proposed changes. This requires a pragmatic, and not an emotional solution: ***What does the repeated game need for success?***
We elected to eliminate some options outright: 
* **Carpe miners**: There is not enough capital to meaningfully tax those users. Any tax would be symbolic.
* **Worker slow wallets** (e.g., beneficiaries of FTW, Hustle Karma, and other community bounties): Again there is not enough to tax, that would meaningfully contribute.
* **Community Wallets**: That’s a bigger topic so, see below


### Why Exclude Community Wallets?


There's a lot of misunderstanding about Community Wallets – and the concept is very important to the project for several reasons, not the least of which is regulatory compliance. 
0L has no centralized treasury, by design, and for regulatory compliance it has been recommended that we never implement one. Community wallets are an emergent property of the network. The wallets have typically  been created to fund programs for the benefit of the community. Part of their role is to safeguard capital for future uses. The vast majority of them have some language related to: a) safeguarding capital for future use in the network, b) deploying that capital. According to the disclosures of these accounts the capital is not used for personal or company enrichment.
Given their stated role, taxing the community wallets is taxing our growth capital. If you reduce the size of community wallets in favor of infrastructure escrow (IEF), you are reducing the amount of discretionary investment capital. 
In the extreme case: If you tax community wallets 100% into the IEF, while we will solve problem one (security capital), we would fail on the second problem (there will be no funds to credibly attract future talent and entrepreneurship).1
We are left with charging the Validators.
## How much do we ask validators to contribute?


If we keep with the numbers above, Validators should contribute 80% of past rewards towards the future IEF. We think this is acceptable for two reasons: First, there is very little choice if we are to survive, and second, the historical payout was not reflective of market conditions and therefore equity favors adjustment.2
### Disproportionate rewards


Our conclusions about the need to address equity were based on data. We conducted a survey to find out how much volunteers have contributed over time, and what is the approximate value of that work. We asked the same of validators, as well as engineers.
The results of our (limited3) research showed that, at the extremes, workers had a cost per coin that was up to 45X higher  than the costs incurred by the Validators. Another way to look at it, the cost per coin (from lost wages and infrastructure payments) that pure Validators paid was 1/45 that of the top contributors (all rewards considered). That's about a 98% discount4, according to our research numbers. Paying more did not confer the workers any advantage in volume (they were not able to accumulate more share of the network).
After the dilution, Validators are still getting an extremely attractive proposition. Excluding outliers (0D for example) the typical validator accounts still have paid 87% less than the top 10 worker accounts.5 It would be inappropriate, however, to conclude that the workers have been given a superior deal. The vast majority of workers have the majority of their coins from validator work. And those accounts will also be contributing 80%. This can only be corrected by using the community wallets judiciously.
Despite the workers not being explicitly and mechanically taxed, they have already been (e.g., inflation). Even after this intervention, and considering possible uses of community wallets to "make\-whole" these workers, in the best case the largest passive validators will have a 76% discount on cost per coin versus the lead engineers. While we can make it better, we can’t fix everything.
Lastly, the most committed Validators will partially reclaim their contributions to IEF if they commit to validating over the long term. By continuing to operate a Validator, a portion of those coins will come back to them. (Note this is the only group of community members that benefits from this mechanism.)
## Budgeting for past workers


A related issue is also being addressed in conjunction with the tokenomics adjustment. Prior to the re\-basing and the dilution and adjustments outlined above, the Tip Jar and Iqlusion FTW wallets will be distributed to workers. Note that these uses are consistent with the stated aims of the wallets and, at least in the case of the FTW wallet, the amounts should have already been paid out. Failure to pay those out prior to the re\-basing would disadvantage those workers. Put another way, the Tip Jar (which 0D has already offered to community purposes), as well as the FTW wallet (which has not made monthly payouts as it was intended to) should "make\-whole" the past workers. 
We think the proposal increases equity but frankly the main purpose of the proposal is for survival. The increase in equity is a bonus. The only scenario in which everyone is equal is the collapse scenario which none of us want.
## Budgeting for future workers


The remaining community programs should focus on the future. There is no formal mechanism, but they can be encouraged to do so by their donors (which are historically validators) through the governance changes to Donor Directed Wallets.
## Conclusion: This is what Good Capital looks like


We looked at many models of dilutions and fees. Asking validators to invest 80% of prior rewards into Infra Escrow, very cleanly (even serendipitously) allowed the network to have these properties:
* 70/30 in favor of future network participants.
* Have future capital for Opex (Infra Escrow) and Capex (Community Wallets) split evenly (out of the 70%) in the base case.
* Reduce the gap between worker and validators to 1\.3X from 16X.


![](../../images/Screenshot-2023-10-24-at-15.39.46-1024x750.png)
We think this allocation, with abundant amounts for future capital, which honors prior workers such that we can continue recruiting for future talent, and sets up all current participants for future success is **unique and exemplary in the industry, and fulfills our mission of creating "good capital" and gives us the best shot at surviving and thriving.**


### **– Team Arctika** (AlexT, Daniyal, Lex, 0D, ricoflan, Wade \| TPT, Zmanian)




*\*\*Note the Arctika Report was originally published to the 0L Network Discord on 23 May, 2023\. See, <https://discord.com/channels/833074824447655976/910315033672704090/1110679498288005130>*

\=\=\=\=\=\=\=\=\=\=\=end notes\=\=\=\=\=\=\=\=\=\=\=\=

1 That all said, there is an important recommendation we must make for community wallets. Keeping with the October poll, where the network expanded the governance of the Donor Directed wallets, to allow the donors to freeze accounts, this was underspecified. What happens with the frozen account? We think the natural conclusion is that the frozen account should get liquidated into a pro\-rata share of the remaining qualifying donor directed wallets. We don't anticipate this will ever be done, but it's important for the game theory of multiparty negotiation of the uses of the community wallets.
2 A key incident contributed to the second issue, the disparity in the history payouts to Validators. There is an acknowledgement that the Reward Auction in 0L was no longer viable after a partial upgrade in April 2022 (the baseline parameters were not updated after some other policies were updated).
3 This was done via a Google Form that a number of members voluntarily completed, so it is based on self\-reported data.
4 We do recognize this is a generalization and may not apply to everyone across the distribution, but the data we gathered did support these numbers as a general matter.
5 Note that our calculations showed that you could achieve equity between the groups, but only at the expense of diluting Validators by 98% – a non\-starter.
6 Note this “BEFORE” data is from the Cap Table research done by ricoflan in March 2023, so it is not current at the time of publication of this paper (23 May 2023\).
54 changes: 54 additions & 0 deletions docs/community/governance/governance.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@

We feel strongly that building a community\-led protocol requires community engagement in all aspects of the community and protocol governance. While the eventual goal is to launch on\-chain community governance, our bottom up vision of community engagement needs to be validated to the extent possible before investing the time, effort and energy required to create the tools needed for on\-chain community governance. To achieve our vision of true community governance, it’s crucial that the ecosystem transition to full stewardship of the protocol and its development as soon as possible, without waiting for the creation of the tooling needed for on\-chain governance, and in doing so, validate, test and improve our processes in a fluid and flexible environment, with the participation of the community. 




To provide some context:




## **Where we started**




The 0L Network launched with the simplest of governance structures in place, that is, onchain governance for the protocol, wherein the only voters are the validators. The project had no foundation, no DAO, no community governance structure. As an exercise in pure decentralization, it was left up to the community to chart the path to a sustainable project governance model.




## **Where we are now**




In January of 2022, the community adopted a proposal to implement MVP community governance. The MVP process took the form of coordination of effort via a set of working groups. As the illustration below shows, the working groups were organized topically, with two of the groups serving meta functions.




![](../../images/WG-Org-Chart.png)




The meta working groups provided coordination between the groups as well as a mechanism for escalating proposals and conflicts. The rules governing this process were codified in the [0L Parliamentary Procedures](https://handbook.0l.network/index.php?title=Parliamentary_Procedures)




While the working group process has been functional for coordination of tasks and general community matters, it falls far short of actual community governance as onchain protocol governance still resides exclusively in the hands of the validators. Moreover, there is no signalling mechanism or other device for informing the validators about the community’s wishes on particular matters. 




## **The 0L Network Constitution**




On 3 May 2022, the community voted to adopt the 0L Network Constitution, which lays out the Community’s foundational values. The creation of the Constitution was a major step towards establishing a decision framework and value system that can serve as the project’s north star as we move forward. You can [read the Constitution here.](http://openlibra.blog/community/governance/the-0l-network-constitution/)


Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/WG-Org-Chart.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 4a85a29

Please sign in to comment.