{"id":17136476,"url":"https://github.com/atomone-hub/genesis","last_synced_at":"2026-02-17T17:37:51.888Z","repository":{"id":207096395,"uuid":"718383838","full_name":"atomone-hub/genesis","owner":"atomone-hub","description":"genesis for AtomOne","archived":false,"fork":false,"pushed_at":"2024-11-18T11:09:39.000Z","size":656,"stargazers_count":131,"open_issues_count":64,"forks_count":58,"subscribers_count":22,"default_branch":"main","last_synced_at":"2025-02-23T04:32:04.569Z","etag":null,"topics":["atomone"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/atomone-hub.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":"GOVERNANCE.md","roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-11-14T00:48:59.000Z","updated_at":"2025-02-15T19:47:10.000Z","dependencies_parsed_at":"2024-01-03T05:34:32.683Z","dependency_job_id":"6e27f7e8-d4df-4509-8ad8-f502b945a1d8","html_url":"https://github.com/atomone-hub/genesis","commit_stats":null,"previous_names":["atomone-hub/genesis"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/atomone-hub/genesis","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomone-hub%2Fgenesis","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomone-hub%2Fgenesis/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomone-hub%2Fgenesis/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomone-hub%2Fgenesis/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/atomone-hub","download_url":"https://codeload.github.com/atomone-hub/genesis/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomone-hub%2Fgenesis/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29551257,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-17T14:33:00.708Z","status":"ssl_error","status_checked_at":"2026-02-17T14:32:58.657Z","response_time":100,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["atomone"],"created_at":"2024-10-14T20:01:33.878Z","updated_at":"2026-02-17T17:37:51.866Z","avatar_url":"https://github.com/atomone-hub.png","language":null,"funding_links":[],"categories":["Misc"],"sub_categories":[],"readme":"\u003e [!NOTE] \n\u003e _This document was written in December 2023, and is left here unchanged for historical\n\u003e purpose. For more recent updates on AtomOne, you can check the following links:_\n\u003e - [The Constitution](CONSTITUTION.md)\n\u003e - [The Roadmap](https://commonwealth.im/govgen/discussion/24800-atomone-roadmap)\n\u003e - [The Tokenomics](https://commonwealth.im/govgen/discussion/24801-atomone-tokenomics)\n\u003e - [The Software versioning](https://commonwealth.im/govgen/discussion/24802-cosmos-softwares-versioning)\n\u003e - [The ATONE distribution](https://commonwealth.im/govgen/discussion/24799-equitable-atone-distribution-in-the-spirit-of-atomones-founding-principles)\n\u003e\n\u003e The proposed genesis file for AtomOne resulting from the proposals above can be found here:\n\u003e https://atomone.fra1.digitaloceanspaces.com/genesis.json\n\u003e The genesis file above is missing gentxs and may not correspond to the final genesis.\n\u003e \n\u003e For more information on how the genesis was built please also look [here](https://github.com/atomone-hub/govbox/blob/master/PROP-001.md).\n\n----------------------------------------\n\n_ALL CONTRIBUTIONS TO THIS REPO, ITS ISSUES, PROJECTS, AND DISCUSSIONS MAY BE USED\nIN ANY EXPLICIT GITHUB FORK WITH A NEW AND DISTINCT NAME TO LAUNCH ANY FORK OR SPLIT\nTHAT MODIFIES ANY OF THE IDEAS MENTIONED HERE UNDER THE GnoNGPL COPYLEFT LICENSE._\n\n----------------------------------------\n# Preamble\n\nThe Cosmos community, at a crossroads, confronts divergent views on key aspects\nsuch as mission, tokenomics, and security philosophy. AtomOne emerges as a\nbeacon, offering an alternative fork to navigate these waters, equipped to\nhandle contingencies and embodying a bastion for diverse political thought.\n\n----------------------------------------\n# Declaration of Genesis\n\nThere comes a time when there is enough disagreement among community members\nand stakers about key concerns regarding the business of their chain, such as\nits vision, mission, tokenomics, architecture, implementation, or philosophy;\nthat it makes the most sense to support an alternative fork running alongside\nthe original so as to be prepared against all contingencies.\n\nRecent times have seen the Cosmos community grappling with significant\nchallenges stemming from differences about core tokenomics, about the very\nnature of the $ATOM token (whether it is staking or monetary), about\nmonetization strategy and what types of projects to fund; and there generally\nappears to be a great cultural chasm that shows no sign of closing about our\nrole and responsibilities as compared to our profit interests. (see [_NWV to\nProp 848 – $ATOM Must NOT be Money_](./STAKING_VS_MONEY.md)).\n\nProposal #848 (\"halvening\") succeeded in getting the required threshold of 50%\nto pass on Gaia, but a significant portion voted NO or NWV which means that\nthat $ATOM stakers are largely split on the most fundamental tokenomics\nsecurity design element. 73,165,203ATOM YES vs 56,667,011ATOM NO +\n11,669,549ATOM NWV overall YES:NO is 1.07:1. Furthermore, this change was\nproposed on chain without addressing the valid security concerns raised by the\ncommunity, with huge errors about the cost of inflation by miscalculating true\nincome, and without a complete halvening schedule, thereby working to undermine\nhub credibility.\n\nThese and prior disagreements have now made clear the need for an alternative\nhub with a renewed focus and Alignment to serve as the canonical minimal\nIBC/ICS token hub with respect to Cosmos to champion the ideals of sovereignty,\nsecurity, and decentralization everywhere; and secondarily to serve as the main\nbase for a political party and more-intelligent voting bloc with respect to\nGaia to save Gaia from itself. A modification to the distribution of $ATONE\nthrough slashing those who voted in favor of #848 would help ensure that the\nresultant distribution is more intelligent about security and would make us\nanti-fragile against even the most powerful of adversaries.\n\n----------------------------------------\n# Vision and Missions\n\nThe vision behind this AtomOne fork is to be an alternative minimal fork of\nGaia (\"cosmoshub4\") running alongside Gaia to prepare for all contingencies,\nand also to operate as a political party base in relation to Gaia. We strive to\ncomplement the broader Cosmos ecosystem while introducing innovative solutions\nand perspectives. Our goals are not just to resolve current challenges but are\nalso to set a new precedent for adaptive and responsive self-organization in\nthe multichain multitoken universe that we call the Cosmos.\n\nAtomOne will lead the development and praxis of giving representation to every\n(sub)group (such as a political party), each defined and strengthened by their\nown living constitutions that state their values, missions, philosophies and so\non. This will foster a more diverse ecosystem of specialized zones in\ncoopetition (cooperation and competition) with each other despite\nirreconcilable differences. AtomOne will be a base for many more partyhubs,\nand itself function as a partyhub in relation to Gaia. There will be many\npartyhubs in a great sea of divisions, and from this soup will emerge\nspecialization, interoperation through common protocols, and fault tolerance in\nnumbers, we pray for the helping hand of reason, wisdom, foresight, empathy,\ntemperance, and all other necessary faculties.\n\n## Role as Minimal IBC/ICS Hub\n\nWhile AtomOne aims to steer Gaia toward safe decisions, it cannot by itself\ndetermine the decisions made by the Cosmos Hub. Yet, Cosmos *needs* minimal\nIBC/ICS hubs without any confusion about what it is, and as mentioned in the\nDeclaration of Genesis Gaia does not embody this (yet). Ergo, AtomOne must not\nonly guide Gaia, but it must also run the desired alternative minimal IBC/ICS\nhub as an alternative in addition to Gaia.\n\nAtomOne re-commits to the original vision and primary mission of Gaia to serve\nas a minimal IBC/ICS hub secured by a staking token that targets 2/3 of the\nstake to be bonded. We believe that minimizing the risk profile is necessary as\nan existential issue for the hub, and an issue of financial security of the\nhighest order for not just the hub but its hosted shards and IBC connected\nnetwork allowing AtomOne to occupy a real and an important niche. When there\nis a double-spend attack on the hub, the staking tokens of those responsible\nfor the attack should be used to compensate the victims as much as reasonable,\nand the non-zero remainder of the penalty burned. A staking token of an\nexchange zone for example must consequently have additional risks related to\nits business, and so $ATONE occupies a niche of minimal risk profile in\ncomparison.\n\nIBC/ICS hubs should in general remain conservative in its function and offer\nutility through dependability and scaling. Any experiments that change the\nnature of the hub belong in new forks or splits, and an ideal hub enables them\ndespite of and in order to celebrate these differences. In the Cosmos there is\nno need for contention as with land-locked states because there is no\nlimitation of finite land. We can create new forks/splits/groups that are\nbetter aligned with what we need if there is enough need or support for it.\n\nThe powers not delegated to the AtomOne hub by the Constitution, nor prohibited\nby it to the consumer chains, are reserved to the consumer chains respectively,\nor to the stakers, token holders, and people; or to other splits or forks of\nthe AtomOne hub.\n\n## Significance as a Political Base \n\nThere are many of stakers and users of Gaia that are aligned with the\nvalues, principles, original mission of Gaia and those of AtomOne, but we have\nno explicit base of operations. In contrast, the informal opposition majority\nparty (which came about first) is well organized in comparison, usually behind\nclosed doors. Meanwhile \"liquid staking\" providers are providing a service that\ndoes more than liquid staking, but have their own governance and powers and\nthus act as a kind of political base. For example, which validators to stake to\nis determined through governance in Informal/Stride.\n\nBy modifying the distribution of staking token holders for AtomOne to be more\naligned with hub security based on voting activity we can make the $ATONE\ndistribution a more intelligent distribution than all other alternatives (until\nanother split is needed due to corruption). As the project grows, by virtue of\nits growth the distribution will naturally evolve (or by default, devolve), so\nthis may precipitate the need for more hubs descendant from AtomOne, with or\nwithout substantial changes to its fork of the constitution. Even with the same\nconstitution its distribution (or how it was modified from the parent\ndistribution) affords its character or flavor which can strengthen or weaken\nover time depending on its tokenomics. \n\nBy our own governance function and the tooling that we fund and create, we will\nbring more intelligence and security to all connected blockchains especially\nGaia. AtomOne must do whatever is necessary within reason to guide Gaia to\nmaintain safety, and the best way to do that is by holding $ATOMs through IBC\npegging and using these $ATOMs to make voting decisions on Cosmos as a voting\nbloc. The following section describes the one and only way the AtomOne hub will\nuse $ATOMs; by offering what is misleadingly referred to as \"liquid staking\".\n\n## Role as $ATOM \"Liquid Staking\" Provider\n\nAtomOne will offer an $ATOM bonding zone in a core shard to compete with\ncollective \"liquid staking\" service providers. These $ATOMs will be\nautomatically delegated via ICA (interchain accounts) to aligned validators as\ndetermined by the system determined by the $ATONE stakers. The bonders of\n$ATOM toward this service will receive liquid $phATOM tokens.\n\nIn addition to Gaia's $ATOM, AtomOne's $ATONE tokens will also be bondable to\n$PHOTON tokens. So there will be $phATOM along side $PHOTON tokens, but with\nsome differences in tokenomics between them. We have more control over $PHOTON\ntokenomics, though the changes we introduce for $PHOTON may be upstreamed to\nGaia for $phATOM.\n\n## Expected Outcomes and Benefits \n\nWe believe that by embracing diversity and fostering open dialogue between\ncompeting self-aligned groups we can create a more robust, innovative, and\ndecentralized ecosystem. The diversity of specialized self-organized groups and\nforks (composed of aligned members) will accelerate innovation and\nimplementation through parallelism. The diversity of competitive groups and\nforks will reduce risk at the local and global levels; at the local level\nthrough competition of implementations, and at the global level through the\ndiversity of hubs and frameworks.\n\nWe hope that the economic recovery measures between $phATOM and $PHOTON will\nincentivize mutual success and allow Gaia to transition safely into a more\nexperimental hub as compared to the more immutable and conservative AtomOne.\n\n----------------------------------------\n# Terms\n\n* Alignment: full agreement with the founding documents in speech and action\n  with relation to AtomOne.\n* AtomOne: an opinionated fork of the Cosmos hub Gaia with chainid\n  \"cosmoshub4\". It is a minimal IBC-token-pegging and ICS hosting hub.\n* Constitutional Majority: a consensus threshold set at a higher bar than the\n  standard two-thirds majority initially set at 90%.\n* IBC: short for Inter-Blockchain Communication, is a protocol that enables\n  communication between different blockchain networks using Byzantine Fault\n  Tolerant (BFT) light client proofs. It allows for the transfer of assets and\n  information across independent blockchains, fostering interoperability and\n  flexibility in the blockchain ecosystem. IBC is a cornerstone of the Cosmos\n  network's architecture, enabling its vision of an 'Internet of Blockchains'.\n* ICS: short for Inter-blockChain Security, is a mechanism for running multiple\n  shard chains under the same validator set. ICS1.5 is an upgrade to ICS1 that\n  improves inter-shard communication efficiency. ICS1 and ICS1.5 help scale the\n  core functionality of AtomOne as well as offer anyone the service of running\n  \"consumer chains\" for any purpose (within the guidelines set forth by\n  AtomOne) secured and hosted by the same validator set as the AtomOne hub root\n  and core shards.\n* Zone: an independent or ICS hosted chain (or a dapp hosted on a smart\n  contract chain or an instance on a parent chain) with a well-defined\n  governing body or bodies that dictate the governance and economic rules\n  internal to that zone. A zone is sovereign or partially sovereign.\n* Fork: an exact copy of a distribution with either the same or different\n  blockchain software, usually with a different chain identifier than the\n  original.\n* Air-drop: like a fork but with modifications to the distribution such as by\n  including a new premine, or excluding addresses (such as those on sanctions\n  lists), or changing the number of tokens for an address in any way, or even\n  including modified or unmodified distributions of other chains.\n* Split: an air-drop of a chain that modifies the distribution based on staker\n  voting activity in both consensus and governance through their cryptographic\n  signatures as well as any other criteria based on a well defined and\n  prominent self-reinforcing constitution; or a fork of a chain with a modified\n  constitution or modified software that is intended to achieve the same.\n* $ATONE: the primary staking token for AtomOne. Previously known as $ATOM1.\n* $PHOTON: the liquid staking token for AtomOne. Previously known as $phATOM1\n  or $phATONE. the latest in tokenomics design.\n* $phATOM: the liquid staking token for Gaia offered on AtomOne for $ATOM (not\n  $ATONE).\n\n----------------------------------------\n# Objectives\n\nAll users and members must agree with these objectives, and at all times when\ncontributing take all appropriate actions to meet these objectives both in the\nAtomOne software as well as open hardware. Otherwise they are at risk of\njudgement by AtomOne or any other community or governing set.\n\nThese objectives can only be changed through Constitutional Majority.\n\n## 1. Define $ATONE\n\nThe $ATONE is defined to be a staking token of a minimal ICS1.5 IBC AtomOne Hub\nthat keeps 2/3 of $ATONEs staked at all times.\n\nAll forks that lose consensus continuity must change their token ticker symbol\nto be distinct from $ATONE ($ATOM2 is ok). If there are competing chains with\ncomparably similar continuity, then the fork that has a higher market cap (as\nmeasured after both tokens have discovered fair market value with sufficient\nliquidity for at least one week) should retain the name while other forks\nchange their token ticker symbol.\n\nAny changes to the distribution besides slashing for pre-established slashing\nconditions such as any additional premines (besides those in the original first\ngenesis) disqualify the fork from retaining the same token ticker symbol; those\nare new airdrops of a different token. No additional premines besides those\nalready defined in this planning document are allowed for any forks whose token\nshall be called $ATONE.\n\n## 2. IBC/ICS Hub and Minimalism\n\nWe are not concerned about any business plan or tokenomics strategy for the\nAtomOne hub besides offering the scaling of transaction throughput through\nICS1.5. We anticipate that our approach will successfully and sufficiently\ncapture the niche market need for utmost security in IBC token transactions and\nICS1.5 shard hosting, and serve as the basis for all the functionality that all\npeople will need and want; and if it cannot be done through the spirit of these\nFounding Documents and the living AtomOne Constitution then it shall be done in\nthe next generation that splits or forks from this AtomOne hub.\n\nThe term \"minimal\" refers not to the totality of functionality offered by all\nthe consumer chains hosted by ICS1.5, but rather the design of the root hub,\nand core shards of the AtomOne hub, the tokenomics of hub, its business plan,\nand its responsibilities; sometimes confusingly referred to as simply \"the\nhub\". A \"minimal hub\" should be understood in this context; smart contract\nsystems and VMs must not be on the hub's root chain (for security and\nefficiency) and ideally not even in core shards (for security), but rather on\nconsumer shard chains on ICS1.5. \n\nThis is the best way to scale to billions of users while providing\nspecialization and isolation. For example, your home internet WIFI network is\nprovided by a minimal router hardware, while your backup harddrives and your\nmany devices are separate machines that only connect to the router. If the\nrouter had to also host application logic, the network performance of all the\ndevices would suffer and the router would be more likely to crash.\n\nAll shards (chains) are secured by the same validator set as the main hub\nchain. The shards that are owned and governed by AtomOne itself are called\n\"core shards\" and they are shards necessary for AtomOne as defined in these\nfounding documents and living constitution; while those hosted on behalf of\nothers are called \"consumer shards\".\n\nWe must at all times distinguish between what is core vs consumer, not only in\nour code, documentation, and specifications, but also to the end user through\nall commensurate reasonable means at our disposal.\n\nArbitrary smart contract functionality must not be allowed on the main hub\nshard, which must instead be reserved primarily for basic transfer and IBC\ntransactions, ICS1.5 shard coordination, and governance voting as safety and\nliveness critical functionality.\n\nThe hub's root shard, IBC, and ICS1.5 implementations must stay minimal and\nonly perform what is specified in these Founding Documents, or must be amended\nto the living AtomOne Constitution. The business plan of the hub must likewise\nbe strictly limited to what is defined in these documents. All other\nfunctionality can be hosted on top of the ICS1.5 hosting layer on consumer\nchains and must not be confused for AtomOne functionality, and it should be\nclear which governing body is the responsible party for each consumer shard.\n\nAtomOne must not subsidize any ICS1.5 core shards that are not necessary to\nfulfill the specification of these documents. No core shard shall host\narbitrary smart contracts from the general public--AtomOne will not itself\nbecome the maintainer for smart contract systems and virtual machines. Instead\nthese must run as consumer chains with their own governing body. However they\nare funded, they must.\n\nAny fixed functionality that could run on alternative VMs should be translated\ninto the dominant language of the official approved software, which for us is a\nrecent version of Go(lang) 1.xx. We should remind ourselves that every virtual\nmachine has (had) numerous zero day exploits. The added security vulnerability\nsurface area of the new VM combined with the compiler to compile one language\nfor the VM, as well as the added complexity of needing to audit another\nlanguage, can and must all be avoided.\n\nMixing implementations across validators is also to be avoided so as to prevent\na failure arising from a low Nakamoto coefficient among the types of\nimplementations. Instead AtomOne will always support one standard\nimplementation.\n\nThe hub will not be used for experimentation. Experimentation should occur in\nother zones. Let's demonstrate that a minimalist hub is not the same as a\nminimalist ecosystem and how we can create a pioneering ecosystem. Any new\nfeature proposals for the hub should be considered only after a successful and\nadequately long testing period in other zones.\n\nWhen it comes to the innovative spirit and creative potential beyond those\nspecified in these founding documents and the living constitution, we recommend\nthat they be implemented as ICS1.5 hosted zones, and only in those cases where\nAtomOne can probably not solve the problem at hand through ICS1.5 hosting\nshould a fork of AtomOne or a new chain be proposed with an entirely different\nconstitution. The spirit of the AtomOne Constitution and the general mission\nand purpose of the AtomOne hub as a utility must not change. \n\n## 3. Validator Incentives\n\nFix Validator incentives so that every validator is PAID to run ICS consumer\nchains and hub shards. Actually, develop a minimal economic model that accurately\ndescribes physical reality in an intuitive and adaptable way for all scenarios.\nLet's implement a system where every ICS chain pays supermajority to validators!\n\n## 4. Governance\n\nImport elements from\n[github.com/decentralists/DAO](https://github.com/decentralists/DAO/tree/main/governance)\n\n### The Supermajority of Two Thirds\n\nAll governance proposals must pass the required ratio threshold of 2/3 in\naddition to the auto-adjusting deposit threshold and the auto-adjusting quorum\nthreshold for the purpose of spam prevention and better utilizing our precious\nattention. The two thirds ratio is derived from the natural limitations of\npartially synchronous consensus, and must at least two thirds in order to\nprevent failure from a dissenting minority of 1/3 by stake. Most proposals that\npass pass with a two thirds supermajority anyways, and this allows us to\nsimplify the governance mechanism such as by removing the distinction between\nNO and NO_WITH_VETO.\n\nThe Supermajority is defined to be exactly \"more than two thirds\" (+2/3, or at\nleast one iota more than two thirds) and cannot change even by a Constitutional\nMajority.\n\n### The Constitutional Majority\n\nThe Constitutional Majority is initially set at 90% which is higher than the\ndefault required Supermajority. The Constitutional Majority cannot be lowered\nlower than 90% even with a Constitutional Majority, but it may be set to any\nvalue between 90% and 100%. This elevated threshold aims to ensure broader\nagreement and inclusivity in critical decision-making processes. It reflects a\ncommitment to achieving near-unanimous consensus on essential governance\ndecisions, enhancing the legitimacy and stability of the outcomes.\n\n## 5. Fix \"Liquid Staking\"\n\nWhat we have isn't liquid staking in its pure form where every validator gets\nits own liquid staking derivative; rather what we have are a collectivized form\nof liquid staking; and when they have their own governance mechanism separate\nfrom the host hub and they can choose which validators to delegate to, they\nshould be perceived as \"partyhubs\" with their own mind and agenda.\n\nPeople seek out these liquid tokens because they want to avoid the inflation\npenalty and use these tokens for purposes other than validator staking (because\nthe inflation rate is too high). These users are generally not interested in\nthe staking token for the purpose of staking, but are more interested in new\nuses of the token especially Defi use-cases. These users are not necessarily\nDecentralists or aligned with AtomOne in spirit--they are anyone and everyone.\nTherefore these staking services must be regulated such as by removing or\ncapping their potentially dominating voting power (in the absence of\nlimitations such as on the portion of rewards that can go to these liquid token\nholders). These voteless liquid staking tokens should generally be made\navailable first; and when there is a need for political differentiation new\ndistinct partyhubs should be allowed to compete against the voteless one. There\nwill generally be demand for the original voteless liquid token because it is\nmanaged directly by the stakers of the hub.\n\nLater we show the $PHOTON token which is deflationary AND liquid, yet fully\nbacked by $ATONEs.\n\n## 6. Declaration of Independence \u0026 Constitution\n\nAdopt a Declaration of Independence and Constitution with cryptographic\nsignatures.\n\nSee [draft declaration](./TODO) and [draft constitution](./CONSTITUTION.md).\n\n## 7. IBC1.5\n\nSolve IBC1.5, or ICS1.5, where the validator sets are implicit, for fast\ninter-hub communication with implied IBC, WITHOUT sacrificing independent BFT\nconsensus layers.\n\nXXX add more\n\n## 8. Transparent Security System\n\nCreate a permissioned and fully accountable, and 100% predetermined-finite-\ntime-delayed transparent security reporting system. Ensure that ABSOLUTELY\nALL information within the system eventually becomes public knowledge to help\ndeal with zero day vulnerabilities and current attacks \u0026 fund it.\n\n## 9. Fund SubDAOs\n\nIn addition to the staking token distribution (and any choice of modifications\nif any to them) we should also consider the vote of individuals (in its purest\nform, one per person) in the form of self-organized self-aligned groups drawn\ntogether by some common interest (too often by greed and sometimes by\nprinciple), because no project will succeed without its community, and by\nnature the community has its own spirit and power distribution independent of\nthe chain by nature.\n\nThis dimension manifests in all social interactions with or without explicit\nform, and must be a core concern that is somehow supported by the hub for\notherwise external influencers will easily sabotage the project through social\nengineering methods. For more on this, see the related document on the\nDecentralists, an experiment that will be subsidized by AtomOne to create\ntooling that allows anyone to discuss and gauge the interest of ideas before\nthey are put up for proposal measured by both liquid-democracy inspired\ndemocratic weighting (for any group selection) as well as stake-based\nweighting.\n\nCreate and support competing marketing, growth, infra, dapp subDAOs, and\nespecially help them foster the best in class in Cosmos; from the user level\ndown to the VM, every component should have a good selection of competition.\n\nSee https://github.com/gnolang/gno\nTODO add more smart contract projects.\n\n## 10. Engineering Task Force\n\nCreate a team tasked with minimizing and simplifying code and reducing\nunnecessary dependencies, taking the best examples from various forks taken\ninto consideration, so that all the best ideas from all forks can integrate\ninto one where-ever possible. FINISH software.\n\nSee https://github.com/gnolang/gno/tree/master/tm2 for Tendermint2\n\n## 11. Enable Meiosis\n\nOssify the partyhub after it has become its own competing IBC/ICS hub. Allow\nothers to likewise fork from you by enabling ICA partyhubs when there is\ndisagreement. Multiply by meiosis and conquer the world.\n\nAtomOne will lead the way in demonstrating a more secure system for splitting\noff new generations of partyhubs as a necessary course of action of last resort\nin the face of gridlock and friction. ICA-based (interchain-account) partyhubs\nwith independent validator sets introduce additional security risks associated\nwith the behavior of the other validator set securing said partyhub--unlike\nshards secured under ICS1.x by the original hub itself.\n\nIn an ideal scenario, once AtomOne is complete in functionality and has proven\nitself, it and its supporters will guide Gaia to adopt the same secure\nsplitting system so that Gaia AND AtomOne can both have a richly diverse\npartyhub set representing many diverse parties each with their own\nphilosophies, expertise, concerns, and jurisdictions.\n\nSee https://github.com/gnolang/gno/pull/1224 for prototype WIP of splitting.\n\n----------------------------------------\n# Plan\n\nThe AtomOne hub exists as a separate minimalist fork of Gaia. Both are separate\nand distinct from gno.land, though gno.land and the GnoVM (as well as other\nVMs) will play significant roles in completing the hub and maintaining its\nupkeep.\n\nThe main goal is to fix what must be fixed in governance and the need for an\nexplicit constitution, before launching the full IBC and ICS functionality of\nthe chain.\n\nFirst, we describe the tokenomics of the AtomOne hub, followed by the main\nmilestones, with an emphasis on completion and even potential phase-out.\n\n## Genesis Distribution\n\nIt should be some distribution of the Cosmos Hub $ATONE token with those who\nvoted against the spirit of this project slashed because they never joined to\nuse the system in the first place (e.g. they were more interested in price\nappreciation of original $ATOM).\n\nAdditionally, the Interchain Foundation playing a key role in the evolution of\nthe hub, should also be removed.\n\nFinally, 10% of the $ATONEs are premined for various purposes.\n\nThe $ATONEs in genesis are locked and cannot be transferred due to the value of\nthe parameter ENABLE_SENDTX except for chosen addresses (e.g. for faucets).\n\nThe Genesis Distribution is largely an opinionated fork of the cosmoshub4 $ATOM\n(judged by Alignment based on voting activity, to slash those who don't align,\nor those who aren't interested in using our chain).\n\nThe Interchain Foundation will be excluded from this distribution, so as to\ncreate a separation of concerns, and instead 10% of the final total amount will\nbe allocated toward contributors and onchain DAOs.\n\nOf the 10% premine, \n - 1% to general pre-launch contributors and early adopters.\n - 1% reserved for IBC contributions (and all that it entails) and early\n   adopters.\n - 1% reserved for ICS1.5 contributors (and all that it entails thereafter)\n   and early adopters.\n - 7% reserved for gov distribution to subDAOs for remainder of plan and\n   constitution (but nothing more).\n\nIn addition to these premines, the earned tax revenue (rewards) and inflation\nwill be split as per the following:\n - 80% of the inflation+rewards going to the stakers who select validators.\n - 10% of the inflation+rewards going to active validators equally.\n -  5% of the inflation+rewards going to the general commons pool with no standalone governance.\n -  2% of the inflation+rewards going to pool for open source blockchain explorer hosting.\n -  2% of the inflation+rewards going to pool for securing open source wallet systems (w/ airgap).\n -  1% of the inflation+rewards going to pool for public relations and growth.\n\nXXX But the % of rewards going to $PHOTON bonders is at least 90%. XXX refactor.\n\nA parameter MIN_STAKER_DISTRIBUTION_FRACTION will be set to 80%, where the\npercent of inflation+rewards going to stakers cannot be lower than this figure.\nChanging this value requires a constitutional majority.\n\nA parameter MIN_VALIDATORS_DISTRIBUTION_FRACTION will be set to 10%, where the\npercent of inflation+rewards going to stakers cannot be lower than this figure.\n\nThe funds held in all the pools above will not be counted toward the bonding\nratio.\n\nThe last three following the pool/treasury will initially go to multisigs set in\nconsensus params of the chain, until they get set as URIs pointing at blockchain\nbased DAOs hosted on ICS1.5. \n\n## Tokenomics\n\nWe opt to replace the market-based \"commission\" system with a flat\ndistribution to all validators, to incentivize the creation of peer validators\n(who should all plan to become data center providers).\n\nThe maximum bounds on the auto-adjust inflation parameter will be set at 20%.\n\nThe inflation will target 2/3 of $ATONE to be bonded. \n\n### ICS Fee Distribution\nEvery ICS zone should be paid for somehow. AtomOne owned ICS shards should be\npaid for from the treasury of AtomOne.  Other ICS \"consumer chains\" can be paid\nfor by the the chain itself, and in emergencies anyone can step in and pay on\nthe zone's behalf.\n\nIn short, every ICS zone should be profitable to every validator.\n\nThe DISTRIBUTION_FRACTION parameter is the fraction (between 0 and 1) of ICS\nshard and consumer chain payments that are shared among the validators equally.\nThis is initially set to 0.8, giving the majority to the validators, and only\n20% as royalty to be paid to $ATONE stakers, with the COMMUNITY_TAX taking its\nportion.\n\n### Staking\n\nThe main difference being introduced is that the total amount of stake going to\none validator doesn't actually increase the validator's power, even though all\nof those staked $ATONEs are at stake should this validator get slashed. This\ncreates a potential exploit opportunity whereby some validators have relatively\nlittle at stake, and 1/3 by total of voting power of those initial validators\nend up causing a double spend attack. To prevent this, overstaking to a\nvalidator will be taxed incrementally with the proceeds going toward general\nrewards.\n\nXXX TODO improve this. Maybe instead there is simply a sqrt(vp) applied to all\nthe voting powers after the original Gaia staking algorithm. You can over-stake\nto a validator but your voting power and returns will be much less, almost\ninverse to the amount of overstaking.\n\nSuppose that 1/3 of the $ATONE stakers are slashed due to a complex double\nspend attack. Assuming that we want to allow the recompensation of victims upon\ndouble spend attacks (within the bounds specified clearly in the constitution)\nonly from the recently slashed $ATONEs, some nonzero portion of the slashed\nstake must be burned to prevent using the double spend attack as a fast way to\nunbond.\n\nIf no victims need to be made whole, then it could be appropriate to burn the\nslashed $ATONEs of the perpetrators. The end result is that the remaining\nstakers own the network, and in a steady state this would result in the price\nof $ATONEs increasing due to the reduced supply, assuming that the confidence in\nand usage of AtomOne hasn't changed; though in perfect theory it should take a\nbit of a hit, at least in proportion to the destruction of the reputation of\nthose validators.\n\nIf victims are to be made whole with slashed $ATONEs, this may require the\nselling of $ATONEs into the market, or result in it, therefore the price of\n$ATONEs will be pushed lower, and the composition of the $ATONE holders mutated\naccording to market conditions.\n\n### $PHOTON the More Deflationary Version of $ATONE\n\nXXX can this be made fully deflationary?\n\nThe only fee token required to be accepted by all shards shall be the $PHOTON\ntoken. This must not change even with a Constitutional Majority as a matter of\ntrust of a preagreed transaction declared in these Founding Documents, except\nto better serve this invariant such as by allowing for an alias or by\nsupporting different denominations of the same underlying $PHOTON. AtomOne\nwill not promote the $ATONE token to be used as a fee token directly, even\nthough it must be supported as a bootstrapping and recovery measure.\n\nWhile the convertibility from $PHOTON to the underlying $ATONE may be managed,\npaused, or throttled by governance of $ATONE with a Constitutional Majority of\nthe $ATONE stakers not including the $ATONE of the $PHOTON bonders, all the\nunderlying $ATONE must be distributable back to $PHOTON holders through a fair\nsystem and all of the $ATONE withdrawn within 20 years starting at any given\nmoment.\n\nRewards from the $ATONE tokens bonded to $PHOTON tokens shall be distributed\nback to $PHOTON as if they were any other $ATONE staked tokens, but they shall\nnot exercise their voting power and instead yield entirely to the other $ATONE\nstaked tokens.\n\nTax will be deducted from these $PHOTON bonded $ATONE rewards as usual just\nlike regular validator staked $ATONE tokens, but unlike the tax burden for\nvalidator staked $ATONE tokens, the tax burden for $PHOTON bonded $ATOM tokens\nshall be capped at 10%. This cap cannot be changed even with a Constitutional\nMajority except by also a two-thirds supermajority from the $PHOTON holders\nwith a prominently announced vote put forth by the AtomOne hub with a voting\nperiod of at least one year, and a quorum threshold of at least 10% of the\ntotal supply of $PHOTON tokens by direct participation where the increased tax\nburden above the 10% must be used for common goods purposes on transparent and\naccountable DAO systems.\n\n$ATONE isn't a monetary token, but a related instrument can serve better as\none.\n\nAuto-staking (staking across all validators proportionally to existing voting\npower) doesn't solve the \"inflation problem\", but it does give a way for people\nwho don't care about staking decisions to make better-than-random staking\ndecisions.\n\nTODO show simplest example that demonstrates slashing.\n\nAuto-staking if done by an external IBC zone, or an individual staker manually,\nwould like any other staking earn the pro-rata revenue and pay the various\ntaxes. So auto-staking per se does not make for a deflationary holding, but it\ncomes with the benefit of automatic diversification.\n\nSince it comes with benefits to the staker (diversification and thus less risk)\nbut it doesn't provide the needed intelligence to AtomOne, it is better for the\nAtomOne hub to provide a standard minimal correct implementation under its\ncontrol, such that it can also regulate it, especially as it relates to control\nover AtomOne governance.\n\nSay when you auto-stake $ATONE through this sanctioned mechanism, you get\n$PHOTON. In order to incentivize the usage of $PHOTON, the AtomOne hub offers a\ntrade that makes $PHOTON deflationary: *non-atom rewards are taxed with an\nimmutable cap, but inflated atoms are not* for $ATONE bonded $PHOTON holders,\nand with the right conversion equation (which adjusts for $ATONE inflation) we\ncan construct a perfectly fixed $PHOTON supply (say of 1 billion $PHOTONs) no\nmatter how many $ATONE bond to $PHOTONs.\n\nShould this \"more monetary\" construction of the fixed supply (\"deflationary\")\n$PHOTON token incentivize a large liquid supply, it becomes more susceptible to\nhostile takeovers, simply because there are more liquid $ATONE staking tokens\navailable in comparison to the total bonded voting power. Therefore for a more\nsecure AtomOne hub we also limit the conversion back from $PHOTON to $ATONE so\nas to make hostile takeovers more expensive.\n\nThe known ways are:\n\n * Widen the gap in bidirectional conversion price between $PHOTON and $ATONE\n   such as by adding a burn premium to for $ATONE -\u003e $PHOTON conversion.\n * Limit the amount of $ATONE that can be released per time period auction.\n * Essentially the same as above with some conversion curve.\n\nIn the case of validator \u0026 delegator $ATONE slashing, $PHOTON holders will of\ncourse also get slashed, but the ratio of $phATOM-bonded $ATONEs and all other\n(non-$phATOM) $ATONEs remains the same. The conversion factor from $PHOTON to\nand from $ATONE will change to correspond with slashing. Any gap manufactured\nbetween the round trip exchange rate (such as via a burn premium one way) is\nindependent of slash events, and is explained in the next section.\n\nThe $ATONEs bonded toward auto-staking do not count toward calculating the\nbonding ratio target of 2/3 in either the numerator or denominator--they are\nignored.\n\nTODO: add benefits over liquid staking and collective \"liquid staking\".\n\nSee also the introductory section \n\n### Create $ATONE / $PHOTON Price Gap\n\nXXX Explain desirability of independence.\nXXX Link to Issues discussion.\n\n## $ATOM \"Liquid Staking\" Service\n\nXXX Explain the goal of Gaia and AtomOne alignment.\n\n### Earn $ATONE or $PHOTON Inflation Rewards\n\nXXX $phATOM holders could be earning $ATONE over time, and this could be the\nprimary method of incentivizing mutual success and value alignment.\n\nXXX Imperfect Analogy: $ATOM is PoW miner, $PHOTON is the reward.\n\nAs an improvement to security, $phATOM holders will earn $PHOTON, with\nmarket-rate $ATONE -\u003e $PHOTON conversion (with all throttling limitations and\npremium charges that may apply). If the demand for $phATOM and $PHOTON is\ngreat then this helps AtomOne influence governance of the hub with the\nintelligence of $ATONE. On the other hand, if the demand is not great, then\nthe $PHOTON to $ATONE conversion is presumably already efficient.\n\nXXX Discussion of inflation schedule, or bounds.\n\nXXX Discussion of touchpoints for governance control.\n\nXXX The earned $ATONE rewards may have some vesting period.\n\n### Parent Chain Failure Insurance\n\n_TODO: discuss further before integration... maybe this isn't wanted._ \n\nIn return for delegating voting decisions from $ATOM bonded $phATOM holders to\n$ATONE stakers, the AtomHub will offer the $phATOM holders the opportunity for\nall perpetuity, the merger of $phATOM to $PHOTON according to a reasonable\nexchange ratio as determined by the best available means as determined by\n$ATONE stakers, with a minimum conversion penalty of 20% and no more favorable\nto $phATOM than 1:2 by total market cap between $phATOM and $PHOTON. For\nclarity this means that upon the failure of Gaia the $phATOM token holders can\ndilute the $PHOTON holders such that $PHOTON holders have as low as 2/3 the\nunderlying $ATONE as before the merge (but no less).\n\nIn the case of Gaia failure this could be seen as a detriment to $PHOTON\nholders because their underlying $ATONE claims from $PHOTON has seemingly\nshrunk by up to half; but if the $ATOM token were to recover it would now be of\nbenefit to $PHOTON holders; and this is an agreement that was pre-established\nin these Founding Documents to support the mutual success of $phATOM and\n$PHOTONto ensure mutual success rather than sabotage. While in the end the\n$ATONE stakers and before that the validators have complete freedom of will,\nhow well they adhere to these founding agreements is left to everyone to\nenforce out of band.\n\nThe conversion penalty may decrease below 20% for $phATOM to $PHOTON merger\nwith a Supermajority of $ATONE stakers.\n\nAtomOne with a Constitutional Majority may decrease the merger ratio cap from\n1:2 (1/3) even down to zero (e.g. to terminate the support of $phATOM) but the\nexecution must be delayed for a period of at least 3 months to allow $phATOM\nholders to preempt this with a merge. Nothing outside of the merge will prevent\n$phATOM holders from being able to redeem their due pro-rata $ATOM tokens for\nall time.\n\nShould the $phATOM be discontinued in support as decided by AtomOne with a\nConstitution Majority (which is NOT signified by a merger ratio cap of 0 by\nitself but must be a separate proposal), the $phATOM holders must be made whole\nby redistributing the underlying $ATOM tokens to their respective $phATOM\nholders completely with the same exchange factors applied to everyone equally,\nbut as with decreasing the merger ratio cap, (for the purpose of giving\nprecedent to the $phATOM -\u003e $PHOTON merge mechanism) this must be delayed by\na period of 3 months to allow $phATOM holders to preempt this with a merge.\n\nAny slashings of the underlying $ATOM, or theft, or loss of $ATOM due to the\nactions of the AtomOne hub and its $ATONE stakers are completely at the risk of\nthe original $ATOM holder who brought it into AtomOne. AtomOne must compensate\nusers within reason, but what is reasonable is up to the $ATONE stakers to\ndecide through AtomOne governance. Everybody must acknowledge the risks of this\nexperiment.\n\nAll other parameters defined here regarding the merger that may negatively\naffect $phATOM holders and $ATOM holders on AtomOne cannot change even with a\nConstitutional Majority.\n\nThere is no merge mechanism for the opposing case upon AtomOne failure. In this\ncase the $ATOM underlying $phATOM must be distributed back to the $phATOM\nholders in proportion, or if there was already a merger, to the $PHOTON\nholders in proportion.\n\nXXX specify the conversion rate before and after the merger both ways.\n\n### Avoid Mixed ATOM+ATONE Liquid Staking\n\nIn an hypothetical alternative model, there could be a three-token AMM system\nwhereby a singular $PHOTON token is backed by both $ATOM and $ATONE, but these\ncan suffer from manipulation; and even with the enforcement of safety bounds\nfor the relative capitalization between $ATOM and $ATONE (such as 2:1 to 1:2)\nthey have the unwanted side effect of additional exposure to unwanted risk. \n\n## AtomOne Governance\n\nUltimately this hub is owned by the $ATONE holders. \n\nWe will prioritize all of these items:\n[github.com/decentralists/DAO](https://github.com/decentralists/DAO/tree/main/governance)\n\nThe constitutional majority threshold is defined by the parameter\nCONSTITUTIONAL_MAJORITY_THRESHOLD initially set to 90%, and requires a\nconstitutional majority to change.\n\nThe constitution itself must be amended by a constitutional majority.\n\n## Milestones\n\nThere are largely four phases to this plan.\n\n### AtomOne Phase 1: Pre-IBC\n\n1. Define Constitution\n2. Governance Fixes\n3. Launch Governance-Only Chain\n4. Implement IBC\n\n### AtomOne Phase 2: Post-IBC\n\n1. $PHOTON with Auto-Staking\n2. Fix Validator Incentives\n3. Implement ICS1.5\n4. Prototypes with SubDAOs (including GNO)\n\n### AtomOne Phase 3: ICS1.5 scaling\n\n1. Migrate $PHOTON to ICS\n2. Promote Smart Contract Use Cases\n3. Develop Scalable Validator Infrastructure\n4. Develop Recovery Procedures\n\n### AtomOne Phase 4: Maintenance\n\n1. Create OnChain Education Curriculum\n2. Promote Good Forks and Projects\n3. Promote Other Common Goods\n4. Finalize the Software\n\nFinalization should not be seen as a thing to avoid, but rather a necessity for\npreserving immutability and thus providing real security benefits.\n\nEveryone who wants something different is given a way to create their own\nvariation to compete and cooperate with the AtomOne hub. We should all be\nfamiliar with this concept, as it is how AtomOne itself was born--by exodus\nfrom Gaia.\n\nIt is possible that what we arrive at is not sufficient in the long run, and\nthat is still OK; the ultimate goal is to be a standard reference, in the very\nleast in relation to an improved fork; a reference that will last a thousand\nyears or more.\n\nIn short, the goal is nothing more than to create timeless code, even knowing\nthat in the end even AtomOne will be phased out, but never forgotten; the\ntemplate will have split into a million different forks and conquered the\nworld. AtomOne Eschatology will be well documented and planned, for a time when\nnobody was around for these early beginnings.\n\n## AtomOne Technical Steering Committee\n\nThe AtomOne Technical Steering Committee (TSC) is a self-mutating organization\nthat is tasked with overseeing the development of the necessary software. It is\nrepresented by ...\n\nXXX AIB, the only thing it can do is invite people; manage the invites.\n\nXXX Do-ocracy; whoever *wants* to make these softwares.\n\nXXX Review process:\n[Proposal: AIB:NO,]\n\nXXX Decentralists: On self-organization and funding...\n\nXXX 3 year term, after 3 years must demonstrate; or otherwise removed.\n\nXXX \n\n----------------------------------------\n\n# AtomOne FAQ\n\n**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.**\n\n----------------------------------------\n# TODO\n\n - [ ] Complete the CONSTITUTION w/ all known functionality\n - [ ] Reconcile this README with CONSTITUTION\n - [ ] Incorporate the \"Constitutional Majority\" in the Constitution.\n - [ ] Move Decentralists governance roadmap here.\n - [ ] Keplr \u0026 Ledger need competition.\n - [ ] Consider referencing https://twitter.com/jaekwon/status/1724641822398681547 with more insight.\n - [ ] Roadmap Timeline\n - [ ] Links to Additional Resources such as technical documentation, or community forums, for in-depth information.\n - [ ] Channels for reaching out to the core team or support, especially for technical support or collaboration inquiries.\n - [ ] Scan through X (formally Twitter) posts for more ideas.\n - [ ] Argument for why hub and spokes are needed (from atom one)\n - [ ] Quantum resistance\n - [ ] Constitution updates: $ATOM -\u003e $ATONE; Add $PHOTON and $phATOM; conversion\n - [ ] At least one week for decentralists feedback on proposals that meet the\n   spam threshold.\n - [ ] Proposals should be self contained no PDF necessary.\n - [ ] TM2 Consensus Court\n - [ ] Subsidize relayers and require payment for every IBC tx.\n - [ ] Fork proves that slashing is real.\n - [ ] Increased Voting Period.\n - [ ] Globally decentralized validator set.\n - [ ] What is a hub? connected zones and shards should use it as such, not\n   make more connections out.\n - [ ] Allow the staking distribution to hone its intelligence via slashing.\n - [ ] Use real human connections to defend against AI.\n - [ ] About diversity of implementation, and its limitations.\n - [ ] Add old PHOTON elements back in if relevant; not counting 2/3 ratio...\n - [ ] Recovery procedure by AtomOne in the case of IBC zone failure.\n - [ ] Recovery procedure by AtomOne in the case of ICS shard failure.\n - [ ] Require the ICF to buy back ATOMs and to allocate them for on-chain disbursement.\n - [ ] Indemnify all actors given no malice outside of the chain. Allow the chain to enforce penalties from outside the chain.\n - [ ] Specify that $ATONE held in pools and bonded for $PHOTON do not count toward the bond ratio.\n - [ ] Add rules for what non-hubs and hubs (separate rules) must abide by. Not all hubs can connect due to this.\n - [ ] XXX\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fatomone-hub%2Fgenesis","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fatomone-hub%2Fgenesis","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fatomone-hub%2Fgenesis/lists"}