We believe a budding web3 protocol needs to go through certain phases throughout its lifetime before it can be deemed “fit enough” to be fully community-owned. In Reitio’s case, its path to decentralized governance will be split into three phases: “seed”, “sapling”, and “tree”.
Phase 1: "Seed" (Team-Governed)
The fully decentralized and autonomous web3 protocol of the future would be the manifestation of a start-up that is consistently iterated upon during its bootstrapping stage — all with the singular aim of achieving product/market fit. At the “seed” phase, for the sake of rapid iteration to find product/market fit, Reitio will be spearheaded by a committed team. to lead development efforts and marketing initiatives to deliver an acceptable MVP (minimum viable product) and establish initial network effects.
Often underestimated in the web3 space, proper treasury management practices could in fact be the difference between a protocol at the “seed” phase folding under intense bear market pressure with one that managed to survive the “crypto winter”.
Similar to how corporate treasurers continuously optimize their treasury balances so that they can finance capital expenditures and other investments in the most capital-efficient manner regardless of market conditions, the team would also undertake an active treasury management stance over the course of Reitio’s “seed” phase, with the explicit goal of maintaining at least a 2-year runway to weather a “crypto winter”.
The treasury at the “seed” phase would be predominantly used to fund the team on endeavors to realize Reitio’s product/market fit:
- Token-based compensation: $REIGN payouts to Reitio’s key hires (ex: lead engineer, etc.);
- Usage-oriented incentives: $REIGN rewards to early adopters of the platform (ex: grants for 3D artists, “Build-to-Earn” program, etc.);
- Community reward campaigns: $REIGN distributions to active community members heavily invested in Reitio’s cause (ex: quiz winners, airdrops, etc.);
- Endorsement “packages”: $REIGN disbursements to third parties deemed to significantly contribute towards Reitio’s public exposure goals (ex: influencers and KOLs, sponsorships to notable blockchain events and conferences, etc.);
Phase 2: “Sapling” (Foundation-Governed)
Reitio leading to the “sapling” phase would have had its initial mission-critical assumptions and hypotheses validated by the market, leading to product/market fit. In other words, the platform would now become sufficiently adapted — to a degree that it would be able to sustain the platform’s “network effects” over the long run.
For a community-owned, web3-native protocol like Reitio, this phase would ‘only’ represent a significant milestone towards the overall maturation of the protocol: kickstarting the transition from a centralized, team-led governance structure to a decentralized, community-led governance model.
In the midst of this governance shift lies the Reitio Foundation: a semi-centralized entity that consults with the Reitio community regarding governance decisions.
Under the Reitio Foundation’s helm, in contrast to the “seed” phase, Reitio at the “sapling” phase would instead be iterating towards finding product/decentralization fit: how Reitio could be retrofitted such that the protocol will be able to operate autonomously in a decentralized manner.
The Reitio Foundation will serve as the backstop to Reitio — retaining sufficient control to intervene in case of black swans, but not to the degree such that it becomes detrimental to Reitio's self-sufficiency aspirations.
At Reitio Foundation’s onset, elections will be held to elect select individuals from the Reitio community to the Reitio Foundation’s governing board. Team-controlled admin accounts that have been acting as Reitio's backdoor during the “seed” phase will be promptly removed — replaced by multi-sig accounts whereby community-elected delegates would be assigned a key each. The quorum will be set such that in order for an action to be carried out, it requires “all hands on deck” — the team cannot unilaterally implement changes to the protocol without the prior approval of delegates.
Delegate elections would be held quarterly, and votes can only be administered by $REIGN holders who have locked up their tokens for a minimum of six months. Since lockups are subject to time-weighting, voting weights would exponentially increase in proportion to the length of time the tokens are locked — in effect, this ensures alignment of incentives such that voters would only vote for delegates (or other proposals) deemed to be in the best interests of Reitio, since it directly correlates with the value of their locked-up $REIGN tokens.
Reitio's code will gradually be made open-source, in the process also polishing its accompanying documentation. The development would no longer be centered around the team, yet pushed to the edges: organically driven by community contributors incentivized via a developer grants/rewards model that is structurally capable to be maintained by a DAO, comes a fully decentralized future.
In addition, Reitio protocol would be further optimized in terms of its revenue extraction and cost structure (if need be) so that profitability can be achieved — making it feasible for Reitio to operate autonomously and be sustained via decentralized governance upon its transition to full community ownership.
Treasury management would also become largely automated: instead of relying on the team's discretion in stockpiling stablecoins up to a 2-year runway, the protocol would follow a predetermined algorithm such that Reitio's stablecoin reserves are reasonably sufficient to cover the protocol's operating expenses, while still leaving enough room for leeway to weather an extended black swan event if need be.
Unlike at the “seed” phase, Reitio at the “sapling” phase would have garnered a strong economic moat such that $REIGN’s token utility from the natural usage of the platform alone would be able to prop up the price of $REIGN for the treasury to conduct open market operations without eating too much of its $REIGN reserve.
With one eye on decentralization, implementing changes to the treasury’s automated strategies would be subject to community-involved multi-sig accounts, ensuring that the quarterly dollar amount that the team can receive to maintain Reitio's day-to-day operations would always fall within reasonableness — the team cannot unilaterally siphon funds away from the treasury without the prior approval of community delegates.
Unlike treasury outflows at the “seed” phase (where it is used for the sole focus of achieving product/market fit), outflows at the “sapling” phase would largely consist of operations that return value to $REIGN token holders. On a quarterly basis, 100% of Reitio's profits (revenue less operating expense) will be burned, creating deflationary pressure on $REIGN.
Phase 3: “Tree” (DAO-Governed)
Similarly, a web3 protocol at the “tree” phase would become a public good of sorts: a profitable “protocol model” with battle-tested smart contracts, paired with autonomous treasury operations and a working decentralized governance model. In the case of Reitio, this would mean the dissolution of the Reitio Foundation — in its wake, the ReitioDAO.
Delegates holding the keys to the protocol’s multi-sig accounts would be subjected to annual elections held by the ReitioDAO — the team would start as incumbents. Elected ‘protocol delegates’ would become the de-facto stewards of the protocol — responsible for code maintenance, distribution of developer grants, social media presence, partnerships, and other off-chain tasks or commitments.
Delegates holding the keys to the treasury’s multi-sig accounts would also be subjected to annual elections separate from the annual elections for ‘protocol delegates’. Elected ‘treasury delegates’ would become the de-facto stewards of the treasury — on a quarterly basis, they are responsible for allocating funds pertinent to the compensation of ‘protocol delegates’ as well as for the protocol’s operating expenses (including authorizing additional financing for ad-hoc initiatives).
Upon the conclusion of the election, the protocol would automatically revoke multi-sig access for leaving delegates — in its place, granting multi-sig access for incoming delegates.
This separation of powers creates a system of checks and balances (an individual cannot be a ‘protocol delegate’ and a ‘treasury delegate’ at the same time) — comparable to the dynamics between the POTUS and Congress: the Congress can only enforce laws but not make them, while the POTUS can only make laws but not enforce them.
Likewise, treasury delegates cannot unilaterally enact changes to the protocol since they do not control the protocol’s multi-sig accounts, while protocol delegates must obtain approval from treasury delegates before they are given the necessary funds to execute C-level initiatives since they do not control the treasury’s multi-sig accounts.
Emergency delegate elections can be initiated by anyone in the event of fiduciary incompetence, and it will immediately go into effect once voter turnout reaches a certain threshold along with a supporting majority for the resolution. This ensures delegates, protocol, or treasury, would always remain the best representative for the job notwithstanding any change to circumstances — one way or another as determined by the wider Reitio community.
Proposals to alter protocol parameters (ex: base fee, deployment and minting fees, etc.) would also need to be voted on by the ReitioDAO: upon passing of the resolution, its actual implementation would be built-in within the proposal itself, meaning that Reitio's source code would automatically reflect the parameter changes without needing any party to guarantee its enforcement.