├── resources ├── stakingrate.png ├── votes_distribution.png └── ATONE_distribution_x9.png ├── GovGen_Townhalls ├── Meeting6.md ├── Meeting8.md ├── Meeting5.md ├── Meeting3.md ├── Meeting15.md ├── Meeting14.md ├── Meeting10.md ├── Meeting9.md ├── Meeting11.md ├── Meeting4.md ├── Meeting7.md ├── Meeting16.md ├── Meeting13.md ├── Meeting2.md ├── Meeting12.md └── Meeting1.md ├── .github └── CODEOWNERS ├── FORKING.md ├── STAKING_VS_MONEY.zh.md ├── DECENTRALISTS.md ├── GOVERNANCE.md ├── DISCORD.md ├── STAKING_VS_MONEY.kr.md ├── FAQ.md ├── STAKING_VS_MONEY.md ├── STAKING_VS_MONEY.id.md └── STAKING_VS_MONEY.es.md /resources/stakingrate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atomone-hub/genesis/HEAD/resources/stakingrate.png -------------------------------------------------------------------------------- /resources/votes_distribution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atomone-hub/genesis/HEAD/resources/votes_distribution.png -------------------------------------------------------------------------------- /resources/ATONE_distribution_x9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atomone-hub/genesis/HEAD/resources/ATONE_distribution_x9.png -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting6.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 6 Notes - GovGen launches!** 2 | 3 | ### Date: February 27th, 2024, 6:00 AM PST 4 | 5 |
6 | 7 | - Link to the [full transcript here](https://docs.google.com/document/d/1_u5QPbDp0Oe3El2zoPi2gA-n1ARcMPSkzB2SklnmrNM/edit?usp=sharing) 8 | - Link to the [full recording here](https://drive.google.com/file/d/1UL_srKcjjl-Pre17oHVgFaFB4Jg7bo_r/view?usp=sharing) 9 | 10 | **Main action items** 11 | 12 | - Launch 13 | - [Join our Discord](https://discord.gg/atomone) 14 | 15 |
16 | 17 | You can read a synopsis of the existing state of GovGen in this blog post, including that the term for applications has been slightly extended. 18 | 19 | https://allinbits.com/blog/shape-the-future-of-atomone-with-govgen/ 20 | 21 | Brief Summary of Discussion 22 | 23 | - GovGen launches 24 | - Couple validators need assistance getting onboarded 25 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Documentation for CODEOWNERS: 2 | # https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners 3 | 4 | # Default owner for all files in the repository, unless overridden by a specific rule below. 5 | * @jaekwon @giunatale 6 | 7 | # Specific file/dir ownership 8 | /.github/ @moul 9 | /README.md @jaekwon 10 | /CONSTITUTION.md @jaekwon 11 | /DECENTRALISTS.md @jaekwon 12 | /GOVERNANCE.md @giunatale @jaekwon 13 | /FORKING.md @moul @jaekwon 14 | 15 | # i18n 16 | *.fr.md @moul @tbruyelle 17 | *.it.md @giunatale 18 | 19 | # XXX: Pending Ownership Assignments 20 | # The CODEOWNERS file will be invalid if it lists users without write permissions to the repository. 21 | # Once the necessary permissions are granted and protected branches are set up, these lines can be uncommented. 22 | # /COMPENDIUM.md @salmad3 23 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting8.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 8 Notes** 2 | 3 | ### Date: March 19th, 2024, 10:00 AM PST 4 | 5 |
6 | 7 | - Link to the [full transcript here](https://docs.google.com/document/d/1E859eTWTqtPyQNNss9Pu6V948_pMMGXCgb37yq76CyE/edit?usp=sharing) 8 | - Link to the [full recording here](https://drive.google.com/file/d/1RoO4DzUA77uRDbxBWwqMw4hyNeJ7LAtW/view?usp=sharing) 9 | - Link to the [full message log here](https://docs.google.com/document/d/1iJw11NzkvK7gdgmIYENQ_8DhGHAOQPrgn1dbWSiad00/edit?usp=sharing) 10 | 11 | **Main action items** 12 | 13 | - Contribute to the [Constitution](https://github.com/atomone-hub/genesis/blob/a9b9d9d5a2440fb623d3bad3c672ae4754377b00/CONSTITUTION.md) 14 | - Contribute to the [issue consolidating ideas for the Constitution](https://github.com/atomone-hub/genesis/issues/136) 15 | - [Join our Discord](https://discord.gg/atomone) 16 | - [Help Define ICS](https://github.com/atomone-hub/genesis/issues/66) 17 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 18 | 19 |
20 | 21 | **Brief Summary of Discussion** 22 | 23 |
24 | 25 | - Engineering updates on latest state of distribution prop draft: https://github.com/atomone-hub/govgen-proposals/pull/5 26 | - Distribution proposal companion doc (and code): https://github.com/atomone-hub/govbox/blob/master/PROP-001.md 27 | - All tools, scripts and code stuff for GovGen proposals (e.g. snapshots analysis code, prop 001 code) now available at https://github.com/atomone-hub/govbox 28 | 29 | - The majority of the rest of this call was a discussion on the distribution draft proposal and whether non stakers and non voters should be slash or penalized. 30 | - Some community members made the point that those that don’t stake or vote should get less distribution than even those who voted yes because at the least they participating in the governance system to begin with and many seemed to be in agreement. 31 | - Further discussion on whether individual voters should be treated differently than those who inherited a vote via delegation. 32 | - Commentary on defining “ICS 1.5” which can be further elaborated upon in this issue "Defining ICS 1.5": https://github.com/atomone-hub/genesis/issues/66#issuecomment-2006912939 33 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting5.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 5 Notes** 2 | 3 | ### Date: February 26th, 2024, 6:00 AM PST 4 | 5 |
6 | 7 | - Link to the [full transcript here](https://docs.google.com/document/d/1W59eqPi4Qudgya4MgDHxircPZZEt8MrEEfdD-qxO-T0/edit?usp=sharing) 8 | - Link to the [full recording here](https://drive.google.com/file/d/18w3G0NMVyot4kxlVUHYJAM4S33HgAj-R/view?usp=sharing) 9 | 10 | **Main action items** 11 | 12 | - Launch 13 | - [Join our Discord](https://discord.gg/atomone) 14 | 15 |
16 | 17 | You can read a synopsis of the existing state of GovGen in this blog post, including that the term for applications has been slightly extended. 18 | 19 | https://allinbits.com/blog/shape-the-future-of-atomone-with-govgen/ 20 | 21 | **Suggested Talking Points** 22 | - Validator Onboarding Process & Timeline 23 | - The initial communicated deadline for submission was Friday, February 23, at 5 p.m. PST (Saturday, 1 a.m. UTC). However, the term has been extended until Saturday, February 24, at 5 p.m. PST (Sunday, 1 a.m. UTC). 24 | - Technical Updates and Governance Discussions 25 | - errata corrige: [PR 7](https://github.com/atomone-hub/govgen/issues/7) is superseded by [PR 20](https://github.com/atomone-hub/govgen/issues/20): validators are allowed to vote in governance, but delegations won't count there, and validators can vote on proposals only using self-stake. Block production/tendermint voting power distribution/staking will work regularly though. 26 | - GovGen v1.0.0 released: https://github.com/atomone-hub/govgen/releases/tag/v1.0.0 27 | - PR for final genesis that collects `gentxs` ready: https://github.com/atomone-hub/govgen-genesis/pull/3 28 | - validator accounts that do not exist in genesis distribution are funded with 25 $GOVGEN (self-stake is 1 $GOVGEN) 29 | - validator accounts that have balance less than 25 $GOVGEN are also topped off to fund operations 30 | - final genesis link will be available both at https://github.com/atomone-hub/govgen-genesis and https://github.com/atomone-hub/validator/tree/main/govgen-1 as soon as complete. 31 | - Initial staking distribution: we want validators to have some delegations on block 0. For this we decided on the following numbers, which can be discussed: 32 | - select accounts with balance > 25 $GOVGEN 33 | - stake 50% of that balance to validators with a fair distribution that results in more or less equal power to all genesis validators. 34 | 35 | With the current genesis, that will stake 33,883,315 govgen, which makes an initial staking ratio of ~49% (total supply is 68,336,631 govgen). We are working on the algorithm to distribute this stake evenly among the validators. 36 | - questions: 37 | - fee and validator setup discussion and recommendations 38 | - final review of genesis parameters: 39 | - x/gov: are pass threshold, quorum, deposits and voting periods OK? 40 | - any other param to discuss/change? 41 | - First Proposals for GovGen 42 | - Cover any questions 43 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting3.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 3 Notes** 2 | 3 | ### Date: February 13th, 2024 4 | 5 |
6 | 7 | - Link to the [full transcript here](https://docs.google.com/document/d/1Hbik8V_yIBN6qVugGpLgoTY_iJ00ClZ85rB9Bot3vco/edit?usp=sharing) 8 | - Link to the [full recording here](https://drive.google.com/file/d/1MRC8Ky_Y92ktrL3Jr813J9E4FTLnCJa2/view?usp=sharing) 9 | 10 | **Main action items** 11 | 12 | - If you're interested in becoming a validator, make a PR on the [validator directory](https://github.com/atomone-hub/validator) following the process listed on there. 13 | 14 | - Take a look at this code for [GovGen Genesis Creation](https://github.com/atomone-hub/govgen-genesis) and the [GovGen Chain Software](https://github.com/atomone-hub/govgen), submit an issue if you have something you want to bring up. 15 | 16 | - [Join our Discord](https://discord.gg/atomone) 17 | 18 |
19 | 20 | **Brief Summary of Discussion** 21 | 22 |
23 | 24 | Technical Updates and Governance Discussions: 25 | - Distribution is 1:1 with No and NWV voters, initial distribution will probably be ~ 68m million GovGen tokens 26 | - GovGen will have a few changes from the starting point of the fork of Cosmos Hub: 27 | 28 | - GovGen is non-transferable 29 | - Inflation Disabled 30 | - Community tax, proposer reward and bonus all set to 0 31 | - Deposit raised to 5000 GovGen 32 | - Voting period suggested to be extended to 365 days, discussion followed on different voting periods for different types of proposals, specifically for software upgrades, changing parameters. Conversation followed some consensus with talks about voting incentives then shut down. 33 | - Vote threshold set to 2/3 34 | - Quorum raised to 50% 35 | - Validators tentatively reduced to 30 36 | - Standard SDK v14.1 without the liquid-staking module 37 | - IBC module removed 38 | - ICS module removed 39 | - Spam prevention changed to 1% of initial deposit by proposer 40 | - GovGen will probably skip the testnet phase. 41 | 42 | - Discussion on whether distribution should go to all Atom Holders / stakers with the exception of slashing Yes Voters 43 | - Discussion on distribution going to CEXes, could be beneficial but will ultimately need to be voted on by Govgen 44 | - Discussion on timeline of GovGen, ideally by Q1 for GovGen, AtomOne dependent on community vote from GovGen 45 | - Discussion on KYC, ideally a decentralized non-date-broker option 46 | 47 | - Validator Onboarding Process 48 | - Part of the conversation focused on onboarding validators, discussing criteria, documentation and verification steps. 49 | - Some discussion on who will handle evaluation for GovGen validators, no conclusion as we may not have more than 30 50 | - Some discussion on what will happen if there's more than 30 validators, potentially expand validator set 51 | 52 | - Governance Mechanisms and Validator Requirements 53 | - Discussion on how to proceed with multiple choice proposals 54 | - Only allowing tokens staked at the time of a proposal 55 | 56 | - Conclusion 57 | - Covered Action Items 58 | 59 | **Suggested talking points** 60 | 61 | - Validator Onboarding Process 62 | - Technical Updates and Governance Discussions 63 | - Governance Mechanisms and Validator Requirements 64 | - Chain Architecture and Documentation 65 | - Governance Model and Community Involvement 66 | - Validator Rewards 67 | - Governance Policies and Tokenomics 68 | - KYC Processes and Regulatory Considerations 69 | - Governance Structures and Meeting Scheduling 70 | 71 |
72 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting15.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 15 Notes** 2 | 3 | ### Date: Date: September 11th, 9am PST 4 |
5 | 6 | 7 | **Main action items** 8 | 9 | Review and provide feedback to: 10 | 11 | - [AtomOne Constitution](https://commonwealth.im/govgen/discussion/24814-atomone-constitution-proposal) 12 | 13 | - [AtomOne Tokenomics](https://commonwealth.im/govgen/discussion/24801-atomone-tokenomics) 14 | 15 | - [AtomOne Roadmap](https://commonwealth.im/govgen/discussion/24800-atomone-roadmap) 16 | 17 | - [AtomOne Software](https://commonwealth.im/govgen/discussion/24802-cosmos-softwares-versioning) 18 | 19 | - [ATONE Distribution](https://commonwealth.im/govgen/discussion/24799-equitable-atone-distribution-in-the-spirit-of-atomones-founding-principles) 20 | 21 | Considering checking your potential allocation at: 22 | 23 | - [Airdrop checker](https://govgen.io/#trackers) 24 | 25 | If you are capable of something a bit more technical, be sure to explore our Grants and Bounties Program 26 | 27 | - [AiB Grants and Bounties Program](https://github.com/allinbits/grants/tree/main/AiB-BUIDL-Grants-and-Bounties-program) 28 | 29 |
30 | 31 | Brief Summary of Discussion 32 | 33 | - The proposed AtomOne project has made significant progress with Phase -1 now complete, and the first code-freeze approaching in a few weeks. 34 | - Key milestones include the publication of the AtomOne Roadmap, Tokenomics, ATONE Distribution, Software Versioning and the AtomOne Constitution (September 9th) on the GovGen Forum for community feedback. 35 | - Feedback will be collected until September 13th for the first four proposals, and until September 16th for the Constitution. On-chain voting for these proposals should begin on September 13th and September 16th, respectively, with a proposed 10-day voting period. 36 | - The GovGen dApp will launch on September 13th to streamline governance interactions, and the initial code-freeze for AtomOne is set for September 26th. The community is encouraged to participate by providing feedback, voting on proposals, and preparing for validator roles as AtomOne approaches its launch. You can find all of the proposals linked above in the *Main action items* section 37 | - Please reference the [document shared during the meeting for further details on this](https://docs.google.com/document/d/1cxkJic7_i0XODNcF5_gFlu0KaxcIDmsckpHfjRK75DQ/edit?usp=sharing) 38 | - After moving on from the text document giving a signicant update on the timeline, the session turned into more of a discussion format with people asking questions and giving suggestion. 39 | - The meeting moved onto discussions about validator elections, governance, and technical updates. 40 | - There was consensus around separating validation from governance, noting that validator sets often become bureaucracies. Worth noting that the Constitution provided a solution for alot of the concerns in validator power, so worth checking out the the Validator section in the AtomOne Constitution. 41 | - Participants also addressed the challenges of decentralized governance, like coordination costs and dissemination of proposal information. 42 | - There was a suggestion on implementing multiple-choice voting for proposals, but there were a few objections on the decision making that led to that possiblity on the CosmosSDK 43 | - The meeting started wrapping up and touched on communication platforms, with opinions on using Commonwealth over forums. 44 | - It concluded with a mention of the upcoming AtomOne logo and inviting people to participate in creating their own version which could potentially be submitted on the AtomOne chain. 45 | - Note that you can check your potential allocation assuming all the existing distribution proposal moves forward [here](https://govgen.io/#trackers) 46 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting14.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 14 Notes** 2 | 3 | ### Date: Date: July 23rd, 9am PDT 4 |
5 | 6 | - Link to the [full transcript](https://docs.google.com/document/d/1RV7kyg0bnKoMlWOnsnXY16mC8EM_lEkwI54O32vSE_k/edit?usp=sharing) 7 | - Link to the [full recording](https://drive.google.com/file/d/1pL-l5rsHVdlMw2vsxOkw7_tGOVtocwlA/view?usp=sharing 8 | ) 9 | - Link to the [full message log](https://drive.google.com/file/d/1brMmpqfaQCbpdvGOs_EWLvebQSvwn3yT/view?usp=sharing) 10 | 11 | 12 | **Main action items** 13 | 14 | - Review and discuss the [proposed AtomOne Roadmap](https://docs.google.com/document/d/1IngHTASov5E8qEJfRY1ONYuBtOcC7a2vDGVfTG2KjK8/edit?usp=sharing) 15 | - [Join our Discord](https://discord.gg/atomone) 16 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 17 | 18 |
19 | 20 | **Brief Summary of Discussion** 21 | 22 | - #### Security Updates 23 | - Internal security audits complete for GovGen and Governance dApp 24 | - Governance dApp 3rd party audit complete, will be sharing final report via GitHub repo 25 | - Bug bounty updates 26 | - [GovGen dApp](https://hackenproof.com/all-in-bits/govgen-governance-dapp) 27 | - [GovGen Binary](https://hackenproof.com/all-in-bits/govgen) 28 | - Making infrastructure security improvements to Govgen Governance dApp 29 | - Launched private bounty program on popular platform Hackerone. Please contact us for invites. Will launch publicly after infra updated. 30 | - 1x high-severity bounty awarded via HackerOne 31 | - Q's? 32 | 33 | 34 | - #### Proposed AtomOne Roadmap Discussion 35 | - After the security updates, the conversation steered into reviewing the [proposed AtomOne Roadmap](https://docs.google.com/document/d/1IngHTASov5E8qEJfRY1ONYuBtOcC7a2vDGVfTG2KjK8/edit?usp=sharing) 36 | - Phase -2: Talks about preparation of the mainnet, drafting documents, the Constitution 37 | - Phase -1: The final point of Phase -1 is to complete the burn mechanism between atone and Photon, simplifying the process so that Photon is obtained by burning atone. The number of Photons, capped at 1 billion, will be exchangeable based on the atone supply. 38 | - Phase 0: The actual launching of the chain with minimal changes to the existing design, disabling ICS and IBC functionalities. Conversation noted significance in ratifying all governance documents and ensuring transparency in storing the Constitution, laws, and charters. 39 | - Phase 1: In Phase 1, the focus is on implementing governance improvements, Photon’s utility, IBC improvements, and security measures. The burn mechanism from Atone to Photon will be enabled, with Photon being the fee token for transactions. The activation of the DAOs, ensuring transparency and clear processes, will also take place. 40 | - Phase 2: Phase 2 will address ICS mechanics and incentives to fix the low Nakamoto coefficient, possibly by tuning rewards based on validator dominance. A grant program will be introduced for community participation. Additionally, there will be the creation of other treasury DAOs. 41 | - The roadmap, designed to bring stability and confidence to the steps needed is subject to change based on project needs. Community involvement and feedback are encouraged to ensure the roadmap reflects collective goals. The draft of the proposed Constitution will be shared soon, providing comprehensive details about the project's elements and their relationships. 42 | - Participants were reminded to follow updates on Twitter and Discord, and to provide feedback on the roadmap once posted. The community was assured that adequate time would be given for review, considering vacation periods. 43 | - The meeting concluded with thanks for the time and participation, expressing anticipation for the next town hall to potentially discuss the Constitution. 44 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting10.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 10 Notes** 2 | 3 | ### Date: April 2nd, 2024, 9am PST 4 |
5 | 6 | - Link to the [full transcript here](https://drive.google.com/file/d/1TyyUK5DNtzyWkme7kX2GsbsocJ3_JONf/view?usp=sharing) 7 | - Link to the [full recording here](https://drive.google.com/file/d/1_LhpR0A-ZteNzpoHWntJ1s8yoxPqcqch/view?usp=sharing) 8 | 9 | **Main action items** 10 | 11 | - Please fill out this [form](https://docs.google.com/forms/d/e/1FAIpQLSe95o3gDCaeF8UoTaIxQ9MB1NdWPqCO19pn7PjG16v6OD2yNg/viewform) if you are interested in contributing to the [Constitution](https://github.com/atomone-hub/genesis/blob/a9b9d9d5a2440fb623d3bad3c672ae4754377b00/CONSTITUTION.md) 12 | - Contribute to the [issue consolidating ideas for the Constitution](https://github.com/atomone-hub/genesis/issues/136) 13 | - [Join our Discord](https://discord.gg/atomone) 14 | - [Help Define ICS](https://github.com/atomone-hub/genesis/issues/66) 15 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 16 | 17 |
18 | 19 | **Brief Summary of Discussion** 20 | 21 | Distribution of the first proposal has been finalized, it was presented and all attendees seemed to be in agreement or satisfied with the changes made, check the specifics in the notes here: 22 | 23 | - Engineering updates: 24 | - Updates on $ATONE distribution: given last Townhall discussions, we 25 | investigated on higher multipliers for the No voters, and it appears that the 26 | x9 multiplier is the best fit for our case because: 27 | - No Voters get more than 60% of the supply 28 | - Yes voters get 1/3 of their initial part of the supply 29 | - Here is the general bar chart that shows the votes distribution with No 30 | multipliers from x4 to x10: 31 | ![votes distribution](/resources/votes_distribution.png) 32 | - Here is a more detailled pie chart of the $ATONE distribution for the x9 33 | multiplier: 34 | ![$ATONE distribution x9](/resources/ATONE_distribution_x9.png) 35 | - All the charts are visibles [here](https://atomone-hub.github.io/govbox/). 36 | 37 | - 'How to Submit Transactions Securely' guide has been merged and is available 38 | [here](https://github.com/atomone-hub/govgen-proposals/blob/main/submit-tx-securely.md) 39 | 40 | 41 | - MVP of the governance dApp has been completed and mainnet deployment is being scheduled. 42 | 43 | - We intend to make significant progress on the constitution this month, beginning with remote meetings to determine participation. We aim to distribute a brief application form for interested individuals to submit later this week. 44 | 45 | - Some attendees show interest in participating in the constitution calls and many verbalize agreement that they should be filtered down into smaller calls. 46 | 47 | - Attendees express enthusiam about how transparent and effective the Townhall calls are in conjunction with the GitHub repository to stay aligned with community. 48 | 49 | - A couple UI suggestions were made to filter everything into folders that Trevor of the governance dApp picked up on to potentially implement into their dApp 50 | 51 | - Some questions are covered on what the goal of AtomOne is, a minimial permissionless ICS hub 52 | 53 | - Converation ensues about a suggestion to slash or penalize those who aren't voting in AtomOne 54 | - Some points are made about how incentive works better than punishment, someone suggests that your vote should weigh more than longer you are staked 55 | - Consider the possibility of delegating to non-validators 56 | 57 | - A long conversation follows when an attendee proposes a multi-token approach to divide voting power from economic security however, 58 | - Many quickly point out there could be some issues with this sort of structure 59 | - Another attendee references some studies that were ran to disprove this system 60 | 61 | - Another attendee points to a different model where different proposals have differing weights 62 | -------------------------------------------------------------------------------- /FORKING.md: -------------------------------------------------------------------------------- 1 | # Forking Guide 2 | 3 | > "The secret of change is to focus all of your energy, not on fighting the old, 4 | > but on building the new." - Socrates. 5 | 6 | In a similar fashion to the CONTRIBUTING.md, the FORKING.md file helps people 7 | understand when and how they should fork. This isn't a common practice, so let's 8 | dive into the specifics. 9 | 10 | For context, you can refer to this issue: [Proposal: ‘How-to-Fork’ Guide #64](https://github.com/atomone-hub/genesis/issues/64). 11 | 12 | ## What is this repository about? 13 | 14 | This 'genesis' repository is about branching (which is like forking software but chains and communities), 15 | specifically forking and branching cosmoshub-4 aka Gaia. The primary objective here is to help people switch from the perception 16 | that forking and branching is necessarily bad, to the understanding that it could be useful 17 | and eventually the best thing to do. 18 | 19 | Forking and branching are not necessarily about competition with the original. 20 | It can also be about exploring alternative paths that could potentially merge or be used in 21 | parallel. A fork or branch is also, by nature, something that can fail and just be an 22 | experiment. But even in failure, the goal is to learn lessons. 23 | 24 | Forking and branching are not necessarily bad, but the goal is to avoid making bad ones. We 25 | aim to optimize the forking and branching processes to maximize chances of success and efficiency. 26 | 27 | This repository was created with the expectation that it will be forked, a lot, 28 | and probably recursively with many descendants. 29 | 30 | ## What to Fork or Branch? 31 | 32 | You can fork the software of a chain, or more broadly you can branch the chain itself 33 | (with the same software, or with a fork of the software, or even a different choice of 34 | the software altogether; but always with some meaningful subset of the original community 35 | and token distribution, and possibly with new external members and air-drops included). 36 | When the chain branches itself, they need to have a plan; this repo is that emergent plan 37 | to fork and branch Gaia to AtomOne. You can also fork this genesis repository to propose 38 | an alternative plan. 39 | 40 | Once our Founding Documents and Plan are finished, the goal is for blockchain(s) to be run using 41 | those documents. The Plan is intended to become finished at some point, so those who want to 42 | change the plan must either get a Constitutional Majority to update the Plan and perhaps 43 | other parts of the Founding Documents including the Constitution; or they must create a new branch 44 | of AtomOne (or Gaia) and they can do so by first forking this repository. 45 | 46 | ## Why to Fork this Repo? 47 | 48 | You can fork this genesis repository for multiple reasons: 49 | 50 | 1. **Contributing:** If you want to contribute to the development of this 51 | project, forking is the first step. 52 | 2. **Maintaining a branch:** You might want to maintain a branch for an 53 | alternate plan for a fork of gaia in the spirit of this repository. 54 | 3. **Splitting another project:** If you want to discuss the genesis of a split 55 | for another project. 56 | 57 | ## How to Fork? 58 | 59 | If you want to fork this repo, make sure: 60 | - the vision/mission statements and the development/growth/maintenance plans in 61 | the README are substantially different (you should explain why the fork is 62 | needed). 63 | - Branding, trademark, tickers also need to be unique. 64 | - XXX 65 | 66 | ### About Trademark Terms and Token Names 67 | 68 | GovGen may be used for any chain, if it is preceded by your chain's name, such as 69 | "Osmosis GovGen". Likewise "Osmosis GovGenA" to include abstainers, is acceptable. 70 | 71 | AtomOne and Atone, and $ATONE are reserved for the AtomOne branch of Gaia. Unless 72 | you are proposing a contribution to the github.com/atomone-hub/genesis repository, 73 | please choose distinct names for your project name, repo, and token. 74 | XXX 75 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting9.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 9 Notes** 2 | 3 | ### Date: March 26th, 2024, time TBD 4 |
5 | 6 | - Link to the [full transcript here](https://docs.google.com/document/d/18sf3QUJ-FA-CSgPyG3ulB95_MiLC4TnsVVlJApQMC7U/edit?usp=sharing) 7 | - Link to the [full recording here](https://drive.google.com/file/d/1DPPRUEkSim5b1kdBmgCbISBbnJOvbjua/view?usp=sharing) 8 | - Link to the [full message log](https://drive.google.com/file/d/1pQcrnr6KMZ17L6LMlLDAMDhm4RHx6Q0L/view?usp=sharing) 9 | 10 | **Main action items** 11 | 12 | - Contribute to the [Constitution](https://github.com/atomone-hub/genesis/blob/a9b9d9d5a2440fb623d3bad3c672ae4754377b00/CONSTITUTION.md) 13 | - Contribute to the [issue consolidating ideas for the Constitution](https://github.com/atomone-hub/genesis/issues/136) 14 | - [Join our Discord](https://discord.gg/atomone) 15 | - [Help Define ICS](https://github.com/atomone-hub/genesis/issues/66) 16 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 17 | 18 |
19 | 20 | **Brief Summary of Discussion** 21 | 22 |
23 | 24 | - Distribution of this first proposal has changed, check the notes here: 25 | 26 |
27 | 28 | - Engineering updates on latest state of distribution prop draft: https://github.com/atomone-hub/govgen-proposals/pull/5 29 | - We took into account the community feedback regarding the previous 30 | distribution, especially the fact that non-voters (including abstrainers) 31 | had too much of the supply (61%). As a result we replaced the blend 32 | formula with an other formula that ensures the non-voters don't get more 33 | than 33% of the supply. 34 | - In addition, we decided to apply a 0.1 decimation factor to the entire 35 | supply. 36 | 37 | | | TOTAL | DID NOT VOTE | YES | NO | NOWITHVETO | ABSTAIN | NOT STAKED | 38 | |-----------------------|-------------|--------------|------------|------------|------------|------------|-------------| 39 | | $ATONE Distributed | 48,503,137 | 5,247,961 | 6,374,676 | 21,340,439 | 4,791,114 | 2,849,864 | 7,899,084 | 40 | | Percentage over total | | 11% | 13% | 44% | 10% | 6% | 16% | 41 | | | | | | | | | | 42 | | $ATOM prop848 | 342,834,268 | 66,855,758 | 70,428,501 | 55,519,213 | 11,664,818 | 35,679,919 | 102,686,059 | 43 | | Percentage over total | | 20% | 21% | 16% | 3% | 10% | 30% | 44 | | | | | | | | | | 45 | | Old $ATONE Distr. | 809,415,611 | 158,897,406 | 63,746,761 | 213,404,392 | 47,911,135 | 86,287,988 | 239,167,930 | 46 | | Percentage over total | | 20% | 8% | 26% | 6% | 11% | 30% | 47 | 48 | - Distribution proposal companion doc (and code): https://github.com/atomone-hub/govbox/blob/master/PROP-001.md 49 | - Added details on the new formula mentioned above 50 | - Long discussion ensues regarding the validity of the new distribution, including some comments on abstain votes, no/nwv distribution to be upped a bit and concession on the not staked and not voted voters. 51 | - There’s a note brought up that this is the first proposal for distribution and changes can happen over the lifespan of GovGen, every proposal is intended to measure sentiment so 52 | - Vladimir of Post Human shares a demonstration of their work on a [governance interface](https://proposals.posthuman.digital/) allowing you to create text proposals with some comments on including different types of proposal in the future. 53 | - Alex gives a presentation of the feature set of the [GovGen](https://govgen.io/) governance dApp, including sorting proposals, GitHub discussions integration to allow convenience in following discussions per proposal and touching on some intended features 54 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting11.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 11 Notes** 2 | 3 | ### Date: April 9th, 2024, time TBD 4 |
5 | 6 | - Link to the [full transcript here](https://docs.google.com/document/d/1JbXFwhQO0TKrRUlx1dOyG_bb0qPFCckHSr4GGx4W19Q/edit?usp=sharing) 7 | - Link to the [full recording here](https://drive.google.com/file/d/1SyXDFICaa81w00aHvp3OdsgCygKGm5zJ/view?usp=sharing) 8 | - Link to the [full message log](https://drive.google.com/file/d/1IR4GtMDLKDZYZzUK7g_3-vBjo3kV0RL3/view?usp=sharing) 9 | 10 | 11 | **Main action items** 12 | 13 | - Sign up for the constitution calls by filling out this [form](https://forms.gle/W8vXbcL1NSqqpotL8) 14 | - Contribute to the [Constitution](https://github.com/atomone-hub/genesis/blob/a9b9d9d5a2440fb623d3bad3c672ae4754377b00/CONSTITUTION.md) 15 | - Contribute to the [issue consolidating ideas for the Constitution](https://github.com/atomone-hub/genesis/issues/136) 16 | - [Join our Discord](https://discord.gg/atomone) 17 | - [Help Define ICS](https://github.com/atomone-hub/genesis/issues/66) 18 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 19 | 20 | **Notice** 21 | 22 | - Townhall restarts on the 23rd of April with a bi-monthly cadence. 23 | - Constitution calls start on the 30th of April, with a bi-monthly cadence. 24 | - We will still have a Govgen call every week but with different talking points. 25 | - We are extending the form sign-ups until the 20th of April. 26 | - We will be using the data from the form to pick a timeslot (or 2) for the Constitution calls 27 | 28 |
29 | 30 | **Statement** 31 | 32 | We are pleased to announce that the AtomOne draft distribution proposal is now finalized and available for community review. You can access it [here](https://github.com/atomone-hub/govgen-proposals/blob/main/001_ATONE_DISTRIBUTION.md) 33 | 34 | In accordance with best practices, we are currently focused on completing rigorous code audit processes for both the GovGen dApp and the GovGen chain binaries. To this end, we are working to ensure that all necessary measures are in place for a secure code release process. 35 | 36 | Based on our current progress, we anticipate this process to be concluded within the next three weeks. 37 | Once this is completed, we plan to proceed with the deployment of the GovGen dApp followed shortly after by the release of the AtomOne draft distribution proposal on chain. 38 | 39 | Your ongoing contribution and commitment are greatly appreciated as we navigate through these final stages. 40 | 41 |

42 | **Brief Summary of Discussion** 43 | 44 | This call was relatively short with a pending need to audit the AtomOne draft distribution. The Proposal is to go live after auditing for the signing process has happened 45 | 46 | There was some discussion on a need for a disclaimer on the binary within the repo which some engineers offered to implement. 47 | 48 | The majority of the call is focused on the signing process and the auditing process that needs to be finished before the proposal can be put on chain. 49 | 50 | Further discusson on repeatable deterministic builds and being able to build it using Go 1.21 51 | 52 | Last minute suggestion to split the constitution calls into seperate working groups. 53 | 54 | 55 |
56 | **Other suggested talking points** 57 | 58 |
59 | 60 | - Further conversation on Defining "ICS 1.5": https://github.com/atomone-hub/genesis/issues/66#issuecomment-2006912939 61 | - Further conversation on what the relationship between Photon Atom vs Photon Atone might look like, to be discussed as a community over the coming weeks. 62 | 63 | - Urgencies in constitution for minimal working draft to move forward such as, 64 | - How exactly to reform governance 65 | - Remove NWV or remove delegations altogether 66 | - Remove validator commission, include fixed rate 67 | - Validator distribution 68 | - Validators have machines onsite, i.e no white labels, no AWS 69 | - Validators should declare conflicts of interest 70 | - Should not roll out fixes that validators don't understand 71 | - If anything to be added to constitution, should be unchallenged for a given term (3 months?) 72 | - Potentially funding multiple teams of leading developers to compete to build ICS 73 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting4.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 4 Notes** 2 | 3 | ### Date: February 20th, 2024, 10:00 AM PST 4 | 5 |
6 | 7 | - Link to the [full transcript here](https://docs.google.com/document/d/1qM0-xYqBg3KqIV0cQD353Axa31BBdeoR6cq1igsJB1g/edit?usp=sharing) 8 | 9 | - Link to the [full recording here](https://drive.google.com/file/d/1jJOYRJyz3ebX4-LK06d8fUsHEsTIm9we/view?usp=sharing) 10 | 11 | **Main action items** 12 | 13 | - If you're interested in becoming a validator, make a PR on the [validator directory](https://github.com/atomone-hub/validator) following the process listed on there. Please submit your GenTx into the validators' repo following this readme [insert GenTx readme] 14 | 15 | - Take a look at this code for [GovGen Genesis Creation](https://github.com/atomone-hub/govgen-genesis) and the [GovGen Chain Software](https://github.com/atomone-hub/govgen), submit an issue if you have something you want to bring up. 16 | 17 | - [Join our Discord](https://discord.gg/atomone) 18 | 19 |
20 | 21 | **Brief Summary of Discussion** 22 | 23 | - Validator Onboarding Process & Timeline 24 | - Tuesday, 20th Feb- publish the Genesis - link is up in the [README.md](https://github.com/atomone-hub/govgen-genesis/blob/main/README.md#genesis-download-link) of https://github.com/atomone-hub/govgen-genesis 25 | - Friday 23rd, 5PM PST- validators submit your Gentx cut off time 26 | - GovGen launch - Tuesday 27th, 6 am PST 27 | - Technical Updates and Governance Discussions 28 | - Working on x/gov changes as discussed in last townhall ([GitHub EPIC](https://github.com/atomone-hub/govgen/issues/6)) 29 | - Forked x/gov to implement discussed modifications 30 | - https://github.com/atomone-hub/govgen/pull/4 31 | - https://github.com/atomone-hub/govgen/pull/9 32 | - Remove ability for validators to vote 33 | - https://github.com/atomone-hub/govgen/pull/10 34 | - Allow different voting periods for different types of proposals 35 | - https://github.com/atomone-hub/govgen/pull/16 36 | - Updated base genesis to reflect software changes 37 | - https://github.com/atomone-hub/govgen-genesis/pull/1 38 | - 365 days voting period for text, 14 days for parameter change and 28 days for software upgrade 39 | - Potential discussions: 40 | - [refund text proposal deposit before the end of the voting period](https://github.com/atomone-hub/govgen/issues/8) 41 | - [consider disallowing validator vote on text proposal only](https://github.com/atomone-hub/govgen/issues/15) 42 | - Discussion on rationale for constitutional chain, included diving into the topic of Atom inflation in relation to proposal 848 43 | - A couple references to [$ATOM Must NOT be Money](https://forum.cosmos.network/t/proposal-set-max-inflation-at-10/11841/240?u=aib) 44 | - Discussion on intricacies of calculating rewards from staking tokens and points made against treating them solely as income for tax purposes. 45 | - Discussion on majority of rewards being more akin to token splits 46 | - Discussion on current tax guidance and efforts to communicate with regulators about the unique nature of staking tokens. Emphasis on the importance of resolving these issues for the security and functionality of blockchains, drawing parallels with corporate shares as a control mechanism. 47 | - Discussion on validator rewards model where validators are paid equally to promote decentralization and efficiency. Jae also acknowledges the need to address flaws in the current incentive mechanism of the Cosmos Hub including the need to change the incentive model for validators to ensure their participation in all ICS chains. 48 | - The conversation delves into the political dynamics within the Cosmos ecosystem, with discussions on the dominance of certain parties and the need for more competition, with suggestions of creating a new political party to counterbalance existing power structures, i.e "Stride" and hence, "AtomOne. 49 | - The discussion also touches on the role of ICS in scaling consumer chains and the potential limitations of targeting specific customers like Stride. 50 | - Discussion continues into the purpose of ICS and the need for scalability in blockchain ecosystems, highlighting the importance of usability and programming languages in smart contract platforms. 51 | - The discussion concludes with plans for validator applications and the upcoming GovGen launch. 52 | 53 | 54 |
55 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting7.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 7 Notes** 2 | 3 | ### Date: March 12th, 2024, 11:00 PM PST 4 | 5 |
6 | 7 | - Link to the [full transcript here](https://docs.google.com/document/d/11i9BY3Vo6GGLlv9DmM7T0LDPS8ufRchMiqmmF_Kyuco/edit?usp=sharing) 8 | - Link to the [full recording here](https://drive.google.com/file/d/1w1SIscLxnN1FzOdclheFq0GL9ePXCb2k/view?usp=sharing) 9 | 10 | **Main action items** 11 | 12 | - Contribute to the [Constitution](https://github.com/atomone-hub/genesis/blob/a9b9d9d5a2440fb623d3bad3c672ae4754377b00/CONSTITUTION.md) 13 | - Contribute to the [issue consolidating ideas for the Constitution](https://github.com/atomone-hub/genesis/issues/136) 14 | - [Join our Discord](https://discord.gg/atomone) 15 | - [Help Define ICS](https://github.com/atomone-hub/genesis/issues/66) 16 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 17 | 18 |
19 | 20 | **Brief Summary of Discussion** 21 | 22 | - Disclaimer to warn users to never enter mnemonics 23 | - How to Sign offline [guide](https://github.com/tbruyelle/govgen-proposals/blob/tbruyelle/doc/submit-tx-securely/submit-tx-securely.md) 24 | - Reach out to security@allinbits.com if you find any issues. 25 | - Cosmostation, Keplr (Testnet) and Leap have integrated support for GovGen 26 | - Mintscan explorer has added support for GovGen - https://www.mintscan.io/govgen/ 27 | - Distribution proposal draft discussion 28 | - Where the "blend" `B` is the sum of the relative percentages of the distribution of YES, NO, and NWV with their respective multipliers, but *not* taking into account any bonus. Given the prop848 tally results, B is ~~1.94~~ ~2.46. The multiplier `B` is computed as `B = Y + (N + V) * 4` where `Y` is the *relative* percentage of *YES* votes (i.e. the total $ATOMs that voted *YES* over the sum of total $ATOMs that voted either *YES*, *NO*, or *NWV*), and `N` and `V` are the *relative percentages* of respectively *NO* and *NWV* votes. 29 | - Bonus and malus are less than 5% (set to 3% currently) 30 | - ~~This makes the total supply of $ATONE about 4x times higher than the supply of $ATOM as of now. [**NOTE**: might have miscounted accounts that *did not vote* at all and had not staked, we are reviewing internally, final supply could be higher]~~ 31 | - *ERRATA CORRIGE* on last point: given that the term `B` should be "neutral" with respect to how it alters the power distribution against the NO, NWV and YES relative percentages and multipliers, the expected resulting $ATONE supply should increase of a term close to `B` with respect to the $ATOM supply. And indeed, the ratio of (as of current calculations) increase of $ATONE with respect to $ATOM is of around ~2.36x (amounting to ~809M $ATONE) 32 | 33 | | | DIDN'T VOTE | YES | ABSTAIN | NO | NWV | 34 | |:------------------:|:-------------:|:---:|:-------:|:--:|:---------:| 35 | | Staking multiplier | B x malus | 1 | B | 4 | 4 x bonus | 36 | | Liquid multiplier | B x malus | - | - | - | - | 37 | 38 | - Distribution prop draft: https://github.com/atomone-hub/govgen-proposals/pull/5 39 | - Be sure to open the raw version or open the file in an editor so that you can see the comments that express some guidelines on the content of each section. 40 | 41 | - Conversation on Defining ICS 42 | - Conversation on what the relationship between Photon Atom vs Photon Atone might look like, to be discussed as a community over the coming weeks. 43 | - Conversation on the "Future of blockchain as a 3 layer cake" 44 | 45 | - Layer 1 (the infrastructure that allows a blockchain to run) - VAAS, scaled security - any application or blockchain can be hosted by any validator set 46 | 47 | - Layer 2 (Application itself) - i.e, Ethereum, Hub Logic, Liquid Staking provider, smart contract platform, any VM 48 | 49 | - Most popular applications that get the most users or tx/s would be smart contract systems, i.e EVM, GnoVM, CosmWasm. Smart contract systems that are good will enable the most application to be built on them. 50 | 51 | - Layer 3 (Dapp Layer) - Dapps or smart contracts built on top of these applications. 52 | 53 | - Detailed converastion on "How do we design a system that allows for any blockchain application to be run more or less permissionlessly?" 54 | - One idea is to turn a blockchain application into a linux container image, like a docker image. Support images that AtomOne can take from a shard. 55 | 56 | **Other suggested talking points that weren't covered due to time** 57 |
58 | - Urgencies in constitution for minimal working draft to move forward such as, 59 | - How exactly to reform governance 60 | - Remove NWV or remove delegations altogether 61 | - Remove validator commission, include fixed rate 62 | - Validators have machines onsite, i.e no white labels, no AWS 63 | - Validators should declare conflicts of interest 64 | - Should not roll out fixes that validators don't understand 65 | - If anything to be added to constitution, should be unchallenged for a given term (3 months?) 66 | - Potentially funding multiple teams of leading developers to compete to build ICS 67 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting16.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 16 Notes** 2 | 3 | ### Date: November 6th, 9am PST 4 |
5 | 6 | - Link to the [full transcript](https://docs.google.com/document/d/1ElevRoW7twLPQu0tc_fngdqQqerhuwqEwMOW43t1vI8/view) 7 | - Link to the [full recording](https://drive.google.com/file/d/1Pqn14v7l2KQ3hE4x-4pGxW0Leq3L6mab/view?usp=sharing) 8 | - Link to the [full message log](https://drive.google.com/file/d/1J3yiHN0W1W5DaTWBRlz8vy-xQ9FV5YJr/view?usp=drive_web) 9 | 10 | 11 | 12 | 13 | **Main action items** 14 | 15 | - Consider checking your allocation on the [distribution tracker.](https://govgen.io/#trackers) 16 | 17 | - Read about the [distribution.](https://x.com/_atomone/status/1852103987950162034) 18 | 19 | - Read the ["The Journey to AtomOne Launch: The Future of Decentralized Blockchain Governance"](https://allinbits.com/blog/atomone/) 20 | 21 | - Delegate your tokens using any of the methods mentioned in the "The Journey to AtomOne Launch" 22 | 23 | - Explore the [AiB Grants and Bounties Program](https://github.com/allinbits/grants/tree/main/AiB-BUIDL-Grants-and-Bounties-program) 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 | **Brief Summary of Discussion** 32 | 33 | The first Community Townhall after AtomOne mainnet focused on updates, governance mechanisms, technical developments, and community contributions. 34 | 35 | - The call started with the suggested talking points (as posted below) where the recent token distribution details were explained and there was clarification on voting multipliers and addressing questions about allocation discrepancies. Community-driven proposals were encouraged, including enabling IBC transfers through governance. 36 | - Engineers presented updates on governance improvements, introducing a “governor” role for delegating voting power based on political alignment. Upcoming updates include preventing proposal spam and introducing Photon as the chain’s primary transaction fee token. 37 | - A new staking dashboard was demonstrated, showcasing its simplicity and compatibility with Kepler, Leap, and Cosmos Station wallets. It will be open-sourced soon for wider community use. 38 | - AIB expresses it's commitment to security, with ongoing audits, bug bounty programs, and third-party security reviews planned. 39 | - Concerns were raised about the initial selection of validators. A community member clarified that the choice was based on technical requirements at launch and noted plans for a transparent delegation program to decentralize voting power further amongst other factors that will develop over time. 40 | - There was discussion about expanding marketing efforts. A decentralized, community-led marketing initiative was proposed, to be funded by the AtomOne community treasury DAO. 41 | - There was extensive discussion on identifying official validator representatives on Discord, with suggestions like using security contact emails or a JSON schema for validator properties. 42 | - The current AtomOne constitution, initially voted on by the GovGen community, allows for future amendments through community proposals and high-approval votes. Discussions and suggestions for improvements were encouraged. 43 | - The townhall concluded with thanks for community engagement and a reminder of upcoming updates. 44 | 45 | 46 | **Suggested Talking Points** 47 | 48 | - Chain Launch 49 | - On October 18th, a group of community validators organized came together, submitted their genTXs, created a new genesis, and successfully launched the AtomOne chain. 50 | - [On-chain data](https://www.mintscan.io/atomone) 51 | - 60 validators 52 | - ~14,000 accounts 53 | - ~300,000 blocks 54 | - ~140,000 transactions 55 | - [Atone Distribution](https://x.com/_atomone/status/1852103987950162034) 56 | - 40.56% vote turnout approved the ATONE token distribution on GovGen community chain. 57 | - 96,997,800 ATONE tokens allocated to 1,128,299 Cosmos Hub (ATOM) addresses. 58 | - 5,388,766 ATONE were allocated to the Community Pool 59 | - 5,388,766 ATONE were allocated to a reserved address for the future funding of the AtomOne Treasury DAO 60 | - 107,775,332 tokens in the total supply of ATONE genesis. 61 | - Engineering updates 62 | - Governors 63 | - Implementation https://github.com/atomone-hub/atomone/pull/16 64 | - Proposal deposit auto throttling 65 | - https://forum.cosmos.network/t/governance-proposal-deposit-auto-throttler/10121 66 | - if the number of active proposals exceeeds a target number, the deposit increases exponentially until it is less than or equal to that target number. 67 | - PHOTON implementation 68 | - Meta issue https://github.com/atomone-hub/atomone/issues/44 69 | - ADR https://github.com/atomone-hub/atomone/pull/34 70 | - New `x/photon` module https://github.com/atomone-hub/atomone/pull/45 71 | - Staking Dashboard Updates 72 | - Status of staking and governance dApp 73 | - Security Updates 74 | - Audits 75 | - Next Steps 76 | - Ratification of Tokenomics and Constitution documents 77 | - IBC Transfer Enablement 78 | - [AiB Grants and Bounties Program](https://github.com/allinbits/grants/tree/main/AiB-BUIDL-Grants-and-Bounties-program) 79 | - [Validator Verification for Discord Roles](https://github.com/atomone-hub/atomone-validator-community/blob/main/validator-info.md) 80 | - Q&A 81 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting13.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 13 Notes** 2 | 3 | ### Date: Date: May 28th 2024, 9am PDT 4 |
5 | 6 | - Link to the [full transcript](https://drive.google.com/file/d/1TYjwKrgMsh0a5GwhnJ8Rt2QX7TSAInK4/view) 7 | - Link to the [full recording](https://drive.google.com/file/d/1_a4waq1-F-4zoZfDrli0GqnwO-MSNqlU/view?usp=sharing) 8 | - Link to the [full message log](https://docs.google.com/document/d/1BfPSbYXCk5Z62Hi5erq_SKlalEuNA0PSAdblfe8Qjwc/edit#heading=h.m2j8z83d9x4l) 9 | 10 | 11 | **Main action items** 12 | 13 | - [Sign up to participate in the Atom One Working Groups](https://docs.google.com/forms/d/e/1FAIpQLScMUf_Jp7iWDObx5efWEwn4wCF08Z3JjkJd0_XzdHI_ZKEzRA/viewform?usp=pp_url) 14 | - Contribute to the [Constitution](https://github.com/atomone-hub/genesis/blob/a9b9d9d5a2440fb623d3bad3c672ae4754377b00/CONSTITUTION.md) 15 | - [Join our Discord](https://discord.gg/atomone) 16 | - [Help Define ICS](https://github.com/atomone-hub/genesis/issues/66) 17 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 18 | 19 |
20 | 21 | **Brief Summary of Discussion** 22 | 23 | - #### AtomOne Proposed Working Groups 24 | - Objective and community support: Strong backing for establishing a Constitution to define community’s rights, liberties, obligations, governance, economics, and implementation for the proposed AtomOne chain 25 | - Working Group: Formed with ~28 members, supported by All in Bits 26 | - Collaboration, progress and commitment: Four weeks of continuous weekly meetings, significant advancements with collaborative discussions, dedication to a sound, inclusive, transparent Constitution. 27 | - Draft Created: Initial Constitution draft [completed AtomOne Constitution draft](https://docs.google.com/document/d/15245A70C8QfDEDvh_iZ2jYCtba1cGZ1HXCWM-NS-Mo0/edit) 28 | - Need for Input: Broader community feedback needed to finalize the draft. 29 | - Next Steps: Form specialized working groups for detailed issue focus: 30 | - Treasury DAOs 31 | - Rights, liberties & obligations 32 | - Conflict resolution 33 | - Governance 34 | - ATONE Token 35 | - PHOTON design 36 | - [Application form, opened to all community members](https://docs.google.com/forms/d/e/1FAIpQLScMUf_Jp7iWDObx5efWEwn4wCF08Z3JjkJd0_XzdHI_ZKEzRA/viewform?usp=pp_url) 37 | - [Check out the Blog post for more information](https://allinbits.com/blog/atomone-constitution-update-on-progress/) 38 | 39 | - The proposal for the ATO token distribution is delayed due to technical security reviews and other factors. One additional reason for the delay is the reconsideration of how tokens are allocated, instead of excluding the Interchain Foundation (ICF) entirely, there is a suggestion to distribute tokens between the community pool and the first treasury, to foster initial funding and planned usage for these resources. 40 | 41 | - Discussion on notable issues with the management and transparency of funds within the Cosmos ecosystem, particularly concerning the ICF and the AADAO. Issues include conflicts of interest and a lack of transparency in project funding. A recent election within the community highlighted these concerns, but also showed positive steps toward addressing conflicts of interest. 42 | 43 | - The community is urged to join the treasury DAO working group to help define and improve the operations of DAOs, ensuring transparent and appropriate use of community funds. Emphasis is placed on the importance of constructive feedback and participation from those concerned with how the ICF and the DAO manage funds, advocating for greater community involvement in these processes. 44 | 45 | - #### Logo Competition Update 46 | - 53 submissions 47 | - Review process underway, winners to be announced by May 31st 48 | - 4 winners, each to be awarded a prize of 7000$ 49 | - We will also search for more designs to complete the first batch of GovGen logo proposals 50 | - The 4 winners together with other new proposals will be put on chain to collect Govgen’s community’s sentiment over the proposed AtomOne logo 51 | - AiB would like to contribute to the AtomOne design by building a proposed brand identity around one of the proposed logos 52 | 53 | - #### Engineering Update 54 | - [Governance with “Governors”, initial performance analysis](https://gist.github.com/giunatale/95e9b43f6e265ba32b29e2769f7b8a37) 55 | - [Proposed constitution enforcement process](https://gist.github.com/giunatale/8d0056633de95b2956b0330a24bde9ad) 56 | - Prototype CLI apps to sign arbitrary txs from (potentially) any Cosmos-SDK blockchain: 57 | - https://github.com/giunatale/cosmos-signer 58 | - https://github.com/tbruyelle/json-signer 59 | - [Sync GitHub constitution with current iteration](https://github.com/atomone-hub/genesis/pull/175 ) 60 | 61 | - #### GovGen proposals 62 | - AtomOne distribution proposal: plan to make changes to set up a Community Treasury 63 | - AtomOne proposed logos 64 | - AtomOne Constitution Working Groups 65 | 66 | 67 | - #### Security Updates 68 | - Bug bounties continue 69 | - [GovGen dApp](https://hackenproof.com/all-in-bits/govgen-governance-dapp) 70 | - [GovGen Binary](https://hackenproof.com/all-in-bits/govgen) 71 | 72 | - #### GovGen proposals 73 | - AtomOne distribution proposal: plan to make changes to set up a Community Treasury 74 | - AtomOne proposed logos 75 | - AtomOne Constitution Working Groups 76 | 77 | - #### GovGen dApp: 78 | - Currently working through our first audit of the dApp and fixing all issues that came up from the audit which was performed by Zellic. 79 | - The audit itself will be posted publicly after addressing any issues that were highlighted from the [audit.](https://github.com/allinbits/govgen-governance-dapp) 80 | - Additionally, we’ll be launching an indexer with a modular query system to lower the unnecessary complexity with launching your own iteration of the GovGen dApp. 81 | - Finally, we’re pushing forward with two additional features which are the voting alignment, and voting history pages. 82 | 83 | -------------------------------------------------------------------------------- /STAKING_VS_MONEY.zh.md: -------------------------------------------------------------------------------- 1 | _Originally published Nov 21st, 2023 by All in Bits, Inc; Christina Comben, 2 | Adriana Mihai, Giuseppe Natale, Jae Kwon, Valeh Tehranchi_ 3 | 4 | # 投票反对提案848 - $ATOM不应成为货币。 5 | 6 | All in Bits, Inc（AiB）即将对提案848投出反对票，该提案旨在将$ATOM代币从一个质押代币转变为货币代币。我们重视Cosmos的核心组件：安全、可持续性和去中心化，并且不能支持可能威胁其基础支柱的提案。目前对$ATOM最大通胀率进行“减半”，由于缺乏充分的研究和讨论，将导致更多不良后果，即显著降低已质押$ATOM的比例，阻碍IBC和ICS采用的增长，影响验证者的奖励，以及使整个Cosmos网络面临风险。 7 | 8 | 提案848代表着对Cosmos Hub自创立以来一直保持我们生态系统安全和可靠的既定代币经济模型做出重大的转变。尽管提案848声称它将增强$ATOM经济区域（AEZ）并提高$ATOM在DeFi领域的竞争力，但我们彻底不同意，并提出以下重大担忧： 9 | 10 | ## 破坏安全模型 11 | 12 | 一个IBC枢纽不应由货币代币来保障。对于那些不依赖其IBC代币锚定安全性的非枢纽链来说（例如那些只关心自己的链），用货币代币来保障链是有意义的。但在IBC互联链的Cosmos定义中，这并非如此。一个好的货币代币按定义是被广泛分配的，因此相对于整体而言，质押给验证者的比例会更少。这使得链的治理容易被任何拥有足够这些货币代币的人接管，而这种代币流动性的增加实际上保证了任何拥有足够资本的对手的成功。当竞争对手是现行银行系统时，就有充足的资本可以针对弱者使用。 13 | 14 | 相比之下，一个保持超级多数（比如2/3）质押状态的质押代币，流动性代币在市场上的量就少，所以敌手不能保证能在市场上购买足够多的代币来成功控制；尽管在某些情况下这可能是可能的，这也为在$ATOM作为货币的情景下敌手能够对区块链接管成功的假设提供了合理性。从长远来看，改变原本可以抵御最强大对手的模型，变为一个保证失败的模型是没有意义的。如果读者不同意该模型应该对抗最强大的对手具有韧性，这意味着读者不了解历史。 15 | 16 | 如果提案848通过，它开始了滑向堕落行为滑坡的先例，鼓励更多追求收益的堕落者进一步降低通胀，总的来说，$ATOM代币的构成和决策能力会减少到一个危险的程度，因为代币持有者不像他们应该的那样是代币经济学的专家，而只关心短期收益。这一点因为Gaia Cosmos Hub是一个IBC代币锚定枢纽而变得更糟，因此，恶意者将会有真正的动机去欺骗那些毫无戒心的投票者，让他们批准一些对中心、其用户以及整个Cosmos不利的事项，或者恶意者可能会使用其投票权直接窃取这些代币。 17 | 18 | $ATOM的主要用途是——并且一直是——质押。$ATOM设计之初从未打算作为货币代币，而是作为一个需要最高安全级别的IBC枢纽的质押代币（见原始代币模型论文）。$ATOM动态通胀的原始设计，作为一个对非质押者的惩罚，在激励网络参与和安全方面发挥着至关重要的作用，通过有意限制流动交易的$ATOM数量，使敌对接管变得代价高昂。提案848冒险削弱这些基础原则并破坏网络的安全模型。 19 | 20 | ## 虚假收入和有缺陷的论证 21 | 22 | 我们不应该通过基于错误前提的提案。提案848的支持者们计算安全成本的方式，以及普遍社区计算质押收入或收益的方法，是根本有缺陷的，因为$ATOM是一个有2/3被质押的质押代币。我们现在需要做的是通过更好地向每个人解释更好的思维模型，并从税务当局那里得到所需的澄清来解决这个问题。请注意，这里没有税务建议，你应该咨询自己的税务顾问。 23 | 24 | 当$ATOM的年复合通胀率为20%，而且通常有2/3的$ATOM被质押时，当你质押你的$ATOM时，你会从原始质押额中获得30%的年回报。这里大多数人所做的是假设代币供应量增加的30%乘以$ATOM代币的价格就是所有的收入，但我们认为这是计算$ATOM质押代币净收入的错误方式。尽管你在年末持有的$ATOM总数是1.3倍的数量，但实际上由于20%的高通胀，每个$ATOM的实用性和价值都按比例下降了。重要的不是一个人持有多少$ATOM，而是他们持有的份额与整体相比。考虑到通胀，实际的收入实际上是1.3倍 / 1.2倍，等于8.33%。这实际上表明，原先认为的30%收益与考虑通胀后的8.33%收益之间有着巨大的差距，相差约为3.6倍。 25 | 26 | 作为一个思维练习，如果我们将每个地址拥有的$ATOM数量翻倍，并保持质押比例不变，$ATOM的价格会立即下降50%（但我们持有的净价值不会改变）；通常这不应该被视为一个应税事件，股票分割的情况也是如此。 27 | 28 | 另一个思维练习，考虑定义$MASS = $ATOM / sum($ATOM)，其中sum($MASS)等于1。这个度量单位更好地代表了$ATOM代币作为整体一部分的内在价值。使用这个度量单位，实际计算的收入将是8.33%（与我们例子中的30%相反）。 29 | 30 | 除了简单模型和$MASS模型之外，第三种模型说我们应该销毁非质押者的代币，并声称质押者没有收入。这也是合理的——因为某人的相对所有权的分数上升并不意味着它应该被视为收入，因为主要目的是为了阻止未绑定的代币，这是对少数子集（大约1/3）的一种惩罚。当然，你可以反过来说这仍然是质押的激励（可以看作两者），所以这里是一个澄清的例子：如果$ATOM的分配像金钱一样广泛分布，如果只有1%的$ATOM被质押，那么对质押者的通胀显然更像是收入。 31 | 32 | 相比之下，如果99%的$ATOM被质押，即使通胀率高达1,000,000%（仅作为讨论之用），通胀也不应该被看作是收入，因为最终整体分布的比率变化不大；自然，我们更多地将其视为对那1%被通胀掉的部分的惩罚。区别在于，前者改变的分配比后者多得多（通常1%不像100%），并且既然它依赖于一个连续变量（通胀率），很明显代币的这一特征可以位于一个连续的区间之内。然而，正确地说，$ATOM的原始代币经济学主要是作为一种惩罚而不是激励。 33 | 34 | 这不是税务建议，但我们将接洽相关税务机关以获得更清晰的理解，并为这个模型辩护。在我们可选择的所有选项中，继续用简单的方式计算收入/所得是最不受欢迎、最不合理的选择，因为这无谓地自我破坏。 35 | 36 | 那些投票支持#848并选择偏离2/3质押目标的人（这就是#848之后会发生的事情）通过破坏上述有利于更优惠税务处理的论点，进一步破坏了他们自己和其他人。货币代币的通胀奖励不太可能被视为非质押的惩罚，而是质押的积极激励。 37 | 38 | ## 不良先例 39 | 40 | 支持#848的人甚至辩称，他们只是在衡量质押者的兴趣。这种与安全和稳定相反的代币经济学根本性改变，在没有完全声明其真实意图（使$ATOM成为货币代币）及其影响的情况下被提出。同样，它也没有提供充分的规划和保证以确保任何形式的一致性，也没有提供必要的风险披露。事实上，我们甚至还没有为Cosmos Hub批准一部宪法。更糟糕的是，这项提案被市场营销为一次“减半”，这对预期的价格走势有所暗示，而所提议的内容完全不像比特币链的不可变减半时间表。 41 | 42 | ## 质押比例进一步下降 43 | 44 | 正如提案中所指出的，Cosmos Hub当前的质押比例略低于目标值，未能超过三分之二的阈值。这种现状引发了重大关注：通过将最大通胀率减半，该提案实际上阻止了质押奖励率的增长，而这是一个旨在阻止非质押行为并推动质押比例达到目标的机制。 45 | 46 | Cosmos网络的设计动态调整通胀率，以鼓励在质押比例低于期望阈值时进行质押。这个机制按预期运作，逐渐增加通胀率以激励更多$ATOM持有者质押他们的代币，从而保障网络安全。过去它已经按预期工作，如下图所示。然而，有人使用错误的数学方法声称这表明机制无效（尽管我们承认变化速度可以更快）。提议中的减少通胀率可能会导致质押比例进一步下降，而此时机制本应推动比率上升。 47 | 48 | ![graph of time vs bond ratio on 49 | Gaia](https://github.com/atomone-hub/genesis/blob/0e65b56e4a0739287f2615ebd2c99d0c1bab4a74/resources/stakingrate.png) 50 | 51 | 提案声称高$ATOM通胀率使得DeFi收益难以竞争。提案中写道：“然而，由于$ATOM的高通胀率，DeFi收益很难竞争，这减缓了用户增长和采用。”首先，这是对实际通胀收益的严重误解，正如之前提到的，最大化20%的复合年通胀率，并不是最多30%的年收益，而是净8.33%。其次，这种推理完全错误，因为如果$ATOM的收益如此之高，那么它应该_增加_用户增长和采用，而不是减少。如果这是真的，这将是值得庆祝的事情，而不是扼杀。 52 | 53 | $ATOM的较高通胀率确实使其不适合在DeFi应用中使用，因为与收益相比，$ATOM的通胀更多。但是$ATOM从未打算以这种方式作为货币使用。使用“流动性质押”（一个用词不当）服务来管理$ATOM的质押，并在DeFi应用中使用由此产生的更具通缩性的流动性质押代币更有意义，但是像这样复合奖励也会增加风险，并且并非没有代价。 54 | 55 | 在支持提供更具通缩性衍生代币的质押管理服务的帮助下，必须通过限制或调节可以转换回$ATOM的“流动性质押”代币的数量来增加额外的检查措施，以防止敌对收购。否则，在货币性$ATOM代币和质押$ATOM代币之间的安全性几乎没有区别，但是质押代币与更具流动性的通缩代币之间的区别是引入具有不同权衡的控制措施的基础。否则，我们只能使用粗糙的杠杆来管理这个关键的安全问题，例如可以使用ICS的质押比例，这并不正是我们需要衡量的。 56 | 57 | ## IBC锚定代币 58 | 59 | 这里的真正安全风险不在于ICS AEZ经济学，因为AEZ内的内容由同一验证者集合通过ICS保护，并且链可以同意回滚任何被认为会导致盗窃的交易（例如通过漏洞）。真正的风险在于Cosmos Hub上的锚定IBC代币。由Hub控制但源自Hub和AEZ外部其他链的代币都有被盗的风险。 60 | 61 | 所有这些代币默认情况下都为恶意行为者创造了真正的激励去进行利用。如果IBC锚定代币的总量从未超过（假设货币性）$ATOM代币质押价值除以3（因为只有⅓保证可对双花攻击进行惩罚，当网络分区时）这可能是可以容忍的，但我们不能假设Hub在其投票者无法理解将$ATOM转换为货币代币的风险时甚至会强制执行这种不变性。此外，大多数代币可能不具流动性，并且重新补偿可能不足以作为受害者的救济。 62 | 63 | ## 论证验证者激励问题 64 | 65 | 今天在Cosmos Hub中，验证者的激励机制是破碎的。每个验证者应该大致上同等地受到激励去保护AEZ中的每条ICS链，因为每个验证者应该执行的工作以确保每条ICS链的安全大致相同。目前按照质押量（乘以他们设定的佣金）来奖励验证者的激励模型在这方面是有缺陷的，因为没有什么可以保证尾部验证者将获得他们需要的收入以保持与顶级验证者的竞争力，而且随着ICS规模扩大，这种情况变得更糟。随着足够的规模，所有尾部验证者必然会破产失败，而那些挣扎着维持生存的验证者必然需要做出影响该验证者安全性的商业决策。这不仅是次优的，而且是残酷的。 66 | 67 | 提议的变化对小型验证者的影响不成比例。虽然一旦验证者激励被修正为更加平等，这将不再是问题，但在整体验证者激励模型被修复之前，它仍然是一个问题，因此给小型验证者带来了不必要的风险。一项分析显示，超过74%的Cosmos Hub验证者在少于六个消费链的情况下面临盈利能力下降的风险。减少最大通胀只会加剧这个问题，并使所有这些验证者更快地变得无利可图。我们永远不应该容忍导致集中化的大规模验证者失败的风险。 68 | 69 | ## 最低通胀率也不应该改变 70 | 71 | 虽然确实随着ICS启用的交易扩展，来自交易费用的奖励可以并将会推动通胀率降至零甚至负值（如果我们允许的话），但如果这导致$ATOM代币作为货币代币的推广和采用（而且它会的），那么这并不是好事。因此，我们也不建议取消7%的最低通胀率限制。这将有助于保留$ATOM代币分配的智能性，并防止天真的代币持有者对其产生负面影响（货币代币的目标人群是天真的，因为它是普通大众）。 72 | 73 | 保持最低通胀率限制在7%的负面后果是，绑定代币的比例可能会上升到三分之二以上，流动供应量可能太小，无法准确衡量质押代币市值，这可能会对Hub提供的可量化安全性产生负面影响。然而，这种效应是有限的，因为当ICS交易吞吐量带来的奖励很高时（假设这就是绑定率高的原因），只要费用主要用除$ATOM代币以外的其他代币支付，就有其他方法通过其持续的收入计算Hub的价值。 74 | 75 | ## 我们接下来该怎么办？ 76 | 77 | 虽然我们因为上述详细原因坚决反对提案848，但总应该有空间进行实验、创新以及开放的讨论和辩论——只要我们同意永远不会妥协网络的安全，并遵循谨慎和衡量的方法。鉴于$ATOM不应该是货币代币，当前设计的最低通胀率为7%，最高通胀率为20%，以确保网络安全，正在按预期工作。对这个模型的任何改变都会使$ATOM代币过于诱人，被市场化为货币代币。 78 | 79 | 我们想要做的是开启一个讨论，调整`NextInflationRate`函数，使其对达到目标比例更加敏感。让我们一起找到最佳的做法，并公开讨论利弊。平衡市场竞争力与网络安全和经济稳定的基本方面对于Cosmos网络的持续增长和成功至关重要。 80 | 81 | 从鸟瞰角度看目前提案的结果以及我们从社区看到的话语，明显缺乏领导力指导社区做出必要的决策。自从提案82以来，我们一直在制定提案以改善Cosmos Hub的治理，这应该优先于像848这样的提案。然而，ICF似乎没有提供帮助，而且经常参与支持糟糕的提案。尽管我们可能会在投票NWV（我们敦促每个人都这样做，并改变投票为NWV）后在这里击败848，但总体情况并不适合我们需要的成功，而且如果不采取积极措施，我们看到这种情况将继续恶化。 82 | 83 | 我们很快会发布一个计划，以改善Hub的这种情况。请继续关注更多信息。 84 | 85 | —---- 86 | 87 | ## 推特讨论 88 | 89 | 1/ 亲爱的宇航员们，All in Bits (AiB) 将在提案848上投票为NWV，即ATOM减半。我们重视Cosmos的核心组成部分：安全性、可持续性和去中心化，并且不能支持威胁其基础支柱的提案。 90 | 91 | 2/ #848旨在将$ATOM代币转变为货币代币。但$ATOM的主要用途是——并且一直是——一个质押代币，使得IBC枢纽能够实现最高水平的安全性。 92 | 93 | 3/ “减半”$ATOM最大通胀率而缺乏充分的研究和讨论将导致不良后果，显著降低$ATOM质押的绑定比例，阻碍IBC和ICS的增长，影响验证器的奖励，并使Cosmos网络面临风险。 94 | 95 | 4/ #848是从Cosmos Hub已确立的代币经济模型中做出的重大转变，这一模型保持了我们生态系统的安全性和可靠性。此外，该提案被市场化为“减半”，但与比特币链的不可变减半时间表完全不同。 96 | 97 | 5/ 提案848的支持者计算安全成本的方式，以及总体上社区如何计算质押收入或收益，都存在根本性的缺陷。我们不应通过基于错误前提的提案。 98 | 99 | 6/ #848对小型验证器的影响不成比例。一项分析显示，超过74%的Cosmos Hub验证器在少于6个消费链的情况下面临无利可图的风险。在首先解决验证器激励问题之前，我们不应讨论降低最大通胀率。 100 | 101 | 7/ 在指导社区做出必要决策方面明显缺乏领导力，我们担心这种情况会继续恶化。因此，我们正在制定一个改善这种情况的计划，我们很快会与社区分享。 102 | 103 | 8/ 充分理解所提出的论点对于做出明智的决策至关重要，我们邀请社区评估提出的观点并积极参与讨论。请阅读我们的完整帖子以获取全部详细信息： 104 | 105 | 106 | 9/ 我们将在今天太平洋夏令时晚上10点（欧洲中部时间周三早上7点）举行Twitter空间讨论提案#848。如果您分享我们的担忧或希望有意义地贡献讨论，请加入我们，成为对话的一部分。 107 | #CosmosDebate #TwitterSpace -------------------------------------------------------------------------------- /DECENTRALISTS.md: -------------------------------------------------------------------------------- 1 | // XXX UNSORTED, WILL DELETE. 2 | 3 | 4 | We prefer to operate with radical transparency in the open, and our name should 5 | reflect our values, so we hereby call ourselves the "Decentralists". The 6 | Decentralists are the opposition conservative party for the Cosmos Hub named 7 | Gaia, and AtomOne is the Decentralists' initial ICS host. 8 | 9 | Decentralists: 10 | * Embody radical transparency. 11 | * Accept both splitting and negotiating. 12 | * Define protocols for interoperability. 13 | * Finish software given a name. 14 | * Respect first principles, so 15 | * Require constitutions and bylaws. 16 | * Create rather than destroy. 17 | 18 | It is important to note that AtomOne is a proof-of-stake hub governed by $ATONE 19 | tokens, while the Decentralists is a membership oriented quasi-political party 20 | with members associated with various companies (or individual proprietors). The 21 | various missions and objectives of this party may eventually drift from the 22 | missions and objectives of AtomOne because the people may be focused on 23 | different things over time and less on time-proven infrastructure, but the core 24 | values must remain the same and the vision compatible with those declared here. 25 | 26 | AtomOne may enforce criteria for Decentralists membership (and temporary bans 27 | and suspensions) with a Constitutional Majority for the purpose of ensuring the 28 | alignment of the Decentralists members with AtomOne, provided that it also 29 | offers everyone the right (through Apache2.0 or more liberal licenses, or 30 | \*GPL\* and GnoPL licenses) and the ability with reasonable ease to maintain a 31 | prior fork of Decentralists membership under a different brand name distinct 32 | from either AtomOne or Decentralists. 33 | 34 | This initial tight coupling is necessary between AtomOne and the Decentralists 35 | brands because the success of either are tied together and we prefer a more 36 | open membership policy for the Decentralists for growth, but the people 37 | ultimately determine what a name means. After a period of 7 years after genesis 38 | the Decentralists can vote via a supermajority or constitutional majority to 39 | become self-sovereign and remove the ability for AtomOne to enforce anything 40 | about the membership of the Decentralists. (XXX maybe replace with a curve). 41 | Correspondingly AtomOne can choose any other membership group (or any other 42 | type of group or DAO) to replace the Decentralists at that time with the same 43 | system but with a new criteria for membership, under a new name. 44 | 45 | Initially the only criteria for Decentralists membership is that members hold 46 | any nonzero amount of $ATONE or $PHOTON tokens (more on $PHOTON later) and 47 | agree with the spirit of the Founding Documents, and agree to at all times 48 | abide by and enforce the living AtomOne Constitution for the AtomOne hub. 49 | 50 | While we respect the stakers and the staking distribution, we also recognize 51 | that the unequal token distribution must be balanced by the natural inalienable 52 | God given powers to individual humans who are vital to make this project 53 | succeed. While the voting on AtomOne is handled solely by the $ATONE stakers, 54 | the Decentralists self-organize as a whole and with groups within, and every 55 | proposal in the governance of the Gaia and AtomOne hubs as well as every open 56 | group are enriched with the best arguments from both sides of the isle as 57 | measured by feedback from all the members of the Decentralists. In short, the 58 | democratic distribution offered by the Decentralists is used to rank the 59 | arguments for and against every proposal to be voted on by stakeholders. 60 | 61 | The chain explorers and wallets that display information about AtomOne and Gaia 62 | hub proposals and the proposals of Decentralists open groups should display the 63 | Decentralists official summary in full (but can customize the order or make 64 | highlights), or they should link to the appropriate Decentralists resource so 65 | users can see all of the related commentary. These are not enforced but are 66 | incentivized through the portion of block rewards reserved for blockchain 67 | explorers and wallets. 68 | 69 | While it may appear that the Decentralists and its integration into AtomOne are 70 | unnecessary complexifications not fit for a "minimal hub", it does address the 71 | real need for a long term development roadmap for AtomOne to improve our 72 | communications amidst irreconcilable differences, the need to give 73 | self-aligned groups more voice through self-organization, and the need for a 74 | long term vision of a market of competing systems and designs that incorporate 75 | a comprehensive range of components from virtual machines, smart contract 76 | systems, DAO frameworks, to end-user interfaces; that offer transparent and 77 | accountable disbursement of funds and decision making for every organization. 78 | The tooling we develop under the brand of Decentralists will be made available 79 | broadly in all communities and serve to introduce more people to AtomOne and 80 | its generations. 81 | 82 | Portions of the constitution regarding the Decentralists, only the 83 | Decentralists can vote to change. 84 | 85 | The Decentralists may adopt a new constitution with a 2/3 supermajority, until this clause is revoked... /// XXX ok but now this is confusing. AtomOne vs Decentralists having separate constitutions? 86 | XXX The Decentralists should also have a minimal constitution. 87 | XXX move and refactor 88 | The Decentralists may elect to add with a 2/3 supermajority a new Judicial System. Each Judicial System will have a 89 | 90 | ##### decentralists UX..... 91 | The initial implementations of UX will be provided by anyone or any community 92 | that wants to implement the whole vertical stack required from maintaining a 93 | chain to the end user interfaces required. AIB & NT along with those aligned 94 | with the GnoVM will work on one implementation, but all reasonable stacks 95 | will be supported such as those that run on (Cosm)WASM as long as there is a 96 | responsible party willing to commit. 97 | 98 | Create tooling to help members register themselves with their associations, 99 | and to allow these members to self-organize into open and closed (yet 100 | transparent) groups in a permissionless way. Each group should have their 101 | own respective founding documents, constitution, mission, bylaws, etc. 102 | Companies as entities also get representation, and everyone must declare 103 | their associations and use their real identities (in order to prevent sybil 104 | attacks). 105 | 106 | * Fix the governance functions from the CosmosSDK and port these and core sdk 107 | modules to Tendermint2. 108 | * Implement AtomOne according to the specifications here and other Founding 109 | Documents linked to from here, and make payments for these purposes from an 110 | internal Decentralists Treasury separate from the AtomOne community pool, 111 | and conduct releases according to the roadmap specified here and other 112 | Founding documents with oversight by the $ATONE stakers. 113 | 114 | AtomOne will subsidize at least one ICS shard if needed, to serve as the zone 115 | for the Decentralists' dapp/DAO needs, including hosting a dapp for 116 | self-organized conversations. 117 | 118 | These arguments provided by the Decentralists for and against every proposal 119 | and the default ranking of them by the Decentralists are not hosted on the root 120 | hub, but shall not be deployed until they are hosted on a separate ICS zone. 121 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting2.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 2 Notes** 2 | 3 | ### Date: February 9th, 2024 4 | 5 |
6 | 7 | - Link to the [full transcript here](https://docs.google.com/document/d/12yRU9Lt1MUIsbwdUBmb6jXZY-AHyjagtqRiGlXuiu1o/edit?usp=sharing) 8 | - Link to the [full recording here](https://drive.google.com/file/d/1wrAhCuxrPDGcc8aRBOZUxQC2VcLsG0TN/view) 9 | [![Recording](https://res.cloudinary.com/marcomontalbano/image/upload/v1707724221/video_to_markdown/images/google-drive--1wrAhCuxrPDGcc8aRBOZUxQC2VcLsG0TN-c05b58ac6eb4c4700831b2b3070cd403.jpg)](https://drive.google.com/file/d/1wrAhCuxrPDGcc8aRBOZUxQC2VcLsG0TN/view "Recording") 10 | 11 |
12 | 13 | **Main action items** 14 | 15 | - If you're interested in becoming a validator, make a PR on the [validator directory](https://github.com/atomone-hub/validator) following the process listed on there. 16 | 17 | - Take a look at this code for [GovGen Genesis Creation](https://github.com/atomone-hub/govgen-genesis) and the [GovGen Chain Software](https://github.com/atomone-hub/govgen), submit an issue if you have something you want to bring up. 18 | 19 | - [Join our Discord](https://discord.gg/atomone) 20 | 21 |
22 | 23 | **Brief Summary of Discussion** 24 | 25 | Technical Updates and Governance Discussions: 26 | - Distribution is 1:1 with No and NWV voters, initial distribution will probably be ~ 68m million GovGen tokens 27 | - GovGen will have a few changes from the starting point of the fork of Cosmos Hub: 28 | 29 | - GovGen is non-transferable 30 | - Inflation Disabled 31 | - Community tax, proposer reward and bonus all set to 0 32 | - Deposit raised to 5000 GovGen 33 | - Voting period suggested to be extended to 365 days, discussion followed on different voting periods for different types of proposals, specifically for software upgrades, changing parameters. Conversation followed some consensus with talks about voting incentives then shut down. 34 | - Vote threshold set to 2/3 35 | - Quorum raised to 50% 36 | - Validators tentatively reduced to 30 37 | - Gaia v14.1 without the liquid-staking module 38 | - IBC module removed 39 | - ICS module removed 40 | - Spam prevention changed to 1% of initial deposit by proposer 41 | - GovGen will probably skip the testnet phase. 42 | 43 | - Validator Onboarding Process 44 | Part of the conversation focused on onboarding validators, discussing criteria, documentation and verification steps. 45 | - Some discussion on how to onboard validators that won't receive GovGen 46 | - Removing self-stake 47 | - Remove delegation potentially or whether validators should be able to vote. 48 | 49 | - Governance Mechanisms and Validator Requirements 50 | - Discussion on how to proceed with multiple choice proposals 51 | - Only allowing tokens staked at the time of a proposal 52 | - Topic focused on the roles of validators and their requirements 53 | 54 | - Chain Architecture and Documentation 55 | - Discussion on methods to improve accessibility and clarity. 56 | 57 | - Governance Model and Community Involvement 58 | - Emphasis on the need for transparency, accountability, and inclusivity in decision-making processes. Discussion on general incentive for early participation in GovGen, potentially being called a founder. 59 | - Talking through gamification of incentives. 60 | 61 | - Validator Rewards 62 | - Discussion focused on whether it makes sense for GovGen or not 63 | 64 | - Covered the Condorcet Paradox 65 | - https://en.wikipedia.org/wiki/Condorcet_paradox 66 | 67 | - Conclusion 68 | - Covered Action Items 69 | - Covered scheduling next meeting 70 | 71 |
72 | 73 | **Main talking points** 74 | 75 | - Validator Onboarding Process 76 | - Technical Updates and Governance Discussions 77 | - Governance Mechanisms and Validator Requirements 78 | - Chain Architecture and Documentation 79 | - Governance Model and Community Involvement 80 | - Technical Updates and Validator Rewards 81 | - Governance Policies and Tokenomics 82 | - KYC Processes and Regulatory Considerations 83 | - Governance Structures and Meeting Scheduling 84 | 85 |
86 | 87 |
88 | 89 | 90 | _This was the original Proposed Agenda for Townhall for Feb 6th 2024, 9 AM PDT/ 6 PM CET_  91 | 92 | **Community growth and Ecosystem Development** 93 | 94 | - GovGen and AtomOne progress (5 minutes) 95 | 96 | - Communication channels: 97 | 98 | - Discord is [set up](https://github.com/atomone-hub/genesis/pull/110) and moderation policy - please join! 99 | 100 | - Twitter, the community has taken the @\_atomone handle and offered that to AiB for moderation, thank you so much @wnmnsr 101 | 102 | - FAQ 103 | 104 | - Add FAQ to read.me 105 | 106 | - Community town halls and get togethers:  (5 minutes) 107 | 108 | - Structure of town halls, alternating between engineering and community calls.Tentative agendas to be published on GitHub at 2-3 days in advance of the each call - make sure you make suggestions for topics that you would like to discuss 109 | 110 | - Meeting notes and recordings will be published after each community call on GitHub  111 | 112 | - Community growth: 113 | 114 | - AiB AtomOne Grant Program (10 minutes) 115 | 116 | - Anyone who needs financial assistance to help, make sure you’ll apply w/ CV and the area of contribution you are interested in etc. We will publish the grant application process and recommendations on Github soon. Stay tuned! 117 | 118 | - Brainstorm technical needs and other project ideas - let’s find the top three ideas! 119 | 120 | - Hub Minimalism 121 | 122 | - Scaled Security 123 | 124 | - Self-Reinforcing Constitution 125 | 126 | - Tendermint2 127 | 128 | - International Ambassador program ideation  129 | 130 | - Branding, naming and visuals (10 minutes) 131 | 132 | - Discuss the name change - [proposing](https://github.com/atomone-hub/genesis/pull/108) GovGen becomes GovGen due to community feedback 133 | 134 | - @wnmnsr would you want to come to the townhall to discuss AtomOne branding ideas? 135 | 136 | - 137 | 138 | - Discussing the best way to decentralize voting on brand and visuals while not creating a governance spam scenario 139 | 140 | - Validator directory and onboarding (15 minutes) 141 | 142 | - Give a brief overview of the directory, what it means, and what you can anticipate as a validator  143 | 144 | - Forbole team has already signed up: https://github.com/atomone-hub/validator. @kwunyeung Would you like to join the Townhall and share with the community what inspired you to apply and what does your alignment with GovGen and AtomOne look like? 145 | 146 | **Engineering updates:** 147 | 148 | - What’s happening in GovGen engineering? (20 to 30 minutes)  149 | 150 | - Building genesis from a snapshot of CosmosHub block [18010657](https://www.mintscan.io/cosmos/block/18010657) 151 | 152 | - Extract relevant data using jq commands 153 | 154 | - Validate data against prop 848 final tally result, consolidate data with all accounts, balances (liquid and staked) and votes (direct & indirect). 155 | 156 | - Created python script to get initial balances. 1:1 GOVGEN distribution to No and NWV voters (only staked amount and only the weight that voted either No or NWV) ( ) 157 | 158 | - Chain params forked from Cosmso Hub, with the following changes: 159 | 160 | - Bank module: 161 | 162 | - Disabled sendTx 163 | 164 | - Distribution module: 165 | 166 | - community tax, proposer reward and bonus all set to 0 167 | 168 | - Mint module: 169 | 170 | - inflation disabled, no new minting of tokens 171 | 172 | - Gov module: 173 | 174 | - Deposit amount raised to 5000 GOVGEN 175 | 176 | - Voting period extended to 365 days 177 | 178 | - Vote threshold for pass raised to ⅔ 179 | 180 | - Quorum raised to 50% 181 | 182 | - Staking module: 183 | 184 | - reduced validators to 30 tentatively 185 | 186 | 187 | * Building govgen chain: ( ) 188 | 189 | - Starting from Gaia 14.1.0 190 | 191 | - Revert to standard sdk 0.45.16 without LSM 192 | 193 | - Remove globalfee module and revert to old mempool decorator 194 | 195 | - Removed IBC & ICS and related modules (e.g. ICA) 196 | 197 | - Set bech32 prefix to govgen 198 | 199 | - Reduced gov initial deposit to 1% to better fit the 5000 $GOVGEN deposit threshold (initial deposit 50 $GOVGEN) 200 | 201 | - What happens next? (5 minutes) 202 | 203 | - Testing, we are ready for launch! 204 | - Discuss initial parameters with the community 205 | - Build the validator set 206 | - Coordinate chain launch 207 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | _NOTE: from https://github.com/decentralists/DAO/edit/main/governance/README.md. 2 | Prob everything there should be refactored and moved into some file in this repo._ 3 | 4 | # Improving and fixing governance on Cosmos Hub and beyond 5 | 6 | As of today, the Cosmos Hub has arguably achieved a lot of what was its 7 | [initial vision](https://v1.cosmos.network/resources/whitepaper) and 8 | [beyond](https://hub.cosmos.network/main/roadmap/): from inter-blockchain 9 | communication (IBC) and multi-token pegging, to having a working on-chain 10 | governance system, to interchain security (ICS) in its initial version as 11 | _Replicated Shared Security_. 12 | 13 | However, as the Cosmos Hub matures and grows - alongside the whole Cosmos 14 | ecosystem - shortcomings are becoming more and more evident, as they impact the 15 | overall security and user experience of the network. _Governance_, in 16 | particular, is a key aspect of Cosmos which uniquely positions it in the 17 | blockchain industry. The ability to vote on-chain on various topics, from funds 18 | allocation to protocol-level changes and chain upgrades, is undoubtedly 19 | powerful. But the lack of a written constitution that defines a common vision 20 | and guiding principles, and can serve as an arbiter when there is any doubt, is 21 | surely a major missing piece. On top of that, there are more technical and 22 | practical changes that we deem essential for improving and fixing the on-chain 23 | governance system. Among these there are for instance implementing mechanisms 24 | for spam prevention and switching over delegation-less voting for most 25 | governance proposals. 26 | 27 | This document aims to outline a roadmap that addresses the issues we have 28 | identified and sets the direction for future improvements in the governance of 29 | the Cosmos Hub and beyond. The key priorities in this roadmap include extending 30 | the voting period for late quorum achievement, implementing a proposal deposit 31 | auto-throttler, separating staking and governance, dynamically adjusting the 32 | quorum, and introducing 2/3 supermajority proposals. 33 | 34 | ## Priorities and Roadmap 35 | 36 | As we strive to improve the governance of the Cosmos Hub, we have identified 37 | several key areas that require attention. These priorities have been chosen 38 | based on their potential to significantly enhance the effectiveness of the 39 | governance system and the overall user experience. 40 | 41 | For each of these priorities, work is either already in progress or planned to 42 | start as we move along in the list. The roadmap for these improvements is 43 | presented in order of planned execution, although things may evolve and 44 | priorities may change as the ecosystem further develops and matures. 45 | 46 | ### 1. Extension of Voting Period for Late Quorum Achievement 47 | 48 | In the current implementation of the `x/governance` module in the Cosmos SDK, a 49 | governance proposal that reaches quorum near the end of the voting period may 50 | not have sufficient time for discussion and deliberation among stakeholders. 51 | 52 | The majority of community interest in a proposal arises when the vote quorum is 53 | reached. This is because a proposal's outcome only becomes valid after 54 | achieving quorum. Reaching quorum near the end of the proposal voting period 55 | could therefore be a symptom of low awareness about the proposal or could 56 | potentially be a form of governance manipulation. 57 | 58 | To address this issue, we propose an extension mechanism for the voting period. 59 | By enforcing an extension when quorum is reached too close to the end of the 60 | voting period, we ensure that the community has enough time to understand all 61 | the proposal's implications and potentially react accordingly without the worry 62 | of an imminent end to the voting period. 63 | 64 | The work-in-progress text of the related _Architecture Description Record_ 65 | (ADR) can be found [here](../adrs/voting-period-extension-late-quorum.md), 66 | while the code can be found 67 | [here](https://github.com/allinbits/cosmos-sdk/tree/giunatale/late-quorum-vote-extension). 68 | Both are still subject to changes and improvements. 69 | 70 | ### 2. Spam Prevention: Proposals Deposit Auto-Throttler 71 | 72 | The Cosmos Hub governance - as well as other Cosmos chains - has been recently 73 | suffering from governance spam, with several proposals being submitted that are 74 | aiming at spreading misinformation and scams. While ultimately the impact for 75 | the chain is only an increase in the governance proposal index, the majority of 76 | these proposals contain harmful links that could potentially pose a risk to 77 | unsuspecting users. 78 | 79 | Despite some mitigations have been designed, like the [initial deposit 80 | requirement for proposals](https://github.com/cosmos/cosmos-sdk/pull/12771) - 81 | waiting for the Hub to upgrade to v0.47 of the Cosmos SDK to be deployed - and 82 | a more minimal [temporary 83 | mitigation](https://github.com/cosmos/gaia/issues/2246) that was deployed in 84 | the _v9-Lambda_ upgrade of the Cosmos Hub, we believe a better system could be 85 | put in place. Moreover, the deployed temporary mitigation seems to be largely 86 | ineffective, as spam proposals are still being regularly submitted, albeit 87 | arguably in lower quantities. 88 | 89 | Using a similar mechanism to the auto-adjusting inflation rate that targets a 90 | 2/3 bonding ratio, we can auto-adjust the deposit amount (between reasonable 91 | minimum and maximum bounds, just like the inflation rate) to target having on 92 | average *N* proposals active at any time, with *N* being a low number, e.g. 1 93 | or 2. 94 | 95 | More details on the idea and some initial considerations can be found on a 96 | Cosmos Hub Forum 97 | [post](https://forum.cosmos.network/t/governance-proposal-deposit-auto-throttler/10121). 98 | 99 | ### 3. Staking and Governance Separation: Introduction of Delegation-less 100 | Voting 101 | 102 | The objective is to separate the Proof of Stake and governance layers, 103 | eliminating governance delegations and switching over *direct voting* for most 104 | cases. 105 | 106 | In the current system validators hold too much political weight. However, 107 | validators should not be politicians, generally speaking. They should be chosen 108 | because of their technical excellency, and their ability to efficiently serve 109 | the blockchain to maintain high levels of availability and security. 110 | 111 | In practice, two kinds of governance proposals - from a high level perspective 112 | - would exist: 113 | 114 | 1. **Urgent infrastructure and/or validator-related proposals**: In this 115 | scenario, validators would retain their delegated governance voting power. 116 | These proposals would carry over similarly to what happens today with 117 | governance delegations mirroring staking delegations. 118 | 2. **Every other proposal**: Only direct voting would be allowed, with no 119 | delegations. However, this would require a mechanism for _quorum 120 | auto-adjustment_ that would account for the inevitable lower participation 121 | (in terms of voting power) with delegation-less voting. 122 | 123 | This would also require a governance body that would be in charge of checking 124 | if proposals are correctly categorized, and possibly punishing proposers 125 | otherwise. 126 | 127 | ### 4. Quorum Threshold Auto-Adjustment 128 | 129 | The idea would be to linearly decrease the quorum threshold when consecutive 130 | proposals fail because they do not meet quorum. This is a mechanism that would 131 | allow us to find the proper quorum threshold in an environment where only 132 | direct voting is allowed, and as a consequence, lower participation (with 133 | respect to total voting power) is to be expected. 134 | 135 | A specific governance proposal could then be used to set the quorum threshold 136 | to a higher value should the need arise. 137 | 138 | This mechanism would also work in tandem with the spam prevention *deposit 139 | auto-throttler*, meaning that generally speaking no more than a few proposals - 140 | for instance, just 2 - would be active at any point in time. 141 | 142 | 143 | ### 5. Introduction of 2/3 Supermajority Proposals 144 | 145 | We aim at introducing an option to allow proposals to pass only if a 2/3+ 146 | supermajority votes *Yes*, and consequently remove the *NoWithVeto* vote option 147 | for these proposals as it would be not needed. 148 | 149 | The supermajority pass threshold might be only used on certain kinds of 150 | proposals - e.g. constitution changes - or enacted for all proposals. This is 151 | yet to be fully decided and is subject to further discussion. 152 | 153 | ## Conclusions 154 | 155 | In conclusion, the roadmap outlined in this document presents an approach to 156 | improving and fixing governance on the Cosmos Hub and beyond. It is clear that 157 | while the Cosmos Hub has achieved significant milestones, there are areas that 158 | require attention and improvement as the ecosystem continues to mature and 159 | grow. 160 | 161 | The enhancement of on-chain governance mechanisms and the active involvement of 162 | the community - as well as the establishment of a written constitution - are 163 | all critical steps towards creating a more robust, secure, and democratic 164 | governance system. These improvements will not only address the current 165 | shortcomings but also ensure that the Cosmos Hub is well-equipped to handle 166 | future challenges and opportunities. 167 | 168 | This roadmap is a living document and will continue to evolve as the Cosmos Hub 169 | and the wider Cosmos ecosystem grow and develop. We welcome feedback and 170 | suggestions from the community as we work towards these goals. 171 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting12.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 12 Notes** 2 | 3 | ### Date: Date: April 23 2024, 8am PDT 4 |
5 | 6 | - Link to the [full transcript](https://docs.google.com/document/d/1lLrhe0pNKTsXMAtkJgOjelKSgwvCtCwLMimteEnDh7I/edit?usp=sharing) 7 | - Link to the [full recording](https://drive.google.com/file/d/1OgyF0myC90_Yu7hpiogLQcHR_4waOdQG/view?usp=sharing) 8 | - Link to the [full message log](https://drive.google.com/file/d/1iGB39795fad1aVIgr1C1oPmy2k25ggcF/view?usp=sharing) 9 | 10 | 11 | **Main action items** 12 | 13 | - Contribute to the [Constitution](https://github.com/atomone-hub/genesis/blob/a9b9d9d5a2440fb623d3bad3c672ae4754377b00/CONSTITUTION.md) 14 | - Contribute to the [issue consolidating ideas for the Constitution](https://github.com/atomone-hub/genesis/issues/136) 15 | - [Join our Discord](https://discord.gg/atomone) 16 | - [Help Define ICS](https://github.com/atomone-hub/genesis/issues/66) 17 | - [Participate in the Atom One Design Competition](https://github.com/atomone-hub/assets/tree/main/AtomOneDesignCompetition) 18 | - Consider applying for [open roles](https://jobs.lever.co/allinbits) 19 | - First Constitution Working Group call is next Tuesday at 9am. 20 | - Calls will alternate starting this week 21 | 22 |
23 | 24 | **Brief Summary of Discussion** 25 | 26 | - The call starts with an introduction bringing attention to the main action items including the Atom One Design competition and a call for contribution to the Constitution. 27 | - There was a discussion about efforts to prevent dependency injections in binary distributions, particularly focusing on reproducible builds. The conversation highlighted the reproducibility of builds in Go 1.20 and emphasized the importance of ensuring consistent builds for user confidence. 28 | - The concept of autostaking, where users stake their tokens to receive rewards, was explained. Two staking methods were detailed: regular staking and autostaking, and discussions revolved around how rewards are distributed among validators based on uptime rather than direct delegation. 29 | - There was also conversation on ideas to ensure equal rewards for validators performing the same work, regardless of the number of delegations they receive. 30 | - Discussions also covered maintaining fairness in rewards distribution and preventing economic attacks on the network. 31 | - The technical implementation of a pool-based delegation system was outlined, where tokens are pooled and distributed among validators based on uptime. This approach aims to simplify delegation for users and promote network security however there were some concerns covered, like how do you define the validator set to begin with? 32 | - Various ideas for selecting validators were discussed, including validators deciding on new additions or community-driven proposals to expand the validator set based on network needs and performance. 33 | - The conversation continued to cover various perspectives on incentivizing governance participation, with participants discussing the importance of validation and delegation mechanisms in ensuring network success and security. 34 | - One participant highlighted the significance of governance participation and suggested considering the the idea of incentivizing governance participation in validating the network's success. 35 | - Another expressed skepticism towards incentivizing governance participation, arguing that not incentivizing participation might lead to more meaningful engagement and better outcomes. They emphasized the need to preserve proof of stake mechanisms while encouraging intelligent delegation. 36 | - A third participant proposed a strategy of distributing tokens equally among good validators to ensure network security, with penalties for validators who do not adhere to the rules. 37 | - The discussion then shifted with a conclusion wrapping up the call focused on updates of the various ongoing projects and initiatives, including the development of the GovGen dapp, a bug bounty programs, and the logo design competition. 38 | 39 | - #### Engineering Update 40 | - internally reviewing the available initial [constitution.md](https://github.com/atomone-hub/genesis/blob/main/CONSTITUTION.md) 41 | - code disclaimers and reproducible build for GovGen 42 | - govgen uses go1.20 which provides [reproducible builds](https://go.dev/blog/rebuild) when cgo is disabled 43 | - need to align goreleaser and Makefile so they produce the same binary signature 44 | 45 | | Go version | Debian (glibc) | Alpine (musl) | Arch (glibc) | Reproducible build | 46 | |------------|----------------|---------------|--------------|--------------------| 47 | | 1.20.14 | c1d25ff | c1d25ff | | ✅ | 48 | | 1.21.9 | 6bbfd3c | 6bbfd3c | | ✅ | 49 | | 1.22.2 | 27affed | 27affed | 27affed | ✅ | 50 | 51 | - analysis of PHOTON design 52 | 53 | 54 | - #### GovGen dApp Update 55 | - Working on going public by finalizing License 56 | - Working on Main Network launch for dApp 57 | - Platform has 100% coverage for translations 58 | - Ramping up additional features to launch for the dApp after Main Network 59 | - Building a minimalistic Calisto inspired Indexer with a very small footprint 60 | 61 | - #### Bug Bounty 62 | - Launching in coming days 63 | - Rewards 200-10k USD per finding 64 | - Scope covers Govgen and the governance dApp 65 | - Follow on Twitter to receive a link when it launches. Rewards go to the first finder of each vulnerability. 66 | 67 | 68 | - #### Logo Competition Update 69 | - All In Bits is hosting a design competition for the AtomOne project's logo. Participants have three weeks to submit their designs, followed by a week of voting. The competition starts on April 22nd, 2024, and ends on May 31st, 2024. Last day to submit is 13th of May. The voting period is from April 22nd to May 20th, 2024. 70 | - Participants must create unique logos that reflect their creativity and innovation. They must submit full-size and short logos, each in three colors (including white and black). Participants can submit up to two entries. 71 | - The total prize pool is $28,000, with four grand prizes of $7,000 each. Winners must waive their rights to the intellectual property of their designs in favor of All In Bits, allowing them to use the logos for the AtomOne project. 72 | - Participants must have a GitHub account to participate and submit their entries via the dedicated GitHub repository. They must also meet eligibility requirements and agree to transfer their submission's rights to All In Bits if selected as a winner. 73 | - The judging process includes community voting on GitHub and evaluation by the All In Bits team. The winning logos may be used for the AtomOne project's future brand identity. 74 | - This logo will be used interim until the proposed AtomOne project runs it's own vote 75 | - Overall, it's a global design competition offering participants the chance to showcase their talent and potentially win cash prizes while contributing to the AtomOne project's branding. [Here's a link](https://github.com/atomone-hub/assets/tree/main/AtomOneDesignCompetition) 76 | 77 | 78 | - #### Working Group Form Update 79 | - Closed on April 20th 80 | - 29 respondents 81 | - **Time Slot** 82 | - The most mentioned time slots (in PDT) were: 9am, 8am, 7am, 6am, 10am, 6pm 83 | - The 6am slot is crucial for folks in China and South Korea 84 | - Of those that mentioned dates, Tuesday and Wednesdays were predominant 85 | - Given that information I would suggest we continue with the Tuesday slot, alternating between 6am, 9am, 6pm time slots. Maybe an experimental 2am timeslot lead by someone in Europe. 86 | - **Blockers from participating** 87 | - Many people requested the meeting time a week or two in advance to ensure they have the time slot available, I think we can improve on this. 88 | - People mentioned time constraints as the main blocker 89 | - **What would make a good constitution?** 90 | - **Transparency and Decentralization**: Preventing abuse of power and ensuring fairness for all contributors. 91 | - **Flexibility and Clarity**: Balancing flexibility to adapt to changing circumstances with clarity on core principles, avoiding overly bureaucratic language, and maintaining a clear direction for the project. 92 | - **Community Engagement and Support**: Supporting community initiatives, funding projects aligned with core values, and fostering inclusivity within the AtomOne ecosystem. 93 | - **Ethical Framework and Dispute Resolution**: Incorporating an ethical framework to guide behavior and establishing clear procedures for resolving disputes, promoting respect, equity, and fairness. 94 | - **Minimalism and Accessibility**: Advocating for a minimalist approach to the constitution, using simple language for accessibility, and ensuring broad understanding and participation within the community. 95 | - **What specific topics would you like to contribute to?** 96 | - **Governance and Decentralization**: Several folks expressed a desire to contribute to aspects related to governance, decentralization, and the role of validators within the ecosystem. 97 | - **Economics and Economic Incentives**: Many indicated interest in contributing ideas for economic incentives to increase voting participation and discussions on voting mechanisms. 98 | - **Community Development and Innovation** **Support**: There was significant interest in contributing to crafting guidelines and support systems for innovation within the AtomOne ecosystem, including mentorship programs and collaborations with external partners. 99 | - **Philosophical and Fundamental Principles**: Some respondents expressed a desire to contribute to defining clear fundamental principles that would guide the constitution and the project as a whole. 100 | - **Proofreading and Legal Advisory**: A notable number of people expressed interest in proofreading the entire constitution, providing input on specific topics, and offering legal advice regarding the content, structure, and design of the AtomOne Constitution. 101 | 102 | - Define a process for deciding what time the working group calls are held 103 | -------------------------------------------------------------------------------- /DISCORD.md: -------------------------------------------------------------------------------- 1 | You can join the AtomOne Discord channel here: https://discord.gg/atomone 2 | 3 | ### Here is a what our welcome message and rules of participation looks like: 4 | 5 | ### **Welcome to the unofficial AtomOne Discord Channel!** 6 | This Discord server is dedicated to fostering collaboration, discussion, and innovation for AtomOne, an alternative fork of Gaia ("cosmoshub4"). AtomOne upholds Cosmos' core components of security, sustainability, and decentralization and offers a minimal and secure alternative IBC hub to prepare for all contingencies. 7 | 8 | **Why Do We Need AtomOne?** 9 | The Cosmos community is at a crossroads and constantly confronts divergent views on key aspects such as mission, tokenomics, and security philosophy. AtomOne provides an alternative, more security-conscious branch, complementing the broader Cosmos ecosystem. 10 | 11 | **Server guidelines & code of conduct** 12 | To ensure a productive and respectful environment for all contributors, we adhere to the following guidelines: 13 | 14 | **Respect and inclusivity** 15 | Treat all members with respect. We welcome diverse viewpoints and encourage constructive discussions. Respect the privacy and boundaries of all community members. 16 | 17 | **No harassment** 18 | Harassment in any form is not tolerated. This includes, but is not limited to, bullying and use of derogatory language. 19 | 20 | **Stay on topic** 21 | Please keep discussions relevant to the channel topics. This helps in maintaining clarity and efficiency in our conversations. 22 | 23 | **No spamming** 24 | Avoid spamming messages, links, or images. Share content that contributes to the discussions. 25 | 26 | **Channels overview** 27 | 28 | #⁠govgen: A channel directly focused on GovGen 29 | ⁠#constitution: A place to discuss the constitution 30 | ⁠#atomone-hub: Dedicated space for technical discussions, development updates, and collaboration. 31 | ⁠#support: Get help from the community on any AtomOne related queries. 32 | ⁠#validators: A place for validators to discuss and coordinate. 33 | 34 | #⁠announcements: Official updates and announcements about AtomOne 35 | ⁠#faq: (WIP) find answers to frequently asked questions and basic information about AtomOne. Ideal for new comers! 36 | #⁠github-feed an automatic feed giving updates on issues straight from the repo. 37 | 38 | ⁠#general: For general discussions about AtomOne and the Cosmos ecosystem. 39 | ⁠#memes: You know what to do 40 | ⁠#off-topic: For non-AtomOne related chatter. Keep it friendly and fun! 41 | 42 | **Getting help** 43 | If you have questions or need assistance, feel free to ask in the #faq channel, if you’re unable to find answers in the #support channel. AtomOne moderators and community members are here to help. 44 | 45 | **Participate and contribute** 46 | Your insights, questions, and feedback are invaluable. We encourage active participation and look forward to your contributions. Together, we can ensure the long-term stability and sustainability of the Cosmos ecosystem and drive innovation and growth. 47 | 48 | **Make PRs on GitHub** 49 | Contributing to the AtomOne GitHub is a great way to get involved! Whether it's reporting issues, proposing new features, or improving documentation, every contribution counts. 50 | 51 | Vision and Mission : https://github.com/atomone-hub/genesis#vision-and-missions 52 | 53 | Objectives: https://github.com/atomone-hub/genesis#objectives 54 | 55 | Plan: https://github.com/atomone-hub/genesis#plan 56 | 57 | FAQs: https://github.com/atomone-hub/genesis#faq 58 | 59 | To Do: https://github.com/atomone-hub/genesis#todo 60 | 61 | Glossary: https://github.com/atomone-hub/genesis#terms 62 | 63 | There is an issue on the AtomOne repo that discusses these interim guidelines, along with our moderation guidelines that are open for input and refinement. 64 | Please contribute if you have suggestions for the structure of this server: https://github.com/atomone-hub/genesis/issues/98 65 | 66 | The future of this channel will be decided upon by GovGen voters! We're excited to have you as part of the AtomOne community. Let's collaborate to make the AtomOne Discord channel a thriving hub for learning, sharing, and contributing to the AtomOne project. 67 | 68 | Welcome aboard! Enjoy your stay! 69 | 70 | 71 | 72 | 73 | ### Here is what our moderation policies look like: 74 | 75 | 76 | ### **Expectations Of A Moderator:**  77 | 78 | **Do your best to help community members with answers about AtomOne related questions:** 79 | 80 | - If members are looking for documentation please point them to the repo. 81 | 82 | - If you think you know exactly which issue the conversation is about, try to make that available.  83 | 84 | - If they're looking for specific info or reporting disruptions about any other project, please direct them to the official channel of that project 85 | 86 | **Be in the channel consistently within reason to ensure that scams are not popping up, make sure to delete them as soon as you can.** 87 | 88 | - A big part of the role of a moderator is to ensure that community members stay safe, it is always good to have an eye on the channel in case someone joins to spread spams, scams or misinformation. 89 | 90 | **Ensure that you are not sharing rumors, and make an effort to guide conversations back to constructive, productive and building-focused chats** 91 | 92 | - Conversations should be relevant to AtomOne, or GovGen 93 | 94 | - If conversation steers away from AtomOne or GovGen in a way that is not bringing relevant or benefit to the conversation, try to invite the community members in the conversation to come back to the main topic or to continue the conversation in an off-topic channel. 95 | 96 | **Try to ensure that people show respect each other, even while sharing differing opinions:** 97 | 98 | - People should feel comfortable sharing thoughts and opinions. Abusive, oppressive or bullying attitude should not be welcome in the channels, please try to de-escalate before turning to more administrative means (i.e, mutes, removals) 99 | 100 | **Avoid engaging with people who are there to create chaos and present disrespectful, condescending or inappropriate attitudes, try to stay detached and provide warnings:** 101 | 102 | - See more in the [Disciplinary Measures] sections 103 | - If it becomes evident that individuals are purposefully promoting their token or product without engaging in a constructive discussion related to AtomOne, please take appropriate action by muting them 104 | 105 | **Encourage users to protect their privacy:**  106 | 107 | - Alert people that giving details about their location, email addresses and so on could be not the best decision. Delete the message if they do so. 108 | 109 | **Encourage Developers and Validators to join our Discord Server and to use appropriate channels** 110 | 111 | - The general channels under Lounge should stay entry-level, try to direct any technical questions, or validator inquiries to the #support and #validator channels respectively so that conversations can stay relevant to their categories. 112 | 113 | **Encourage users to do their own research.** 114 | 115 | - A lot of the time people will come in hoping to find an absolute answer, but most of the time that isn't possible, especially with questions regarding their own finances.**  116 | 117 | - Try to avoid giving absolute answers unless you are absolutely certain that is true. 118 | 119 | - Always refer members to existing articles or groups that will more likely have the information that is relevant to what they are looking for 120 | 121 | **Avoid Direct Messaging (DM) anyone, even if they reach out first:**  122 | 123 | - Please attempt to resolve all the eventual issues/disruptions within the chat room, unless the information exchanged is confidential in which case the moderator should ask the user to initiate the direct message. 124 | 125 | **Avoid sending tokens to community members** 126 | 127 | - This will set a precedence that is not fun to continue, encourage the use of faucets 128 | 129 | **Share the latest announcement and the most important news from AtomOne's Github, or other future social platforms to encourage healthy discussions.** 130 | 131 | ### **Disciplinary Measures** 132 | 133 | Cases can usually be divided into 3 categories: 134 | 135 | Scams/Spam: Those who post scams or intentionally spam the channel with promotional content regarding projects not belonging to the AtomOne ecosystem. 136 | 137 | Inappropriate Behavior: Those who use vulgar language or behave aggressively or inappropriately towards other users. 138 | 139 | Toxic Behavior: Those who make heavy personal attacks, racism, sexism or discriminatory, defamatory or any other toxic behavior 140 | 141 | **Scams/Spam** 142 | 143 | - Scams and spam can come in many different forms: 144 | 145 | - Content that is extremely irrelevant to AtomOne 146 | 147 | - Talking about shitcoins, memecoins, weird Ethereum or BSC contracts 148 | 149 | - Users offering financial advice, "Fred made me $5,000 dollars," 150 | 151 | - "User support" that links to wallets that aren't what is used for AtomOne 152 | 153 | We should have a bot instantiated at some point to remove the scam/spam immediately, however if the bot happens to miss it, please delete the message and ban the user who posted it. 154 | 155 | **Inappropriate Behavior** 156 | 157 | Inappropriate behavior can be identified as: 158 | 159 | - Person who ignores help and claims to have answers we cannot provide or claims to have them in an inappropriate way. 160 | 161 | - People who insist on carrying on attitudes that are vulgar, intimidating, disrespectful or that may in any way make the rest of the community uncomfortable. 162 | 163 | - People who do not observe the topic of the chat by intentionally going on tangential and borderline abusive conspiracy related conversation. 164 | 165 | In these cases, the suggested behavior is as follows: 166 | 167 | Warn the person that he/she will continue to persist in their behavior, they will be removed from the community. Once you warn someone, please mention it in the moderator's only channel. 168 | 169 | After two warnings, no matter the time passed from the first and the second one, this person will be muted for 1 day. Then you can inform the person in the channel, inviting him/her to DM you to find a way to resolve this in the best way possible. 170 | 171 | If the person proves to be uncooperative, uses other accounts to continue with his conduct despite the imposed limitation or after the period of limitation starts again with the unsuitable behavior, it will be necessary to mute the person again. 172 | 173 | Please report this situation in the AtomOne Moderator's Only channel with the screenshot of the message that triggered the second mute and we can have a vote on permanent bans. 174 | 175 | **Toxic Behavior** 176 | 177 | These cases can be identified as: 178 | 179 | - People who carry out personal attacks on other members of the channel 180 | 181 | - People who use toxic language with references to racism, sexism and any sort of discrimination. 182 | 183 | In these cases, please: 184 | 185 | Mute the person immediately and report it to the AtomOne Moderator's only channel and we can have a vote on permanent bans. 186 | -------------------------------------------------------------------------------- /GovGen_Townhalls/Meeting1.md: -------------------------------------------------------------------------------- 1 | ### **GovGen Townhall Meeting 1 Notes** 2 | 3 | ### Date: December 14th, 2023 4 | 5 | [Link to recording](https://x.com/Allinbits_inc/status/1735383245787701589?s=20) 6 | 7 | Meeting notes from the first GovGen townhall. 8 | 9 | Action: Create Discord moderation policy and setup 10 | 11 | - **Introduction: What is the [GovGen](https://github.com/atomone-hub/genesis/issues/71) chain: definition, purpose, utility** 12 | - GovGen is primarily a governance chain, with the design to get a large consensus amongst the No/NWV voters on what and how AtomOne should work 13 | - Purpose of GovGen is to find sentiment and get direction 14 | - Why GovGen? The genesis for AtomOne and GovGen stems from prop 848, which defined a split. No/NWV voters are key, and AtomOne wouldn’t make sense if there wasn’t support from No/NWV voters on this proposal. 15 | - GovGen is not governance for AtomOne, but a way to bootstrap governance to kick it off 16 | - What is AiB’s part? We are a participant and contributor in GovGen having voted No on prop 848, along with many members of the community, and you are an equal in this project;we want to facilitate a way for the No/NWV vote community to speak out. We are primarily here to serve and moderate the discussion on No/NWV voters. 17 | - For building GovGen, we should consider our available tooling 18 | - Audits: important, but as there is no central authority it isn’t always done, so everyone has to be cautious about the technology they are using 19 | - Questions, we need to answer: 20 | - How much support do we need from No/NWV voters? We need to find the right answers to find consensus among No/NWV voters 21 | - What ratio of Yes and No/NWV voters should be included in AtomOne? 22 | - **Define the Governance Token** 23 | - **GovGen token and the governance structure:** 24 | - The purpose of the GovGen chain, token and structure is to help us answer questions and coordinate together 25 | - We don’t have the infrastructure to deal with per person uniqueness, so anything to modify distribution will end up creating distortions that other people will exploit. Example: Bot accounts ended up voting yes - 164,000 yes voters and 6,867 No voters. 26 | - NWV for purity will receive the same as No voters and those that abstained could also receive a proportionate amount.. 27 | - Proposal for a two step distribution: GovGen token to be distributed only to NWV and No and they can decide to increase the distribution to share with delegators who didn’t vote but inherited the vote from their validators 28 | - Proposal for $ATONE distribution, abstainers and non voters to receive 50% of the rewards that No voters receive and on top of that a slight penalty for not participating that shouldn’t be significant and open to making it 0. Why? You don’t want to force people to vote. 29 | - **GovGen governance vs. Cosmos Hub governance** 30 | - **Who are the members of GovGen?** 31 | - No voting members and NWV voters 32 | - **How will the voting system work?** 33 | - Start simple, minimal modifications to the Cosmos governance module. Over time, we can iterate and improve it. 34 | - We can create a multitude of GovGen chains, maybe throw them away, but ultimately the community will select the primary GovGen chain. 35 | - It is important to not require new tooling to use the system. However, if there is new software, it could be a vulnerability at this time since we are loosely coordinated. There is no central authority to audit the software, so we have to be cautious. 36 | - Suggested change: In terms of editing code, it is to increase governance duration. Let's consider infinite duration, all proposals last forever and you can change your votes or even create a duplicate because you want a new measure. 37 | - **GovGen and AtomOne:** 38 | - **What is the relation between GovGen and AtomOne?** 39 | - We fork the chain of Gaia, GovGen chain, we don’t make a lot of changes, the governance proposals on GovGen shouldn’t have much effect. 40 | - **How is GovGen contributing to AtomOne?** 41 | - **How to contribute to GovGen:** 42 | - **Validators** 43 | - Should disclose relations without validators, this is required and if related should follow certain rules so there is independence among split validators. 44 | - If a validator and associations are too big, we find a way to cap group validators, because what we want and need is more or less equal full size validators unless we make it explicit. 45 | - In the constitution, we need to clearly state the rules or the rails for decision making and require full disclosure on chain that might be enough. 46 | - **If you are a member:** 47 | - Contribute early on GitHub 48 | - Make contributions and propose ideas 49 | - **If you are an external contributor (but not a member)** 50 | - Contribute early on on GitHub 51 | - Make contributions and propose ideas 52 | - **Self organization and autonomy** 53 | - **How can you advance discussions and contributions** 54 | - Ideally GitHub for discussion and topics that they would like to contribute to 55 | - AtomOne arguably should be allowed to be called AtomOne regardless of ICF 56 | - AtomOne is consistent with writings during Atom2, a minimal hub 57 | - AiB should not own it, start with No voters and grow 58 | - Link to all forks from atom one repo 59 | - Community creating a split and using GovGen and everyone can play a role here 60 | - **What is the best way for people to self organize?** 61 | - **Are there dedicated channels to stay in touch with the current development?** 62 | - Discord, and build a Discord moderation policy 63 | - Are there dedicated channels to stay in touch with the current development? 64 | - GitHub and Discord will be the main ones. 65 | - **What’s next?** 66 | - **Discord issue on GitHub to build the guidelines and then appoint someone from the community to open it** 67 | - Create Discord channel 68 | - Discuss there where and when for the next townhall 69 | - Discord. Markdown file 70 | - Gabriel suggests proposals on branding and identity of AtomOne and GovGen this will affect the channels 71 | - GitHub is the place to have permanent discussion, move from Discord to GitHub. Discord is the live chat medium. 72 | 73 | **Questions and discussion from community during the townhall Q&A:** 74 | 75 | - If you have delegated and did not vote on prop 848 but your validator voted NO, should you receive GovGen tokens? 76 | - GovGen is a sentiment chain 77 | - Proposal is to focus on the votes without delegation 78 | - Fork Gaia, create GovGen chain, don’t make a lot of changes 79 | - Primary purpose is to understand the sentiment of the community 80 | - Increase the threshold to 67% from 50%+1 81 | - Snapshot of GovGen- limited to the NO voters at the limit of #848 82 | - GovGen- the GovGen chain ideally should not be transferable to preserve the initial distribution set 83 | - We should not count validator delegations, GovGen is a sentiment chain, we don’t know who to delegate to 84 | - How can we delegate and trust that delegation system? Because of that it’s better to focus on votes without delegation. 85 | - Chain is called GovGen, GovGen is staking token, distribution to be decided 86 | - Minimal changes, proposals on GovGen have little effect, not trying to change parameters or improve the chain but the primary purpose is to understand what portion of the chain believes this or that. 87 | - Nothing is really decided on GovGen until there’s a higher percentages (67%) from 51 to 67 because that’s safer 88 | - With GovGen we should follow the desired governance structure of AtomOne 89 | - How do you enforce legal jurisdiction? 90 | - AtomOne has its own court and we can look at the evidence, for a simple court procedure. 91 | - How do avoid a super majority 92 | - Should the community support raising the threshold to change parameters of the chain? 93 | - Instead of ICS chains, having their own tokens they can use base tokens of the main chain. 94 | - Validators voting with their own tokens, not their delegators? 95 | - For AtomOne is not decided 96 | - Use GovGen to come to consensus 97 | - Approval of validators and stakers 98 | - Two parties? 99 | - For GovGen, no value to protect so validators don’t have as much weight 100 | - What about newcomers? 101 | - Some of us want after launching AtomOne that they are out of luck 102 | - It makes more sense to demonstrate a split in a friendly and constructive way, if we slash them out, we’re incentivizing the narrative that we overtly competing 103 | - Supporting AtomOne in spite of Gaia is not logical, it should be collaborative 104 | - Secondary mechanism to acquire AtomOne tokens aside from airdrop, what that looks like is up for discussion on repo 105 | - If you bring atoms to AtomOne then you can earn AtomOne over time using liquid staking 106 | - Benefit to AtomOne is that AtomOne gets voting power in Gaia 107 | - Gaia becomes like LikeCoin to AtomOne’s Bitcoin, more flexible while AtomOne is more immutable 108 | - Premine? Distributed to Atom holders in a premine 109 | - Liquid stake? 110 | - AtomOne liquid staked token is photon 111 | - Atom liquid tokens become Phantom 112 | - Phantom convert to Photons? 113 | - Photon holders will get diluted “when gaia fails” 114 | - Can they merge? Can they work together? 115 | - Better idea of what people are comfortable with after GovGen launches 116 | - Should we limit transfers of GovGen tokens? 117 | - For GovGen, absolutely. Use them, delegate/stake and vote but cannot send 118 | - Is the snapshot for GovGen tokens done by 848 closing vote? 119 | - Yes for the purpose of GovGen, which is sentiment understanding for the purpose of AtomOne, so limit only to No voters. 120 | - Question: validator delegation included? 121 | - Question: Changes occurring to the state impact? 122 | - No only the snapshot 123 | - Consider using DAODAO? 124 | - Would be good to rely on what we have, going with general idea of not introducing too many things 125 | - GovGen can start creating validator base community for AtomOne 126 | - Makes sense to eat our own dog food that way we have a base for validator community 127 | - Full functionality from app and web browser? 128 | - Yes 129 | - Potentially try both, DAODAO as a temporary solution to get direction for GovGen 130 | - Purpose of GovGen is to find sentiment? 131 | - Yes, to get direction 132 | - Will people be excluded for not voting? 133 | - No voters need to support GovGen decisions and will probably agree that we should include non voters 134 | - Even yes voters should be included 135 | - 7th comment in issue 12 on repo 136 | - Start with same distribution of 848 137 | - Only slash ICF 138 | - If you voted no is 3x 139 | - If you voted yes, 1:1 140 | - If you abstain or no vote is 1.5x 141 | - When we talked about no voters are no and NWV voters different? 142 | - For GovGen we shouldn’t, it’s a question because we don’t know. Keep it simple for NWV 143 | - Was this a veto worthy proposal? 144 | - Yes from perspective of security 145 | - Are we gonna punish most of us? 146 | - How do we consider punishing of non voters 147 | - Counterproductive to not punish because you should DYOR on validators 148 | - Member for punishing non voters, “if we include lazy voters they stay lazy” for GovGen 149 | - Do we have a timeline for when we expect AtomOne? 150 | - January Q1 151 | - Being scrappy is better 152 | - Launch with simple fork 153 | - Before Gno.land 154 | - “You can fork a chain but not a community of developers”, are there plans to build incentives for builders in AtomOne? 155 | - Different approach than Swiss foundation 156 | - Do as much on chain, transparent, according to specs and budget plans 157 | - Funding comes from premine, inflation, transaction fees (main source) should go into the community pool to fund developers. 158 | - Devs should be funded through contracts that specify how much and for what and in combination of stable coin and $ATONE tokens 159 | - Specify what happens when price changes 160 | - Governance of chain should be deciding what system to use 161 | - Best solution comes from expressive platform 162 | - Support smart contract DAO systems there should be diversity of them 163 | - Gno.land 164 | - Define the scope of how community funds are used in the constitution, don’t focus on investments of other projects 165 | - KYC for validators? 166 | - Genesis validators of AtomOne, maybe makes sense to KYC the validators 167 | - After launch - up to the stakers of the chain to decide 168 | - Not for GovGen 169 | - Issue 75: https://github.com/atomone-hub/genesis/issues/75 170 | -------------------------------------------------------------------------------- /STAKING_VS_MONEY.kr.md: -------------------------------------------------------------------------------- 1 | _Originally published Nov 21st, 2023 by All in Bits, Inc; Christina Comben, 2 | Adriana Mihai, Giuseppe Natale, Jae Kwon, Valeh Tehranchi_ 3 | 4 | # "$ATOM의 화폐화"를 주장하는 848번 의제를 거부합니다 5 | 6 | AiB는 848번 의제에 거부권(No With Veto, NWV)을 행사할 예정입니다. 해당 의제는 스테이킹 7 | 토큰으로 설계된 $ATOM에 반감기를 도입하여 화폐화를 시도하자고 주장합니다. 당사는 8 | 코스모스의 핵심 가치인 보안, 지속가능성, 탈중앙화를 우선시하며, 이러한 본질들을 위협하는 9 | 의제를 지지할 수 없음을 밝힙니다. 충분한 연구 및 논의 없이 $ATOM의 최대 인플레이션율에 10 | 반감기를 도입 하는 결정은 바람직하지 않은 결과로 이어질 것입니다. 대표적인 문제로 $ATOM의 11 | 스테이킹 비율이 큰 폭으로 감소될 것으로 예상되며, 이는 IBC와 ICS의 채택에 악영향을 12 | 미치며 검증인들에게 지급되는 보상을 감소시켜 코스모스 네트워크의 존재적 위험으로 이어 13 | 질 수 있습니다. 14 | 15 | $ATOM의 토크노믹스는 코스모스 허브의 탄생 이후 코스모스 생태계가 안전하며 신뢰 가능하도록 16 | 기반을 다지는데 핵심적인 역할을 하며, 검증되어 왔습니다. 848번 의제는 반감기를 통한 17 | 토크노믹스 개혁으로 $ATOM 경제 구역($ATOM Economic Zone, AEZ)의 고도화 및 디파이 18 | 생태계 내 $ATOM의 경쟁력 강화를 달성할 수 있다고 주장합니다. AiB는 이에 절대적으로 19 | 반대하며, 이에 대한 근거로 848번 의제에 대한 당사의 우려를 표명하고자합니다. 20 | 21 | ## 보안 모델의 불안정화 22 | 23 | IBC 허브를 화폐성 토큰으로 보호해선 안됩니다. 체인의 보안에 화폐성 토큰을 사용하는 24 | 행위는 IBC 토큰 브릿징에 의존하지 않고 하나의 체인으로 독립성을 갖는 비(非)허브들에게는 25 | 고려대상일 수도 있습니다. 그러나, IBC 기반의 상호 운용성을 지원하는 코스모스 생태계에 26 | 서 이는 해당하지 않습니다. 효과적인 화폐성 토큰은 널리 분배 및 유통되어야 하며, 이는 27 | 검증인들에게 위임 및 스테이킹된 비율의 감소로 이어집니다. 결과적으로 체인의 거버넌스는 28 | 이러한 화폐성 토큰을 확보하는 주체에게 장악당할 수 있는 위험에 노출됩니다. 즉, 체인을 29 | 보호하는 토큰의 높은 유동성은 강력한 자금력을 바탕으로 공격을 시도하는 적대적인 세력들 30 | 에게 유리한 요소가 될 수 있습니다. 블록체인의 경쟁상대가 금융 시스템의 기득권이라는 31 | 점을 감안한다면, 우리는 상대에게 이런 공격을 계획할 수 있는 충분한 자금력이 있다는 사실 32 | 을 인지해야 합니다. 33 | 34 | 반면, 2/3과 같은 절대 다수 비율의 스테이킹 상태를 유지하는 토큰은 시장에 유통되는 35 | 수량이 적어 앞서 언급된 자금력을 동반한 공격으로부터 비교적 안전합니다. 이러한 구조마저 36 | 체인의 절대적인 보안을 보장할 수는 없지만, $ATOM의 화폐화는 이런 방어수단마저 해제하여 37 | 공격자가 확정적으로 체인을 장악할 수 있는 환경을 조성할 것입니다. 장기적인 관점에서 38 | 보았을 때, 가장 강력한 상대의 공격마저 합리적으로 방어할 수 있는 현 시스템을 확정적인 39 | 공격에 노출시키는 허술한 구조로 개혁하는 것은 비이성적인 행위입니다. 만약 이 글을 읽는 40 | 독자가 코스모스의 시스템이 가장 강력한 적의 공격을 받는 최악의 상황에도 대비해야 한다는 41 | 의견에 공감하지 못한다면, 그 독자는 역사에 무지한 사람일 것입니다. 42 | 43 | 848번 의제가 통과한다면, 투기행위를 조장한 나쁜 선례로 남을 것이며, 고이율 디파이 상품 44 | 투기를 위해 인플레이션율을 더욱 감소시키려는 시도를 권장하게 될 것입니다. 또한, $ATOM 45 | 보유자들의 전반적인 구성과 지적 수준을 감소시켜 거버넌스가 위험하거나 유해한 결정을 46 | 하는 결과로 이어질 것입니다. 이는 대체적으로 토큰 보유자들이 토크노믹스에 대한 충분한 47 | 이해가 없고, 단기적인 수익만 추구하는 성향을 띄기 때문입니다. 코스모스 허브(가이아)가 48 | IBC 토큰 브릿징 허브라는 점은 이런 문제의 심각성을 극대화합니다. 단순하게 허브, 49 | 유저들, 코스모스 생태계를 공격하겠다는 악의로 순진한 투표자들을 기만하여 유해한 의제를 50 | 통과시키려는 세력 뿐만 아니라, 브릿징 된 토큰을 노리고 금전적인 목적으로 거버넌스를 51 | 장악하는 세력의 인센티브 또한 충분하기 때문입니다. 52 | 53 | $ATOM의 핵심 기능은 스테이킹입니다. 이는 지금까지 그래왔고, 앞으로도 변하지 않을 사실 54 | 입니다. [토큰 모델 백서 원본](https://github.com/cosmos/cosmos/blob/0141bbcdbf68a784348ba059096f8238c696f9a8/Cosmos_Token_Model.pdf)에서 확인할 수 있다시피, $ATOM은 최고 수준의 보안이 요구되 55 | 는 IBC 허브 구현을 위한 스테이킹 토큰으로 설계되었습니다. 절대 화폐성 토큰이 아닙니다. 56 | 본래 $ATOM의 동적인 인플레이션 구조는 비(非)스테이킹 $ATOM 보유자들을 처벌함으로써 57 | 적극적인 네트워크 참여 및 보안에 대한 인센티브를 제공하기 위해 설계되었습니다. 이는 58 | $ATOM의 유동성을 의도적으로 감소시켜 체인 장악에 소모되는 비용을 비합리적인 수준으로 59 | 높히는 원리로 작동합니다. 848번 의제는 코스모스의 본질적인 설계를 약화시켜 네트워크의 60 | 보안을 불안정하게 만드는 결과를 초래할 것입니다. 61 | 62 | ## 허구의 수익율 및 의제의 논리적 오류 63 | 64 | 우리는 거버넌스의 일원들로써 논리에 오류가 있는 근거를 내세우는 의제를 통과시키지 않을 65 | 의무가 있습니다. 848번 의제의 제안자들과 커뮤니티 여러분이 전반적으로 허브가 보안 지출에 66 | 소비하는 비용과 스테이킹 보상을 계산하는 방식은 근본적으로 잘못되었으며, 이는 $ATOM 67 | 이 2/3의 스테이킹 비율을 유지하도록 설계된 토큰이기 때문입니다. 현시점에서 우리에게 68 | 가장 필요한건 $ATOM의 설계에 대한 충분한 설명으로 대중의 인식과 이해도를 개선하는 것이며, 69 | 세무 당국으로부터 확답을 받는 것입니다. 본 글의 어떠한 내용도 공식적인 세무 관련 자문으로 70 | 받아들여져선 안되며, 정확한 내용을 위해선 세무 전문가에게 상담을 받으시길 권장합니다. 71 | 72 | $ATOM의 연간 복리 인플레이션율이 20%라고 가정할 때, $ATOM의 스테이킹 비율은 2/3 73 | 수준으로 유지되기 때문에 $ATOM을 스테이킹하는 사람들은 스테이킹을 하지 않는 사람들에 74 | 비해보유 수량이 연간 약 30% 증가합니다. 일반적으로 대중은 30%만큼 증가한 $ATOM의 수량과 75 | $ATOM의 가격을 곱하여 스테이킹으로부터 발생하는 이익을 계산하지만, 당사는 이것이 잘못된 76 | 계산 방식이라고 생각합니다. 비록 $ATOM의 수량은 1.3배 증가하였지만, 1개의 $ATOM이 77 | 총 발행량 대비 차지하는 지분율과 가치는 20%의 인플레이션으로 인해 줄어듭니다. 78 | 가장 중요한 수치는 사실 $ATOM 보유 수량이 아닌, 보유자의 전체 대비 지분율입니다. 79 | 인플레이션을 감안하는 실질적인 수익률은 수량 증가분을 인플레이션율로 나누는 수식인 80 | 1.3/1.2로 계산되는 값인 8.33%입니다. 이는 기존에 생각되던 30%라는 값과 비교할 시 81 | 3.6배라는 큰 수치의 차이가 있습니다. 82 | 83 | 사고(思考)실험을 위해 현재 모든 사람이 보유 중인 $ATOM의 수량이 두배로 증가하고, 84 | 스테이킹 비율이 유지된다고 가정해보겠습니다. $ATOM의 가격은 즉시 50% 감소하겠지만, 85 | 보유량의 증가 때문에 $ATOM 보유자들의 자산 가치는 유지될 것입니다. 이는 액면분할과 86 | 유사한상황이며, 통상적으로 과세 대상이 아닙니다. 87 | 88 | 또 하나의 사고실험을 위해 이번에는 $MASS = $ATOM / ($ATOM 수량 총합) 이며, $MASS 89 | 수량의 총합은 1이라고 가정해보겠습니다. 이 $MASS라는 단위는 전체 발행량 대비 $ATOM의 90 | 가치를 더 정확히 표현할 수 있는 방법입니다. 이 단위를 바탕으로 수익율을 계산한다면, 91 | 30%가 아닌 8.33%라는 정확한 값에 도달하게 됩니다. 92 | 93 | 마지막 사고실험은 스테이킹 중이 아닌 토큰의 일부를 소각하여 스테이킹하는 사람들의 수익은 94 | 전혀 없다고 볼 수 있는 모델이 있다고 가정해보겠습니다. 이 모델도 합리적이며, 현재 구조와 95 | 동일한 효과를 갖는다고 볼 수 있습니다. 핵심은, 스테이킹 중이 아닌 1/3의 $ATOM을 96 | 보유 중인 사람들에게 패널티를 주기 위해 스테이킹 중인 $ATOM 보유자들의 지분율을 올린 97 | 것은 수익으로 해석할 순 없습니다. 물론, 이 논점을 역으로 활용하여 이게 바로 스테이킹에 98 | 대한 인센티브라고 주장할 수도 있으니 예시를 들어드리겠습니다. 만약 $ATOM이 화폐와 같이 99 | 널리 분배되어 스테이킹 비율이 1%라고 가정할 시, 스테이킹에 참여하는 사람들에게 돌아가는 100 | 인플레이션은 수익에 가까운 성격일 것입니다. 101 | 102 | 역으로, 스테이킹 비율이 99%라고 가정한다면, $ATOM의 인플레이션율이 1,000,000%라는 말도 103 | 안되는 수치로 설정된다고 하더라도, 이러한 인플레이션은 개인의 지분율에 큰 변화를 주지 104 | 않기 때문에 수익이라고 볼 수 없습니다. 이는 인플레이션으로 지분율이 심하게 감소한 1%에 105 | 대한 패널티라고 인식할 것입니다. 차이점은, 전자는 후자보다 분배에 더 많은 변화를 106 | 가져온다는 점입니다. 또한, 이는 인플레이션이라는 지속적인 변수에 의존하므로, 토큰은 역동적인 107 | 성격을 가진다는 것을 의미합니다. 하지만, $ATOM의 본래 토크노믹스에 의하면, 인플레이션은 108 | 인센티브보다 기본적으로 패널티의 역할을 합니다. 109 | 110 | 이는 세무 자문이 아님을 다시 한번 밝힙니다. 당사는 세무 당국과 접선하여 명확한 가이드를 111 | 받을 계획이며, 이 모델의 논리를 설득하기 위해 노력할 것입니다. 현재 우리에게 놓여진 112 | 선택지 중 가장 불리하고 비이성적인 선택지는 지금처럼 인플레이션에 대한 수익을 일차원적으로 113 | 계산하는 방식입니다. 114 | 115 | 848번 의제에 찬성 투표를 하여 목표 스테이킹 비율인 2/3를 유지하지 않는 것(848번 의제의 116 | 통과 이후 필연적으로 발생할 상황)을 선택하는 사람들은 스스로 뿐만 아니라 모두를 해치는 117 | 결정을 내리는 것입니다. 상기 제시한 주장에 반대하여 인플레이션이 과세 대상이 될 확률을 118 | 높이는데 일조하는 것이기 때문입니다. 화폐성 토큰의 인플레이션은 비스테이킹에 대한 패널티보다 119 | 스테이킹에 대한 인센티브로 분류될 가능성이 높습니다. 120 | 121 | ## 부적절한 선례 122 | 123 | 848번 의제를 지지하는 사람들은 이제 하다못해 그들은 단순히 $ATOM을 스테이킹하는 124 | 사람들의 의견을 조사하고 있는 것이라고 주장하고 있습니다. 문제는 이와 같이 토크노믹스의 125 | 본질적인 변화를 주어 보안과 안정성과는 상반되는 태도를 취하는 의제가 $ATOM을 화폐성 126 | 토큰으로 개혁하겠다는 실제 의도와 그로 인한 영향에 대한 완전한 성명을 포함하지 않는다는 127 | 것입니다. 128 | 129 | 또한, 이 의제는 지속가능성에 대한 충분한 계획이나 보장 혹은 위험성에 대해서도 전혀 130 | 고지하고 있지 않습니다. 코스모스 허브를 위한 헌법조차 제정되어 있지 않다는 현실도 131 | 문제입니다. 더 나아가, 이 의제가 제안하는 발행량 감소는 계획에 따라 작동하며 변경 불가능한 132 | 비트코인의 반감기와는 전혀 다른 성격임에도 불구하고, 가격의 변동에 대한 의미를 내재하고 있는 133 | "반감기"라는 용어를 마케팅에 사용하고 있습니다. 134 | 135 | ## 스테이킹 비율의 감소 136 | 137 | 의제가 언급한대로, 현재 코스모스 허브의 스테이킹 비율은 목표 수치인 2/3보다 조금 아래인 138 | 상태입니다. 이 상황에 대해 당사는 다음과 같은 중대한 우려를 제기합니다. 현재 코스모스 허브는 139 | 목표 스테이킹 비율을 달성하기 위해 스테이킹 보상율의 상승을 통한 비스테이킹 $ATOM 패널티라는 140 | 메커니즘을 채택하고 있습니다. 848번 의제는 이 메커니즘을 실질적으로 중단시킵니다. 141 | 142 | 코스모스 허브는 현재 스테이킹 비율이 목표 수치 이하일 경우, 인플레이션율을 동적으로 조정하여 143 | 스테이킹을 유도합니다. 이 메커니즘은 현재 설계된대로 인플레이션율을 서서히 증가시킴으로써 144 | 더 많은 $ATOM 보유자들이 토큰을 스테이킹하여 네트워크의 보안을 강화하도록 작동하고 있습니다. 145 | 아래 그래프에서 확인하실 수 있다시피 이 메커니즘은 이제까지 설계 의도에 맞게 작동하고 있습니다. 146 | 그럼에도 불구하고 아래 그래프는 오류가 있는 계산법을 활용하여 이 메커니즘이 작동하고 있지 147 | 않다는 것에 대한 근거로 사용되었습니다(다만, 당사는 인플레이션율의 변화 속도는 증가시켜야 148 | 한다는 주장에는 동의합니다). 메커니즘이 스테이킹 비율을 상승시킬 반면, 인플레이션율 감소는 149 | 이의 감소로 이어질 것입니다. 150 | 151 | ![graph of time vs bond ratio on 152 | Gaia](https://github.com/atomone-hub/genesis/blob/0e65b56e4a0739287f2615ebd2c99d0c1bab4a74/resources/stakingrate.png) 153 | 154 | 848번 의제는 $ATOM의 높은 인플레이션율이 디파이가 제공하는 이율의 경쟁력을 감소시킨다고 155 | 다음과 같이 주장합니다. "*그러나, $ATOM의 높은 인플레이션율로 인해, 디파이 이율은 156 | **경쟁력**을 갖지 못하며, 이는 유저 수 확보와 채택의 방해되는 요소입니다.*". 먼저, 이 주장은 157 | 앞서 언급한 바와 같이 실제 이율과 인플레이션에 대한 잘못된 이해로부터 비롯되었습니다. 158 | $ATOM의 최대 연간 인플레이션율은 30%가 아니라 20%이며, 실질적인 최대 수익율은 8.33%입니다. 159 | 다음으로, 만약 해당 의제가 주장하는대로 $ATOM으로부터 발생하는 수익이 그렇게 높다면 유저 수와 160 | 채택이 증가해야 하는게 정상이라는 점에서 이 근거는 본질적으로 잘못되었다고볼 수 있습니다. 만약 161 | 이와 같은 수익률이 진짜라면, 이는 오히려 막을 것이 아니라 축하해야 할 일일 것입니다. 162 | 163 | $ATOM은 디파이가 제공하는 수익률 대비 높은 인플레이션율으로 인해 디파이 앱에서 사용하기에 164 | 적절하지 않다는건 사실입니다. 이것은 $ATOM이 애초에 화폐처럼 사용되기 위해 설계된 것이 165 | 아니기 때문입니다. 디파이 앱에서는 유동성 스테이킹 (liquid staking) 서비스를 활용하여 166 | $ATOM을 스테이킹 할 시 지급받는 디플레이션 성질의 유동성 스테이킹 토큰을 사용하는것이 보다 167 | 적절할 것입니다. 하지만, 이처럼 보상을 복리로 적용하는 행위는 리스크 또한 배로 증가시킨다는 168 | 점을 인지해야 합니다. 169 | 170 | 디플레이션 성질을 띄는 파생 토큰을 지원하는 스테이킹 관리 서비스를 지원할 시, 악의적인 171 | 체인 장악을 사전 방지하기 위해 유동성 스테이킹 토큰과 $ATOM 간의 변환을 제한하는 추가적인 172 | 보호 장치가 필요합니다. 이러한 장치가 없다면, 화폐성 토큰으로써의 $ATOM이 제공하는 보안과 173 | 스테이킹 토큰으로써의 $ATOM이 제공하는 보안의 수준에는 별 차이가 없을 것입니다. 스테이킹 174 | 토큰은 효과적인 보안 제어 수단으로 사용되기 위해 높은 유동성을 제공하는 디플레이션 성질의 175 | 토큰과 비교되는 여러 트레이드오프를 선택합니다. 이러한 보호장치가 없다면, 우리는 이 중대한 176 | 보안 이슈를 다루기 위해 ICS를 위해 사용될 수 있는 스테이킹 된 $ATOM의 비율을 제한하는 등 177 | 효과적이지 않은 방식을 선택해야 할 것입니다. 178 | 179 | ## IBC 브릿징 토큰의 보안 180 | 181 | AEZ에 속한 소비자 체인들은 ICS로 허브와 동일한 검증인들로부터 보호를 받기 때문에 특정 체인의 182 | 보안 결함을 통한 자산 탈취와 같은 문제들은 합의에 의한 롤백으로 해결할 수 있으며, 이 덕분에 183 | ICS AEZ의 경제적 보호 규모에 대한 문제는 사실 핵심 리스크가 아닙니다. 가장 중요한 문제는 184 | 코스모스 허브에 페깅된 IBC 토큰들에게 존재합니다. AEZ를 포함한 외부 체인들 로부터 이동하여 185 | 허브에 의해 관리되는 모든 IBC 토큰들은 탈취당할 위기에 놓일 수 있습니다. 186 | 187 | 이러한 토큰들은 악의를 가진 주체가 허브를 공격할 인센티브로 작용합니다. 만약 허브에 있는 모든 188 | IBC 페깅 토큰의 가치가 스테이킹 상태인 $ATOM의 1/3 (네트워크 파티션으로 이중 지불에 대한 189 | 패널티로 적용할 수 있는 최대 수치) 이하로 유지된다면 문제가 없겠지만, 현재 허브의 투표자들이 190 | $ATOM이 화폐성 자산으로 변해서는 안되는 이유도 이해를 하지 못하고 있는현재 상황에서 이런 제약을 191 | 걸도록 합의하는 것은 불가능해 보입니다. 또한, 대부분의 토큰은유동성이 낮아 피해자들에 대한 보상 192 | 또한 효과적인 구제 수단이 되지 못할 것입니다. 193 | 194 | ## 검증인 인센티브 구조의 비본질적인 개선 195 | 196 | 현재 코스모스 허브의 검증인 인센티브 구조 또한 문제가 있습니다. 모든 검증인들은 AEZ 내 197 | 각 체인을 보호하는데에 있어서 동일한 수준의 인센티브를 제공받아야 하며, 이는 각 검증인들로부터 198 | 요구되는 자원이 유사하기 때문입니다. 각 검증인의 $ATOM 위임 수량에 비례하여 검증인 수수료를 199 | 적용한 수준의 보상을 지급하는 현재 인센티브 구조는 결함이 있으며, 그것은 하위 검증인들이 상위 200 | 검증인들과 경쟁력 있는 수준의 노드를 제공하기 위해 충분한 수익을 낼 수 없다는 것입니다. 201 | 이는 ICS의 확장성과도 연결됩니다. ICS의 규모가 커짐에 따라, 모든 하위 검증인들은 적자를 202 | 면하지 못할 것이며, 간신히 손익분기점을 유지하는 검증인들 마저 사업 지속을 위해 검증인 노드의 203 | 보안을 저하할 수 있는 조치를 취할 수도 있습니다. 이는 이상적이지 않은 구조입니다. 204 | 205 | 848번 의제가 제안하는 변경사항들은 소형 검증인들에게 불공평한 수준의 영향을 미칠 것입니다. 206 | 이는 검증인 인센티브 구조가 개선되면 해결될 문제이지만, 그 전까지는 소규모 검증인들이 불필요한 207 | 리스크를 감소하도록 강제할 것입니다. 한 분석 결과에 따르면, 소비자 체인이 6개로 증가할 시, 208 | 코스모스 허브 검증인의 74% 이상이 적자를 맞이할 위험에 놓여있다고 합니다. 최대 인플레이션율을 209 | 감소시키는 것은 이 문제의 심각성을 키울 것이며, 검증인들의 적자전환을 가속화 할 것입니다. 210 | 우리는 중앙화로 이어질 수 있는 다수 검증인의 적자전환을 용납해선 안됩니다. 211 | 212 | ## 최소 인플레이션율 유지의 중요성 213 | 214 | ICS 트랜잭션의 확장으로 인해 트랜잭션 수수료로부터 발생하는 보상이 $ATOM의 인플레이션율을 215 | 0이나 음수로 감소시킬 수 있다는 점은 사실입니다 (거버넌스의 동의 하에). 그러나, 만약 216 | 이것이 $ATOM의 화폐성 토큰으로의 홍보 및 채택으로 이어진다면, 좋지 않은 현상일 것입니다. 217 | 이것을 이유로 우리는 최소 인플레이션율인 7%를 제거하지 않는 것을 권유합니다. 이는 $ATOM 218 | 토큰 홀더들의 지적 수준을 유지하여, 전문성이 없는 토큰 보유자들이 부정적인 영향을미치는 것을 219 | 방지할 것입니다. (화폐성 토큰의 대상은 대중이므로, 전문성이 보다 떨어질 것이라고 예상할 220 | 수 있습니다) 221 | 222 | 최소 인플레이션율을 7%로 유지하는 것에 대한 부정적인 결과로는 스테이킹 비율이 목표 수치인 223 | 2/3 이상으로 증가할 시, 시중에 유통되는 수량이 너무 적어 $ATOM의 시가총액을 계산하기 224 | 어려운 상황을 발생시킬 수 있다는 점입니다. 이는 허브가 제공하는 보안에 대한 수치화에 대한 225 | 어려움을 의미합니다. 그러나, 이는 ICS 트랜잭션으로부터 발생하는 보상이 높다고 가정한다면, 226 | (스테이킹 비율이 높은 이유라고 볼 수 있습니다) 문제되지 않습니다. 왜냐하면현재와 같이 227 | 수수료가 $ATOM이 아니라 타 토큰으로 지불된다고 가정할 시, 허브의 가치를 측정하기 위해 228 | 지속적인 매출을 기반으로 다른 방식으로 평가할 수 있기 때문입니다. 229 | 230 | ## 앞으로의 방향성 231 | 232 | 당사는 상기 언급된 이유들로 인해 848번 의제에 절대적으로 반대합니다. 그러나, 네트워크의 233 | 보안을 타협하지 않으며, 조심스럽고 신중하게 접근한다는 가정하에 실험, 혁신, 토론을 위한 234 | 공간은 필요하다고 생각합니다. $ATOM이 화폐성 토큰이 되어선 안된다는 점을 감안하면, 235 | 네트워크를 보호하기 위한 최소 인플레이션율 7%와 최대 인플레이션율 20%는 현재 설계대로 236 | 작동하고 있다고 볼 수 있습니다. 이 모델에 대한 어떠한 변화도 $ATOM을 화폐성 자산으로 237 | 마케팅하는 것을 부추킬 위험이 있습니다. 당사는 대신 목표 스테이킹 비율 달성을 위해 238 | 인플레이션율이 더 신속하게 반응하도록 `NextInflationRate` 함수를 조정하는 것에 대한 239 | 논의를 시작하고자 합니다. 당사는 커뮤니티가 합심하여 원하는 결과를 달성할 수 있도록 이 240 | 제안에 대한 장단점을 공개적으로 논의하길 희망합니다. 코스모스 허브의 지속적인 성장과 241 | 반영을 위해시장 내 경쟁력과 네트워크 보안 및 경제적 안정성 사이의 균형을 유지하는 것은 242 | 필수적입니다. 243 | 244 | 현재 의제의 투표 결과와 커뮤니티 일원들간의 토론을 포괄적인 시야로 바라볼 때, 현재 중대한 245 | 의사결정을 이끌 수 있는 지도자들의 부재는 명확하다고 볼 수 있습니다. 82번 의제 이후, 246 | 당사는 코스모스 허브 거버넌스의 개선을 위한 제안들을 준비하고 있었으며, 이 제안들은 848번과 247 | 같은 의제보다 우선시 되어야 합니다. 안타깝게도, ICF는 어떠한 도움도 주고 있지 않으며, 248 | 종종 바람직하지 않은 의제들을 지지하는 모습을 보이고 있습니다. 848번 의제에 거부권을 249 | 행사하여 통과를 막을 가능성이 있지만, (독자 여러분도 거부권을 행사하시길 권유드립니다) 250 | 현재 코스모스 허브는 성공을 위해 필요한 것들이 갖춰져 있지 않다고 생각합니다. 당사는 251 | 적극적인 조치가 없을 경우, 상황이 더욱 악화될 것이라고 예상합니다. 252 | 253 | AiB는 곧 허브의 현상 개선을 위한 계획을 발표할 에정입니다. 당사의 발표를 기다려 254 | 주시길 바랍니다. 255 | 256 | 257 | —---- 258 | 259 | ## 트위터 스레드 260 | 261 | 1/ 코스모스 커뮤니티 여러분께 안내드립니다. All in Bits (AiB)는 ATOM의 반감기를 262 | 도입하자는 848번 의제에 거부권을 행사할 예정입니다. 당사는 코스모스의 핵심 가치인 보안, 263 | 지속가능성, 탈중앙화를 우선시하며, 이러한 본질들을 위협하는 의제를 지지할 수 없음을 밝힙니다. 264 | 265 | 2/ 848번 의제는 $ATOM을 화폐성 토큰으로 전환시키고자 합니다. 그러나, $ATOM의 핵심 266 | 기능은 가장 높은 수준의 보안이 요구되는 IBC 허브를 위한 스테이킹 토큰이었으며, 이것은 절대 267 | 변하지 않는 사실입니다. 268 | 269 | 3/ 충분한 연구 및 논의 없이 $ATOM의 최대 인플레이션율에 반감기를 도입하는 결정은 270 | 바람직하지 않은 결과로 이어질 것입니다. 대표적인 문제로 $ATOM의 스테이킹 비율이 큰 271 | 폭으로 감소될 것으로 예상되며, 이는 IBC와 ICS의 채택에 악영향을 미치며 검증인들에게 272 | 지급되는 보상을 감소시켜 코스모스 네트워크의 존재적 위험으로 이어질 수 있습니다. 273 | 274 | 4/ 848번 의제는 코스모스 생태계를 안전하게 지켜오며 검증된 토크노믹스에 큰 변화를 275 | 적용할 것을 제안하고 있습니다. 더 나아가, 해당 의제는 비트코인의 변경 불가한 276 | 반감기와는 전혀 다른 발행량 감소임에도 불구하고 "반감기"라는 용어로 마케팅을 시도하고 있습니다. 277 | 278 | 5/ 848번 의제의 제안자들과 커뮤니티 여러분이 전반적으로 허브가 보안 지출에 소비하는 279 | 비용과 스테이킹 보상을 계산하는 방식은 근본적으로 잘못되었으며, 우리는 거버넌스의 280 | 일원들로써 논리에 오류가 있는 근거를 내세우는 의제를 통과시키지 않을 의무가 있습니다. 281 | 282 | 6/ 848번 의제는 소형 검증인들에게 불공평한 수준의 영향을 미칠 것입니다. 한 분석 결과에 283 | 따르면, 소비자 체인이 6개로 증가할 시, 코스모스 허브 검증인의 74% 이상이 적자를 284 | 맞이할 위험에 놓여있다고 합니다. 검증인 인센티브 문제를 해결하기 전에 최대 인플레이션율을 285 | 감소시키는 것에 대한 논의가 이루어지는 것은 바람직하지 않습니다. 286 | 287 | 7/ 현재 커뮤니티의 의사결정을 이끌 수 있는 지도자들의 부재는 명확하다고 볼 수 있으며, 288 | 당사는 현 상황이 더욱 심각해질 것이라고 예상합니다. 당사는 현상 개선을 위한 계획을 289 | 수립하고 있으며, 이를 빠른 시일 내 커뮤니티 여러분과 공유할 예정입니다. 290 | 291 | 8/ 커뮤니티의 이성적인 의사결정을 위해 토론에 제시되는 근거들에 대한 투표자들의 충분한 292 | 이해는 필수적입니다. 당사는 논점들의 대한 검토와 토론에 여러분들을 초대하고자 합니다. 293 | 보다 자세한 내용은 당사의 블로그에서 확인하시길 바랍니다. 294 | 295 | 296 | 9/ 당사는 금일 오후 10시 (PDT)에 트위터 스페이스를 주최하여 848번 의제에 대해 논의할 297 | 예정입니다. 만약 여러분이 저희의 우려에 공감하시거나, 토론에 의미있는 기여를 하고 298 | 싶으시다면, 저희와 함께하시길 바랍니다. 299 | 300 | #CosmosDebate #TwitterSpace 301 | -------------------------------------------------------------------------------- /FAQ.md: -------------------------------------------------------------------------------- 1 | # AtomOne FAQ 2 | 3 | **This FAQ attempts to consolidate and answer most of the questions received so far about AtomOne and GovGen, but discussions are ongoing in the [repo](https://github.com/atomone-hub/genesis/issues). You can join an existing discussion by clicking on “Issues,” selecting the topic that interests you, and adding your comment, or you can open a new discussion by starting a new Issue or creating a Pull Request. Also, if you would like to add to this effort, please submit a PR with your contribution. You can also join the unofficial [AtomOne Discord](https://discord.com/invite/atomone) channel and contribute to the conversation there.** 4 | 5 | ### Q: What is AtomOne, and how does it benefit the Cosmos community? 6 | 7 | A: AtomOne is a branch of Gaia that complements the broader Cosmos ecosystem with a security-conscious alternative hub. AtomOne recommits to the founding vision of the Cosmos Hub as a minimal IBC/ICS hub secured by a staking token targeting two-thirds of the stake bonded. AtomOne contributors uphold the original values of the Cosmos Hub—security, sustainability, decentralization—and agree that hub minimalism enforced by a written constitution is the only way to ensure financial security and scale to billions of people. 8 | 9 | AtomOne’s tokenomics, core shards, growth plan, and responsibilities align with a true minimal hub. Smart contract systems and VMs do not live on the Hub but on consumer shard chains to preserve utmost security and efficiency. AtomOne solves the scaling of transaction throughput using an optimized version of ICS (scaled security) where the validator sets are implicit for fast inter-hub communication without sacrificing independent BFT consensus layers. 10 | 11 | ### Q: What is ATONE, and how does it differ from ATOM? 12 | 13 | A: ATONE is a staking token, as originally intended for ATOM. ATONE will maintain the ⅔ majority staked target to ensure the security of the AtomOne chain. AtomOne contributors align highly with the vision as a minimal IBC-token-pegging and ICS hosting hub and that the ATONE token must never become a monetary token, as prop 848 does to ATOM. 14 | 15 | ### Q: Does AtomOne offer insurance against a Cosmos Hub failure? 16 | 17 | A: The passing of 848 presents manifold risks to the Cosmos Hub and ATOM token, which can be read in detail in an [AIB blog post here](https://allinbits.com/blog/nwv-to-prop-848-atom-must-not-be-money/). AtomOne re-commits to the original vision and primary mission of Cosmos Hub and provides a more security-conscious alternative to the Cosmos Hub. 18 | 19 | ### Q: What does AtomOne mean for the original Cosmos Hub? 20 | 21 | A: AtomOne does not compete with the Cosmos Hub but offers a bridge to make it more secure while implementing improved technical designs to guide Cosmos Hub’s future development. AtomOne contributors may also be contributors to the Cosmos Hub that align with the need for greater security, acting as a political party that advocates for steering the Hub toward making safer decisions. While AtomOne preserves hub minimalism, the AtomOne ecosystem will support innovative solutions such as liquid staking and smart contract systems deployed on ICS-secured shard chains. 22 | 23 | ### Q: When will AtomOne launch? 24 | 25 | A: There is no definitive timeline for the launch of AtomOne yet, as this will depend on community involvement and willingness to support the new chain. However, the software is already available and can be iterated over time to launch the AtomOne chain quickly. To ensure alignment throughout the creation of AtomOne and assess the sentiments of NO and NVW voters on prop 848, we propose launching a governance-only chain first, GovGen. GovGen will enable the completion of the repository, preparation of the documentation in a decentralized and fair way, and establishment of the Genesis for AtomOne (more on GovGen below). 26 | 27 | ### Q: How can I contribute to AtomOne? 28 | 29 | A: Anyone can contribute to AtomOne, as it is a community-driven initiative and the decision-making process is collaborativе. If you understand the importance of hub minimalism for security and sustainability, join the movement. If you would like to contribute, sign up for a GitHub account (if you don’t already have one) and head over to the [AtomOne repo](https://github.com/orgs/atomone-hub/repositories). You can join an existing discussion by clicking on “Issues,” selecting the topic that interests you, and adding your comment, or you can open a new discussion by starting a new Issue or creating a Pull Request. 30 | 31 | Alternatively, you can join the unofficial [AtomOne Discord](https://discord.com/invite/atomone) channel and contribute to the conversation there. 32 | 33 | ### Q: Is AtomOne the final name of the new chain? 34 | 35 | A: The AtomOne name is a placeholder pending the community’s input and discussions. 36 | 37 | ### Q: Is $ATONE the ticker symbol? 38 | 39 | A: Discussions are ongoing about the ticker symbol, and there is an open issue in the repo ([#63](https://github.com/atomone-hub/genesis/issues/63)). As it stands, $ATONE is the agreed-upon ticker symbol for AtomOne. If you have another idea, you are welcome to comment on the conversation. 40 | 41 | ### Q: How will the tokens be distributed? 42 | 43 | A: The distribution method is an ongoing discussion in [issue #12](https://github.com/atomone-hub/genesis/issues/12). As it stands, ATONE tokens will be mainly distributed to those who voted ‘NO’ or ‘NWV’ on prop 848 and are aligned with the vision of ATOM as a staking token. The ICF will be excluded from the distribution, and instead, 10% of the final amount will be allocated to contributors and on-chain DAOs. 10% of ATONEs will be premined for various purposes (such as pre-launch contributors and early adopters, IBC contributions, ICS contributors, etc.). See ATONE distribution details [here](https://github.com/atomone-hub/govgen-proposals/blob/main/001_ATONE_DISTRIBUTION.md) . 44 | 45 | ### Q: How much will I be slashed for voting YES on Prop 848? 46 | 47 | A: In principle, all ‘YES’ votes on #848 will be slashed, as their decision does not align with the values of the new chain, which focuses on ATONE's intrinsic value as a staking token rather than a monetary token. However, there could be a small distribution made to ‘YES’ voters, as the details of the airdrop distribution are still being discussed (join the discussion on the repo). The final decision of what Genesis will look like will be taken by the community and voted on through the GovGen chain. 48 | 49 | ### Q: Will I be excluded for not voting on Prop 848? 50 | 51 | A: Airdrop distribution is still up for discussion on the repo, but non-voters will likely be included in the distribution. We want AtomOne to give concessions to Gaia and support it without being competitive or discriminatory. One such concession may be allowing liquid stakers to earn ATONE from staking ATOMs on AtomOne. These questions should be discussed and answered by the GovGen chain. 52 | 53 | ### Q: Will I receive an airdrop for my ATOM if they are locked/LP’d/liquid staked/etc. ? 54 | 55 | A: Airdrop distribution discussion is ongoing, but liquid-staked, LP’d, and locked ATOM could be included in the distribution. The community must agree and do the legwork to track the tokens. 56 | 57 | ### Q: Do NO and NWV votes carry the same weight? 58 | 59 | A: Airdrop distribution is tentative and up for discussion on the repo, but NWV may be weighed heavier than NO. 60 | 61 | ### Q: Is there a distribution snapshot? 62 | 63 | A: The initial distribution snapshot will likely be taken from the final results of prop 848 (and possibly Prop 82). Those who voted ‘NO’ or ‘NWV’ will automatically be added to the airdrop distribution list with a future calculation of the amount. The snapshot for the GovGen chain will be taken immediately after the closing vote on 848. 64 | 65 | ### Q: When will the airdrop be? 66 | 67 | A: The airdrop will happen when all the work is completed and the chain is live. 68 | 69 | ### Q: How can I become a validator on AtomOne? 70 | 71 | A: AtomOne will use a Proof-of-Stake delegation system similar to Cosmos Hub with some modifications to fix validator incentives and ensure that validators are paid more fairly and evenly. The incentive system is still a work in progress on the repo. However, priority will be given to validators who voted ‘NO’ and ‘NWV’ on Prop 848. 72 | 73 | ### Q: How do we encourage developer activity on the platform, and how do we fund the development of the chain? 74 | 75 | A: The initial premine will reserve funds for development, and the transaction fees will fund developers. Ideally, AtomOne will support DAO systems and smart contracts that specify how much developers are getting paid and for what. Everything should be recorded transparently and on-chain. GovGen should be used to figure out the scope of AtomOne and define what is and is not allowed in the AtomOne constitution. 76 | 77 | ### Q: What is the incentive for validators to contribute early in GovGen? Will they be rewarded with incentives on AtomOne? 78 | 79 | A: Early contributors have historically been rewarded by the chain, and some incentives for participation could make sense. However, we don’t want to draw in the wrong set of validators more motivated by the money than the idea. 80 | 81 | ### Q: If we slash the validators who voted YES, how do we secure additional validators to ensure the chain is decentralized? 82 | 83 | A: AtomOne will be community-driven, with opportunities for new validators that align with the chain’s vision. People who contribute meaningfully to the AtomOne repo will have opportunities to earn tokens and spin up a node if they are willing and aligned with the new chain’s values. AtomOne intends to fix validator incentives so that validators are incentivized to secure ICS consumer chains and hub shards through a constitutional economic model, where every validator is paid to run these services. 84 | 85 | ### Q: What is the plan for scaling AtomOne? 86 | 87 | A: AtomOne solves the scaling of transaction throughput using an optimized version of ICS (scaled security) where the validator sets are implicit for fast inter-hub communication without sacrificing independent BFT consensus layers. 88 | 89 | ### Q: Will AtomOne use Cosmos Hub’s shared security? 90 | 91 | A: AtomOne hub will have its own ICS model (scaled security), a modified and optimized version of ICS1. 92 | 93 | ### Q: Is there a possibility of AtomOne and Cosmos Hub providing security to each other through mesh security? 94 | 95 | A: This could be a possibility in the future. However, mesh security is still a developing technology and is something to consider at a later date. 96 | 97 | ### Q: What is GovGen? 98 | 99 | A: GovGen is a governance-only chain proposed as an independent component of AtomOne Genesis. The proposed token, GOVGEN, is only for governance (and staking for governance). This chain software is proposed as a fork of cosmoshub4 with minimal modifications; for example, SendTx will be disabled for GOVGEN. GOVGEN cannot be transferred, sold, or given to another individual or entity. It has no cash value and cannot be redeemed for cash, credit, or any other item of value. 100 | 101 | GovGen is not intended to be the main AtomOne chain. It is intended only for the purposes of assessing the sentiments of the NO and NWV voters on Prop #848, which was the defining proposition for the branch and the genesis of AtomOne. GovGen will enable the community to assess the support for AtomOne and discuss the next steps. 102 | 103 | ### Q: Who can take part in GovGen? 104 | 105 | A: The criteria for inclusion in this governance set is simply those who voted NO and NWV on Prop 848. NoWithVeto voters will not be given a bonus for their veto for the purpose of the AtomOne GovGen chain. GovGen will not be the governance for AtomOne but will bootstrap the requirements and definitions of the new chain. 106 | 107 | ### Q: How will the voting system work? 108 | 109 | A: We should start as simply as possible with minimal modifications to Cosmos Hub and not require new tooling (which could present a point of vulnerability) to be able to use the system. This will allow us to be more agile and run the chain faster. We could use the Gaia CLI to sign transactions and Cosmos wallets Keplr and Leap. We can make some minor tweaks to the governance module, to increase the governance duration, maybe to even include an infinite duration so that votes can be changed at any time. All these issues will be discussed on the GovGen chain. 110 | 111 | We suggest increasing the threshold of proposals passing from 51% to 67% and holding off on making decisions without at least ⅔ majority on proposals. This will ensure that the decisions taken are safer and that there is no sizable vehement opposition that tries to sabotage the chain or affect consensus. Even after decisions are taken on GovGen, they should not be considered set in stone but may be subject to change. 112 | 113 | ### Q: How will the distribution of GovGen happen? Will it be equally distributed to all wallets that voted NO, or will it be prorated according to stake? 114 | 115 | A: This is a Proof of Stake system, so we will distribute according to stake, especially to avoid distributing to dust/bot accounts. NWV will not receive additional rewards from NO voters. ABSTAIN voters will not be included in GovGen, but they will receive rewards (proportionately slashed to what the actual distribution of YES versus NO was for that proposal) on AtomOne. 116 | 117 | ### Q: Should wallets that have not directly voted but delegated to their validators be included in the GovGen token distribution? 118 | 119 | A: Yes. We don’t want to punish people who did not vote because they agreed with their validator’s vote. In fact, the system was designed so that individuals do not have to vote but can delegate their votes. If we want to include this stipulation in the governance that individuals should actively vote, we should introduce it beforehand and not afterward. Let’s hold a poll to see how the community feels about this. 120 | 121 | ### Q: How about wallets with multiple validators, including validators that voted YES? 122 | 123 | A: If we introduce too many penalties, we risk reducing the participation in GovGen and being unable to reach quorum on proposals. Moreover, the YES votes are already excluded from the GovGen chain, and this part of the vote has already been considered. 124 | 125 | ### Q: What kind of support will validators be offered for supporting AtomOne and GovGen? 126 | 127 | A: We believe that validators should receive more or less equitable payment to ensure fairness and make sure that smaller validators are able to work and new validators can get started and ramp up and be paid according to the work they put in and how many shards they are running. Incentives and disincentives need to be baked into the reward system to make sure this happens. The discussion is ongoing, and you can read more about validator incentives in the AtomOne repo. 128 | 129 | ### Q: Should we count validator delegations for GovGen or only the voters who explicitly voted? 130 | 131 | A: Since there was no prior agreement that non-voters (who otherwise inherit their validator's votes) would ever be punished, we should not exclude them. We would significantly dilute participation by excluding the stakers who inherited their validators' votes. However, perhaps governance votes on GovGen could pass both modes of tallying (with and without delegations) so that validators can also agree to the changes proposed as well as the stakers. This discussion is ongoing in [issue #71](https://github.com/atomone-hub/genesis/issues/71#issuecomment-1859281531). 132 | 133 | ### Q: Will GOVGEN tokens be transferable? 134 | 135 | A: SendTx will be disabled for GOVGEN. GOVGEN cannot be transferred, sold, or given to another individual or entity. It has no cash value and cannot be redeemed for cash, credit, or any other item of value. 136 | 137 | ### Q: How will you prevent spam governance proposals on the GovGen chain? 138 | 139 | A: We propose setting a very high deposit limit for the proposals to prevent spamming. If a proposal is rejected with more than ⅓ voting NWV, we suggest the deposit be considered for slashing for any relevant future Genesis distribution. Furthermore, if the NO and NWV voters judge an account to be spamming, the spammer’s tokens in any relevant future Genesis distribution may be subject to slashing. 140 | 141 | ### Q: How will the GovGen chain be secure? 142 | 143 | A: AiB has volunteered to provide recommendations about Genesis software readiness, along with publishing and auditing procedures. However, this should not be the only source of information, especially as this is a decentralized process. Nothing that hasn’t already been used and audited will be used for the GovGen chain. 144 | 145 | ### Q: Can we use DAO DAO for the GovGen chain? 146 | 147 | A: As we are using a staking token, we plan to deploy a PoS GovGen chain in collaboration with validators, in line with the proposed practices. Exploring the use of DAO DAO is also an option, subject to community interest. 148 | 149 | ### Q: Can you clarify the concept of Hub Minimalism? 150 | 151 | A: Hub Minimalism is discussed in depth on [GitHub here](https://github.com/decentralists/DAO/tree/main/cosmoshub). In a nutshell, the key to durability and scalability is minimal implementation. Just as Bitcoin does one thing well (reliably transferring value between parties), AtomOne will focus on doing one thing well: acting as a security provider that is dependable and reliable for multi-token IBC pegging, keeping the attack vector on the Hub as small as possible. 152 | 153 | -------------------------------------------------------------------------------- /STAKING_VS_MONEY.md: -------------------------------------------------------------------------------- 1 | _Originally published Nov 21st, 2023 by All in Bits, Inc; Christina Comben, 2 | Adriana Mihai, Giuseppe Natale, Jae Kwon, Valeh Tehranchi_ 3 | 4 | # NWV to Prop 848 – $ATOM Must NOT be Money 5 | 6 | AiB will soon be voting NWV to prop 848, $ATOM “Halving,” which aims at turning 7 | the $ATOM token into a monetary token rather than a staking token. We value 8 | Cosmos' core components of security, sustainability, and decentralization, and 9 | cannot support a proposal that may threaten its foundational pillars. Halving 10 | $ATOM max inflation at this time with insufficient research and discussion will 11 | lead to more undesirable outcomes, namely lowering the bonded ratio of staked 12 | $ATOMs significantly, hampering the growth of IBC and ICS adoption, affecting 13 | the rewards for validators, and placing the entire Cosmos network at risk. 14 | 15 | Prop 848 represents a significant shift from the established tokenomics of the 16 | Cosmos Hub that has kept our ecosystem secure and dependable since inception. 17 | While prop 848 argues that it would enhance the $ATOM Economic Zone (AEZ) and 18 | increase $ATOM's competitiveness in the DeFi space, we disagree categorically 19 | and raise the following substantial concerns: 20 | 21 | ## Destabilizing the Security Model 22 | 23 | An IBC hub must not be secured by a monetary token. Securing the chain with a 24 | monetary token might make sense for non-hubs that don’t rely on the security of 25 | its IBC token pegs (for example, if the chain is only concerned about itself). 26 | But this isn’t true by definition in the Cosmos of IBC interconnected chains. A 27 | good money token is widely distributed by definition, and therefore less by 28 | proportion to the whole would be staked to validators. This leaves the 29 | governance of the chain open to be taken-over by anyone who has enough of these 30 | monetary tokens, and the increase in the liquidity of this token practically 31 | guarantees the success of any adversary with sufficient capital. When the 32 | competition is the status quo banking system, there is ample capital to be used 33 | against the underdog. 34 | 35 | In contrast, a staking token that maintains that the supermajority (say ⅔) 36 | stays staked has less in circulation as liquid tokens, so the adversary is not 37 | guaranteed to be able to purchase enough on the market to succeed in taking 38 | over control; while in some cases it may be possible, it is also true that in 39 | the scenario with $ATOM as money, the adversary is practically guaranteed 40 | success of takeover given reasonable assumptions. It doesn’t make sense in the 41 | long run to change what could be secure against the most powerful of 42 | adversaries, to one that is guaranteed to fail. And if the reader doesn’t agree 43 | that the model should be resilient against the most powerful of adversaries, it 44 | means the reader is not aware of history. 45 | 46 | Should proposal 848 pass, it starts a precedent of sliding down the slippery 47 | slope of degen behavior, encouraging more yield degens to decrease the 48 | inflation even further, and in general, the composition and intelligence of the 49 | $ATOM token will decrease to such an extent that it will make harmful and 50 | dangerous decisions; because the token holders are not experts in tokenomics as 51 | they ought to be, and instead only care for short-term yield. This is made 52 | worse by the fact that the Gaia Cosmos Hub is an IBC token-pegging hub, and so 53 | there will be real incentives for malicious parties to dupe the unsuspecting 54 | voters into approving something that is detrimental to the Hub, its users, and 55 | Cosmos at large, or for the malicious parties to use its voting power to steal 56 | these tokens outright. 57 | 58 | $ATOM's primary utility is – and has always been – staking. $ATOM was never 59 | designed to be a monetary token but a staking token enabling an IBC hub that 60 | requires the highest level of security (see [original token model 61 | paper](https://github.com/cosmos/cosmos/blob/0141bbcdbf68a784348ba059096f8238c696f9a8/Cosmos_Token_Model.pdf)). 62 | The original design of $ATOM's dynamic inflation, acting as a penalty to 63 | non-stakers, plays a crucial role in incentivizing network participation and 64 | security by intentionally limiting the amount of liquid trading $ATOMs so as to 65 | make hostile takeovers prohibitively expensive. Prop 848 risks undermining 66 | these foundational principles and destabilizing the network's security model. 67 | 68 | ## Phantom Revenue and Flawed Arguments 69 | 70 | We should not be passing proposals that are based on faulty premises. The way 71 | the proponents of prop 848 have been calculating the cost of security, as well 72 | as, in general, how the community is calculating staking income or revenue, is 73 | fundamentally flawed because $ATOM is a staking token with ⅔ staked. What we 74 | need now is to address this problem by better explaining the better mental 75 | model to everyone, and by getting the needed clarification from tax 76 | authorities. Please note that nothing here is tax advice, and you should talk 77 | to your own tax advisors. 78 | 79 | When the annual compounded inflation rate of $ATOM is 20%, and because there 80 | are generally ⅔ of the $ATOM staked, when you stake your $ATOMs, you earn a 30% 81 | return from the original stake, annually. What most people do here is assume 82 | that the 30% increase in token supply multiplied by the price of the $ATOM 83 | token is all revenue, but we believe this is the wrong way to calculate net 84 | revenue for the $ATOM staking token. While the total number of $ATOMs you hold 85 | at the end of the year is 1.3x in quantity, the reality is that each $ATOM also 86 | went down in proportional utility and value due to the substantial inflation of 87 | 20%. What matters is not the number of $ATOMs one holds, but the fraction they 88 | hold in comparison to the whole. The effective income considering inflation is 89 | actually 1.3x / 1.2x, which equals 8.33%. That is a massive factor of 3.6 to 1. 90 | 91 | As a thought exercise, if we were to double the amount of $ATOM tokens every 92 | address has, and keep the bonding ratio the same, the price of $ATOM would 93 | immediately decrease by 50% (but the net value of our holdings would not 94 | change); and usually this shouldn’t be seen as a taxable event, and it isn’t in 95 | the case of a stock-split. 96 | 97 | As another thought exercise, consider the definition of $MASS = $ATOM / 98 | sum($ATOM), where sum($MASS) equals say 1. This unit of measure better 99 | represents the intrinsic value of the $ATOM token as a fraction of the whole. 100 | With this unit of measure, the calculated income would actually be 8.33% (as 101 | opposed to 30% in our example). 102 | 103 | Besides the naive model and the $MASS model, the third model says that we 104 | should be burning non-staker tokens and claim that the stakers have zero 105 | income. This is also reasonable – just because one’s relative ownership in 106 | fractions has gone up doesn’t mean that it should be treated as income, since 107 | the primary purpose is to disincentivize unbonded tokens and is a form of 108 | punishment to a minority subset (of ⅓ more or less). Of course, you can flip 109 | this argument around and say that it’s still an incentive for staking (it can 110 | be seen as both), so here is a clarifying example; if the $ATOM distribution 111 | were like money and massively distributed, and if say only 1% of the $ATOMs 112 | were staked, then the inflation going to the stakers is more clearly income. 113 | 114 | In comparison, if 99% of the $ATOMs were staked, even with the ludicrous 115 | inflation rate of 1,000,000% (for the sake of argument) the inflation shouldn’t 116 | be seen as income since the overall distribution by ratio hasn’t changed much 117 | at the end of the day; naturally, we perceive this more as a penalty for the 1% 118 | that got inflated away. The difference is that the former changes the 119 | distribution much more than the latter (generally, the 1% is not like the 120 | 100%), and since it depends on a continuous variable (the inflation rate), it 121 | is clear that a token can be on a spectrum. Yet it is also correct to say that 122 | $ATOM’s original tokenomics makes it primarily a penalty rather than an 123 | incentive. 124 | 125 | This is not tax advice, but we will approach the relevant tax authorities to 126 | get better clarity and argue for this model. Of all the options at our 127 | disposal, continuing to calculate revenue/income the naive way is the least 128 | favorable, irrational option because it is unnecessarily self-sabotaging. 129 | 130 | Those voting in favor of #848 and choosing to deviate from the ⅔ staking target 131 | (which is what will happen after #848) are further sabotaging themselves and 132 | everyone else by destroying the arguments above in favor of more favorable tax 133 | treatment. The inflation rewards of a monetary token are less likely to be seen 134 | as a penalty for non-staking, but a positive incentive to stake. 135 | 136 | ## A Bad Precedent 137 | 138 | Those who argued in favor of #848 have gone so far as to argue that they are 139 | merely gauging the interest of the stakers. This fundamental change to 140 | tokenomics that goes counter to security and stability is offered without full 141 | disclaimers about the true intended purpose (to make $ATOM a monetary token) 142 | and its effects. It is also offered without sufficient planning and guarantees 143 | for any sort of consistency, and without the needed disclosures of risks. 144 | Indeed we don’t even have a Constitution ratified for the Cosmos Hub yet. 145 | Furthermore, to make things worse, this proposal is marketed as a “halvening” 146 | which has implications about expected price movements, while what is proposed 147 | is nothing at all like the immutable halvening schedule of the Bitcoin chain. 148 | 149 | ## A Further Decline in the Bond Ratio 150 | 151 | As noted in the proposal, the current bond ratio of the Cosmos Hub is slightly 152 | below the target, not surpassing the ⅔ threshold. This existing condition 153 | raises a significant concern: by halving the max inflation, the proposal 154 | effectively arrests the increase in staking reward rate, a mechanism currently 155 | in place to disincentivize non-staking and push the bond ratio towards the 156 | target. 157 | 158 | The design of the Cosmos network dynamically adjusts the inflation rate to 159 | encourage staking when the bond ratio is below the desired threshold. This 160 | mechanism is functioning as intended, gradually increasing the inflation rate 161 | to incentivize more $ATOM holders to stake their tokens, thereby securing the 162 | network. And it has worked as intended in the past, as shown in the graph 163 | below. Yet, it was cited as showing that the mechanism doesn’t work using 164 | flawed math (however, we concede that the rate of change could be faster). The 165 | proposed reduction will likely result in a further decline in the bond ratio 166 | when the mechanism should push the ratio to go higher. 167 | 168 | ![graph of time vs bond ratio on 169 | Gaia](https://github.com/atomone-hub/genesis/blob/0e65b56e4a0739287f2615ebd2c99d0c1bab4a74/resources/stakingrate.png) 170 | 171 | The proposal claims that the high $ATOM inflation rate makes DeFi yields less 172 | competitive. The proposal states, “However, due to the high inflation rate of 173 | $ATOM, DeFi yield can hardly compete which slows down user growth and 174 | adoption.” First and foremost this is a gross misunderstanding of the real 175 | yield from inflation, which as mentioned before, is with the maximum 20% 176 | compounded annual inflation rate, not at most 30% annual yield, but a net 177 | 8.33%. Secondly, the reasoning is completely flawed because if the yield from 178 | $ATOM is so high then it should _increase_ user growth and adoption, not 179 | decrease it. This would be something to celebrate, if true, not stifle. 180 | 181 | The higher inflation rate of $ATOM does make it ill-suited for use within DeFi 182 | applications because $ATOM inflates more in comparison to the yields. But $ATOM 183 | was never intended to be used this way as money. It makes more sense to use a 184 | “liquid staking” (a misnomer) service to manage the staking of $ATOM and to use 185 | the resulting more deflationary liquid staking tokens within DeFi applications, 186 | but compounding rewards like this also compounds the risk and does not come for 187 | free. 188 | 189 | With the support of such stake management services that offer a more 190 | deflationary derivative token, there must be additional checks against hostile 191 | takeovers by limiting or throttling how many “liquid staking” tokens can be 192 | converted back to $ATOMs. Otherwise, there would be little difference in 193 | security between a monetary $ATOM token and a staking $ATOM token, but the 194 | distinction between the staking token and the more liquid deflationary token is 195 | the basis for introducing control measures with different tradeoffs. Otherwise, 196 | we are left with crude levers to manage this key security issue, such as the % 197 | of stake that can use ICS, which is not exactly what we need to measure. 198 | 199 | ## IBC Pegged Tokens 200 | 201 | The real risk in security here is not with ICS AEZ economics because what is 202 | within the AEZ is secured by the same validator set with ICS, and the chain can 203 | agree to roll back any transactions that are deemed as leading to theft (e.g. 204 | through an exploit). The real risk lies with pegged IBC tokens on the Cosmos 205 | Hub. The tokens that are controlled by the Hub but originate from other chains 206 | external to the Hub and AEZ are all at risk of being stolen. 207 | 208 | All these tokens by default create a real incentive for a malicious actor to 209 | exploit. This might be tolerable if the total amount of IBC pegged tokens never 210 | exceeded the value of (hypothetically monetary) $ATOM tokens staked divided by 211 | 3 (since only ⅓ is guaranteed to be slashable for double-spend attacks with a 212 | network partition) but we can’t assume that the Hub will even enforce this 213 | invariant when its voters cannot understand the risks of converting $ATOM into 214 | a monetary token. Furthermore, most tokens may not be liquid, and 215 | re-compensation may not be sufficient recourse for the victims. 216 | 217 | ## Beating the Dead Horse of Validator Incentives 218 | 219 | Validator incentives are broken in the Cosmos Hub today. Every validator should 220 | be roughly equally incentivized to secure each ICS chain in the AEZ, because 221 | the work that every validator should be performing to secure each ICS chain is 222 | roughly the same. The current incentive model of rewarding validators in 223 | proportion to their stake (multiplied by their set commission) is flawed in 224 | this regard because nothing guarantees that tail validators will receive the 225 | income they need to remain competitive vs top validators, and this is made 226 | worse with ICS scaling. With enough scale, all tail validators will necessarily 227 | become insolvent and fail, while the ones that are struggling to stay afloat 228 | and survive will necessarily need to make business decisions that affect the 229 | security of that validator. This is not only suboptimal but cruel. 230 | 231 | The proposed change disproportionately affects smaller validators. While this 232 | will cease to be a problem once validator incentives are fixed to be more 233 | equal, it still remains a problem until the overall validator incentive model 234 | is fixed, and therefore presents an unnecessary risk to smaller validators. One 235 | analysis showed that over 74% of Cosmos Hub validators risk becoming 236 | unprofitable with less than six consumer chains. Reducing the max inflation can 237 | only exacerbate this problem, and make all these validators unprofitable 238 | sooner. We should never tolerate the risk of mass validator failures leading to 239 | centralization. 240 | 241 | ## The Min Inflation Rate shouldn’t change either 242 | 243 | While it is true that with the ICS-enabled transaction scaling, the rewards 244 | from transaction fees can and will drive the inflation rate to zero and even 245 | negative if we allow it, this is not good if it leads to the promotion and 246 | adoption of the $ATOM token as a monetary token (and it will). For this reason, 247 | we do not suggest removing the minimum inflation rate bounds of 7% either. This 248 | will help retain the intelligence of the $ATOM token distribution and prevent 249 | naive token holders from affecting it negatively (and the target demographic of 250 | a monetary token is naive because it is the general population). 251 | 252 | The negative consequence of keeping the minimum inflation bound at 7% is that 253 | the ratio of bonded tokens may rise above ⅔ and the amount of liquid supply may 254 | be too small for an accurate measure of the staking token market cap, which can 255 | negatively impact the quantifiable security offered by the Hub. However, this 256 | effect is limited because when the rewards from ICS transaction throughputs are 257 | high (presumably why the bonding rate is high), then there are other ways to 258 | calculate the value of the Hub through its continuous revenue, as long as the 259 | fees are primarily paid in other tokens besides the $ATOM token. 260 | 261 | ## Where Do We Go From Here? 262 | 263 | While we are most staunchly against prop 848 for all the reasons detailed 264 | above, there should always be room for experimentation, innovation, and open 265 | discussion and debate – as long as we agree to never compromise the network’s 266 | security and follow a cautious and measured approach. Given that $ATOM should 267 | not be a monetary token, the current design with a minimum inflation rate of 7% 268 | and a maximum one of 20% put in place to secure the network is working as 269 | intended. Any change to this model would make the $ATOM token too tempting to 270 | be marketed as a monetary token. 271 | 272 | What we would like to do instead is to open up a discussion for adjusting the 273 | `NextInflationRate` function to become more responsive to reaching the target 274 | ratio. Let’s find the best way of doing this together and discuss the pros and 275 | cons openly. Balancing market competitiveness with fundamental aspects of 276 | network security and economic stability is essential for the continued growth 277 | and success of the Cosmos network. 278 | 279 | From a bird's eye perspective looking at the current results of the proposal so 280 | far and the discourse we are seeing from the community, there is a clear lack 281 | of leadership in guiding the community toward making the necessary decisions. 282 | Since proposition 82 we have been working on proposals to improve the 283 | governance of the Cosmos Hub that should be prioritized over proposals such as 284 | 848. However, the ICF doesn’t appear to be helping and is often involved in 285 | backing bad proposals. While we might win here in defeating 848 after we vote 286 | NWV (and we urge everyone to do the same, and change votes to NWV), the overall 287 | situation is not amenable to what we need in order to succeed, and without 288 | active measures, we see this situation continue to worsen. 289 | 290 | We will soon publish a plan that will improve this situation with the Hub. 291 | Please stay tuned for more information. 292 | 293 | —---- 294 | 295 | ## Twitter Thread 296 | 297 | 1/ Dear Cosmonauts, All in Bits (AiB) will vote NWV on prop 848, ATOM Halving. 298 | We value Cosmos' core components of security, sustainability, and 299 | decentralization and cannot support a proposal that threatens its foundational 300 | pillars. 301 | 302 | 2/ #848 aims at turning the $ATOM token into a monetary token. But $ATOM's 303 | primary utility is – and has always been – a staking token enabling an IBC hub 304 | that requires the highest level of security. 305 | 306 | 3/ “Halving” $ATOM max inflation with insufficient research and discussion will 307 | lead to undesirable outcomes, significantly lowering the bonded ratio of staked 308 | $ATOMs, hampering the growth of IBC and ICS, affecting rewards for validators, 309 | and placing the Cosmos network at risk. 310 | 311 | 4/ #848 is a significant shift from the established tokenomics of the Cosmos 312 | Hub that has kept our ecosystem secure and dependable. Furthermore, the 313 | proposal is marketed as a “halvening,” yet is nothing like the immutable 314 | halvening schedule of the Bitcoin chain. 315 | 316 | 5/ The way the proponents of prop 848 have been calculating the cost of 317 | security, as well as, in general, how the community is calculating staking 318 | income or revenue, is fundamentally flawed. We should not pass proposals that 319 | are based on faulty premises. 320 | 321 | 6/ #848 disproportionately affects smaller validators. One analysis showed that 322 | over 74% of Cosmos Hub validators risk becoming unprofitable with less than 6 323 | consumer chains. We should not discuss reducing the max inflation without 324 | fixing the validators incentive problem first. 325 | 326 | 7/ There is a clear lack of leadership in guiding the community toward making 327 | necessary decisions, and we fear this situation will continue to worsen. We are 328 | therefore working on a plan to improve this situation that we will be sharing 329 | with the community soon. 330 | 331 | 8/ A thorough understanding of the presented arguments is vital for informed 332 | decision-making, and we invite the community to assess the points raised and 333 | actively participate in the discussion. For full details, please read our 334 | complete post: 335 | 336 | 337 | 9/ We will hold a Twitter space at 10 pm PDT today (7 am CET Wednesday) to 338 | discuss prop #848. If you share our concerns or would like to meaningfully 339 | contribute to the discussion, join us and be part of the dialogue. 340 | #CosmosDebate #TwitterSpace 341 | -------------------------------------------------------------------------------- /STAKING_VS_MONEY.id.md: -------------------------------------------------------------------------------- 1 | Diterbitkan pertama kali pada 21 November 2023 oleh All in Bits, Inc:Christina Comben, 2 | Adriana Mihai, Giuseppe Natale, Jae Kwon, Valeh Tehranchi 3 | 4 | # NWV untuk Proposal 848 – $ATOM tidak boleh didefinisikan sebagai Uang 5 | 6 | AiB akan segera melakukan voting terhadap NWV untuk proposal 848, "Pengurangan Setengah $ATOM," yang bertujuan mengubah token $ATOM menjadi token moneter dari token staking. Kami menghargai komponen inti Cosmos berupa keamanan, keberlanjutan, dan desentralisasi, dan tidak dapat mendukung proposal yang dapat mengancam pilar-pilar fundamental tersebut. Mengurangi separuh inflasi maksimum $ATOM pada saat ini dengan penelitian dan diskusi yang tidak mencukupi akan mengarah pada hasil yang tidak diinginkan, yaitu: 7 | 8 | Menurunkan rasio staking $ATOM secara signifikan: Hal ini mengurangi jumlah $ATOM yang di-staking, dan berpotensi melemahkan keamanan jaringan. 9 | Menghambat pertumbuhan adopsi IBC dan ICS: Kurangnya insentif staking dapat mengurangi adopsi teknologi antar-blockchain Cosmos. 10 | Mempengaruhi rewards validator: Penghasilan validator bergantung pada biaya transaksi dan rewards staking. Pengurangan rewards dapat menurunkan partisipasi validator. 11 | Membahayakan seluruh jaringan Cosmos: Keamanan dan stabilitas jaringan bergantung pada kesehatan ekosistem token $ATOM. 12 | Prop 848 merepresentasikan perubahan signifikan dari tokenomics established Cosmos Hub yang telah menjaga ekosistem aman dan terpercaya sejak awal. Meskipun prop 848 berpendapat bahwa hal itu akan meningkatkan $ATOM Economic Zone (AEZ) dan meningkatkan daya saing $ATOM dalam ruang DeFi, kami sangat tidak setuju dan mengemukakan beberapa kekhawatiran substansial berikut: 13 | 14 | ## Menggoyahkan Model Keamanan 15 | 16 | Hub IBC tidak boleh diamankan dengan token moneter. Mengamankan rantai dengan token moneter mungkin masuk akal untuk rantai non-hub yang tidak bergantung pada keamanan pasak token IBC-nya (misalnya, jika rantai hanya mementingkan dirinya sendiri). Namun, hal ini tidak berlaku secara definisi dalam Cosmos yang terdiri dari rantai-rantai yang saling terhubung melalui IBC. 17 | 18 | Token moneter yang baik didistribusikan secara luas secara definisi, dan oleh karena itu proporsi yang lebih kecil dari keseluruhan akan dipertaruhkan kepada validator. Hal ini membuat tata kelola rantai rentan diambil alih oleh siapa saja yang memiliki cukup token moneter ini, dan peningkatan likuiditas token ini secara praktis menjamin keberhasilan musuh dengan modal yang cukup. Ketika persaingan adalah sistem perbankan status quo, ada banyak modal yang dapat digunakan untuk melawan pihak yang lebih lemah. 19 | 20 | Sebaliknya, token staking yang memastikan mayoritas (katakanlah ⅔) tetap dipertaruhkan, memiliki lebih sedikit token likuid yang beredar. Hal ini membuat penyerang tidak dijamin dapat membeli cukup token di pasar untuk berhasil mengambil alih kendali; meskipun dalam beberapa kasus mungkin hal itu bisa terjadi, namun dalam skenario dengan $ATOM sebagai uang, penyerang dijamin akan berhasil mengambil alih kendali dengan asumsi yang wajar. 21 | 22 | Tidak masuk akal dalam jangka panjang untuk mengubah sistem yang aman terhadap pihak lawan terkuat, menjadi sistem yang dijamin gagal. Dan jika pembaca tidak setuju bahwa model harus tahan terhadap pihak lawan terkuat, itu berarti pembaca tidak menyadari sejarah. 23 | 24 | Jika proposal 848 lolos, maka akan memulai preseden meluncur menuruni lereng yang licin 25 | kemiringan perilaku degen, mendorong lebih banyak hasil degen untuk mengurangi 26 | inflasi lebih jauh, dan secara umum, komposisi dan kecerdasan 27 | Token $ ATOM akan menurun sedemikian rupa sehingga akan membuat keputusan yang berbahaya dan 28 | keputusan yang berbahaya; karena pemegang token tidak ahli dalam tokenomics seperti 29 | seharusnya, dan sebaliknya hanya peduli dengan hasil jangka pendek. Ini dibuat 30 | diperparah oleh fakta bahwa Gaia Cosmos Hub adalah hub token-pegging IBC, dan seterusnya 31 | akan ada insentif nyata bagi pihak-pihak jahat untuk menipu orang yang tidak menaruh curiga 32 | pemilih untuk menyetujui sesuatu yang merugikan Hub, penggunanya, dan 33 | Cosmos pada umumnya, atau bagi pihak-pihak jahat untuk menggunakan kekuatan pemungutan suaranya untuk mencuri 34 | token ini secara langsung. 35 | 36 | Inti dari $ATOM adalah, dan selalu ada, staking. $ATOM tidak pernah dirancang menjadi token moneter, melainkan token staking yang memungkinkan hub IBC yang membutuhkan tingkat keamanan tertinggi (lihat makalah model token awal: https://github.com/cosmos/cosmos/blob/0141bbcdbf68a784348ba059096f8238c696f9a8/Cosmos_Token_Model.pdf). 37 | 38 | Desain asli inflasi dinamis $ATOM, yang bertindak sebagai penalti bagi non-staker, memainkan peran penting dalam mendorong partisipasi dan keamanan jaringan. Hal ini dilakukan dengan sengaja membatasi jumlah $ATOM yang dapat ditransaksikan secara bebas, sehingga membuat pengambilalihan secara paksa menjadi sangat mahal. Proposal 848 berisiko merusak prinsip dasar ini dan mengacaukan model keamanan jaringan. 39 | 40 | ## Pendapatan Maya dan Argumen yang Cacat 41 | 42 | Kita tidak boleh meloloskan proposal yang didasarkan pada premis yang salah. Cara pendukung proposal 848 menghitung biaya keamanan dan, secara umum, bagaimana komunitas menghitung pendapatan atau keuntungan staking, pada dasarnya cacat karena $ATOM adalah token staking dengan ⅔ di-staking. Yang perlu kita lakukan sekarang adalah mengatasi masalah ini dengan menjelaskan model mental yang lebih baik kepada semua orang, dan dengan mendapatkan klarifikasi yang diperlukan dari otoritas pajak. Harap dicatat bahwa tidak ada di sini yang merupakan nasihat pajak, dan Anda harus berkonsultasi dengan penasihat pajak Anda sendiri. 43 | 44 | Ketika tingkat inflasi $ATOM tahunan mencapai 20% dan sekitar ⅔ token $ATOM di-staking, Anda sebenarnya mendapatkan keuntungan tahunan 30% dari jumlah awal yang di-stake (1,2 x 1,2 = 1,44). Namun, kebanyakan orang salah kaprah dengan berasumsi bahwa 30% peningkatan pasokan token yang dikalikan dengan harga $ATOM adalah keuntungan bersih. Kami berpendapat ini adalah cara yang salah untuk menghitung pendapatan bersih dari staking $ATOM. Meskipun jumlah total $ATOM yang Anda pegang di akhir tahun meningkat 1,3 kali lipat, kenyataannya setiap $ATOM juga mengalami penurunan nilai dan utilitas proporsional akibat inflasi 20%. Yang penting bukanlah berapa banyak $ATOM yang Anda pegang, melainkan persentase kepemilikan Anda dibandingkan dengan total pasokan. Pendapatan efektif yang memperhitungkan inflasi sebenarnya adalah 1,3x dibagi 1,2x, yaitu 8,33%. Ini adalah perbedaan besar, faktor 3,6 kali lebih rendah dari perhitungan yang tidak memperhitungkan inflasi. 45 | 46 | Sebagai latihan pemikiran, bayangkan jika kita menggandakan jumlah token $ATOM yang dimiliki setiap alamat, dan mempertahankan rasio bonding yang sama. Harga $ATOM akan langsung turun 50% (tetapi nilai bersih kepemilikan kita tidak berubah). Biasanya, ini tidak dianggap sebagai peristiwa kena pajak, seperti halnya pada stock-split (pemecahan saham). 47 | 48 | Mari kita pertimbangkan definisi $MASS = $ATOM / sum($ATOM), dengan sum($MASS) sama dengan 1. Satuan ukuran ini lebih baik merepresentasikan nilai intrinsik token $ATOM sebagai pecahan dari keseluruhan. Dengan satuan ukuran ini, pendapatan yang dihitung sebenarnya adalah 8,33% (dibandingkan dengan 30% dalam contoh sebelumnya). 49 | 50 | Selain model naif dan model $MASS, model ketiga berpendapat bahwa kita harus membakar token non-staker dan menganggap staker tidak memiliki pendapatan. Ini juga masuk akal - hanya karena kepemilikan relatif seseorang dalam pecahan saham meningkat tidak berarti itu harus diperlakukan sebagai pendapatan, karena tujuan utama adalah untuk mengurangi insentif pada token yang tidak di-stake dan merupakan bentuk hukuman bagi sebagian kecil (lebih atau kurang dari ⅓). Tentu saja, Anda dapat membalik argumen ini dan mengatakan bahwa itu masih merupakan insentif untuk staking (bisa dilihat sebagai keduanya), jadi di sini ada contoh untuk memperjelas; jika distribusi $ATOM seperti uang dan tersebar luas, dan jika katakanlah hanya 1% dari $ATOM di-stake, maka inflasi yang diberikan kepada staker lebih jelas dianggap sebagai pendapatan. 51 | 52 | Sebaliknya, jika 99% $ATOM di-stake, bahkan dengan tingkat inflasi yang tidak masuk akal sebesar 1.000.000% (hanya untuk contoh), inflasi tidak boleh dilihat sebagai pendapatan karena distribusi secara keseluruhan berdasarkan rasio belum banyak berubah pada akhirnya. Wajar jika kita melihat ini lebih sebagai penalti bagi 1% yang terkena inflasi. Perbedaannya adalah bahwa inflasi tinggi mengubah distribusi secara jauh lebih drastis daripada inflasi rendah (umumnya, 1% tidak sama dengan 100%). Dan karena tergantung pada variabel kontinu (tingkat inflasi), jelas bahwa token dapat berada pada spektrum. Namun, juga benar bahwa model tokenomics $ATOM yang asli membuatnya lebih sebagai penalti daripada insentif. 53 | 54 | Ini bukan nasihat pajak, tetapi kami akan menghubungi otoritas pajak terkait untuk mendapatkan kejelasan yang lebih baik dan mengadvokasi model ini. Dari semua opsi yang tersedia, mempertahankan perhitungan pendapatan/keuntungan dengan cara yang naif adalah opsi yang paling tidak disukai dan tidak rasional karena pada dasarnya merusak diri sendiri. 55 | 56 | Mereka yang mendukung #848 dan memilih untuk menyimpang dari target staking ⅔ (yang akan terjadi setelah #848) justru semakin merusak diri sendiri dan orang lain dengan menghancurkan argumen-argumen di atas yang mendukung perlakuan pajak yang lebih menguntungkan. Hadiah inflasi dari token moneter cenderung tidak dilihat sebagai penalti untuk tidak staking, tetapi insentif positif untuk melakukan staking. 57 | 58 | ## Precedent yang buruk 59 | 60 | Pihak-pihak yang mendukung proposal #848 sejauh ini beralasan bahwa mereka hanya mengukur minat para staker. Namun, perubahan fundamental pada tokenomics yang bertentangan dengan keamanan dan stabilitas ini ditawarkan tanpa adanya pengungkapan penuh tentang tujuan sebenarnya (menjadikan $ATOM sebagai token moneter) dan dampaknya. Proposal ini juga ditawarkan tanpa perencanaan dan jaminan yang cukup untuk konsistensi, dan tanpa pengungkapan risiko yang diperlukan. Faktanya, kita bahkan belum meratifikasi Konstitusi untuk Cosmos Hub. 61 | 62 | Lebih buruk lagi, proposal ini dipasarkan sebagai "halving" yang memiliki implikasi pada pergerakan harga yang diharapkan, padahal apa yang diusulkan sama sekali tidak seperti jadwal halving Bitcoin yang tidak dapat diubah. 63 | 64 | ## Penurunan Lebih Lanjut dalam Rasio Bond 65 | 66 | Seperti yang disebutkan dalam proposal, rasio bonding Cosmos Hub saat ini sedikit di bawah target, belum melampaui batas ⅔. Kondisi yang ada ini menimbulkan kekhawatiran yang signifikan: dengan mengurangi separuh inflasi maksimum, proposal secara efektif menghentikan peningkatan tingkat hadiah staking, sebuah mekanisme yang saat ini diterapkan untuk mengurangi insentif non-staking dan mendorong rasio bonding menuju target. 67 | 68 | Desain jaringan Cosmos secara dinamis menyesuaikan tingkat inflasi untuk mendorong staking ketika rasio bonding berada di bawah ambang batas yang diinginkan. Mekanisme ini berfungsi sebagaimana mestinya, secara bertahap meningkatkan tingkat inflasi untuk mendorong lebih banyak pemegang $ATOM untuk staking token mereka, sehingga mengamankan jaringan. Dan ini telah bekerja sesuai dengan yang diharapkan di masa lalu, seperti yang ditunjukkan pada grafik di bawah ini. Namun, proposal tersebut mengutip grafik ini sebagai bukti bahwa mekanisme ini tidak berfungsi dengan menggunakan perhitungan yang salah (namun, kami mengakui bahwa laju perubahannya bisa lebih cepat). Pengurangan yang diusulkan kemungkinan akan mengakibatkan penurunan lebih lanjut dalam rasio bonding ketika mekanisme seharusnya mendorong rasio untuk naik lebih tinggi. 69 | 70 | grafik waktu vs rasio bonding pada Gaia (https://github.com/atomone-hub/genesis/blob/0e65b56e4a0739287f2615ebd2c99d0c1bab4a74/resources/stakingrate.png) 71 | 72 | Proposal berpendapat bahwa tingkat inflasi $ATOM yang tinggi membuat imbal hasil DeFi menjadi kurang kompetitif. Proposal tersebut menyatakan, "Namun, karena tingkat inflasi $ATOM yang tinggi, imbal hasil DeFi sulit bersaing sehingga memperlambat pertumbuhan dan adopsi pengguna." 73 | 74 | Pertama-tama, ini adalah kesalahpahaman besar tentang imbal hasil sebenarnya dari inflasi, yang seperti disebutkan sebelumnya, dengan tingkat inflasi tahunan maksimum 20% majemuk, bukan hasil tahunan paling banyak 30%, tetapi bersih 8,33%. Kedua, alasannya sama sekali tidak masuk akal karena jika imbal hasil dari $ATOM begitu tinggi, maka harusnya meningkatkan pertumbuhan dan adopsi pengguna, bukan menurunkannya. Ini akan menjadi sesuatu yang patut dirayakan, jika benar, bukan dihambat. 75 | 76 | Tingkat inflasi $ATOM yang lebih tinggi memang membuatnya tidak cocok untuk digunakan dalam aplikasi DeFi karena $ATOM lebih mengembang dibandingkan dengan imbal hasil. Namun, $ATOM tidak pernah dimaksudkan untuk digunakan seperti ini sebagai uang. Lebih masuk akal menggunakan layanan "liquid staking" (istilah yang tidak tepat) untuk mengatur staking $ATOM dan menggunakan token staking cair yang lebih deflasi pada aplikasi DeFi, tetapi menggabungkan reward seperti ini juga menambah risiko dan tidak gratis. 77 | 78 | Dengan dukungan layanan manajemen staking yang menawarkan token derivatif deflasi, harus ada pemeriksaan tambahan terhadap pengambilalihan hostile dengan membatasi atau mengatur berapa banyak token "liquid staking" yang dapat dikonversi kembali menjadi $ATOM. Jika tidak, perbedaan keamanannya akan sedikit antara token $ATOM moneter dan token $ATOM staking, tetapi perbedaan antara token staking dan token deflasi yang lebih likuid merupakan dasar untuk menerapkan langkah kontrol dengan keseimbangan yang berbeda. Tanpa kontrol ini, kita hanya memiliki pengungkit kasar untuk mengelola masalah keamanan utama ini, seperti % staking yang dapat menggunakan ICS, yang tidak sejalan dengan apa yang sebenarnya kita perlu ukur. 79 | 80 | ## IBC Pegged Tokens 81 | 82 | Risiko keamanan yang sebenarnya di sini bukanlah dengan ekonomi ICS AEZ, karena apa yang ada di dalam AEZ dilindungi oleh set validator yang sama dengan ICS, dan rantai dapat setuju untuk membatalkan transaksi apa pun yang dianggap mengarah pada pencurian (misalnya melalui eksploitasi). Risiko sebenarnya terletak pada token IBC yang dipatok pada Cosmos Hub. Token yang dikendalikan oleh Hub tetapi berasal dari rantai lain di luar Hub dan AEZ semuanya berisiko dicuri. 83 | 84 | Semua token ini secara default menciptakan insentif nyata bagi aktor jahat untuk mengeksploitasi. Ini mungkin dapat ditoleransi jika jumlah total token IBC yang dipatok tidak pernah melebihi nilai token $ATOM yang di-staking (secara hipotetis moneter) dibagi 3 (karena hanya ⅓ yang dijamin dapat di-slash untuk serangan double-spend dengan partisi jaringan), tetapi kita tidak dapat berasumsi bahwa Hub akan memberlakukan invarian ini ketika para voter-nya tidak dapat memahami risiko mengubah $ATOM menjadi token moneter. Selain itu, sebagian besar token mungkin tidak likuid, dan kompensasi ulang mungkin bukan pemulihan yang memadai bagi para korban. 85 | 86 | ## Membicarakan insentif validator yang sudah tidak relevan 87 | 88 | Insentif validator rusak di Cosmos Hub saat ini. Setiap validator seharusnya memiliki insentif yang relatif sama untuk mengamankan setiap rantai ICS di AEZ, karena pekerjaan yang harus dilakukan setiap validator untuk mengamankan setiap rantai ICS adalah kurang lebih sama. Model insentif saat ini yang memberi penghargaan kepada validator sebanding dengan staking mereka (dikalikan dengan komisi yang mereka tetapkan) cacat dalam hal ini karena tidak ada yang menjamin bahwa validator ekor (tail validator) akan menerima pendapatan yang mereka butuhkan untuk tetap kompetitif dibandingkan validator teratas, dan ini diperburuk dengan penskalaan ICS. Dengan skala yang cukup, semua validator ekor akan menjadi bangkrut dan gagal, sementara mereka yang berjuang untuk bertahan akan perlu membuat keputusan bisnis yang memengaruhi keamanan validator tersebut. Ini tidak hanya suboptimal tetapi juga kejam. 89 | 90 | Proposal ini merugikan validator kecil secara tidak adil. Memang, masalah ini akan teratasi saat insentif validator diperbaiki menjadi lebih merata, tapi tetap saja ini masalah besar sampai model insentif validator secara keseluruhan ditata ulang. Akibatnya, proposal ini menimbulkan risiko yang tidak perlu bagi validator kecil. Sebuah analisis menunjukkan bahwa lebih dari 74% validator Cosmos Hub berisiko menjadi tidak menguntungkan jika ada kurang dari enam rantai konsumen. Mengurangi inflasi maksimum hanya akan memperburuk masalah ini dan membuat semua validator ini merugi lebih cepat. Kita tidak boleh membiarkan risiko kegagalan massal validator yang mengarah ke sentralisasi. 91 | 92 | ## Tingkat Inflasi Minimal seharusnya juga tidak berubah 93 | 94 | Meskipun benar bahwa dengan penskalaan transaksi yang diaktifkan ICS, imbalan dari biaya transaksi dapat dan akan mendorong tingkat inflasi ke nol dan bahkan negatif jika kita biarkan, ini tidak baik jika itu mengarah pada promosi dan adopsi token $ATOM sebagai token moneter (dan itu akan terjadi). Untuk alasan ini, kami juga tidak menyarankan penghapusan batas minimum tingkat inflasi sebesar 7%. Ini akan membantu mempertahankan kecerdasan distribusi token $ATOM dan mencegah pemegang token yang naif dari mempengaruhinya secara negatif (dan target demografis dari token moneter adalah naif karena itu adalah populasi umum). 95 | 96 | Konsekuensi negatif dari mempertahankan batas inflasi minimum di 7% adalah bahwa rasio token yang terikat dapat naik di atas ⅔ dan jumlah suplai likuid mungkin terlalu kecil untuk pengukuran akurat dari kapitalisasi pasar token staking, yang dapat berdampak negatif pada keamanan terukur yang ditawarkan oleh Hub. Namun, efek ini terbatas karena ketika imbalan dari throughput transaksi ICS tinggi (mungkin mengapa rasio ikatan tinggi), maka ada cara lain untuk menghitung nilai Hub melalui pendapatannya yang berkelanjutan, selama biaya utamanya dibayar dalam token lain selain token $ATOM. 97 | 98 | ## Kemana Kita Melangkah Dari Sini? 99 | 100 | Meskipun kami dengan tegas menentang proposal 848 karena semua alasan yang telah dijelaskan di atas, seharusnya selalu ada ruang untuk eksperimen, inovasi, dan diskusi dan debat terbuka - selama kita setuju untuk tidak pernah mengorbankan keamanan jaringan dan mengikuti pendekatan yang hati-hati dan terukur. Mengingat $ATOM tidak boleh menjadi token moneter, desain saat ini dengan tingkat inflasi minimum 7% dan maksimum 20% yang diterapkan untuk mengamankan jaringan berfungsi sebagaimana mestinya. Setiap perubahan pada model ini akan membuat token $ATOM terlalu menggoda untuk dipasarkan sebagai token moneter. 101 | 102 | Alih-alih menyetujui proposal 848, kami ingin membuka diskusi untuk menyesuaikan fungsi `NextInflationRate` agar lebih responsif dalam mencapai rasio target. Mari temukan cara terbaik untuk melakukannya bersama dan diskusikan pro dan kontra secara terbuka. Menyeimbangkan daya saing pasar dengan aspek fundamental keamanan jaringan dan stabilitas ekonomi sangat penting untuk pertumbuhan dan keberhasilan berkelanjutan jaringan Cosmos. 103 | 104 | Dari sudut pandang yang luas, melihat hasil proposal saat ini dan diskusi yang berlangsung di komunitas, terlihat jelas kurangnya kepemimpinan dalam membimbing komunitas untuk membuat keputusan yang diperlukan. Sejak proposal 82, kami telah mengerjakan proposal untuk meningkatkan tata kelola Cosmos Hub yang seharusnya diprioritaskan daripada proposal seperti 848. Namun, ICF tampaknya tidak membantu dan sering terlibat dalam mendukung proposal yang buruk. 105 | 106 | Meskipun kita mungkin menang dalam mengalahkan proposal 848 setelah kita memberikan suara "Tidak Setuju dengan Wajib" (dan kami mendesak semua orang untuk melakukan hal yang sama, dan mengubah suara menjadi "Tidak Setuju dengan Wajib"), situasi secara keseluruhan tidak menguntungkan untuk apa yang kita butuhkan agar sukses, dan tanpa tindakan aktif, kita melihat situasi ini terus memburuk. 107 | 108 | Kami akan segera mempublikasikan rencana untuk memperbaiki situasi ini dengan Hub. Harap pantau terus untuk informasi lebih lanjut. 109 | 110 | —---- 111 | 112 | ## Twitter Thread 113 | 114 | 1/ Para Cosmonaut, All in Bits (AiB) akan memberikan suara "Tidak Setuju dengan Wajib" (NWV) pada proposal 848, "ATOM Halving". 115 | 116 | Kami memprioritaskan komponen inti Cosmos seperti keamanan, keberlanjutan, dan desentralisasi, dan tidak dapat mendukung proposal yang mengancam pilar-pilar fundamental tersebut. 117 | 118 | 2/ #848 bertujuan mengubah token $ATOM menjadi token moneter. Namun, kegunaan utama $ATOM – dan selalu demikian – adalah sebagai token staking yang memungkinkan hub IBC beroperasi dan membutuhkan tingkat keamanan tertinggi. 119 | 120 | 3/ "Halving" inflasi maksimum $ATOM dengan penelitian dan diskusi yang tidak cukup akan mengarah pada hasil yang tidak diinginkan, secara signifikan menurunkan rasio token $ATOM yang di-staking, menghambat pertumbuhan IBC dan ICS, memengaruhi reward bagi validator, dan menempatkan jaringan Cosmos pada risiko. 121 | 122 | 4/ #848 merupakan perubahan signifikan dari tokenomics Cosmos Hub yang telah terbukti menjaga ekosistem kami aman dan terpercaya. Lebih lanjut, proposal ini dipasarkan sebagai "Halving", namun sama sekali tidak sama dengan jadwal Halving tak terubah dari rantai Bitcoin. 123 | 124 | 5/ Cara pendukung proposal 848 menghitung biaya keamanan, dan secara umum, bagaimana komunitas menghitung pendapatan atau revenue staking, pada dasarnya cacat. Kita tidak boleh meloloskan proposal yang didasarkan pada premis yang salah. 125 | 126 | 6/ #848 berdampak tidak proporsional terhadap validator yang lebih kecil. Satu analisis menunjukkan bahwa lebih dari 74% validator Cosmos Hub berisiko menjadi tidak menguntungkan dengan kurang dari 6 rantai konsumen. Kita tidak boleh membahas pengurangan inflasi maksimum tanpa memperbaiki masalah insentif validator terlebih dahulu. 127 | 128 | 7/ Ada kekurangan kepemimpinan yang jelas dalam membimbing komunitas untuk membuat keputusan yang diperlukan, dan kami khawatir situasi ini akan terus memburuk. Oleh karena itu, kami sedang mengerjakan rencana untuk memperbaiki situasi ini yang akan kami bagikan dengan komunitas segera. 129 | 130 | 8/ Pemahaman menyeluruh tentang argumen yang disajikan sangat penting untuk pengambilan keputusan yang terinformasi, dan kami mengundang komunitas untuk menilai poin-poin yang dikemukakan dan secara aktif berpartisipasi dalam diskusi. Untuk detail lengkap, silakan baca posting lengkap kami: 131 | https://forum.cosmos.network/t/proposal-set-max-inflation-at-10/11841/240?u=aib 132 | 133 | 9/ Kami akan mengadakan Twitter Space pada jam 10 malam PDT hari ini (jam 7 pagi CET Rabu) untuk membahas proposal #848. Jika Anda berbagi kepedulian kami atau ingin berkontribusi secara bermakna dalam diskusi, bergabunglah dengan kami dan jadilah bagian dari dialog. #CosmosDebate #TwitterSpace -------------------------------------------------------------------------------- /STAKING_VS_MONEY.es.md: -------------------------------------------------------------------------------- 1 | _Originalmente publicado el 21 de noviembre del 2023 por All in Bits, Inc; Christina Comben, Adriana Mihai, Giuseppe Natale, Jae Kwon, Valeh Tehranchi_ 2 | 3 | # NWV a la propuesta 848 - $ATOM no debe ser dinero. 4 | 5 | AiB pronto estará votando NWV a la propuesta 848, $ATOM “Halving” (reducir a la mitad), la cual apunta a convertir el token $ATOM a un token monetario en vez de un token de staking (participación o apostar en la validación de bloques). Valoramos los componentes núcleo de Cosmos de seguridad, sostenibilidad y descentralización, y no podemos apoyar una propuesta que pueda amenazar estos pilares fundacionales. El ‘halving’ de la inflación máxima de $ATOM en este tiempo, junto a investigaciones y discusiones insuficientes llevará a resultados no-deseables, en específico, la reducción de la proporción vinculada de $ATOMs en staking, afectando los rewards (recompensas) para los validadores, y poniendo así en riesgo a toda la red Cosmos. 6 | 7 | La propuesta 848 representa un cambio significativo de los tokenomics del Cosmos Hub que han mantenido nuestro ecosistema seguro y dependiente desde su incepción. Mientras que la propuesta 848 argumenta que mejoraría la $ATOM Economic Zone (AEZ) (zona económica $ATOM) e incrementaría la competitividad de $ATOM en el el espacio DeFi, estamos en desacuerdo categóricamente y levantamos las siguientes preocupaciones sustanciales: 8 | 9 | ## Desestabilizando el modelo de seguridad 10 | 11 | Un hub IBC no debe ser asegurado por un token monetario. Asegurar la blockchain con un token monetario pudiera hacer sentido para blockchains que no son hubs las cuales no dependen de la seguridad del ‘peg’ (fijación, estabilidad) de sus tokens IBC (por ejemplo, si el blockchain solo se preocupara por sí mismo). Pero esto no es verdad por definición en el Cosmos del IBC de blockchains interconectadas. Esto deja el gobierno del blockchain abierto a ser ocupado por cualquiera que tenga la cantidad suficiente de estos tokens monetarios, y el incremento en la liquidez de este token prácticamente garantiza el triunfo de cualquier adversario con el capital suficiente. Cuando la competición es el estatus quo del sistema bancario, hay un amplio capital para ser utilizado contra el partido desfavorecido. 12 | 13 | En contraste, un token de staking que mantenga que la super-mayoría (digamos 2/3) se preserve staked tiene menos en circulación como tokens líquidos, de esta forma el adversario no tiene garantía de poder comprar suficiente en el mercado para poder triunfar en ganar el control; mientras que en algunos casos esto puede ser posible, también es cierto que en el escenario de $ATOM como dinero, el adversario es prácticamente garantizado a triunfar en el apoderamiento dadas las asunciones razonables. No hace sentido a largo-plazo cambiar lo que pudiera ser seguro en contra de los adversarios más poderosos, a uno que está garantizado a fallar. Y si el lector no está de acuerdo en que el modelo debe ser resistente contra los más poderosos adversarios, significa que el lector no está consciente de la historia. 14 | 15 | Si la propuesta 848 pasa, comienza un precedente de deslizarse por la pendiente resbaladiza del comportamiento ‘degen’, alentando así a más degens de ganancia a decrecer la inflación más y más, y en en general, la composición e inteligencia del token $ATOM decrecerá a un nivel en el que decisiones dañinas y peligrosas serán tomadas; porque los holders (propietarios) del token nos son expertos en tokenomics como deberían ser, y en vez, solo les importa la ganancia a corto plazo. Esto se empeora por el hecho de que Gaia Cosmos Hub es un hub IBC que hace ‘token-pegging’ (fijación de tokens), y por eso habrán grandes incentivos para que entidades maliciosas engañen a votantes desprevenidos a aprobar algo que es detrimental para el Hub, para sus usuarios, y para Cosmos en general, o también para las entidades maliciosas usar su poder de votación para robar estos tokens. 16 | 17 | La utilidad principal de $ATOM es y siempre ha sido el staking. $ATOM nunca fue diseñado para ser un token monetario sino un token de staking que habilita un hub IBC que requiere el más alto nivel de seguridad (ver el ensayo del modelo de token original). El diseño original de la inflación dinámica de $ATOM, actuando como una penalidad para los que no hacen staking, juega un papel crucial en la incentivación de la participación en la red y la seguridad por medio de la limitación intencional de $ATOM líquido que puede ser intercambiado así haciendo una toma de control hostil imposiblemente caro. La propuesta 848 arriesga minar estos principios fundacionales y desestabilizar el modelo de seguridad de la red. 18 | 19 | ## Ingresos fantasma y argumentos fallidos 20 | 21 | No debemos pasar propuestas que están basadas en premisas falsas. La forma en la que los proponentes de la propuesta 848 han estado calculando el costo de seguridad, así como, en general, cómo la comunidad ha calculado el ingreso de staking, es fundamentalmente fallido ya que $ATOM es un token de staking con 2/3 en staking. Lo que necesitamos ahora es tocar este problema por medio del mejor modelo mental para todos, y por medio de la clarificación necesaria de las autoridades fiscales. Por favor, note que nada de lo que se dice aquí es consejo tributario, y que usted debe hablar con su propio asesor financiero. 22 | 23 | Cuando la tasa de inflación anual compuesta de $ATOM es 20%, y porque generalmente 2/3 de $ATOM están staked, cuando usted pone sus $ATOMs en staking, usted gana anualmente un retorno de un 30% del monto originalmente puesto en staking. Lo que la mayoría de las personas hace en esta situación es asumir que el incremento de 30% en el cantidad de tokens multiplicado por el precio del token $ATOM equivale a toda la ganancia, pero nosotros entendemos que esta forma de calcular la ganancia neta para $ATOM está errada. Si bien es cierto que el número total de $ATOMS que se tienen al final del año es 1.3x en cantidad, la realidad es que cada $ATOM también bajó en su utilidad proporcional y en valor por causa de la inflación sustancial del 20%. Lo que importa no es el número total de $ATOMs que uno pueda tener, sino la fracción que se posee en comparación al total. El ingreso efectivo considerando la inflación es 1.3x / 1.2x, lo cual equivale a 8.33%. Este es un factor masivo de 3.6 a 1. 24 | 25 | Como un ejercicio mental, si fuésemos a duplicar la cantidad de $ATOMs que cada dirección posee, y mantuviésemos la proporción vinculada de la misma forma, el precio de $ATOM inmediatamente decrecería por 50% (pero el valor neto de nuestros bienes no cambiaría); y usualmente esto no debería ser visto como un evento sujeto a impuestos, y no lo es en el caso de un desdoblamiento de acciones. 26 | Como otro ejercicio mental, considere la definición de $MASS = $ATOM / sum($ATOM), donde sum($MASS) digamos que equivale a 1. Esta unidad de medida representa mejor el valor intrínseco del token $ATOM como una fracción del total. Con esta unidad de medida, el calculo de ingreso sería 8.33% (opuesto al 30% en nuestro ejemplo). 27 | 28 | A parte del modelo ingenuo y el modelo $MASS, el tercer modelo dice que deberíamos estar quemando los tokens que no están en staking y reclama que los stakers deberían tener cero ingresos. Esto también es razonable —solo porque la propiedad relativa de alguien ha incrementado en fracciones no significa que debe ser tratada como ingreso, ya que el propósito primario es desincentivar los tokens que no están vinculados en staking y es una forma de castigo a la minoría subconjunta (de 1/3 más o menos). Claro está, se puede tornar el argumento y decir que aún es un incentivo para staking (puede ser visto como ambos), así que aquí hay un argumento clarificador; si la distribución de $ATOM fuese como dinero, masivamente distribuido, y digamos que solo 1% de los $ATOMs estuviera en staking, entonces la inflación yendo a los stakers pudiera ser vista más claramente como un ingreso. 29 | 30 | En comparación, si 99% de los $ATOMs estuviesen vinculados en staking, aún con el ridículo porcentaje de inflación de 1,000,000% (por el bien del argumento) la inflación no debería ser vista como ingreso ya que la distribución total por relación no ha cambiado mucho al final del día; naturalmente, percibimos esto más como una penalidad para el 1% que fue inflado. La diferencia es que el anterior cambia la distribución más que el último (generalmente el 1% no es como el 100%), y ya que esto depende de una variable continua (el porcentaje de inflación), está claro que un token puede estar en un espectro. Sin embargo, es también correcto decir que los tokenomics originales de $ATOM lo hacen primariamente una penalidad, no un incentivo. 31 | 32 | Esto no es consejo fiscal, pero nos estaremos acercando a las autoridades fiscales relevantes para obtener más claridad y argumentar por este modelo. De todas las opciones a nuestra disposición, continuar calculando las ganancias e ingresos ingenuamente es la forma menos favorable e irracional ya que constituye un auto-sabotaje innecesario. 33 | 34 | Aquellos votando a favor de #848 y escogiendo desviar a Cosmos de el estándar de staking de 2/3 (que será lo que pasará después de #848) están saboteándose a sí mismos así como a todos los demás al destruir los argumentos mencionados anteriormente a favor de un trato fiscal más favorable. Los rewards de inflación de un token monetario son menos propensos a ser vistos como una penalidad para non-staking, pero siguen siento un incentivo positivo para staking. 35 | 36 | ## Un mal precedente 37 | 38 | Aquellos que argumentaron a favor de #848 han ido tan lejos como para argumentar que ellos están estimando los intereses de los stakers. Este cambio fundamental a los tokenomics que va en contra a la seguridad y estabilidad es ofrecida sin descargos de responsabilidad completos sobre el propósito de sus intenciones (hacer $ATOM un token monetario) y sus efectos. También es ofrecido sin suficiente planeamiento ni garantías de cualquier tipo de consistencia, y sin ninguna de los descargos de responsabilidad de riesgo necesarios. Ciertamente, nosotros ni siquiera tenemos una Constitución ratificada para el Cosmos Hub aún. Además, para empeorar las cosas, esta propuesta está mercadeado como un ‘halvening’ (reducción a la mitad) lo cual tiene implicaciones respecto a expectativas de movimiento de precio, mientras que lo que está siendo propuesto no se asemeja en nada al calendario inmutable de halvening de la cadena Bitcoin. 39 | 40 | ## Un mayor descenso en el porcentaje de staking 41 | 42 | Como fue mencionado en la propuesta, el porcentaje vinculado actual del Cosmos Hub está levemente por debajo de lo estimado, no sobrepasando la marca de los 2/3. Esta condición existente levanta preocupaciones significativas: al reducir a la mitad la inflación máxima, la propuesta efectivamente arresta el incremento en rewards por staking, un mecanismo actualmente en lugar para desincentivar non-staking y empujar el la tasa de vínculos hacia el porcentaje deseado. 43 | 44 | El diseño de la red Cosmos dinámicamente ajusta la inflación para alentar el staking cuando la proporción de vínculos está por debajo del punto deseado. Este mecanismo está funcionando según lo previsto, gradualmente incrementando la tasa de inflación para incentivar a más usuarios a hacer staking de sus tokens, y así asegurar la red. Y ha funcionado como se esperaba, como se muestra en el gráfico debajo. Aun así, se citó como un ejemplo de que este mecanismo no funciona utilizando matemáticas defectuosas (sin embargo, admitimos que la tasa de cambio podría ser más rápida). La reducción propuesta probablemente resultará en un más profundo declive de la proporción de staking cuando el mecanismo debería de empujar esa tasa a elevarse. 45 | 46 | ![gráfico del tiempo vs reporte de staking en 47 | Gaia](https://github.com/atomone-hub/genesis/blob/0e65b56e4a0739287f2615ebd2c99d0c1bab4a74/resources/stakingrate.png) 48 | 49 | La propuesta reclama que la alta tasa de inflación de $ATOM hace las ganancias DeFi menos competitivas. La propuesta declara, “Sin embargo, debido a la alta tasa de inflación de $ATOM, el rendimiento de DeFi difícilmente puede ser competitivo, lo que hace más lento el crecimiento de los usuarios y la adopción.” Primero que nada, este es un grave malentendimiento de la producción real por medio de la inflación, como fue mencionado antes, es con una tasa de inflación anual compuesta máxima del 20%, no como máximo una ganancia anual del 30%, sino un 8.33% neto. Segundo, el razonamiento es completamente fallido ya que si la ganancia de $ATOM es tan alta, entonces debería incrementar el crecimiento de la base de usuarios y la adopción, no decrecerla. Esto sería algo para celebrar, de ser verdad, no para sofocar. 50 | 51 | La alta tasa de inflación de $ATOM lo hace inapropiado para usar dentro de aplicaciones DeFi porque $ATOM se infla más en comparación a las ganancias. Pero $ATOM nunca fue diseñado para ser usado en esta forma como dinero. Hace más sentido usar un servicio de ‘staking líquido’ (un nombre errado) para administrar el staking de $ATOM y para utilizar los tokens de staking líquido más deflacionarios resultantes dentro de las aplicaciones DeFi, pero combinar ganancias de esta forma también combina los riesgos y no está exento de costos. 52 | 53 | Con el soporte de dichos servicios de administración de staking que ofrecen tokens derivativos más deflacionarios, debe haber revisiones adicionales contra tomas de control hostiles a través de una limitación o un estrangulamiento de cuántos tokens de staking líquido pueden ser convertidos de vuelta a $ATOM. De otra forma, habría poca diferencia en seguridad entre un $ATOM monetario y un $ATOM de staking pero la distinción entre el token de staking y el token liquido deflacionario es el fundamento para introducir medidas de control con diferentes compensaciones. De otra forma, nos quedaríamos con palancas toscas para manejar este asunto clave respecto a la seguridad, como lo es el % de staking que puede usar ICS (Interchain Security), lo cual no es exactamente lo que debemos medir. 54 | 55 | ## Tokens fijados en IBC 56 | 57 | El riesgo real en seguridad no es con la economía de ICS AEZ ya que lo que está en AEZ está asegurado por el mismo set de validadores que en ICS, y la cadena puede acordar recortar cualquier transacción que se determine como subyacente a un robo (por ejemplo a través de una explotación). El riesgo real yace en los tokens fijados del IBC en el Cosmos Hub. Los tokens que están controlados por el Hub pero originan en otros blockchains externos al Hub y al AEX están en riesgo de ser robados. 58 | 59 | Estos tokens, por default, crean un incentivo para que entes maliciosos ataquen. Esto puede ser tolerable si la cantidad total de tokens fijados en IBC nunca excede el valor de los tokens (hipotéticamente monetario) $ATOM staked divididos entre 3 (ya que solo 1/3 está garantizado a ser ‘slashed’ (cortado) para ataques de doble-gasto con una red de partición) pero no podemos asumir que el Hub alguna vez vaya a hacer cumplir esta invariante cuando sus votantes no pueden comprender los riesgos de convertir $ATOM a un token monetario. Además, la mayoría de los tokens puede que no sean líquidos y una recompensa puede que no sea un recurso suficiente para las víctimas. 60 | 61 | ## La futilidad de los incentivos a validadores 62 | 63 | Hoy en día los incentivos a validadores en el Cosmos Hub están rotos. Cada validado debería de recibir aproximadamente el mismo incentivo para asegurar cada cadena ICS en el AEZ, porque el trabajo que cada validado debería de hacer para asegurar cada cadena ICS es aproximadamente el mismo. El modelo de incentivo actual de recompensar a cada validados en proporción a su stake (multiplicado por su porcentaje de comisión) está fallida en este respecto ya que nada garantiza que los validadores menores recibirán el ingreso necesario para permanecer competitivamente contra los validadores mayores, y esto se hace peor con el escalamiento del ICS. Con la suficiente escala, todos los validadores menores inevitablemente se convertirán en insolventes y fracasarán, mientras que los que están batallando para mantenerse a flote y sobrevivir necesariamente tendrán que tomar decisiones que afectarán la seguridad del validador. Esto no es solo subóptimo, sino cruel. 64 | 65 | El cambio propuesto afecta a los validadores menores de manera desproporcional. Mientras que esto dejará de ser un problema cuando los incentivos a validadores sean arreglados para ser más equitativos, sigue siendo un problema hasta que el modelo de incentivo general sea arreglado, y por tanto presenta un riesgo innecesario para validadores más pequeños. Un análisis mostró que más de 74% de los validadores del Cosmos Hub están en riesgo de convertirse en no-rentables con menos de seis cadenas de consumidores. Reducir la inflación máxima solo puede exacerbar el problema, y hace a todos estos validadores improductivos más pronto. No debemos nunca tolerar el riesgo de fallas masivas en los validadores que conduzcan a la centralización. 66 | 67 | ## La tasa de inflación mínima tampoco debería cambiar 68 | 69 | Si bien es cierto que con el escalamiento de transacciones habilitado por ICS, los rewards de impuestos de transacción pueden llevar la tasa de inflación a cero y hasta negativo si lo permitimos, esto no sería bueno si conduce a la promoción y adopción del token de $ATOM como un token monetario (y así lo hará). Por esta razón, sugerimos no remover la tasa mínima de inflación de 7% tampoco. Esto ayudara a retener la inteligencia de la distribución del token $ATOM y a prevenir a usuarios ingenuos de afectarle negativamente (y el demográfico blanco de un token monetario es ingenuo porque el mismo es la población general). 70 | 71 | La consecuencia negativa de mantener la inflación mínima en 7% es que la tasa de tokens vinculados en staking puede incrementar la marca de 2/3 y la cantidad de suministro líquido puede ser demasiado pequeña para tener una medida precisa del market-cap (capitalización del mercado) del token de staking, lo cual a su vez puede impactar negativamente la seguridad cuantificable ofrecida por el Hub. Sin embargo, este efecto es limitado ya que cuando los rewards de los rendimientos de transacciones ICS son altos (presumiblemente por qué la tasa de vinculación staking es alta), entonces hay otras formas de calcular el valor del Hub a través de sus ingresos continuos, siempre y cuando los impuestos sean primariamente pagados en tokens que no sean $ATOM. 72 | 73 | ## ¿A dónde vamos desde aquí? 74 | 75 | Si bien estamos definitivamente contra la propuesta #848 dadas todas las razones antes mencionadas, debe siempre haber espacio para la experimentación, innovación, y para la discusión y el debate abiertos —siempre y cuando aceptemos no comprometer nunca la seguridad de la red y seguir un enfoque cauteloso y medido. Dado que $ATOM no debe ser un token monetario, el diseño actual con una tasa de inflación mínima de 7% y una máxima de 20%, puesta en lugar para asegurar la red, está funcionando según lo previsto. Cualquier cambio a este modelo convertiría a $ATOM en un token demasiado tentador para ser mercadeado como uno de tipo monetario. 76 | 77 | Lo que quisiéramos hacer es abrir una discusión para ajustar la función de NextInflationRate (próxima tasa de inflación) para ser más receptivos para alcanzar la tasa deseada. Encontremos la mejor forma de hacer esto juntos y discutir los pros y contras de manera abierta. Balancear la competitividad de mercado con los aspectos fundamentales de la seguridad de la red y la estabilidad económica es esencial para el crecimiento continuo y el triunfo de la red Cosmos. 78 | 79 | Desde una perspectiva de vuelo de pájaro, viendo los resultados de la propuesta hasta ahora y el discurso que hemos podido ver por parte de la comunidad, hay una clara falta de liderazgo para guiar a la comunidad hacia tomar las decisiones necesarias. Desde la propuesta #82 hemos estado trabajando en otras propuestas para mejorar el gobierno del Cosmos Hub que deberían tener prioridad sobre propuestas como la #848. Sin embargo, la ICF no parece estar ayudando y a menudo ha apoyado malas propuestas. Si bien podríamos ganar aquí al derrotar a #848 después de votar NWV (y les urgimos a todos a hacer lo mismo y cambiar sus votos a NWV), la situación general no se adapta a lo que necesitamos para tener éxito, y sin medidas activas, vemos que esta situación continuará empeorando. 80 | 81 | Pronto estaremos publicando un plan que mejorará esta situación con el Hub. Por favor, esté atento para más información. 82 | 83 | —---- 84 | 85 | ## Hilo de Twitter 86 | 87 | 1/ Queridos cosmonautas, All in Bits (AiB) votará NWV (no with veto) en la propuesta 848, el Halving de ATOM. Valoramos los componentes núcleo de Cosmos como lo son la seguridad, sostenibilidad, y descentralización, y no podemos apoyar una propuesta que amenaza sus pilares fundacionales. 88 | 89 | 2/ #848 apunta a convertir el token $ATOM en un token monetario. Pero la utilidad primaria de $ATOM es y siempre ha sido la de un token de staking que habilita un hub IBC que requiere el mayor nivel de seguridad. 90 | 91 | 3/ El “halving” de la inflación máxima de $ATOM con junto a investigaciones y discusiones insuficientes nos dirigirá a resultados no deseados, significativamente reduciendo la tasa de vinculación de $ATOMs en staking, obstaculizando así el crecimiento del IBC y el ICS, afectando también los incentivos de los validadores, y colocando a la red Cosmos en riesgo. 92 | 93 | 4/ #848 es un cambio significativo de los tokenomics establecidos en el Cosmos Hub, los cuales han mantenido a nuestro ecosistema seguro y confiable. Además, la propuesta está mercadeada como un ‘halvening’, aun cuando no se asemeja en nada al calendario inmutable de halvening de la cadena Bitcoin. 94 | 95 | 5/ La forma en la que los proponentes de la propuesta #848 han calculado los costos de seguridad, así como también, como la comunidad en general está calculando los ingresos o ganancias por vía de staking, está fundamentalmente fallida. No deberíamos pasar propuestas que están basadas en falsas premisas. 96 | 97 | 6/ #848 desproporcionadamente afecta a los validadores más pequeños. Un análisis mostró que más de 74% de los validadores del Cosmos Hub están en riesgo de convertirse en no-rentables con menos de seis cadenas de consumidores. No debemos discutir la reducción de una inflación máxima sin antes arreglar el problema de los incentivos de validadores. 98 | 99 | 7/ Hay una clara falta de liderazgo guiando a la comunidad hacia tomar las decisiones necesarias, y tememos que esta situación continuará empeorando. Por tanto, estamos trabajando en un plan para mejorar esta situación, el cual pronto será compartido con la comunidad. 100 | 101 | 8/ Un entendimiento exhaustivo de los argumentos presentados es vital para tomar decisiones de manera informada, e invitamos a la comunidad a valorar los puntos levantados y activamente participar en la discusión. Para más detalles, por favor lea nuestra publicación completa: https://forum.cosmos.network/t/proposal-set-max-inflation-at-10/11841/240?u=aib 102 | 103 | 9/ Estaremos organizando una reunión a través de Twitter Spaces a las 10 pm PDT hoy (7 am CET miércoles) para discutir la propuesta #848. Si usted comparte nuestras preocupaciones o desea de manera significativa contribuir a la discusión, únase a nosotros para ser parte del diálogo. #CosmosDebate #TwitterSpace 104 | --------------------------------------------------------------------------------