Just want to call out that Atomone airdrop to

1. No with veto or veto to last proposal where users qualified for GNOLAND
2. Those who did not vote and their vote got overwritten by validators yes vote. A lot of users did not have visibility on Jae messaging for this vote. If I had seen Jae reasoning I would have voted no or no with veto

The Cosmos Ecosystem has experienced a prolonged period of political intricacies. It's essential to foster an environment where zones aren't compelled into direct competition with the central hub. AtomOne's approach stands out by championing a minimalist version of the hub, providing a refreshing alternative.

Currently, Gaia has become concentrated, favoring only a select few teams and insiders. This concentration can be frustrating for other Cosmos zones seeking resources and attention. Presently, the ICF, Atom Accelerator, and hub governance serve as the primary mechanisms for supporting teams within the Cosmos ecosystem.

I advocate for a primary chain devoted to elevating all teams within the Cosmos ecosystem, regardless of their affiliations or exclusivity. A commitment to assisting every entity within Cosmos aligns with a more inclusive and equitable vision for the entire ecosystem.

Griffin

Similar to QA, but for security.

Should we mandate that all proposals include evidence of maintaining high security standards? Ideally, this could be akin to a 'security coverage' badge, marking proposals as failing if there's any decline in security.

We could use labels like 'Meeting#1', 'Meeting#2', etc., to tag issues that we plan to discuss in a call. Additionally, another label could indicate the status of an issue in a Kanban format, such as 'draft', 'title-verified', 'body', 'solved', and so on.

We need “write” permission to be able to create projects or assign issues to projects.

I'm thinking of creating a HOW-TO-FORK.md file or a new section in the README.
This would outline key steps such as 'choosing a ticker'.

The aim is to highlight that our discussions are largely framework-centric, while also providing guidance on envisioning the initial and subsequent blockchain instances derived from this framework.

WDYT? Maybe too early?

Related with #63

Should we use the block at the end of the vote based on date 18010654? Or should we consider an alternative? Can someone double-check if I have selected the correct block?

Once we confirm the correct block, I can help create a snapshot with all the metadata. We can process this snapshot later when we finalize the rules.

an abandoned place in the middle of nowhere!

a community of 1000 adult M/F individuals find themselves stranded on a beach one fine morning.
no one knows each other, the day passes, we get to know each other, in the evening we go to bed
on the beach on an empty stomach.

Day 1:
When we wake up, we get together and unanimously decide that we need water and food.
this vote received a 100% YES.....so there are things that unite us!

we set off in search of food, it was not an easy thing to move through this jungle,
where all kinds of critters are swarming but we find something to feed and refresh ourselves.

in the evening, we vote by show of hands to find out if everything will be distributed fairly or
everyone keeps what they found......so there are things that separate us!
It’s a mess, the one who found the water source says it belongs to him etc.....!

so you understand, we need a strong authority to regulate all this mess and protect food.

water and food are the most precious things we have and which we must protect at all costs,
it’s what allows us to live.

if I understood the vision correctly, water is AtomOne.
the source of water is inflation.
water must be protected by the constitution, this is essential.
is the constitution the white paper?
Water is H2O, without water life does not exist
H:atomic number 1
O:atomic number 8
If we add the two together, I say to myself that there are a lot of inexplicable and strange things!

authority and regulation are the Decentralists?

tell me if I'm wrong about the vision!
help me make this story something coherent that everyone can understand.

Days: 2
every day is a new story, ................

I have been arguing that it is necessary for ATOM1 to make slashing in order to ensure an improvement in the distribution set's intelligence in making security decisions.

Proponents of no-slashing forks argue that there should be no mutation of the distribution set, and that token holders will naturally sell their ATOM1 and buy ATOM (and vice versa) depending on their interest. The problem with this argument is that this doesn't hold in the security model that we should be building for -- one where a decentralized adversary with a much larger power base & treasury than the market cap of ATOM1 itself.

While this might seem like a remote possibility, the reader has to understand that in all likelihood JPMorgan did sink the Titanic with the intent to kill some of those onboard such as Strauss (who was the head and treasurer of a public advisory watchdog group which tasked itself with overseeing the development of what became the "Federal" Reserve), that the US Constitution never gave the "Federal" Reserve the power it wields today, that it came from meetings behind closed doors from Jekyll Island and has over the past decades the dollar has stripped the populace from its wealth by control from what is in actuality a private corporation that created the present day situation wherein the dollar will soon hyper-inflate due to the collapse of the dollar hegemony and petrodollar empire. This is just one example of how determined an adversary can be in the power-game of finance. And any intelligent global adversary will keep its enemies closer, and hold ownership of something that poses a threat. Ergo these adversaries will not sell their $ATOM1 for $ATOM, or certainly not at the rate that we expect them to. They would instead naturally accumulate $ATOM1 if it is a viable threat to the status quo, and use these $ATOM1 tokens in the most harmful way possible--to vote again to turn $ATOM1 into money, and thereby dilute the intelligence of the chain, or something just as damaging.

(this is where many people get frustrated, claiming that these are just nutty conspiracy theories without any refutation; but what are they even doing in crypto if they don't agree with why Satoshi made Bitcoin, as memorialized in the first Bitcoin transaction as a link to a news article about the damning insecurity of our financial system? they are naive capitalists with no frame of reference Donny, and we don't write for them, we write for the initiated with ears to hear.)

The real problem is that there is nothing at stake in an airdrop, and tokens given without anything at stake, with nothing earned, makes for a poorer distribution than the alternative. This creates an unnecessary selling pressure if there is a market, and if there isn't a market it would remain and fester in governance.

Furthermore giving a 1:1 no-slashing airdrop fails to exercise the function of slashing and creates precedent for lack of accountability. We WILL see governance voting used maliciously against the will of the rational and/or principled minority, and we WILL see those who are opposed to the autonomy of a minority exert their airdropped voting power not to sell but to suppress innovation of competition, because it is possible to do so (or in the very least it is an evolutionary cat and mouse game). It is trivial to concoct fork suppression strategies that incentivize say $ATOM1 holders to keep their tokens and to use it for harm. The question is not whether these meta-strategies matter and whether they will be deployed, but when, and so the pertinent question for us from first principles is how we can ensure that we can survive despite it. Some (or "They" since they are other) will always frame it as this or that and chide us for splitting (while slashing YES voters), but splitting is NEEDED as an existential matter and so we must exercise this power and ensure that this option remains open for future generations and not closed for a while by public sentiment manipulation as it is happening now.

On the other hand if there is some skin in the game to get say $ATOM1 from $ATOM after genesis, then this can improve the distribution and creates by fiat an (initial or ongoing) integration, and can prevent a mass selloff of the original staking token which isn't at this time beneficial to anyone. This can be accomplished by a variety of means as a second stage to come after genesis, where genesis is an opinionated post-slash distribution, but any $ATOM holder can still participate and acquire $ATOM1 as long as they are willing to put up the skin so to speak. And this ensures that there more cost to the sufficiently capitalized adversary. We could allow some ATOM to bid for ATOM1 up to a limit. If we 100% slash YES voters for ATOM1 then letting ATOM bid for half of ATOM1 seems pretty reasonable. This way if you voted YES you will get slashed on genesis but if you participate with everyone else on the post-genesis mechanism (whatever that is) then in the end you would end up with about half as much as someone who voted NO (roughly speaking).

There are many ways to implement this second $ATOM1 acquisition mechanism from $ATOM. The best approach would maybe incentivize the early $ATOM->$ATOM1 acquirers a slight incentive over those who come later, but not in such a way that there is egregious favoritism for early participants. More like how Ethereum did their fundraiser, less like a typical bonding curve.

Will this be enough to appease the masses and ensure harmoney rather than discord, while also ensuring a higher cost to a global adversary? We can't know unless we try. We know that some people will always be unhappy, and we know that some shills will be hired to promote discord. We ourselves will have to deal with the need to advertise our hub as more secure than the alternatives and the discord that comes from that, but also we should be comfortable with competition dynamics.

Arguably what matters is the degree of slashing for genesis and the degree of integration for the post-genesis mechanism (if any). Whatever it ends up being, as long as there is substantial penalty to those who voted YES for a proposal that should not have passed (by the nature and spirit of OUR real unwritten constitution) for genesis and real skin in the game and limitations for the secondary mechanism, the narrative is secure; and we will be better set up for the next round of splitting where the slashing can be more or less and other parameters tweaked.

Proposed GOVNO.md file with following contents:

AtomOne Governance-Only “GovNo” Chain

The governance-only chain AtomOne GovNo chain is hereby proposed to be an independent component of genesis. The proposed token GOVNO is only for governance (and staking for governance).
This chain software is proposed to be a fork of cosmoshub4 with minimal modifications.

SendTx will be disabled for GOVNO. GOVNO cannot be transferred, sold, or given to another individual or entity, have no cash value and cannot be redeemed for cash, credit, or any other item of value. GOVNO are intended solely for use within the governance-only chain. (Govno is also slang for “shit” or "turd". This helps communicate that the token is not expected to have any value. 💩)

The AtomOne GovNo chain is not the main chain, and it is intended only for the purposes of assessing the sentiments of the No and NoWithVeto voters for proposition #848* and for discussion of next steps such as the AtomOne proposal. NoWithVeto voters will not be given a bonus for their veto for the purpose of the AtomOne GovNo chain.

This governance-only chain is inclusive of alternative proposals which can or should have their own distinct name. Nothing shall prevent this governance-only chain from discussing alternative forks of the AtomOne draft proposal in github.com/atomone-hub/genesis unless the chain DECIDES to limit itself. In this way, the github.com/atomone-hub/genesis repository is not exclusive, and this process can be inclusive of alternative ideas.

The criteria for inclusion in this governance set is simply the No and NoWithVeto voters of proposition 848. The dissenters were a sizable minority at 48.2% (nearly half) where the voting turnout was 73%, and these dissenters have uniquely demonstrated alignment (since prop 82) for a proposal that cut to the heart of identity. Therefore it is naturally up to this group to decide the genesis distribution, constitution, and other founding documents of the AtomOne split. In this way, proposal 848 was fortuitous. (We may not be so lucky in the future, and we should invest in tools to better help split a community in the face of distributed adversity.)

No decision from the chain will be used to force a change of this or any genesis repository if there is disagreement from the owners and maintainers of such repository. In this way, every subgroup working on their own genesis recommendations (especially forks of github.com/atomone-hub/genesis) can have their own opinion about genesis, and they can update it and accept merge-requests voluntarily, and work over time to convince GOVNO to accept its version again later. Anyone can resubmit the (substantially same) proposal after the community has had a chance to rethink it (but your deposit is at risk; see below).

We propose that in our public communications we emphasize that it requires a ⅔ supermajority for anything to be “decided” by governance of this chain (partially because that will be the acceptance threshold for all proposals on AtomOne, but primarily to avoid accidentally inducing another split). We propose that all proposals on the AtomOne GovNo chain only be used to determine the sentiment of the Proposition #848 No and NoWithVeto voters; and that all proposals first be discussed on GitHub (namely github.com/atomone-hub/genesis/issues).

We propose that in order to reduce spam, the governance chain set a very high deposit limit for the proposals to prevent spamming. Furthermore, if a proposal is rejected with more than ½ voting NoWithVeto, we suggest as the initial assumption that the deposit be considered for slashing for any relevant future genesis distribution, and how much. Furthermore, if the No and NoWithVeto voters judge an account to be spamming, that the spammer’s tokens in any relevant future genesis distribution may be considered for slashing, and how much.

This document does not specify any further the potential role of the AtomOne GovNo chain with regards to genesis and what it can decide on. When and how genesis happens should be guided by reason in the discussions on chain and in the various repo issues (such as those on GitHub).

Here are some suggestions and ideas about what may happen after launching the governance-only AtomOne GovNo chain:

• This chain might continue to serve as an advisory group for AtomOne.
• GOVNO may at any time be used by participants to endorse the GOVNOA distribution (another non-transferrable governance-only token) which includes weighted abstain/non-voters, and may give a slight reward to NoWithVeto over No voters, for the purpose of polling a broader distribution for non-security related questions. Security related proposals are best answered by GOVNO.
• GOVNO may at any time be used to discuss other token distribution strategies (such as whether to include prop 82, etc) but must confirm these decisions with a second proposal.
• GOVNO may at any time be used to republish and update any token distribution mentioned here or derived on the AtomOne GovNo chain.
• The AtomOne GovNo chain itself may fork.
• The AtomOne GovNo chain may adopt a more sensible name.

Security Specifications

Nothing that hasn’t already been in use and audited (except a custom cli if required, any such cli will need to be audited first by the chain and at least one independent security firm).

AIB has volunteered to publish recommendations about genesis software readiness and the release and audit of procedures, but should not be the only source of information especially as this is a decentralized process.

Wallet Integrations

We can use permissionless APIs like the one that Kelpr offers for hardware wallet signing, but we should use the same Cosmos signing app, not create a new one.
We can also recruit validators and blockchain explorers to support the AtomOne GovNo chain (and similar GovNo chains for other projects)
Anything else?

Disclaimer: Nothing in this document shall be construed as a token offering. Nothing is guaranteed, such as participation for those addresses that are on the OFAC sanctions list.

What’s the current and expected upcoming relationship between this repo and https://github.com/tendermint/atom_one?

I generally support using Creative Commons or a similar license for no-code gems.

While I'm fond of the GnoPL for projects where we need to safeguard development time to create robust products, it's closely tied to Gno and the Gno Network, which may not suit all projects.

Therefore, my recommendation is to go with Apache2, potentially adding a term for X years of strong attribution to ensure credit is given where due.

Related with #46

It appears ICF own the 'ATOM' trademark in the context of cosmos & blockchain etc. I believe this needs attention asap.

At present, I don't see any, but it's worth asking if there might be reasons to consider one.

If not, should we explicitly mention in the README that such a situation will never occur?

What timezone are you in?
What topic do you want to talk about?
What app/site/medium works best for you?

Reserved the handle @_atomone (following Gnoland's handle nomenclature, @_gnoland) and have created a first direction for ATOM ONE's brand identity.

The handle is transferrable at the team's request.
With the team's support I would like to continue to develop ATOM ONE's identity.

stATOM holders are ATOM stakers, through Stride.

stATOM holders are part of the ATOM community and secure the Cosmos Hub. As such, they should be included in the ATOM1 genesis file or airdrop, like all other ATOM holders and stakers.

stATOM is primarily held on the following chains:

• Cosmos Hub
• Stride
• Osmosis
• Umee
• Kujira
• Secret Network (Shade)
• Evmos

The Stride Labs team can snapshot stATOM holders and balances on each of these chains, at whatever block height ATOM1 chooses and upload the snapshot to this Github repository.

Stride does not vote on governance proposals, so how stATOM holders should be treated is up to debate. They are probably most similar to an ABSTAIN vote on Prop 848.

There are two different ways this distribution could work:
(1) stATOM holders receive $ATOM1 tokens at their address, on the ATOM1 chain.
(2) Stride launches liquid staking for $ATOM1, and a Stride ICA is credited ATOM1. Then, Stride can mint stATOM1 and distribute it to the addresses directly, so the stATOM1 holders can more easily use the tokens in defi.

Open questions:

• How should stATOM holders be treated, relative to ATOM holders, ATOM stakers, and 848 voters?
• To which accounts should the ATOM1 be airdropped?

This is a list of thoughts/considerations I believe will be beneficial to the design of AtomOne:

• Adopt Decentralists DAO governance suggestions: https://github.com/decentralists/DAO/tree/main/governance

Some have already been adopted by the hub. The most important one in my view is the separation of staking and governance.
Extending on that, and because direct voting suffers from voter apathy to an extent. I think a staker should be able to delegate to an account for voting on proposals the same way they delegate to validators. It is already possible via authz but I think a specific module/redesign of the mechanism would be better.

In a slightly more extended system, proposals could be "tagged" as pertaining to a specific domain: e.g. marketing or architecture etc. and a staker could have the option of setting different accounts he delegates to for different tags.

The reasoning behind this design is that as mentioned in the Decentralists DAO roadmap, validators should not be politicians. Validators should be solely chosen based on their performance, security considerations and technical know-how.

The reasoning for the afore-mentioned tagging system is that it's very hard for a staker to follow everything that might be happening within the chain and wider ecosystem or have the necessary know-how to evaluate/judge a proposal.

Over time, certain accounts will become recognized in the community for their expertise in specific domains. Allowing stakers to delegate decision-making to these trusted accounts will foster broader, though indirect, participation in governance.

The crux of it is that as a staker, I want to be able to codify that:

1. I trust person X to run a secure and reliable validator
2. I trust person Y to know his stuff when it comes to marketing
3. I trust person Z to make architecture decisions

etc.

• Community Pool overhaul

The community pool is a very powerful tool for growing a chain and ecosystem that has been severely abused and misused in the past due to the existing governance system and certain aspects of its design. Based on my observations and the discussion here: #32 I would propose the following:

1. Limit funding per proposal
   This can be a hard-limit in $ or a perc-of-pool limit. Changeable by governance within bounds

2. Funding proposals should have a start-date and end-date thus allowing for a total funding limit at any given time.

3. Proposals should be denominated in $ (or other fiat equivalent) until such time where token volatility is sufficiently low to not have to. For approved funding requests, a faux-stable/USD-pegged token could be minted for the amount requested which could be redeemed in part or in full at any time between start/end dates for the actual community pool funds based on an (oracle-provided) exchange rate.

4. Building on the above, release of funds could be gradual/vested over the start/end period for most proposals. Lump sum release could be requested but would require a higher majority approval.

5. With a gradual/vested release, a proposal could be contested in the future and with appropriate majority approval rescinded to stop the release of funds. This would be appropriate in scenarios such as the one currently in progress with Notional and Proposal 104 of the hub

I will add to this topic based on discussion and subsequent ideas

Hi community,

looking at the foundation of what AtomOne shall be, also in relation with #41 Photon Token design, I propose to not name the new token ATOM1.
Instead my suggestion would be #GAIA to relate to the core ideas which would also reflect the reasoning of the fork.
#HUB would also be a possibility I prefer over #ATOM1.

The similarity with the Atom to Atom1 token would not only always remember of the fork character, which will also carry a level of tensions, it also shows less independence. To restart and find an own identity it would be an advantage to have no similar token ticker.
Also, there is the aspect of purchasing the token and understand the ecosystem for less involved investors or somebody researching info about AtomOne.
A more distinguished brand from the Cosmos Atom token is neccesary to be independent; also to ensure its identity in speech, merch, public relation etc.

On the back of this token discussion you could also discuss if the whole project in this case could be names #Gaia or #Hub but that would be a follow-up decission.
Though I understand Jaes sentiment to relate to the core of his former project Cosmos Hub with #Atom I believe a further step away to ensure the resturn to the core ideas of the hub+ photon is required to ensure a well done split as intended.

Regards.

Money is tokenized trust

Money is the most common collective hallucination in the modern world. Its primary function is to increase social cooperation and lower entropy, by streamlining interactions such as exchanges of goods and services.

Initial assumptions

Money starts to exist as a mental concept way before its material representation. Before owning coins, notes or bits in a computer, we alredy have an intrinsic representation (and expectation) of some specific value. That perceived value of an item or activity is different for each individual, based on education, current context, expectations, etc. Food is more valuable when you're hungry. Housing is less valuable if you already have 3 properties.

Money acts as a collective mental plasma for aligning these perceived values and expectations.

It does this in two ways:

• first, it creates material representaions of the mental concept (metal coins, paper notes, bits in a distributed ledger)
• and second, it tokenizes them - splitting into fungible, interchangeable units.

This process of tokenization makes the infinite differences in perception of value manageable: it's easier to move a needle on a scale with 100 equal steps, than to assess one big rock of gold. That's how the double coincidence of wants is solved.

As interactions in a community are unfolding and as community members are aligning their perceived values, a subtle shift happens in the perception of the money itself: the material, tokenized representation takes over the initial mental representation.

Because each specific interaction reinforces the expectations, more trust is added to the external system, so eventually the material representation frontruns the mental process for establishing value. We start to think in terms of dollars and Bitcoins, not in terms of food, housing, clothing, performing or receiving specific services.

Ironically, the more a specific type of money is aligned with our mental expectations, the faster it frontruns them, replacing the internal process with external material units.

This back and forth process is never ending. We are continually assessing our needs and ascribing value to what we get or give, and we are using various types of material tokenized trust to represent them.

The most important consequence of this is that if enough trust is placed on the material, tokenized layer, modifying that layer will modify the value itself.

Remmeber that each individual has different perceptions of value based on education, context, etc? Well, if the collective hallucination is strong enough, these are overwritten by the collective representation, and instantly actualized in the mental plasma uniting all members of the community.

In a balanced, healthy community, whoever controls the material, tokenized layer of the collective hallucination (usually the community leaders, the "government") ends up controlling the mental represenation of value too.

From that moment on, any modification of the external layer will end up either decreasing, or increasing trust too. Most common action taken on the external layer is supply manipulation (increasing / decreasig the number of tokens in circulation).

For instance, if the material layer is destabilized by artbitrarily printing new tokens, trust starts migrating back into the mental level, and out of the tokenized suppport. Slowly, the collective mental plasma is not as conducive as it used to be, so new alternatives are researched. New forms of material, tokenized support are created.

Similarly, if the external layer is modified by verifiably limiting the token supply, the trust in the material layer increases and the mental representation subsides. We start to take for granted that some token carries more value, simply because more people seem to trust it.

Consequences

The right to soft fork

If the back and forth between the mental representation and its material, tokenized support is never ending, it means money soft forks are inevitable.

USD is a soft fork of the GBP, as more trust started to migrate from an old country to a new one. EUR is a soft fork of a few local currencies, because more trust started to migrate from those local communities to the newly established federation / community.

Any ecosystem will soft fork at some point, if the discrepancy in trust between the mental representation and the tokenized support is too big to handle for a majority of stakeholders.

As such, the AtomeOne consistution should implement the fundamental right to soft fork.

The primary value is trust

With the maturation of any ecosystem comes the inevitable trust migration from mental representations of value to material tokens. The trust loop acts as a self-fulfilling propehcy, and eventually makes the tokenized support the default level of value.

But too much reliance on material support creates a governance vulenrability. Leaders controlling the token creation and supply can become corrupt, or they can be disconnected from the main goals of the community they lead.

Thus, the fundamental layer of any thriving ecosystem is not its economical power, which can be (and almost always is) corrupted at the material level, but the measurable level of trust in its leaders / governance. If trust is there, it will eventually migrate into tokens too. If trust is dwindling, even if the tokens are "valuable" now, they will lose power as trust fades away.

As such, AtomOne consitution should primarily enforce trust (in its vision, processes and execution) over the material, tokenized layer. Trust should be constantly measured and assessed and it should be considered the default level of value, regardless of the actual market value of the tokens in which it may migrate.

Prioritizing trust at the governance level, coupled with the right to soft fork may - and it probably will - result not in a monolithic AtomOne ecosystem, but in a constellation of autonomous entities, each carrying various levels of the initial AtomOne DNA. AtomOne constitution should guarantee their right to existence.

In view of recent events in the Cosmos ecosystem, and in particular the community reactions to proposal 836 on the Community Pool fund for an amount of 44,000 $ATOM (https://www.mintscan.io/cosmos/proposals/836), > 1M of $ATOM (https://www.mintscan.io/cosmos/proposals/839), I hereby propose a new funding approach.

Problems

Community pools have often been controversial in the past. Many community members around me believe that some funding has been aberrant, others have been arranged with validators.

Problem number 1: A priori project funding is given in $ATOM

Even though I believe, and I hope the other builders do too, that the $ATOM token will regain strength against the dollar, there is still a significant amount in circulation with each proposal.

Over the past 12 months, $ATOM 1,420,485 has been allocated to funding, rising to $ATOM 1,460,485 if proposal 836 is accepted.

At the current $ATOM token price, this represents $9.403 million.
That’s 0.0485% of $ATOM’s market capitalization, but more importantly, almost all the liquidity available for ATOM pools on Osmosis today…
(see community-approved proposal numbers 814, 800, 717, 687, 202, 155, 104, 103, 101, 95, 94, 89, 79 and 77.)

Problem number 2: $ATOM spent leaves the Community Pool

This may sound logical, but I don’t think it is. Project funding should be a long-term, ongoing process, not a one-shot affair. I would add that we should have milestones in the funding, with a public presentation of the results, and the implementation of a continuation, or not of the funding.

This is not the case at the moment, and so we have funding allocated that does not lead to the expected result, with maximum risk-taking for the Community Pool, and therefore the community (find examples).

To date, the Cosmos Community Pool has $5,075,301 available. This represents $970,905ATOM in staking revenues, per year, with the current APR.

That’s 6.4M of funding, per year, at the current price.

That’s more than enough funding.

Proposed solutions for ATOM1 Community Pool

Focus 1: Preserving and expanding the Community Pool

My first proposal is that, when funding is requested, it should be presented in terms of the number of $ATOM1 per day, and the duration of the day.

In this way, the Community Pool will be able to store the number of ATOM1s needed (the latter being variable) to provide the financing required and voted by the majority, without touching its capital.

Let’s go back to our figures. We have financed $1,420,485 in ATOMs over the last 12 months. To simplify the calculation, let’s agree that 12 months ago, we already had $5,075,301 + $1,420,485. If these $ATOM had been staked, they would have generated ((5,075,301+1,420,485)*0.1913) 1,242,643 $ATOM in rewards.

Without staking and linear financing, our Community Pool went from (5,075,301+1,420,485) $ATOM 6,495,786 to $ATOM 5,075,301, with builders financed out of capital.

With staking and linear financing we would have an unchanged Community Pool, and builders financed on rewards.

Focus 2: Organize financing via the Community Pool in a linear fashion

A development project is complex, managing teams, particularly in Web 3, is tedious and time-consuming, and blockchain, apart from ATOM Accelerator on ATOM, which has its own funding, currently has no means of monitoring the project.

Thus, achieving linear financing, day after day, with funding renewal gates, via public proposals, secures the long-term financing of AtomOne, and its builders.

Fund a central support team for all chains which launch on cosmosone and hub only. to route IBC transactions

1. HUB only to route IBC transactions will generate a lot of $$ and could be used for growth, support and reward users
2. A central support/growth team for atomone ecosystem could be required

Please feel free to use this issue to ask questions that you are unsure about whether they deserve their own issue. We will select them (if not duplicate) and reply to them in a new FAQ.md file over time, and we can discuss them during an AMA.

See also #53.

UPDATE: trying out $ATONE for now until there is need to change it.

We've discussed that the $ATOM1 ticker might be an issue, as seen in these links:

• #53 (comment)
• #14 (comment)
• #14 (comment)
• https://x.com/sunnya97/status/1731677548713529521?s=20

This thread is to focus the conversation on choosing a ticker. We want a clear issue name for easy follow-up and understanding.

Note: The genesis repo is likely more of a framework than a specific blockchain instance. This means we could use $ATOM1 to simplify our documentation, emphasizing concept explanation. We can update the README to state it more clearly. Similarly, we should consider a term like $ATOMX as an equivalent to $phATOM1 for $ATOM1. For uniformity, we might also adopt $PHOTONX in place of $phATOM1.

If you believe that we need a new ticker, please comment here with suggestions and your reasons.

Is there anyway to set up a system that supports creators and atom1 supporters? To reward supporters or users that have left the cosmos network by unstaking their atom’s. Give users a opportunity to earn since A lot of users seen this coming from miles away and unstaked in the beginning of these proposals.

We have contributors that really love the Vision that Jae kwon introduced but it’s been poisoned by other people’s greed.. entities that don’t steer in the same direction.

groups trying to get any kind of value they can. Extracting what they can.. and dumping any kind of money they get their hands on.

what about people who believed in cosmos network; thought it was going to change the temperature in crypto but then soon came to realize that most devs and insiders are just in it for the money.

This is an opportunity to change the direction of ATOM and create a new product called atomONE.

reinforce the vision that we all shared and to shut up the doubters. Make the losers whole again. It’s not impossible to create a winning product in this shit show we see today.

Originally, there was a snapshot for a past proposal. There’s supposedly a new snapshot for users that voted no. A lot of users seen this coming from miles away.

We’ve had many Jae supporters leave the $ATOM & cosmos network due to the changes that were happening.

there should be another method that is used to create some noise and attract some users that laugh at the old atom. Create a new community that is better and thrives harder.

will leave this short and sweet…. until next time America

yours truly. — > WeldingBTC

On several threads there seems to be an underlying tension between favoring the use of AI for contributions and an opposition to such practices—the latter mainly from the project visionary @jaekwon. It's fully understandable how the use of AI can be a seemingly practical quick fix, but one with severe consequences over the long term.

I suggest we, those in favor of building and contributing without the use of AI, commit to it publicly. This should not be a constraint for all (especially those who might not convinced about the harmfulness of AI), but just a public decision from those who refuse, to commit to human-made work. This issue pertains to a philosophy of work, an approach to how we contribute.

If this issue is out of place, please delete it.

This goez way ahead but ..

Official Cosmos Network ATOM-ONE hub NFT which would be distributed at the genesis for everyone as an OG bluemark which can have later usecases and hold future benefits

I think it's worth discussing more in depth how the $PHOTON token system would work in practice. For now, let's leave out the issue of how these design choices would map in the context of offering the same "liquid staking" for the Cosmos Hub as an external liquid staking provider. I wanted to focus the attention on the section https://github.com/atomone-hub/genesis#phatom1-the-more-deflationary-version-of-atom1

Also for the record, I will refer to $PHOTON here even though the document talks about $phATOM1 (and sometimes interchangeably also $phATOM), but it's meant to be the same thing. Btw I kind of like the idea of getting away from the prefixTOKEN convention for this experiment - hence why I am using just $PHOTON - I am advocating for removing this explicit link in the name. In the end, we are trying to create a token backed by $ATOM1 but that can have it's own independent existence. But I am digressing.

1. $PHOTONs give in general no governance rights
   1a. $PHOTON holders can have governance voting power for certain specific proposals, related to $PHOTON itself (e.g. raising the tax cap). Interesting, but complicated to achieve fairly without $PHOTON token-locks (cause e.g. I could vote with a flash-loan otherwise). More clarity around how $PHOTON holders could be allowed to vote is required

2. underlying $ATOM1s are auto-staked proportionally to existing voting power. Would be interesting to understand what would be the minimal changes required to attain this without a need for constant rebalancing whenever VP distribution shifts (if at all possible). And would this rebalancing consist of regular re-delegations, subject to re-delegation slashing rules? I also think figuring this out is important to minimize the Principal-Agent problem: https://eprint.iacr.org/2023/605. See also my reply in #13 (comment)

3. a 10%-capped tax is deducted similarly to a validator commission (this cap can increase as specified in the section) on the auto-staked underlying $ATOM1s non-$ATOM1 rewards (see #41 (comment)). Aside from that, no other tax is applied, and underlying $ATOM1s are auto-compounded so that the percentage share of $ATOM1s bonded through $PHOTON over the total $ATOM1s supply can only decrease due to slashing events. How is this tax set? fixed number through governance? dynamic? Is validator commission bypassed?

4. $PHOTON only accrues $ATOM1s rewards, other non-$ATOM1s rewards are forfeited (this is actually not the case: see #41 (comment))

5. The $ATOM1s bonded toward auto-staking do not count toward calculating the bonding ratio target of 2/3 in either the numerator or denominator.

6. A total of 1 Billion $PHOTON are only allowed to exist, the invariant being that if all the $ATOM1 in circulation would be converted to $PHOTON, it would be for at most 1B $PHOTONs and never more.
   In classic liquid staking derivatives, the conversion formulae are, as for example shown here:

   • when bonding x $ATOM1 tokens to mint y $PHOTON liquid staking tokens, y = x * y_t/x_b where x_b is the amount of tokens already bonded through liquid staking and y_t the total issued liquid staking tokens currently in circulation. Initially, when y_t = 0, the conversion x to y is 1:1.
   • when burning y $PHOTON liquid staking tokens to unbond x $ATOM1 tokens, x = y * x_b/y_t, where x_b and y_t are the same as above. This second formula I assume would not change even in our case. The redemption $PHOTON to $ATOM1 should rely on the actual $ATOM1s available. Where we want to probably make a change is in the formula to convert from $ATOM1 to $PHOTON

   If we want to add the 1B max (noted as y_max) $PHOTON invariant, a simple approach might be to use the percentage share of the x $ATOM1 that gets bonded over the total x_t $ATOM1 supply. We would introduce a "virtual" conversion rate that could equate to:

   C = (y_max - y_t) / (x_t - x_b)

   Using the same notation as above. Therefore whenever someone bonds x $ATOM1s for y $PHOTON the conversion would happen as:

   y = x * C

   while the redemption of x $ATOM1s from y $PHOTON would follow the formula:

   x = y * x_b / y_t

   Considerations:

   • If the ratio of x_b/x_t increases (because staking reward > inflation), there is an incentive to bond more $ATOM1s to get $PHOTON as you "steal" some of the $ATOM1s from the $PHOTON-bonded "pool", up to equalizing with the inflation rate (you decrease the redemption rate because you "dilute" the existing $PHOTONs, but redemption rate still remains higher or equal than the conversion rate). It is also true however that the amount of arbitrage that can be done is actually limited by the $PHOTON to $ATOM1 redemption mechanism (which is essentially supposed to be rate-limited from my understanding). In the end, if you care about getting the true staking reward rate, you should stake $ATOM1s yourself and not bond to get $PHOTONs. The guarantee $PHOTON gives you is only that you will not be taxed through inflation.

   • when a slashing event occurs, the proportion of $PHOTON-bonded $ATOM1s over the total $ATOM1s supply x_b/x_t diminishes, since in proportion the $PHOTON-bonded $ATOM1s x_b decreased more than the total $ATOM1s supply x_t due to the total $ATOM1s staked being less than 100% (in the case of 100% $ATOM1s bonded it would decrease equally in proportion and the ratio would not be affected). The mere fact that there are less x_b causes the redemption rate to go down, which in case it goes below the conversion rate (or rather it's inverse) would disincentivize bonding more $ATOM1s for $PHOTONs as you will immediately incur in a loss of $ATOM1s when depositing, while everyone else's $PHOTONs will increase their redemption power. However, assuming the protocol works as intended, since the growth rate of x_b is faster than x_t the redemption rate will eventually recover. The case in which this is not true is either if bond ratio of $ATOM1 is 100% or if the protocol constantly slashes validators. Both cases are impractical and the second one in particular would already disincentivize by itself $PHOTON bonding, so conversion/redemption dynamics would only exacerbate this (disincentivize $PHOTON bonding more), not be the cause by themselves. And maybe this is fine.
     The opportunity cost of not bonding your $ATOM1s to $PHOTON right now and wait instead is marginal. It could even actually be that conversion rate after a slash event is still lower than redemption rate. Actually, this is expected in most cases.

7. We have to define how redemption works in practice. What about re-using some of the ideas in https://github.com/tendermint/atom_one/tree/c0f7d935930fedb700866c079a7056729e87d899#article-3c-the-photon-token ?

I'd love feedback, especially on point 6 (I am open to the possiblity that all I did there was completely flawed 😂). And in general to explore more in depth the dynamics of the dual-token model.

Let's start our chat about what software we should use first for our project.

We've got two main ideas:

1. Starting with Tendermint 2 (tm2): This means we'll need to build some missing parts. We've got two ways to do this:

   1. We could start tm2 with what it's got now.
   2. Or, we could make some early changes, like adding a new governance module.

2. Starting with a Cosmos Hub 4 fork: We're thinking about this release: Cosmos Gaia v13.0.1. This could be done fast. Then we would add the changes we want, bit by bit. In the end, we can think about moving to tm2 when it makes sense.

Once we've decided how to start, we can plan out the details for this launch, and also the rest of our roadmap and big milestones. Then, we can start the first milestone, making a list of things we need to do in a big issue or a GitHub milestone. This way, we can keep all the tasks together as issues, but also use issues for long chats or things we need after milestone 1.

Remember: I'll keep this top issue updated with big decisions, as well as replying with comments.

1. Validators acting maliciously or negligently leading to slashing predominantly affects delegators, a significant concern within the Cosmos ecosystem. Many validators merely meet the minimal self-bond requirement, a practice that can be detrimental. While delegators should ideally choose the most reliable validators, they often lack the necessary expertise to do so. Smaller delegators, in particular, tend to trust validators implicitly, without frequent verification. In such cases, it is the delegators, not the validators, who bear the brunt of any loss in value. To address this, one potential solution is a variable minimum self-bond requirement. Validators could be required to maintain a self-bonded token amount equal to the potential slashing penalty (thus directly linking their stake to their behavior) or a significant percentage, such as 50%. Additionally, validators might be restricted from withdrawing commissions if their self-bond falls below this floating minimum.
   The case of the Notional validator on Osmosis exemplifies this issue. Despite its inactivity and jailed status, it still holds 3.83 million bonded tokens, underscoring the urgent need for tighter control and greater awareness among delegators.

2. The practice of creating new validators with the same name after one is jailed, as observed in some chains, should be disallowed. This would prevent confusion and potential misuse of trust.

3. To reduce risks in the chain, imposing a cap on the amount of bonded tokens held by a single validator might be effective. For example, limiting a validator to a maximum of 10% of staked tokens would prevent excessive centralization of power. Once this threshold is reached, no further delegations would be permitted, encouraging delegators to seek alternative validators, thus promoting a more equitable and secure network.

4. Finally, addressing the issue of jailed validators, they should not be allowed to undelegate their tokens. It would also be prudent to implement a comprehensive undelegation function for validators. In cases where a validator is jailed, they could issue a full undelegation request to the chain, automatically returning all delegated tokens to the respective owners' wallets. This would enhance the security and fairness of the staking process.

Context

Given this blog post, we can define the following versions of the main interchain security (ICS) protocols :

• ICS v1 : Replicated Security
• ICS v2 : Opt-in Security
• ICS v3 : Mesh Security

So ICS1.5 is an evolution of the Replicated Security (RS) protocol, let's define how Replicated Security actually works (for the other protocols I invite you to check the article).

Replicated Security requires a provider chain and one to many consumer chain(s).

The validator set of the provider chain is replicated (hence the name) to each consumer chain. This means that for each new consumer chain (a consumer chain can only be added by a governance proposal in the provider chain), each validator of the provider chain must run a new node for that consumer chain.

Once live, the provider and consumer chains exchange messages using IBC. For example, each time there's a change in the validator set of the provider chain, the consumer chain receives a Validator Set Change (VSC) IBC message to reflect this change in voting power. These IBC communications are handled by new modules, the provider chain must import the x/ccv/provider module, while the consumer chains must import the /x/ccv/consumer module. Note that the consumer module must replace the staking module, since the consumer chain doesn't have its own validator set, and has no staking mechanism. Both modules are hosted in the interchain-security repo.

There's another type of message exchanged in this protocol, the VSCMaturedPackets. This one, sent by the consumer chain, ensures that unbonding operations are synchronized between the provider and consumer chains. In other words, it ensures that an unbonding operation registered in the provider doesn't end earlier than in the consumer chain (due to IBC asynchronicity). This is a safety measure to prevent misbehavior of a validator on the consumer chain. If a validator has unbounded on the provider chain, but due to IBC asynchronicity, has kept his voting power on the consumer chain, he can potentially misbehave on that consumer chain without being slashed.

These VCSMaturedPackets imply a lot of code, and based on @jaekwon idea, we think it could be simplified. We (the decentralists) proposed an ADR where we remove the VCSMaturedPacket but it wasn't accepted at this time.

Define ICS1.5

Removal of VCSMaturedPackets

I believe ICS1.5 is ICS v1 without VCSMaturedPackets, but at this point we have no guarantees that this is actually doable.
Recent report done at Informal to see if it's possible to remove these packets found that the above ADR does not guarantee the security model.

Here's an excerpt from the report describing the problem:

A malicious validator can keep sending bogus updates to a light client tracking a consumer chain even though the consumer chain might have stopped or might not be accepting user-generated transactions.

Core and Consumer shards

Another feature of ICS1.5, mentioned in the README is the creation of 2 types of consumer chains, the "core shards" and the "consumer shards".
While "consumer shards" is something similar to the consumer chain in RS, "core shards" states about a stronger link between the provider and the consumer chain, especially the fact that the governance of these chains is only handled by the provider chain, hence AtomOne.

There's probably more differences between core and consumer shards, if anyone has more information, please comment this issue.

Other features ?

There may be other features we want in ICS1.5, let's use this issue to list them and evaluate their code complexity and security impact.

Nothing has been decided for sure regarding the ATOM1 split currently being discussed in X, but I would like to hear Jaekwon's plans or desired direction.

1. What is the airdrop rate for YES / NO / VETO / Abstain / new holders (holders who did not hold ATOM at the time of voting)?

2. When is the expected Snapshot date?

3. Will the CEX(binance, coinbase, upbit etc..) exchange request support for airdrops at the time of snapshot?

I think it is important that we have a safe haven against AI, and I didn't think the moment would already be here but blockchains IMO are part of the needed defense against AI takeover.

I believe the constitution should put some limits on where and how AI can be used, such as by disallowing any mandate in proposals to use them, for example, and banning the use of AI from core code.

Some usage can be fine; blockchain explorers we can't necessarily stop them from using ChatGPT, but overall this creates a backdoor to our collective intelligence unless we are careful with its use.

And personally I feel strongly for myself that I should not use it at all, for the same reason why we wouldn't want to give a hostile enemy that much power over us and to support its growth by using it, until its ultimate takeover.

My personal desire is for AtomOne to ban AI outright to the highest degree, but I will not enforce this upon the hub if the $ATOM1 stakers do not wish for it. This can be another split.

Hello everyone,

Following yesterday's exchanges with Jae on the Community Pool and the already substantial information content, it's clear that most people won't read all the documents we produce.

I've tried to create a specific GPT, connected to this repo, to make it easier for those new to Atom One to understand it. The idea is to use this conversational agent to discover and understand Atom One, without having to read all the documentation.

I'm curious to hear your feedback on this subject.

https://chat.openai.com/g/g-t50BSINT4-atom-one-gpt

In addition to obtaining governance approval, should we establish any hardcoded conditions for becoming an ICS consumer of the hub, encoded directly into the software? Also, if we define these conditions, should we continuously monitor them over time?

With ATOM-ONE should be considered better alternatives for communications than Telegram which is not end-2-end encrypted and is full of malicious phishing bots or Discord which have suffered from hackings. Some better secure app where the official governance with different channels could be created

Before anyone can fully align with the constitution as a member, I believe it's important to establish a temporary space for individuals to express their interest in contributing to the project. This allows them to participate in its development without the obligation of committing to the final decisions.

For this purpose, we could create a list that serves as the basis for a mailing list. This list would be used to organize Google Meet sessions where open discussions can take place, helping to minimize scams compared to a completely open system.

I propose setting up a dedicated repository in the Atomone-hub organization. Here, interested individuals can either create an issue or a pull request to add a file with their details, like so:

name: Manfred Touron
github_handle: @moul  
email: [email protected]
intro: “Blockchain engineer, decentralization enthusiast”

Intro could be: “Curious staker” (not limited to builders).

Additionally, it would be beneficial to implement a mechanism to prevent email spam, while still allowing us to compile a list of email addresses for meeting invitations. This could be a simple cryptographic solution or perhaps a Google Form.

However, I think it's crucial that we maintain transparency and public engagement in this process.

UPDATE
I split this out entirely so ATOM ONE doesn't include the Decentralists much at all except once by reference.
And this seems right, because the Decentralists should be its own independent project. They complement one another but they also should not mix together excessively so as to allow for independent development. This is more decentralized thank linking them too early too soon forcing us to figure everything out at once.

The Decentralists is a party of equal individuals.
The AtomOne hub is a proof-of-stake hub based on $ATOM1.
They are related but different.
It's almost like one is the democratic view of the other.
How many $ATOM1 does one have to own to be a Decentralist?
I suppose it doesn't matter as long as you can prove your worth on chain e.g. even through contributions and discussions. But Decentralists I suppose can be expected to have at least one.

The main thing is, they are different governing bodies, so this should be reflected in all aspects of the document.

We require moderation, but the question remains: who should spearhead this effort? Who holds the authority and duty to moderate?

I offer my assistance, either in suggesting moderation strategies or in actively implementing them. Ideally, this should be a collaborative or rotating responsibility. It's crucial that we clearly communicate the rationale behind any decisions to close or merge, and provide clear guidelines for individuals to voice concerns if they believe a moderation decision was unjustified.

Additionally, we could enlist the assistance of others, or perhaps utilize tools like ChatGPT, to help identify areas with the most pressing need for moderation. See #24.

The document frequently mentions "The Cosmos Hub" without clearly specifying whether it pertains to CosmosHub4, AtomOne-Hub, or any hub that follows this constitution presently and in the future.

It is also a possibility that it specifically refers to Cosmos, while some individuals believe that the true hub is the IBC Hub. Considering that forks will inherit the constitution, perhaps we should consider a more inclusive concept?

Should we make any modifications to the document? I suggest considering a different wording or at least adding a definition.

PS: Can you confirm if CONSTITUTION.md should eventually be independent or if we should always consider it in conjunction with README.md? Because README.md is undoubtedly superior for definitions.

Once a document has settled enough that the paragraph structure has more or less settled and all known issues fixed, then the document should begin to be translated into other langauges. This repository should store all of the translated documents.
Each translation should include the translator, and the method of translation.

Rather than have AI do it, I think we should give time for people to take a stab. This way our choice of terms for example isn't determined by a centrally controlled service, and the community expertise grows and strengthens.

If in the end there are no human submissions, then arguably we don't even have the capacity to judge whether the AI's translations are correct or not, so we should wait for human submissions first anyways as that is a way to gauge interest naturally grow the decentralized localized community ecosystem.

We expect much from our validators. Not only to provide security, but also to make good governance choices as delegates (even if we support more flexible delegation systems where one can delegate to non-validators, we still need to delegate our trust of running validators securely to validators as a matter orthogonal to most others.).

What should the founding documents say about KYC and validators? The genesis validators can be KYCd by anyone, that is easy enough. But in general, what should be the policy for AtomOne?

Theoretically, it seems that stakers should be KYC'ing their own validators. If they don't know who the founders are, or executives are, for example, then how do they know enough to stake to them responsibly? Maybe somehow they do, but maybe you still want to make sure that the validator you delegate to isn't running their validator in a sanctioned country. But other stakers could live under different rules. Ultimately the policy that the hub adopts is by nature a self-sovereign one, but it can choose to align with any axis that it wants, and its voluntary choice of alignment should be considered before everything else, as well as the chances that it may be allowed to change alignment, and that it may not be able to stick to any one thing because of various external circumstances.

We can require that validators self-select and self-declare their jurisdiction policy choice by blockchain-based identifier, and these choices should determine what regulations the chain must abide by but only to be changed once +2/3 of the voting power agree to enact a new one first by chain then by governance. The stakers need to agree to the change to. But to change anything otherwise would be insecure. And until we have a secure system that works across hubs and zones, it is safest first to start with the permissionless base, and to support experiments of control, and also to support experiments of guaranteed freedoms.

I suggest we create a job for someone to take care of the Atomone project at AiB. This person would help Atomone move forward and be the link between Atomone’s community and AiB.

Let’s first find a leader for this job. We can think about hiring more people later if we need to.

I’m sharing this idea here, even though it’s mainly about AiB, because I think it’s good to be very open about our plans. It might encourage other groups to do the same.

We mention the goal of "fostering diversity and alignment." However, this phrase can be open to interpretation and may seem contradictory at first. We need to define what we mean by "foster diversity and alignment" to ensure a shared understanding.

Things to avoid include misinterpretation, conflicting priorities, biased judgments, and ineffective communication that makes people feel unsafe.

Maybe: alignment involves endorsing the constitution and core values, while diversity entails experimenting, competing, pioneering, taking risks, and iterating.

          > Instead of worrying about appeasing the current sloshy-ness (which can be traced all the way to the titanic, fed reserve, etc. aforementioned) around the Cosmos Hub, a full fledged exclusion for some parties is appropriate. Those that discount the minority opinion as "conspiracy theory" will only be a burden on what is trying to be accomplished.

I have to say I do love the principle. Let's encourage these people to sell what they get of their own accord. Then there will be less harsh feelings, and they will regret their own actions down the line. ;)

One thing I'm looking out for: the resulting genesis distribution must be capable of passing (with supermajority, or constitutional majority depending) what must be passed, AND have enough buffer to guard against the distribution becoming diluted again.

Also, it is really up to those who voted NO, to decide on the genesis distribution. It wouldn't make sense if the NO voters don't agree with the resulting distribution. If they would rather use a different genesis distribution, then there is no value to the rejected distribution at all.

In addition, we should be looking outward at how to bring those outside of crypto, who may share similar beliefs, into the sphere of an $ATOM1 constellation. Those who understand the scam of central banks and the like, are less likely to find ATOM1 if they have to sift through the grifter garbage patch elements that are the current Cosmos Hub.

Fully agreed. Please make a new issue to start the discussion about how to attract the right people into our community, those who are aligned and want to participate as equals.

Originally posted by @jaekwon in #12 (comment)

One question new protocols seem to ask themselves is “how can we bring crypto-native developers and users over to our ecosystem?”

Of course, this should be asked by the early participants of the ATOM1 fork as well.

But maybe more importantly, the ATOM1 Hub should ALSO be asking:
“How do we bring new users and developers, who are still outside of crypto, into our ecosystem? And not just anyone, but rather those who are likely to align with an ATOM1 constitution (which would emphasize the original cosmos hub vision of prioritizing security and hub minimalism).”

The general population still doesn’t understand crypto, and often won’t care enough to try to understand it.
What the general population DOES understand is that many of the institutions that dictate the policies and procedures of our society, are not to be trusted.
For example, in the United States, as of November 2023, it is estimated that only 15% of the American population approves of the job that congress is doing: https://news.gallup.com/poll/1600/congress-public.aspx

Roughly 2 in 3 Americans also don’t trust the mainstream media to cover the news accurately and fairly: https://news.gallup.com/poll/403166/americans-trust-media-remains-near-record-low.aspx

We often lose faith in government, media, etc. after we’ve been exposed to the fact that persons in these institutions are benefiting at our expense. In other words, misaligned incentives (something we are familiar with in the Cosmos ecosystem). These problems can often be traced back to the very nature of our money. It is debt based, and the monetary policy is controlled by a few powerful individuals behind closed doors. More of this money can be issued at a moment’s notice, and it can be used to harm society while benefitting only those closest to the money printer.

So why haven’t more people turned to crypto? After all, this is supposed to be the system that promotes transparency capable of shattering corruption.

This issue was opened to start the discussion about how to attract the right people into our community, those who are aligned and want to participate as equals.

I’ll open this discussion with three different topics that hopefully we can expand on in the coming weeks/months. I Believe dissecting these topics could help bring in aligned individuals who are currently both inside and outside of crypto. But I am more so thinking about those that are still outside of crypto and mostly see the space as one big circus.

1. Current cryptocurrency ecosystems don’t highlight the problems in society that have led to such distrust in today’s institutions.

Sure, we see twitter pages of protocols using the catch phrases of “finance for all” or “permissionless” from time to time. But they don’t go much further than that.
IMO, there are many valuable ecosystem participants who are missed, when protocols are only speaking to crypto-natives in their messaging. Protocols are announcing that they’ve reduced their block times by a full second, or that they have surpassed N number of transactions, or the infamous “announcement of the upcoming announcement”.

To be blunt, nobody really gives a shit. Especially those outside of crypto.

In marketing, the idea of “latent needs” is prevalent. This is the idea that users/consumers have problems that they don’t realize they have. It is up to a business/organization to shine light on these problems, so that the user/consumer understands how using a product or service benefits them. This is what we should be focusing on to onboard those who are still on the outside of crypto, looking in.

In crypto today, when someone says that a protocol doesn’t have good “marketing”, what they mean is that they aren’t paying influencers to shill them, and they aren’t dishing out money to centralized exchanges to get listed.

There appears to be a big opportunity for a protocol to completely revamp the “marketing” approach. Instead of having a social media presence that only talks about its big new partnership with an obscure crypto company that no one’s ever heard of, why not put out content that appeals to a bigger audience?

Producing simple 2-3 minute videos on Twitter covering or explaining the issues being created by the existing systems, with no mention of cryptocurrencies, would make for more shareable content. These could be done in the style of the “NowThis” group or “Afterskool” like so (I am not advocating for either of them politically. I am just referring to their delivery styles):
https://youtube.com/watch?v=3gkjWxCl6zE

This format could be used to cover things like:
How Ukrainian officials were spending 10s of millions of dollars on luxury Swiss real estate during a time the US was sending them $billions to fight a war (and the pentagon not knowing where the weapons they were sending them were ending up).

These types of clips could be attached to a thread explaining how the system we are attempting to build with ATOM1 aims to make these types of corrupt activities much more difficult.

With the stats in distrust aforementioned, we should be focused on making the ATOM1 Hub a landing spot for those who are distrustful of the status quo.

The media produced doesn’t need to be purposefully bombastic, but rather, explained clearly and concisely. Something that would be easy to send to your parents, if you were trying to get them to understand a situation.

Jae Kwon is one of the few crypto founders that is willing to talk on these sensitive subjects. We hear people call him a “conspiracy theorist” and the like. But the truth is, the majority of citizens now understand that conspiracy theories, often have at least some elements of truth. Most crypto projects seem to be bending over backward to be politically correct or virtue signal to stay in the good graces of institutions like Blackrock and the WEF, in hopes they can secure some partnerships and funding.

While there needs to be a healthy balance between being pragmatic and critical, it seems as if much of the industry has strayed too far from the original ethos of the crypto movement. We should use Jae’s track record of being willing to question things, as a badge to wear proudly, and not something we have to apologize for.

This strategy casts a wider net over the disaffected population, and we can bring them closer to a constitutional hub at a steady pace.

Of course, we need to not always approach topics from an American-centric perspective. I am just doing so because I myself am an American. This would ideally be an effort led by an international team.

If success is found in this method, we could always add additional avenues of reach. Such as, how Zerohedge has recently added debates to their arsenal.

The ATOM1 Hub should be a cultural hub as much as it is a crypto hub. It should aim to push societal issues forward, and allow people to organically find crypto as a potential solution to these problems.

2. There is no meaningful commerce in current crypto ecosystems.

Guys…. Look around you! People are buying and selling items on blockchains like crazy! Well, mostly just NFTS and crypto domains. But still, it’s happening. This initiative to fork the cosmos hub is certainly a political fork. Perhaps this hub could benefit from its own “political economy”.

I believe the logical next step is some kind of commerce consumer chain. I am talking about commerce of physical goods. This could start very small, as a micro-economy, but could have the potential to grow into much more.

Of course, selling things this way isn’t very convenient for merchants. Businesses need to be able to sell their products in their local currency, so that they can pay the bills necessary to grow and sustain the operation. But if we have a Hub that has distinguished itself as something of a political/social movement, built on the foundations of prioritizing security, as in, security of an economy we are aiming to build, then that may hold some weight with aligned merchants.

For instance, I am currently in the process of setting up a farm (a real one with animals and stuff. not the crypto yield-farming stuff lol). While I know I won’t be able to sell everything I produce for crypto tokens, I would be thrilled to be able to contribute to an economy that stands on principles that I personally align with. Allocating certain items I produce as blockchain-exclusive products could serve as something unique.

Just to be clear, I’m not taking about reinventing Ross Ulbricht’s Silk Road for illegal drug commerce. I’m talking about legal consumable products. The type people order from Amazon and such.

This may sounds small and insignificant. But I think it makes an impact for two reasons:

First,
think about the nature of interactions between all of us crypto natives. It’s on Twitter, Telegram, etc. and we’re communicating behind cartoon avatars with silly user names via text. There’s certainly a feeling of disconnect there. I believe buying a few products from your crypto pals could reinforce the moral, which is certainly needed as we’re here to build + participate in an economy capable of challenging the existing dishonest economies. This is quite the task.

And who knows, in a few years, we could find ourselves doing 25% or more of our shopping on an ATOM1 consumer chain.

I would encourage you guys to check out @the_vanman_company on Instagram. They have some unique messaging, and have built up a social media following that is very fine tuned to their ethos of “most things we consume are poison”. Their eggshell tooth powder is awesome for brushing your teeth with btw 😊
But they are a good example how topics 1 and 2 tie together.

Second,
Jae Kwon mentioned in suggesting to open this issue that we should consider how to get people into our community to participate as “equals”. This is certainly tricky in today’s crypto landscape because if you aren’t a technical person you can’t contribute to a network in an equal manner. I do think however, that if we open this commerce avenue, it engages the community in a whole new way. It would encourage them to participate and feel like part of the ecosystem. This could have a network effect that is not found in any other ecosystem.

The technicals of this endeavor could be a whole ‘nother topic. What tokens could be appropriately used as money? Could/should a privacy feature be added? How do we minimize the trust issue? How would disputes be settled between merchants and purchasers (would probably have to be based off of mandatory reviews)?

3. Scale voting power in favor of the delegators

At the end of the day, validators are infrastructure providers. They can certainly play politician and advocate for their yes’s and no’s on their props, but they have too much voting power in the current Dpos governance system imo. I don’t believe a voting machine voting for a delegator, should be weighted the same as that delegator actually voting. I propose that votes cast with non-voting delegator tokens, by validators, should be worth only 50-75 percent of an actual voting delegator.

I think this gives governance a better flavor. Everyone seems to have a bad taste in their mouth already with the current governance in the Cosmos. I believe this gets back into the idea of how to get people to participate as “Equals”.

I think we want to avoid people feeing like “their vote doesn’t count”. This is the feeling of our nation state systems in many regards. And this I believe, ties back into the stats of discontent and distrust mentioned earlier.

I could elaborate further on any of these 3 topics, but I believe this is enough to get the conversation started.

What are your thoughts and ideas on how to bring aligned people into the community to participate as equals?

About #23, initiating a weekly report summarizing recent changes could be beneficial. This report, ideally organized and interlinking various aspects, can assist in moderation efforts, particularly in avoiding duplicate issues. Additionally, it would be a great way to keep the community informed about current developments. This approach also encourages members to contribute in areas where they have expertise, addressing specific concerns more effectively.

We could use tools like ChatGPT to compile this list, but I think we'll still require human intervention to fine-tune the details.

ADOPT EVERYTHING WHICH WORKED WITH THE COSMOS HUB AND FIX EVERYTHING WHICH FAILED

Governance

The Cosmos hub validator set consists of 180 validators, but 60% of the voting power holds the top 20 validators

• Staking Limits: Set maximum limits on the amount of tokens that can be staked with a single validator or other mechanisms for better decentralation

• We believe in privacy, but for security, validators should disclose their identity so they can be held responsible from any malicious or bad acts

• Validators who wants to participate from the Cosmos hub set to validating Atom-one, the voting history (Cosmos hub-4) should be taken into account according to the principles of hub minimalism and the original Cosmos vision so that the main idea of ​​the Atom-one fork is not invalidated. Exclude the validators with yes votes at least for the Cosmos hub proposals

#69
Include CosmWasm in Rho Upgrade

#82
ATOM 2.0: A new vision for Cosmos Hub

#848
ATOM Halving: Set the max. Inflation Rate to 10%

• Exclude VaaS validators. VaaS stands for “Validator as a Service”, another term is white label solution. VaaS providers allow users to participate in the network without having to set up and maintain their own validator node. The owner address mnemonic (seed phrase) is used to activate a node, participate in governance, and manage the node. It is not uncommon for services in the VaaS industry to have access to this mnemonic. Some services may even refuse to provide this key to the customer upon request. This kind of validators private keys could be exposed/managed by the service providers and thereof are high risk and should not be included to Atom-One validator set

• Threshold for governance participation. There is evidences of manipulations on Yes votes at least with the proposals #82 (ATOM 2.0) and latest with the proposal #848 (ATOM Halving)

Case study of proposal #848 from Kintsugi Tech which shows that 160,379 dust or bots accounts voted for Yes
Link

• CEX and Institutional validators, Cosmos hub has proved that this kind of validators have had zero contributions and governance participation so they have other interests to validate and should not be included

• Validators should participate in governance and vote for every proposal. Non-participation should be slashed

• Do we need Abstain and Weighted vote choices? Validators should not be able game their voting choices because of the fear of undelegations and trying to avoid this with controversial proposals. Thereof would be better to have just Yes, No, NWV votes

• Should there be only one time option to change the vote from a. to b. with Yes and No votes in the voting period? NWV should always remain available for voting without restrictions incase anything malicious appears during the voting period which should get rejected

AIRDROP

• Snapshot from Cosmos hub-4 version from proposal #848 backwards (proposal end-time 11/25/2023 21:00 UTC) which initiated the Atom-One fork

• Exclude all the Yes voters at least for the following proposals which endanger the original Cosmos vision and hub minimalism

#69
Include CosmWasm in Rho Upgrade

#82
ATOM 2.0: A new vision for Cosmos Hub

#848
ATOM Halving: Set the max. Inflation Rate to 10%

• Whale and bottom (dust, bot accounts) cap

• Prevention of gaming the Airdrop from multiple accounts

• By the mintscan explorer

List of the top 1,000 accounts with the highest holdings of ATOM is between
19.98M-26K Atom

1,634,664 accounts majority holds
0.. to 26,000 Atom

1:1 distribution wouldn't be fair in nowadays anymore because the Cosmos early contributors holds significantly more Atom than the later comers because of the Atom higher price in fiat which prevented acquiring a larger amount of Atom financially. That doesn't mean that the later smaller holders wouldn't be one of the most enthusiastic cosmonauts and would be wrong that their skin in the game would continue to be low with Atom-One hub too like in the Cosmos hub. So I suggest for sub 5,000 Atom stakeholders some kind of multilpliers that the distribution would be more equal and decentralized right from the beginning. Multipliers could consist from e.g. Atom-One contributions, Cosmos hub-4 voting history, Cosmos loyalty; staking duration since Cosmos hub-4 launch etc.

Tokenomics

This needs the best expertise, and here too Atom tokenomics can be used as a measure of what succeeded and what failed. The future Atom-One native token should maintain and accumulate its value to prevent that the Cosmos hub Atom money like parties do not emerge, incentives holding and staking. Usecases/lower total supply/avoiding surplus .. but I'm not expert with these

Treasury/Communitypool

• No centralized ICF-like foundation. Community based rotated Oversight Committee to oversee that the transparency/accountability of spend and funding proposals is met 100% to the community and to prevent any conflict of interests and mis-use of funds

This may partially seem somewhat cold, but the so-called Atom money party will not care about the Atom-One hub, they are mainly interested in Airdrop and dumping it as a financial benefit. The second is malicious attempts at governance. We should stick to the main idea of ​​the Atom-One fork and only reward those who were serious with the original vision and hub minimalism on Cosmos hub who will surely be with same-minded cosmonauts even more serious with the Atom-One hub, instead of trying to please everyone. At the other hand there is also Yes delegator voters who didn't necessarily fully understand technically what they voted, but how these are seperated? If some of the Yes voters will be included I suggest vested Airdrop for them.

.. few

Let's have conversation on what kind of improvements could be implemented in the new governance system to better ensure that governance is not used for "griefing" and so that it represents the will of the common Atom One delegator and not that of validator politicians, Youtube personalities and Twitter influencers.

This is a great opportunity to discuss the flaws of Cosmos Hub governance and to think up some fixes, so I'm opening up this issue to highlight some governance topics that i've always thought could be improved on Cosmos Hub with the hopes to co-brainstorm or hear other ideas.

1. Don't let newly bought / transferred tokens vote - lock voting for each proposal to only the addresses staked at the beginning of that proposal

2. Restrict changing votes last minute - lock voting for proposal in the last day with the exception of NWV

3. Mandate atleast one public community hearing per new governance proposal that is professionally moderated (instead of scheduled 1:1 private meetings) so that discussions can be more open, transparent and recorded

4. Mandate atleast one week of discussion on a public forum before proposal goes on-chain to allow time for reiteration.

5. Figure out how to better use the Atom One delegator/voters to negotiate terms / reiterate on proposals without having it be shameful and defeating or a drawn-out process. Perhaps a new option to extend a proposal for a week?

6. Figure out how to minimize spam proposals, perhaps only counting a proposal as a proposal once the deposit has been met.

7. Push forward conversations on concepts and ideal scenarios for DAO / smart contract tooling to further standardize community pool-funded operations.

8. Enable people asking for community pool funding the ability to receive it but with proper transparency on how funds are being used and ideally the smart contract capabilities to prove/ensure that happens the way it was proposed.

9. Brainstorm alternative validator power structures - An idea would be to have validators forced to vote the same as the majority of their delegator's votes, so that each validator works as a representative of their delegators instead of just having the power of their delegations. Another alternative is this "hyperdelegation" concept from @clockworkgr and Decentralists #40

10. Brainstorm alternative voting limitations - should dust accounts even be allowed to vote? A minimum of 1-5 tokens per vote could fix voting optics created by bots.

11. Brainstorm quorum re-calibrations - what kind of proposals should require supermajority besides inflation parameter changes as stated in the current CONSTITUTION.MD draft? Should NWV + NO be weighed together against a Yes vote? Should Abstain votes count? Should we have Abstain votes at all?

We recently witnessed a contentious proposal, Atom #848, seeking to reduce the inflation rate from 14% to 10%. The prevailing sentiment in favor of this reduction is rooted in the belief that lower inflation is inherently advantageous. However, I find myself in disagreement for the following reasons:

Firstly, with the current inflation standing at 14%, staking offers rewards of approximately 20%. This significant disparity raises questions about the perceived benefits of reducing inflation, especially when staking already provides substantial returns.

Moreover, the assumption that lower inflation is unequivocally beneficial is challenged when considering an extreme hypothetical scenario. For instance, if inflation were reduced to a mere 1%, and staking rewards amounted to 2%, the calculus of participation changes. In such a scenario, the proposition becomes less enticing, as the marginal gain of 2% through staking is overshadowed by the potential "loss" of 1% in value annually. This analysis becomes even more pronounced when factoring in the inconvenience of staking, which involves locking one's coins for 21 days if a sale is desired.

To prevent this, We need an effective governance procedure in ATOMONE, and also need to help the community (token holders) understand the pros and cons of the ongoing proposal.

The purpose of this issue is to reference and update high-level DAGs that can serve as indexes for navigating topics, like Compendium (#42).

Moderator (@atomone-hub/mod) who have write permissions should keep the top-level DAGs updated according to the comments below. This allows anyone to suggest changes, ensuring that the DAGs are always up to date.

Eras / Milestones

timeline
    title AtomOne Hub Milestones
    Phase 1 - Pre-IBC   			: Define Constitution
                       			    			: Launch Governance-Only Chain
    Phase 2 - Post-IBC 			: $PHOTON with Auto-Staking
                                       			: Fix Validator Incentives
                                       			: Implement ICS1.5
                                       			: Prototypes with SubDAOs (including GNO)
    Phase 3 - ICS1.5 Scaling 	: Migrate $PHOTON to ICS
                                                 	: Promote Smart Contract Use Cases
                                                 	: Develop Scalable Validator Infrastructure
                                                 	: Develop Recovery Procedures
    Phase 4 - Maintenance   	: Create OnChain Education Curriculum
                                              	: Promote Good Forks and Projects
                                              	: Promote Other Common Goods
                                              	: Finalize the Software

AtomOne Phase 1 - Pre-IBC's Tasks (current focus)

Phase 1 High-Level Roadmap. Please include links to issues, preferably a single meta issue, whenever available.

graph LR
    A[Licensing & Legal] --> B[Define Constitution]
    C[Documentation & Resources] --> B
    D[Constitutional Development] --> B
    E[Feedback & Governance] --> B
    F[Technical & Security] --> B
    G[Recovery & Compliance] --> B
    H[Other Tasks] --> B

    I[Prepare Genesis] --> J[Launch Governance-Only Chain]
    K[Prepare Software] --> J
    L[Run Testnets] --> J
    M[Prepare Mainnet Launch] --> J

    B --> N[Phase 1]
    J --> N

• Define Constitution
  • Legal and Licensing
    • Choose License(s) for this repo (#49)
    • Branding & Legal
  • Constitutional Development
    • Complete the CONSTITUTION w/ all known functionality
    • Reconcile this README with CONSTITUTION
    • Incorporate the "Constitutional Majority" in the Constitution.
    • Constitution updates: $ATOM -> $ATOM1; Add $phATOM and $phATOM1; conversion
  • Governance and Community Engagement
    • Move Decentralists governance roadmap here.
    • At least one week for decentralists feedback on proposals that meet the spam threshold.
    • Proposals should be self contained no PDF necessary.
    • TM2 Consensus Court
    • Fork proves that slashing is real.
    • Increased Voting Period.
    • Globally decentralized validator set.
    • Use real human connections to defend against AI.
  • Technical Aspects and Innovation
    • Keplr & Ledger need competition.
    • Consider referencing https://twitter.com/jaekwon/status/1724641822398681547 with more insight.
    • Quantum resistance
    • What is a hub? Connected zones and shards should use it as such, not make more connections out.
    • Allow the staking distribution to hone its intelligence via slashing.
    • About diversity of implementation, and its limitations.
    • Add old PHOTON elements back in if relevant; not counting 2/3 ratio...
  • Documentation and Resources
    • Roadmap Timeline
    • Links to Additional Resources such as technical documentation, or community forums, for in-depth information.
    • Channels for reaching out to the core team or support, especially for technical support or collaboration inquiries.
    • Scan through twitter posts for more ideas.
    • Argument for why hub and spokes are needed (from atom one)
  • Recovery and Compliance
    • Recovery procedure by AtomOne in the case of IBC zone failure.
    • Recovery procedure by AtomOne in the case of ICS shard failure.
    • Require the ICF to buy back ATOMs and to allocate them for on-chain disbursement.
    • Indemnify all actors given no malice outside of the chain. Allow the chain to enforce penalties from outside the chain.
    • Specify that $ATOM1 held in pools and bonded for $phATOM1 do not count toward the bond ratio.
    • Add rules for what non-hubs and hubs (separate rules) must abide by. Not all hubs can connect due to this.
• Launch Governance-Only Chain
  • Prepare Genesis
    • Snapshot Cosmos-Hub4 (balances, votes) (#18)
    • Define Airdrop rules
    • Generate Genesis
  • Prepare Software
    • Choose Software Target (#17)
    • Fork & Cleanup
    • Develop/adapt modules
      • Governance improvements (#45)
      • XXX
    • Configure native tokens
  • Run Testnets
    • Coordinate validators
    • Run testnets
    • Organize testing sessions
  • Prepare Mainnet Launch
    • XXX

We should consider creating a repository similar to the community-driven "awesome-gno" on GitHub.

Could be:

• https://github.com/atomone-hub/community
• https://github.com/atomone-hub/awesome-atomeone
• https://github.com/atomone-hub/awesome-atone

We include a disclaimer stating that the content is community-generated/curated and unofficial. This repository would provide a space for community discussions, initiatives, recipes, and scripts. We can be less restrictive regarding AI limitations (#39) and use the Wiki feature instead of PRs for maintaining news and summaries. It would also make moderation more manageable by distributing the responsibility. Over time, it could reference new forks, important tweets, and more.

This would make the current repo stricter overall, while also allowing for more accessibility and other topics on the new one.

I believe that it's probably too early now and we should focus on pushing the limits of the current repo and wait for more foundations (especially the README), I believe this move will be important for scaling the initiative.