AI prompts
base on genesis for AtomOne > [!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 Constitution](CONSTITUTION.md)
> - [The Roadmap](https://commonwealth.im/govgen/discussion/24800-atomone-roadmap)
> - [The Tokenomics](https://commonwealth.im/govgen/discussion/24801-atomone-tokenomics)
> - [The Software versioning](https://commonwealth.im/govgen/discussion/24802-cosmos-softwares-versioning)
> - [The ATONE distribution](https://commonwealth.im/govgen/discussion/24799-equitable-atone-distribution-in-the-spirit-of-atomones-founding-principles)
>
> 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](https://github.com/atomone-hub/govbox/blob/master/PROP-001.md).
----------------------------------------
_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._
----------------------------------------
# Preamble
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.
----------------------------------------
# Declaration of Genesis
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_](./STAKING_VS_MONEY.md)).
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.
----------------------------------------
# Vision and Missions
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.
## Role as Minimal IBC/ICS Hub
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.
## Significance as a Political Base
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".
## Role as $ATOM "Liquid Staking" Provider
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.
## Expected Outcomes and Benefits
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.
----------------------------------------
# Terms
* 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).
----------------------------------------
# Objectives
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.
## 1. Define $ATONE
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.
## 2. IBC/ICS Hub and Minimalism
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.
## 3. Validator Incentives
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!
## 4. Governance
Import elements from
[github.com/decentralists/DAO](https://github.com/decentralists/DAO/tree/main/governance)
### The Supermajority of Two Thirds
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
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.
## 5. Fix "Liquid Staking"
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.
## 6. Declaration of Independence & Constitution
Adopt a Declaration of Independence and Constitution with cryptographic
signatures.
See [draft declaration](./TODO) and [draft constitution](./CONSTITUTION.md).
## 7. IBC1.5
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
## 8. Transparent Security System
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.
## 9. Fund SubDAOs
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.
## 10. Engineering Task Force
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
## 11. Enable Meiosis
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 https://github.com/gnolang/gno/pull/1224 for prototype WIP of splitting.
----------------------------------------
# Plan
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.
## Genesis Distribution
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.
## Tokenomics
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.
### ICS Fee Distribution
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.
### Staking
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.
### $PHOTON the More Deflationary Version of $ATONE
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
### Create $ATONE / $PHOTON Price Gap
XXX Explain desirability of independence.
XXX Link to Issues discussion.
## $ATOM "Liquid Staking" Service
XXX Explain the goal of Gaia and AtomOne alignment.
### Earn $ATONE or $PHOTON Inflation Rewards
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.
### Parent Chain Failure Insurance
_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.
### Avoid Mixed ATOM+ATONE Liquid Staking
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.
## AtomOne Governance
Ultimately this hub is owned by the $ATONE holders.
We will prioritize all of these items:
[github.com/decentralists/DAO](https://github.com/decentralists/DAO/tree/main/governance)
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.
## Milestones
There are largely four phases to this plan.
### AtomOne Phase 1: Pre-IBC
1. Define Constitution
2. Governance Fixes
3. Launch Governance-Only Chain
4. Implement IBC
### AtomOne Phase 2: Post-IBC
1. $PHOTON with Auto-Staking
2. Fix Validator Incentives
3. Implement ICS1.5
4. Prototypes with SubDAOs (including GNO)
### AtomOne Phase 3: ICS1.5 scaling
1. Migrate $PHOTON to ICS
2. Promote Smart Contract Use Cases
3. Develop Scalable Validator Infrastructure
4. Develop Recovery Procedures
### AtomOne Phase 4: Maintenance
1. Create OnChain Education Curriculum
2. Promote Good Forks and Projects
3. Promote Other Common Goods
4. 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.
## AtomOne Technical Steering Committee
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
----------------------------------------
# AtomOne FAQ
**There have been many questions from the community about AtomOne and GovGen across various platforms. Please refer to the [FAQ.md](./FAQ.md) for a detailed list.**
----------------------------------------
# TODO
- [ ] 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
", Assign "at most 3 tags" to the expected json: {"id":"5387","tags":[]} "only from the tags list I provide: [{"id":77,"name":"3d"},{"id":89,"name":"agent"},{"id":17,"name":"ai"},{"id":54,"name":"algorithm"},{"id":24,"name":"api"},{"id":44,"name":"authentication"},{"id":3,"name":"aws"},{"id":27,"name":"backend"},{"id":60,"name":"benchmark"},{"id":72,"name":"best-practices"},{"id":39,"name":"bitcoin"},{"id":37,"name":"blockchain"},{"id":1,"name":"blog"},{"id":45,"name":"bundler"},{"id":58,"name":"cache"},{"id":21,"name":"chat"},{"id":49,"name":"cicd"},{"id":4,"name":"cli"},{"id":64,"name":"cloud-native"},{"id":48,"name":"cms"},{"id":61,"name":"compiler"},{"id":68,"name":"containerization"},{"id":92,"name":"crm"},{"id":34,"name":"data"},{"id":47,"name":"database"},{"id":8,"name":"declarative-gui "},{"id":9,"name":"deploy-tool"},{"id":53,"name":"desktop-app"},{"id":6,"name":"dev-exp-lib"},{"id":59,"name":"dev-tool"},{"id":13,"name":"ecommerce"},{"id":26,"name":"editor"},{"id":66,"name":"emulator"},{"id":62,"name":"filesystem"},{"id":80,"name":"finance"},{"id":15,"name":"firmware"},{"id":73,"name":"for-fun"},{"id":2,"name":"framework"},{"id":11,"name":"frontend"},{"id":22,"name":"game"},{"id":81,"name":"game-engine "},{"id":23,"name":"graphql"},{"id":84,"name":"gui"},{"id":91,"name":"http"},{"id":5,"name":"http-client"},{"id":51,"name":"iac"},{"id":30,"name":"ide"},{"id":78,"name":"iot"},{"id":40,"name":"json"},{"id":83,"name":"julian"},{"id":38,"name":"k8s"},{"id":31,"name":"language"},{"id":10,"name":"learning-resource"},{"id":33,"name":"lib"},{"id":41,"name":"linter"},{"id":28,"name":"lms"},{"id":16,"name":"logging"},{"id":76,"name":"low-code"},{"id":90,"name":"message-queue"},{"id":42,"name":"mobile-app"},{"id":18,"name":"monitoring"},{"id":36,"name":"networking"},{"id":7,"name":"node-version"},{"id":55,"name":"nosql"},{"id":57,"name":"observability"},{"id":46,"name":"orm"},{"id":52,"name":"os"},{"id":14,"name":"parser"},{"id":74,"name":"react"},{"id":82,"name":"real-time"},{"id":56,"name":"robot"},{"id":65,"name":"runtime"},{"id":32,"name":"sdk"},{"id":71,"name":"search"},{"id":63,"name":"secrets"},{"id":25,"name":"security"},{"id":85,"name":"server"},{"id":86,"name":"serverless"},{"id":70,"name":"storage"},{"id":75,"name":"system-design"},{"id":79,"name":"terminal"},{"id":29,"name":"testing"},{"id":12,"name":"ui"},{"id":50,"name":"ux"},{"id":88,"name":"video"},{"id":20,"name":"web-app"},{"id":35,"name":"web-server"},{"id":43,"name":"webassembly"},{"id":69,"name":"workflow"},{"id":87,"name":"yaml"}]" returns me the "expected json"