Community Pool Financial Model

[cryptulien]

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.

[cryptulien]

Additionally, we could develop an automatic model for allocating delegations from the Community Pool, inversely proportional to voting rights. Currently, the top 20 validators represent more than 50% of the voting rights on $ATOM.

This is decentralized, and therefore there's not much we can do about it, except to redelegate from a personal standpoint.

However, the chain should try to counteract this.

Thus, we could both reduce the one-shot release of tokens with each funding, and we could better distribute resources among validators.

[cryptulien]

I also wonder if creating private groups of addresses solicited to analyze the milestones of a funded project is relevant.

Imagine if the chain could randomly select 1000 addresses. Then, each address, anonymously, evaluates, with equal voting power, whether the funded project is being accomplished or not.

This would allow for not funding a priori but continuously, or stopping the funding, by conducting a vote based on a sample analysis of the progress.

[jaekwon]

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

this title doesn't seem to match the following section or i don't follow.

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.

some thoughts...

1. We should create a separate document about funding proposal templates and bylaws.
2. Funding asked should IMO be denominated primarily in $DOLLARs based on the required headcount and any % extra going to the companies that employ these people, or maybe a smaller amount going to oneself for individuals.
3. On top there can be a bonus that is denominated in $ATOM1, or something, but the idea is to have to components to this; the first being what is NEEDED, and what is NEEDED is defined by dollars and percentages; and then what is WANTED are the $ATOM1 and it makes sense to consider maybe an annual bonus, but something that can adjust over time.
4. It makes sense to create structure from the community pool whereby we ALLOCATE some $ATOM1s for the purpose of paying out within a BUDGET GROUP, where not all of the $ATOM1s are expected to be used, but is just in a pool meant to be replenished with ANNUAL/QUARTERLY governance proposals at the AtomOne or some subDAO level; based on the exchange rate and expected range until say next year or next quarter; and if a BUDGET GROUP runs out of $ATOM1 or money then it needs to ask some authority to replenish it or that's when we change the plan and create a new plan that is slimmer (or has more objectives if we are #winning); and if the BUDGET GROUP is not using funds it needs to send the tokens back to the community pool.
5. The $ATOM1 bonus can be large but unless we do good structuring it will all be taxed as income generally speaking, I don't know we should just be careful about tax considerations and make it easy to understand and reasonable. But can this be made more efficient with say, offering options instead?
6. Related to the question above, when companies are associated with individuals, these companies should maybe have the option of taking the equivalent amount of "salary" in for the company to redistribute however it wants, so that there isn't any unnecessary complexity from a parallel alternative payroll-like system.

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

I would re-phrase this as, implementing continuous flows into sub-DAOs or sub-pools, does that sound about right? If so I am in complete alignment. But also here we can make it configurable, with some pools we will want to denominate in dollars, or blends.

[cryptulien]

To conclude my reflections for tonight, I believe that all chains relying on ATOM1, beyond ICS, but including all pools, swaps, transactions using the developed technologies, can charge fees in ATOM1 that are directly reverted to the pool.

I feel that the security provided by the network should increasingly belong to the network itself.

Indeed, the proportion of the Community Pool in relation to the total amount of circulating tokens should grow over time.

In my opinion, the network should progressively self-secure from a token perspective.

[jaekwon]

Imagine if the chain could randomly select 1000 addresses. Then, each address, anonymously, evaluates, with equal voting power, whether the funded project is being accomplished or not.

We can't deviate from using stake for important decisions, without complicating the governance model, but some stake-based random selection might make sense, just like any draft or jury duty makes sense for a subset. But they also should be given responsibility to judge correctly, and they might in turn be punished if a greater set disagrees. And so we could make a natural geometric judicial circuit system just by what % of the total stake needs to participate.

[cryptulien]

Thank you @jaekwon, indeed what you're saying leads me to many thoughts, do you want to continue here or create an issue channel or a document to start reflecting on this?

[jaekwon]

Let's make modular documents where we know we need them, but not too many at a time. We can branch this off into independent issues and make this more of a general conversation. Either way! I like to accumulate a little bit and be a tiny bit lazy before refactors take place, whatever works.

[0xFDg]

Good things.

Problem number 2: $ATOM spent leaves the Community Pool

1. I agree with observation and I suggest to use % of rewards from LST from users (phATOM and phATOM1) to allocate to community STAKING POOL for pay Projects and Dev with reward.
2. I add also to use tokens which came from phATOM1 and phATOM ( ATOM1 and ATOM ) for rebalance the staking ratio through an algorithm
3. I suggest to additional % FEEs (in sense of commission protocol like a commission of a validator) at stakers who allocate token to validator with number of delegated token which overcame the threshold (delegation mean number - a feature to set ). Fees for pay devs.
4. Show the Validator in descending order of power for gentle push people to delegate to small validator

The $ATOM1 bonus can be large but unless we do good structuring it will all be taxed as income generally speaking, I don't know we should just be careful about tax considerations and make it easy to understand and reasonable. But can this be made more efficient with say, offering options instead?

what if instead of salaries we offer task rewards ? like for large trading firms, data is placed online, various datasciences create predictive models, and the best takes the loot.

Imagine if the chain could randomly select 1000 addresses. Then, each address, anonymously, evaluates, with equal voting power, whether the funded project is being accomplished or not.

I agree a lot with the @jaekwon suggestions about a responsibility to judge correctly, I propose again the public closed-box system, a reward for those who validate the code with a consensus model where multiple random teams have to judge and can take % on the loot but maybe must to bet a portion of their money to gain access to the system, they lose money if they lie or cheat.

[zdeadex]

Also adding algorithmic DCA to convert small proportion of the community pool based on few parameters to generate a fiat based pool would be a much needed thing to have a community pool not only based on his own success (and not get robbed in bear market for large amount of native tokens that never represent the real value of the asset).

For me the Community Pool should be seen as the bank, we a large diversification of assets, mostly in fiat $ but with also placement of assets (DeFi and more simple CeFi to generate revenue - T bill, RWA, Pools, Liquid Staking...).

There is no community pool that is currently used even at 1% of their capacity.

For that, we also need that in any case it use mechanism such as ICA to keep the power from the source chain, only taking two risk factor : bug on the contract, bug on the protocol (halt of the chain)

On the random factor judge, we do have some work made on game theorisation for making a decentralised oracle (which means voters are the oracle and judge of the result). The model is almost working perfectly but would need to start with incentivisation or centralisation at the beginning to educate and users/voters until we reach an enough large decentralisation to have it working in any cases. Can drop some paper done on that if that's something you would think interesting to read/work on.

[cryptulien]

@zdeadex I think you are addressing two different subjects :

The need to mitigate the financial risk of the underlying asset by its distribution into different tokens, including tokens indexed to fiat. Real problem, especially when we look at the last 24 months of the Atom community pool, and the token amounts...

The second problem raised is the oracle, which can address much more in a broader topic?