[PASSED] Development Approval Request for the ATOM Alignment Treasury

[Noam]

@Tricky

Would you say this is a replacement/competition for Timewave, or supplemental to it?

Absolutely supplemental. The AAT can handle very simple mechanisms like IBC transfers and bonding, but we can’t build out the logic on the Hub for swapping, or interacting with the plethora of DeFi protocols out there. All of that, and probably much more is in scope for Timewave. The AAT can be seen as a mechanism for the Hub to express itself, Timewave can be seen as the executing party.

@Tricky

Do you have any estimations of cost if this did end up as a community pool ask?

Tagging @tanned as they asked the same question. We would start development in Q1. The work shouldn’t take long, but it depends on resource availability when we’ll be done. Ideally we’d complete work between 3-6 months time part-time. Full time this would take ~2 months. We haven’t fully mapped out the costs at this stage and were planning to do so at the end of the year. This isn’t a funding request, but a sentiment check on the AAT itself, which is why we don’t have these numbers yet.

Besides this we’re also committed to developing the DRIP and another module in 2024. Each of these would be separate requests for funding and would total under a million USD I reckon (napkin math).

Now, on the more interesting design questions:

@Tricky

What about tokens that aren’t deployed as POL and sit in the community pool?

These tokens should sit in the AAT imo, not the community pool’s spending account. In my mind, because ATOM holders have the same control over the AAT as they do over the CP, the AAT is essentially an extension of the CP, with a more specific scope. This is not to say all assets in the AAT need to be deployed though! It’s just that we shouldn’t want to keep CC tokens in the Community Pool, as its scope is one-time grant deployments (more or less), and we likely don’t want to pay these in CC tokens because it reduces our alignment.

So, if there are bunch of Consumer Chain tokens there we don’t want to deploy, we can just stake them from the AAT if needed for using governance.

@Tricky

Could the AAT track the number of said token it owns at any given point whether LP’s or not and enforce that voting weight to consumer chains? This needs to be standard for every consumer chain relationship.

It’s hard to standardize this across Consumer Chains because voting systems differ (Stride uses Cosmos SDK’s x/gov while Neutron uses CosmWasm). This gets worse with increasing tech plurality. We haven’t fully mapped out yet whether if, and how, to calculate the voting weight. Neutron team has signalled they are willing to do some work on their end to accommodate. If anything, new agreements with Consumer Chains needs to include requirements to enable the Hub’s vote to be successfully cast on the CC.

This is one of those cases where we’re really going to need to see how this plays out practically. At a very minimum we want to make sure we can solve for our current issue (NTRN voting power), and iterate as use cases become apparent.

@Tricky

This will get tricky on when to include proposals and when not to.

I’m personally quite convinced that having every prop auto-copied to the Hub is a terrible idea as it will overwhelm governance and drown out actually important props. We should see how things play out imo. I have a feeling non-relevant props that are copied to the Hub will get no-with-vetoed. If not, we can explore other options.

@Tricky

Considering the timing of making sure the prop is finished before the end of the vote and so many other parameters that could go wrong, its probably best to automate as much as possible to limit any mistakes.

Yes, this will all be automated as much as possible. Essentially the “clone prop” transaction would require no input from the user if possible. However, this will depend on the IBC query implementation we choose due to potential metadata decoding issues.