Note
This document was written in December 2023, and is left here unchanged for historical purpose. For more recent updates on AtomOne, you can check the following links:
The proposed genesis file for AtomOne resulting from the proposals above can be found here: https://atomone.fra1.digitaloceanspaces.com/genesis.json The genesis file above is missing gentxs and may not correspond to the final genesis.
For more information on how the genesis was built please also look here.
ALL CONTRIBUTIONS TO THIS REPO, ITS ISSUES, PROJECTS, AND DISCUSSIONS MAY BE USED IN ANY EXPLICIT GITHUB FORK WITH A NEW AND DISTINCT NAME TO LAUNCH ANY FORK OR SPLIT THAT MODIFIES ANY OF THE IDEAS MENTIONED HERE UNDER THE GnoNGPL COPYLEFT LICENSE.
The Cosmos community, at a crossroads, confronts divergent views on key aspects such as mission, tokenomics, and security philosophy. AtomOne emerges as a beacon, offering an alternative fork to navigate these waters, equipped to handle contingencies and embodying a bastion for diverse political thought.
There comes a time when there is enough disagreement among community members and stakers about key concerns regarding the business of their chain, such as its vision, mission, tokenomics, architecture, implementation, or philosophy; that it makes the most sense to support an alternative fork running alongside the original so as to be prepared against all contingencies.
Recent times have seen the Cosmos community grappling with significant challenges stemming from differences about core tokenomics, about the very nature of the $ATOM token (whether it is staking or monetary), about monetization strategy and what types of projects to fund; and there generally appears to be a great cultural chasm that shows no sign of closing about our role and responsibilities as compared to our profit interests. (see NWV to Prop 848 – $ATOM Must NOT be Money).
Proposal #848 ("halvening") succeeded in getting the required threshold of 50% to pass on Gaia, but a significant portion voted NO or NWV which means that that $ATOM stakers are largely split on the most fundamental tokenomics security design element. 73,165,203ATOM YES vs 56,667,011ATOM NO + 11,669,549ATOM NWV overall YES:NO is 1.07:1. Furthermore, this change was proposed on chain without addressing the valid security concerns raised by the community, with huge errors about the cost of inflation by miscalculating true income, and without a complete halvening schedule, thereby working to undermine hub credibility.
These and prior disagreements have now made clear the need for an alternative hub with a renewed focus and Alignment to serve as the canonical minimal IBC/ICS token hub with respect to Cosmos to champion the ideals of sovereignty, security, and decentralization everywhere; and secondarily to serve as the main base for a political party and more-intelligent voting bloc with respect to Gaia to save Gaia from itself. A modification to the distribution of $ATONE through slashing those who voted in favor of #848 would help ensure that the resultant distribution is more intelligent about security and would make us anti-fragile against even the most powerful of adversaries.
The vision behind this AtomOne fork is to be an alternative minimal fork of Gaia ("cosmoshub4") running alongside Gaia to prepare for all contingencies, and also to operate as a political party base in relation to Gaia. We strive to complement the broader Cosmos ecosystem while introducing innovative solutions and perspectives. Our goals are not just to resolve current challenges but are also to set a new precedent for adaptive and responsive self-organization in the multichain multitoken universe that we call the Cosmos.
AtomOne will lead the development and praxis of giving representation to every (sub)group (such as a political party), each defined and strengthened by their own living constitutions that state their values, missions, philosophies and so on. This will foster a more diverse ecosystem of specialized zones in coopetition (cooperation and competition) with each other despite irreconcilable differences. AtomOne will be a base for many more partyhubs, and itself function as a partyhub in relation to Gaia. There will be many partyhubs in a great sea of divisions, and from this soup will emerge specialization, interoperation through common protocols, and fault tolerance in numbers, we pray for the helping hand of reason, wisdom, foresight, empathy, temperance, and all other necessary faculties.
While AtomOne aims to steer Gaia toward safe decisions, it cannot by itself determine the decisions made by the Cosmos Hub. Yet, Cosmos needs minimal IBC/ICS hubs without any confusion about what it is, and as mentioned in the Declaration of Genesis Gaia does not embody this (yet). Ergo, AtomOne must not only guide Gaia, but it must also run the desired alternative minimal IBC/ICS hub as an alternative in addition to Gaia.
AtomOne re-commits to the original vision and primary mission of Gaia to serve as a minimal IBC/ICS hub secured by a staking token that targets 2/3 of the stake to be bonded. We believe that minimizing the risk profile is necessary as an existential issue for the hub, and an issue of financial security of the highest order for not just the hub but its hosted shards and IBC connected network allowing AtomOne to occupy a real and an important niche. When there is a double-spend attack on the hub, the staking tokens of those responsible for the attack should be used to compensate the victims as much as reasonable, and the non-zero remainder of the penalty burned. A staking token of an exchange zone for example must consequently have additional risks related to its business, and so $ATONE occupies a niche of minimal risk profile in comparison.
IBC/ICS hubs should in general remain conservative in its function and offer utility through dependability and scaling. Any experiments that change the nature of the hub belong in new forks or splits, and an ideal hub enables them despite of and in order to celebrate these differences. In the Cosmos there is no need for contention as with land-locked states because there is no limitation of finite land. We can create new forks/splits/groups that are better aligned with what we need if there is enough need or support for it.
The powers not delegated to the AtomOne hub by the Constitution, nor prohibited by it to the consumer chains, are reserved to the consumer chains respectively, or to the stakers, token holders, and people; or to other splits or forks of the AtomOne hub.
There are many of stakers and users of Gaia that are aligned with the values, principles, original mission of Gaia and those of AtomOne, but we have no explicit base of operations. In contrast, the informal opposition majority party (which came about first) is well organized in comparison, usually behind closed doors. Meanwhile "liquid staking" providers are providing a service that does more than liquid staking, but have their own governance and powers and thus act as a kind of political base. For example, which validators to stake to is determined through governance in Informal/Stride.
By modifying the distribution of staking token holders for AtomOne to be more aligned with hub security based on voting activity we can make the $ATONE distribution a more intelligent distribution than all other alternatives (until another split is needed due to corruption). As the project grows, by virtue of its growth the distribution will naturally evolve (or by default, devolve), so this may precipitate the need for more hubs descendant from AtomOne, with or without substantial changes to its fork of the constitution. Even with the same constitution its distribution (or how it was modified from the parent distribution) affords its character or flavor which can strengthen or weaken over time depending on its tokenomics.
By our own governance function and the tooling that we fund and create, we will bring more intelligence and security to all connected blockchains especially Gaia. AtomOne must do whatever is necessary within reason to guide Gaia to maintain safety, and the best way to do that is by holding $ATOMs through IBC pegging and using these $ATOMs to make voting decisions on Cosmos as a voting bloc. The following section describes the one and only way the AtomOne hub will use $ATOMs; by offering what is misleadingly referred to as "liquid staking".
AtomOne will offer an $ATOM bonding zone in a core shard to compete with collective "liquid staking" service providers. These $ATOMs will be automatically delegated via ICA (interchain accounts) to aligned validators as determined by the system determined by the $ATONE stakers. The bonders of $ATOM toward this service will receive liquid $phATOM tokens.
In addition to Gaia's $ATOM, AtomOne's $ATONE tokens will also be bondable to $PHOTON tokens. So there will be $phATOM along side $PHOTON tokens, but with some differences in tokenomics between them. We have more control over $PHOTON tokenomics, though the changes we introduce for $PHOTON may be upstreamed to Gaia for $phATOM.
We believe that by embracing diversity and fostering open dialogue between competing self-aligned groups we can create a more robust, innovative, and decentralized ecosystem. The diversity of specialized self-organized groups and forks (composed of aligned members) will accelerate innovation and implementation through parallelism. The diversity of competitive groups and forks will reduce risk at the local and global levels; at the local level through competition of implementations, and at the global level through the diversity of hubs and frameworks.
We hope that the economic recovery measures between $phATOM and $PHOTON will incentivize mutual success and allow Gaia to transition safely into a more experimental hub as compared to the more immutable and conservative AtomOne.
- Alignment: full agreement with the founding documents in speech and action with relation to AtomOne.
- AtomOne: an opinionated fork of the Cosmos hub Gaia with chainid "cosmoshub4". It is a minimal IBC-token-pegging and ICS hosting hub.
- Constitutional Majority: a consensus threshold set at a higher bar than the standard two-thirds majority initially set at 90%.
- IBC: short for Inter-Blockchain Communication, is a protocol that enables communication between different blockchain networks using Byzantine Fault Tolerant (BFT) light client proofs. It allows for the transfer of assets and information across independent blockchains, fostering interoperability and flexibility in the blockchain ecosystem. IBC is a cornerstone of the Cosmos network's architecture, enabling its vision of an 'Internet of Blockchains'.
- ICS: short for Inter-blockChain Security, is a mechanism for running multiple shard chains under the same validator set. ICS1.5 is an upgrade to ICS1 that improves inter-shard communication efficiency. ICS1 and ICS1.5 help scale the core functionality of AtomOne as well as offer anyone the service of running "consumer chains" for any purpose (within the guidelines set forth by AtomOne) secured and hosted by the same validator set as the AtomOne hub root and core shards.
- Zone: an independent or ICS hosted chain (or a dapp hosted on a smart contract chain or an instance on a parent chain) with a well-defined governing body or bodies that dictate the governance and economic rules internal to that zone. A zone is sovereign or partially sovereign.
- Fork: an exact copy of a distribution with either the same or different blockchain software, usually with a different chain identifier than the original.
- Air-drop: like a fork but with modifications to the distribution such as by including a new premine, or excluding addresses (such as those on sanctions lists), or changing the number of tokens for an address in any way, or even including modified or unmodified distributions of other chains.
- Split: an air-drop of a chain that modifies the distribution based on staker voting activity in both consensus and governance through their cryptographic signatures as well as any other criteria based on a well defined and prominent self-reinforcing constitution; or a fork of a chain with a modified constitution or modified software that is intended to achieve the same.
- $ATONE: the primary staking token for AtomOne. Previously known as $ATOM1.
- $PHOTON: the liquid staking token for AtomOne. Previously known as $phATOM1 or $phATONE. the latest in tokenomics design.
- $phATOM: the liquid staking token for Gaia offered on AtomOne for $ATOM (not $ATONE).
All users and members must agree with these objectives, and at all times when contributing take all appropriate actions to meet these objectives both in the AtomOne software as well as open hardware. Otherwise they are at risk of judgement by AtomOne or any other community or governing set.
These objectives can only be changed through Constitutional Majority.
The $ATONE is defined to be a staking token of a minimal ICS1.5 IBC AtomOne Hub that keeps 2/3 of $ATONEs staked at all times.
All forks that lose consensus continuity must change their token ticker symbol to be distinct from $ATONE ($ATOM2 is ok). If there are competing chains with comparably similar continuity, then the fork that has a higher market cap (as measured after both tokens have discovered fair market value with sufficient liquidity for at least one week) should retain the name while other forks change their token ticker symbol.
Any changes to the distribution besides slashing for pre-established slashing conditions such as any additional premines (besides those in the original first genesis) disqualify the fork from retaining the same token ticker symbol; those are new airdrops of a different token. No additional premines besides those already defined in this planning document are allowed for any forks whose token shall be called $ATONE.
We are not concerned about any business plan or tokenomics strategy for the AtomOne hub besides offering the scaling of transaction throughput through ICS1.5. We anticipate that our approach will successfully and sufficiently capture the niche market need for utmost security in IBC token transactions and ICS1.5 shard hosting, and serve as the basis for all the functionality that all people will need and want; and if it cannot be done through the spirit of these Founding Documents and the living AtomOne Constitution then it shall be done in the next generation that splits or forks from this AtomOne hub.
The term "minimal" refers not to the totality of functionality offered by all the consumer chains hosted by ICS1.5, but rather the design of the root hub, and core shards of the AtomOne hub, the tokenomics of hub, its business plan, and its responsibilities; sometimes confusingly referred to as simply "the hub". A "minimal hub" should be understood in this context; smart contract systems and VMs must not be on the hub's root chain (for security and efficiency) and ideally not even in core shards (for security), but rather on consumer shard chains on ICS1.5.
This is the best way to scale to billions of users while providing specialization and isolation. For example, your home internet WIFI network is provided by a minimal router hardware, while your backup harddrives and your many devices are separate machines that only connect to the router. If the router had to also host application logic, the network performance of all the devices would suffer and the router would be more likely to crash.
All shards (chains) are secured by the same validator set as the main hub chain. The shards that are owned and governed by AtomOne itself are called "core shards" and they are shards necessary for AtomOne as defined in these founding documents and living constitution; while those hosted on behalf of others are called "consumer shards".
We must at all times distinguish between what is core vs consumer, not only in our code, documentation, and specifications, but also to the end user through all commensurate reasonable means at our disposal.
Arbitrary smart contract functionality must not be allowed on the main hub shard, which must instead be reserved primarily for basic transfer and IBC transactions, ICS1.5 shard coordination, and governance voting as safety and liveness critical functionality.
The hub's root shard, IBC, and ICS1.5 implementations must stay minimal and only perform what is specified in these Founding Documents, or must be amended to the living AtomOne Constitution. The business plan of the hub must likewise be strictly limited to what is defined in these documents. All other functionality can be hosted on top of the ICS1.5 hosting layer on consumer chains and must not be confused for AtomOne functionality, and it should be clear which governing body is the responsible party for each consumer shard.
AtomOne must not subsidize any ICS1.5 core shards that are not necessary to fulfill the specification of these documents. No core shard shall host arbitrary smart contracts from the general public--AtomOne will not itself become the maintainer for smart contract systems and virtual machines. Instead these must run as consumer chains with their own governing body. However they are funded, they must.
Any fixed functionality that could run on alternative VMs should be translated into the dominant language of the official approved software, which for us is a recent version of Go(lang) 1.xx. We should remind ourselves that every virtual machine has (had) numerous zero day exploits. The added security vulnerability surface area of the new VM combined with the compiler to compile one language for the VM, as well as the added complexity of needing to audit another language, can and must all be avoided.
Mixing implementations across validators is also to be avoided so as to prevent a failure arising from a low Nakamoto coefficient among the types of implementations. Instead AtomOne will always support one standard implementation.
The hub will not be used for experimentation. Experimentation should occur in other zones. Let's demonstrate that a minimalist hub is not the same as a minimalist ecosystem and how we can create a pioneering ecosystem. Any new feature proposals for the hub should be considered only after a successful and adequately long testing period in other zones.
When it comes to the innovative spirit and creative potential beyond those specified in these founding documents and the living constitution, we recommend that they be implemented as ICS1.5 hosted zones, and only in those cases where AtomOne can probably not solve the problem at hand through ICS1.5 hosting should a fork of AtomOne or a new chain be proposed with an entirely different constitution. The spirit of the AtomOne Constitution and the general mission and purpose of the AtomOne hub as a utility must not change.
Fix Validator incentives so that every validator is PAID to run ICS consumer chains and hub shards. Actually, develop a minimal economic model that accurately describes physical reality in an intuitive and adaptable way for all scenarios. Let's implement a system where every ICS chain pays supermajority to validators!
Import elements from github.com/decentralists/DAO
All governance proposals must pass the required ratio threshold of 2/3 in addition to the auto-adjusting deposit threshold and the auto-adjusting quorum threshold for the purpose of spam prevention and better utilizing our precious attention. The two thirds ratio is derived from the natural limitations of partially synchronous consensus, and must at least two thirds in order to prevent failure from a dissenting minority of 1/3 by stake. Most proposals that pass pass with a two thirds supermajority anyways, and this allows us to simplify the governance mechanism such as by removing the distinction between NO and NO_WITH_VETO.
The Supermajority is defined to be exactly "more than two thirds" (+2/3, or at least one iota more than two thirds) and cannot change even by a Constitutional Majority.
The Constitutional Majority is initially set at 90% which is higher than the default required Supermajority. The Constitutional Majority cannot be lowered lower than 90% even with a Constitutional Majority, but it may be set to any value between 90% and 100%. This elevated threshold aims to ensure broader agreement and inclusivity in critical decision-making processes. It reflects a commitment to achieving near-unanimous consensus on essential governance decisions, enhancing the legitimacy and stability of the outcomes.
What we have isn't liquid staking in its pure form where every validator gets its own liquid staking derivative; rather what we have are a collectivized form of liquid staking; and when they have their own governance mechanism separate from the host hub and they can choose which validators to delegate to, they should be perceived as "partyhubs" with their own mind and agenda.
People seek out these liquid tokens because they want to avoid the inflation penalty and use these tokens for purposes other than validator staking (because the inflation rate is too high). These users are generally not interested in the staking token for the purpose of staking, but are more interested in new uses of the token especially Defi use-cases. These users are not necessarily Decentralists or aligned with AtomOne in spirit--they are anyone and everyone. Therefore these staking services must be regulated such as by removing or capping their potentially dominating voting power (in the absence of limitations such as on the portion of rewards that can go to these liquid token holders). These voteless liquid staking tokens should generally be made available first; and when there is a need for political differentiation new distinct partyhubs should be allowed to compete against the voteless one. There will generally be demand for the original voteless liquid token because it is managed directly by the stakers of the hub.
Later we show the $PHOTON token which is deflationary AND liquid, yet fully backed by $ATONEs.
Adopt a Declaration of Independence and Constitution with cryptographic signatures.
See draft declaration and draft constitution.
Solve IBC1.5, or ICS1.5, where the validator sets are implicit, for fast inter-hub communication with implied IBC, WITHOUT sacrificing independent BFT consensus layers.
XXX add more
Create a permissioned and fully accountable, and 100% predetermined-finite- time-delayed transparent security reporting system. Ensure that ABSOLUTELY ALL information within the system eventually becomes public knowledge to help deal with zero day vulnerabilities and current attacks & fund it.
In addition to the staking token distribution (and any choice of modifications if any to them) we should also consider the vote of individuals (in its purest form, one per person) in the form of self-organized self-aligned groups drawn together by some common interest (too often by greed and sometimes by principle), because no project will succeed without its community, and by nature the community has its own spirit and power distribution independent of the chain by nature.
This dimension manifests in all social interactions with or without explicit form, and must be a core concern that is somehow supported by the hub for otherwise external influencers will easily sabotage the project through social engineering methods. For more on this, see the related document on the Decentralists, an experiment that will be subsidized by AtomOne to create tooling that allows anyone to discuss and gauge the interest of ideas before they are put up for proposal measured by both liquid-democracy inspired democratic weighting (for any group selection) as well as stake-based weighting.
Create and support competing marketing, growth, infra, dapp subDAOs, and especially help them foster the best in class in Cosmos; from the user level down to the VM, every component should have a good selection of competition.
See https://github.com/gnolang/gno TODO add more smart contract projects.
Create a team tasked with minimizing and simplifying code and reducing unnecessary dependencies, taking the best examples from various forks taken into consideration, so that all the best ideas from all forks can integrate into one where-ever possible. FINISH software.
See https://github.com/gnolang/gno/tree/master/tm2 for Tendermint2
Ossify the partyhub after it has become its own competing IBC/ICS hub. Allow others to likewise fork from you by enabling ICA partyhubs when there is disagreement. Multiply by meiosis and conquer the world.
AtomOne will lead the way in demonstrating a more secure system for splitting off new generations of partyhubs as a necessary course of action of last resort in the face of gridlock and friction. ICA-based (interchain-account) partyhubs with independent validator sets introduce additional security risks associated with the behavior of the other validator set securing said partyhub--unlike shards secured under ICS1.x by the original hub itself.
In an ideal scenario, once AtomOne is complete in functionality and has proven itself, it and its supporters will guide Gaia to adopt the same secure splitting system so that Gaia AND AtomOne can both have a richly diverse partyhub set representing many diverse parties each with their own philosophies, expertise, concerns, and jurisdictions.
See gnolang/gno#1224 for prototype WIP of splitting.
The AtomOne hub exists as a separate minimalist fork of Gaia. Both are separate and distinct from gno.land, though gno.land and the GnoVM (as well as other VMs) will play significant roles in completing the hub and maintaining its upkeep.
The main goal is to fix what must be fixed in governance and the need for an explicit constitution, before launching the full IBC and ICS functionality of the chain.
First, we describe the tokenomics of the AtomOne hub, followed by the main milestones, with an emphasis on completion and even potential phase-out.
It should be some distribution of the Cosmos Hub $ATONE token with those who voted against the spirit of this project slashed because they never joined to use the system in the first place (e.g. they were more interested in price appreciation of original $ATOM).
Additionally, the Interchain Foundation playing a key role in the evolution of the hub, should also be removed.
Finally, 10% of the $ATONEs are premined for various purposes.
The $ATONEs in genesis are locked and cannot be transferred due to the value of the parameter ENABLE_SENDTX except for chosen addresses (e.g. for faucets).
The Genesis Distribution is largely an opinionated fork of the cosmoshub4 $ATOM (judged by Alignment based on voting activity, to slash those who don't align, or those who aren't interested in using our chain).
The Interchain Foundation will be excluded from this distribution, so as to create a separation of concerns, and instead 10% of the final total amount will be allocated toward contributors and onchain DAOs.
Of the 10% premine,
- 1% to general pre-launch contributors and early adopters.
- 1% reserved for IBC contributions (and all that it entails) and early adopters.
- 1% reserved for ICS1.5 contributors (and all that it entails thereafter) and early adopters.
- 7% reserved for gov distribution to subDAOs for remainder of plan and constitution (but nothing more).
In addition to these premines, the earned tax revenue (rewards) and inflation will be split as per the following:
- 80% of the inflation+rewards going to the stakers who select validators.
- 10% of the inflation+rewards going to active validators equally.
- 5% of the inflation+rewards going to the general commons pool with no standalone governance.
- 2% of the inflation+rewards going to pool for open source blockchain explorer hosting.
- 2% of the inflation+rewards going to pool for securing open source wallet systems (w/ airgap).
- 1% of the inflation+rewards going to pool for public relations and growth.
XXX But the % of rewards going to $PHOTON bonders is at least 90%. XXX refactor.
A parameter MIN_STAKER_DISTRIBUTION_FRACTION will be set to 80%, where the percent of inflation+rewards going to stakers cannot be lower than this figure. Changing this value requires a constitutional majority.
A parameter MIN_VALIDATORS_DISTRIBUTION_FRACTION will be set to 10%, where the percent of inflation+rewards going to stakers cannot be lower than this figure.
The funds held in all the pools above will not be counted toward the bonding ratio.
The last three following the pool/treasury will initially go to multisigs set in consensus params of the chain, until they get set as URIs pointing at blockchain based DAOs hosted on ICS1.5.
We opt to replace the market-based "commission" system with a flat distribution to all validators, to incentivize the creation of peer validators (who should all plan to become data center providers).
The maximum bounds on the auto-adjust inflation parameter will be set at 20%.
The inflation will target 2/3 of $ATONE to be bonded.
Every ICS zone should be paid for somehow. AtomOne owned ICS shards should be paid for from the treasury of AtomOne. Other ICS "consumer chains" can be paid for by the the chain itself, and in emergencies anyone can step in and pay on the zone's behalf.
In short, every ICS zone should be profitable to every validator.
The DISTRIBUTION_FRACTION parameter is the fraction (between 0 and 1) of ICS shard and consumer chain payments that are shared among the validators equally. This is initially set to 0.8, giving the majority to the validators, and only 20% as royalty to be paid to $ATONE stakers, with the COMMUNITY_TAX taking its portion.
The main difference being introduced is that the total amount of stake going to one validator doesn't actually increase the validator's power, even though all of those staked $ATONEs are at stake should this validator get slashed. This creates a potential exploit opportunity whereby some validators have relatively little at stake, and 1/3 by total of voting power of those initial validators end up causing a double spend attack. To prevent this, overstaking to a validator will be taxed incrementally with the proceeds going toward general rewards.
XXX TODO improve this. Maybe instead there is simply a sqrt(vp) applied to all the voting powers after the original Gaia staking algorithm. You can over-stake to a validator but your voting power and returns will be much less, almost inverse to the amount of overstaking.
Suppose that 1/3 of the $ATONE stakers are slashed due to a complex double spend attack. Assuming that we want to allow the recompensation of victims upon double spend attacks (within the bounds specified clearly in the constitution) only from the recently slashed $ATONEs, some nonzero portion of the slashed stake must be burned to prevent using the double spend attack as a fast way to unbond.
If no victims need to be made whole, then it could be appropriate to burn the slashed $ATONEs of the perpetrators. The end result is that the remaining stakers own the network, and in a steady state this would result in the price of $ATONEs increasing due to the reduced supply, assuming that the confidence in and usage of AtomOne hasn't changed; though in perfect theory it should take a bit of a hit, at least in proportion to the destruction of the reputation of those validators.
If victims are to be made whole with slashed $ATONEs, this may require the selling of $ATONEs into the market, or result in it, therefore the price of $ATONEs will be pushed lower, and the composition of the $ATONE holders mutated according to market conditions.
XXX can this be made fully deflationary?
The only fee token required to be accepted by all shards shall be the $PHOTON token. This must not change even with a Constitutional Majority as a matter of trust of a preagreed transaction declared in these Founding Documents, except to better serve this invariant such as by allowing for an alias or by supporting different denominations of the same underlying $PHOTON. AtomOne will not promote the $ATONE token to be used as a fee token directly, even though it must be supported as a bootstrapping and recovery measure.
While the convertibility from $PHOTON to the underlying $ATONE may be managed, paused, or throttled by governance of $ATONE with a Constitutional Majority of the $ATONE stakers not including the $ATONE of the $PHOTON bonders, all the underlying $ATONE must be distributable back to $PHOTON holders through a fair system and all of the $ATONE withdrawn within 20 years starting at any given moment.
Rewards from the $ATONE tokens bonded to $PHOTON tokens shall be distributed back to $PHOTON as if they were any other $ATONE staked tokens, but they shall not exercise their voting power and instead yield entirely to the other $ATONE staked tokens.
Tax will be deducted from these $PHOTON bonded $ATONE rewards as usual just like regular validator staked $ATONE tokens, but unlike the tax burden for validator staked $ATONE tokens, the tax burden for $PHOTON bonded $ATOM tokens shall be capped at 10%. This cap cannot be changed even with a Constitutional Majority except by also a two-thirds supermajority from the $PHOTON holders with a prominently announced vote put forth by the AtomOne hub with a voting period of at least one year, and a quorum threshold of at least 10% of the total supply of $PHOTON tokens by direct participation where the increased tax burden above the 10% must be used for common goods purposes on transparent and accountable DAO systems.
$ATONE isn't a monetary token, but a related instrument can serve better as one.
Auto-staking (staking across all validators proportionally to existing voting power) doesn't solve the "inflation problem", but it does give a way for people who don't care about staking decisions to make better-than-random staking decisions.
TODO show simplest example that demonstrates slashing.
Auto-staking if done by an external IBC zone, or an individual staker manually, would like any other staking earn the pro-rata revenue and pay the various taxes. So auto-staking per se does not make for a deflationary holding, but it comes with the benefit of automatic diversification.
Since it comes with benefits to the staker (diversification and thus less risk) but it doesn't provide the needed intelligence to AtomOne, it is better for the AtomOne hub to provide a standard minimal correct implementation under its control, such that it can also regulate it, especially as it relates to control over AtomOne governance.
Say when you auto-stake $ATONE through this sanctioned mechanism, you get $PHOTON. In order to incentivize the usage of $PHOTON, the AtomOne hub offers a trade that makes $PHOTON deflationary: non-atom rewards are taxed with an immutable cap, but inflated atoms are not for $ATONE bonded $PHOTON holders, and with the right conversion equation (which adjusts for $ATONE inflation) we can construct a perfectly fixed $PHOTON supply (say of 1 billion $PHOTONs) no matter how many $ATONE bond to $PHOTONs.
Should this "more monetary" construction of the fixed supply ("deflationary") $PHOTON token incentivize a large liquid supply, it becomes more susceptible to hostile takeovers, simply because there are more liquid $ATONE staking tokens available in comparison to the total bonded voting power. Therefore for a more secure AtomOne hub we also limit the conversion back from $PHOTON to $ATONE so as to make hostile takeovers more expensive.
The known ways are:
- Widen the gap in bidirectional conversion price between $PHOTON and $ATONE such as by adding a burn premium to for $ATONE -> $PHOTON conversion.
- Limit the amount of $ATONE that can be released per time period auction.
- Essentially the same as above with some conversion curve.
In the case of validator & delegator $ATONE slashing, $PHOTON holders will of course also get slashed, but the ratio of $phATOM-bonded $ATONEs and all other (non-$phATOM) $ATONEs remains the same. The conversion factor from $PHOTON to and from $ATONE will change to correspond with slashing. Any gap manufactured between the round trip exchange rate (such as via a burn premium one way) is independent of slash events, and is explained in the next section.
The $ATONEs bonded toward auto-staking do not count toward calculating the bonding ratio target of 2/3 in either the numerator or denominator--they are ignored.
TODO: add benefits over liquid staking and collective "liquid staking".
See also the introductory section
XXX Explain desirability of independence. XXX Link to Issues discussion.
XXX Explain the goal of Gaia and AtomOne alignment.
XXX $phATOM holders could be earning $ATONE over time, and this could be the primary method of incentivizing mutual success and value alignment.
XXX Imperfect Analogy: $ATOM is PoW miner, $PHOTON is the reward.
As an improvement to security, $phATOM holders will earn $PHOTON, with market-rate $ATONE -> $PHOTON conversion (with all throttling limitations and premium charges that may apply). If the demand for $phATOM and $PHOTON is great then this helps AtomOne influence governance of the hub with the intelligence of $ATONE. On the other hand, if the demand is not great, then the $PHOTON to $ATONE conversion is presumably already efficient.
XXX Discussion of inflation schedule, or bounds.
XXX Discussion of touchpoints for governance control.
XXX The earned $ATONE rewards may have some vesting period.
TODO: discuss further before integration... maybe this isn't wanted.
In return for delegating voting decisions from $ATOM bonded $phATOM holders to $ATONE stakers, the AtomHub will offer the $phATOM holders the opportunity for all perpetuity, the merger of $phATOM to $PHOTON according to a reasonable exchange ratio as determined by the best available means as determined by $ATONE stakers, with a minimum conversion penalty of 20% and no more favorable to $phATOM than 1:2 by total market cap between $phATOM and $PHOTON. For clarity this means that upon the failure of Gaia the $phATOM token holders can dilute the $PHOTON holders such that $PHOTON holders have as low as 2/3 the underlying $ATONE as before the merge (but no less).
In the case of Gaia failure this could be seen as a detriment to $PHOTON holders because their underlying $ATONE claims from $PHOTON has seemingly shrunk by up to half; but if the $ATOM token were to recover it would now be of benefit to $PHOTON holders; and this is an agreement that was pre-established in these Founding Documents to support the mutual success of $phATOM and $PHOTONto ensure mutual success rather than sabotage. While in the end the $ATONE stakers and before that the validators have complete freedom of will, how well they adhere to these founding agreements is left to everyone to enforce out of band.
The conversion penalty may decrease below 20% for $phATOM to $PHOTON merger with a Supermajority of $ATONE stakers.
AtomOne with a Constitutional Majority may decrease the merger ratio cap from 1:2 (1/3) even down to zero (e.g. to terminate the support of $phATOM) but the execution must be delayed for a period of at least 3 months to allow $phATOM holders to preempt this with a merge. Nothing outside of the merge will prevent $phATOM holders from being able to redeem their due pro-rata $ATOM tokens for all time.
Should the $phATOM be discontinued in support as decided by AtomOne with a Constitution Majority (which is NOT signified by a merger ratio cap of 0 by itself but must be a separate proposal), the $phATOM holders must be made whole by redistributing the underlying $ATOM tokens to their respective $phATOM holders completely with the same exchange factors applied to everyone equally, but as with decreasing the merger ratio cap, (for the purpose of giving precedent to the $phATOM -> $PHOTON merge mechanism) this must be delayed by a period of 3 months to allow $phATOM holders to preempt this with a merge.
Any slashings of the underlying $ATOM, or theft, or loss of $ATOM due to the actions of the AtomOne hub and its $ATONE stakers are completely at the risk of the original $ATOM holder who brought it into AtomOne. AtomOne must compensate users within reason, but what is reasonable is up to the $ATONE stakers to decide through AtomOne governance. Everybody must acknowledge the risks of this experiment.
All other parameters defined here regarding the merger that may negatively affect $phATOM holders and $ATOM holders on AtomOne cannot change even with a Constitutional Majority.
There is no merge mechanism for the opposing case upon AtomOne failure. In this case the $ATOM underlying $phATOM must be distributed back to the $phATOM holders in proportion, or if there was already a merger, to the $PHOTON holders in proportion.
XXX specify the conversion rate before and after the merger both ways.
In an hypothetical alternative model, there could be a three-token AMM system whereby a singular $PHOTON token is backed by both $ATOM and $ATONE, but these can suffer from manipulation; and even with the enforcement of safety bounds for the relative capitalization between $ATOM and $ATONE (such as 2:1 to 1:2) they have the unwanted side effect of additional exposure to unwanted risk.
Ultimately this hub is owned by the $ATONE holders.
We will prioritize all of these items: github.com/decentralists/DAO
The constitutional majority threshold is defined by the parameter CONSTITUTIONAL_MAJORITY_THRESHOLD initially set to 90%, and requires a constitutional majority to change.
The constitution itself must be amended by a constitutional majority.
There are largely four phases to this plan.
- Define Constitution
- Governance Fixes
- Launch Governance-Only Chain
- Implement IBC
- $PHOTON with Auto-Staking
- Fix Validator Incentives
- Implement ICS1.5
- Prototypes with SubDAOs (including GNO)
- Migrate $PHOTON to ICS
- Promote Smart Contract Use Cases
- Develop Scalable Validator Infrastructure
- Develop Recovery Procedures
- Create OnChain Education Curriculum
- Promote Good Forks and Projects
- Promote Other Common Goods
- Finalize the Software
Finalization should not be seen as a thing to avoid, but rather a necessity for preserving immutability and thus providing real security benefits.
Everyone who wants something different is given a way to create their own variation to compete and cooperate with the AtomOne hub. We should all be familiar with this concept, as it is how AtomOne itself was born--by exodus from Gaia.
It is possible that what we arrive at is not sufficient in the long run, and that is still OK; the ultimate goal is to be a standard reference, in the very least in relation to an improved fork; a reference that will last a thousand years or more.
In short, the goal is nothing more than to create timeless code, even knowing that in the end even AtomOne will be phased out, but never forgotten; the template will have split into a million different forks and conquered the world. AtomOne Eschatology will be well documented and planned, for a time when nobody was around for these early beginnings.
The AtomOne Technical Steering Committee (TSC) is a self-mutating organization that is tasked with overseeing the development of the necessary software. It is represented by ...
XXX AIB, the only thing it can do is invite people; manage the invites.
XXX Do-ocracy; whoever wants to make these softwares.
XXX Review process: [Proposal: AIB:NO,]
XXX Decentralists: On self-organization and funding...
XXX 3 year term, after 3 years must demonstrate; or otherwise removed.
XXX
There have been many questions from the community about AtomOne and GovGen across various platforms. Please refer to the FAQ.md for a detailed list.
- Complete the CONSTITUTION w/ all known functionality
- Reconcile this README with CONSTITUTION
- Incorporate the "Constitutional Majority" in the Constitution.
- Move Decentralists governance roadmap here.
- Keplr & Ledger need competition.
- Consider referencing https://twitter.com/jaekwon/status/1724641822398681547 with more insight.
- Roadmap Timeline
- Links to Additional Resources such as technical documentation, or community forums, for in-depth information.
- Channels for reaching out to the core team or support, especially for technical support or collaboration inquiries.
- Scan through X (formally Twitter) posts for more ideas.
- Argument for why hub and spokes are needed (from atom one)
- Quantum resistance
- Constitution updates: $ATOM -> $ATONE; Add $PHOTON and $phATOM; conversion
- At least one week for decentralists feedback on proposals that meet the spam threshold.
- Proposals should be self contained no PDF necessary.
- TM2 Consensus Court
- Subsidize relayers and require payment for every IBC tx.
- Fork proves that slashing is real.
- Increased Voting Period.
- Globally decentralized validator set.
- What is a hub? connected zones and shards should use it as such, not make more connections out.
- Allow the staking distribution to hone its intelligence via slashing.
- Use real human connections to defend against AI.
- About diversity of implementation, and its limitations.
- Add old PHOTON elements back in if relevant; not counting 2/3 ratio...
- Recovery procedure by AtomOne in the case of IBC zone failure.
- Recovery procedure by AtomOne in the case of ICS shard failure.
- Require the ICF to buy back ATOMs and to allocate them for on-chain disbursement.
- Indemnify all actors given no malice outside of the chain. Allow the chain to enforce penalties from outside the chain.
- Specify that $ATONE held in pools and bonded for $PHOTON do not count toward the bond ratio.
- Add rules for what non-hubs and hubs (separate rules) must abide by. Not all hubs can connect due to this.
- XXX