Liquidity Council

Proposals
1

Introduction:

As it stands, most ARCH tokens are locked and inaccessible, making it difficult to get sufficient on-chain liquidity in DeFi protocols. On-chain liquidity enables on-chain transactions, which through Archway’s design, perpetuates the value-flow of the Archway fly-wheel.

This proposal seeks to set up a pool of liquid Community Pool funds, for the purpose of enabling liquidity for DeFi protocols. By doing so, this will unlock significant ARCH liquidity for the community, as well as provide value to ARCH and ARCH holders.

The funds requested in this proposal will remain the property of the Archway community and will be strictly utilized to provide initial liquidity to DeFi protocols. The funds will be controlled via multi-sig and dispersed as directed by the community of ARCH token holders.

Contributor(s) Background:

I, Eric Waisanen, am proposing this, but do not need to take part in oversight or multisigs that hold funds. Potential conflicts of interest for disclosure include spending the better part of the last 9 months as the Tokenomics Lead for Phi Labs, co-founding Astrovault, and advising/consulting for several protocols both on and off Archway. This is not meant to be a conventional ‘spend’ proposal, and if enacted properly, the only gain I’ll receive from it is the growth of the Archway Ecosystem, and the dapps on it.

Proposal Details:

A multisig is to be set up to manage community funds that are to be used in DeFi on-chain. This multisig should be a ⅗ signer, consisting of 2 Phi Labs employees, 1 Archway Foundation employee, and 2 community representatives; each selected by their represented groups. These positions will not be compensated through this proposal. Once the multisig is created and funded, the address will be made public here on the forum.

Spends from this wallet under 250,000 ARCH can be done transparently, and with notice, without additional signaling proposals. Spends from this wallet of over 250,000 ARCH would require a signaling proposal to pass through Archway governance. This enables dapps and protocols launching on Archway to bootstrap some liquidity quickly and without voter fatigue, but ensures community alignment for large deployments of funds such as bootstrapping liquidity with another Layer 1.

Budget Request:

To start, I propose 5 Million ARCH, 5% of the current Community Pool, and about a $520k value at current valuation, be deployed in this liquid Community Pool. As it gets deployed it can always get topped off, but additionally, if unused, spend proposals of any kind can request partial deployment of funds from this pool, based on Community needs.

Roadmap:

Within 1 week of passing the multisig, representatives will be set, the wallet funded, and the address recorded. Terms for seats should last 3 months to start, at which time there will be another vote. No set term limits apply at this time. At the end of this first term, it should be aimed to have a smart-contract wallet set up so that signer seats can be replaced without necessitating a migration of funds. Vectis has some interesting solutions in the pipeline that could help with this, but we’ll revisit this closer to the end of the term.

Projected Measurable KPIs:

There are no measurable KPIs as none of these funds are being spent, and no compensation being awarded. All funds held by this wallet are to be done transparently and with routine analysis/reporting. Funds are to be fully subject to the will of the Archway DAO.

Communication and Support:

Representatives from the Liquidity Council should regularly attend governance meetings and relay feedback. Additionally they should provide monthly updates on the forums.

Request for Comment:

If you think that numbers or structure of this should be amended, please comment and let’s discuss proper structuring. It’s the idea, rather than the proposed structure, that I believe most imperative. I’ve seen community comments for Sub-DAOs that could be safer or better structured than a multi-sig, and I’m all for something like that! Let’s spend this next week ironing this out, gauging sentiment, and discuss this on Wednesday’s governance call. At this time it is my intention to put this proposal on-chain in one week.

11 Likes
2

Hey, Eric :wave:

I just read through everything, and in conjunction with the aforesaid governance call from yesterday, I believe this is a prudent plan all around.

No specific amendments or suggestions, but I at least wanted to signal my support :handshake:

6 Likes
3

As this is the first iteration of the liquidity council, I believe it most prudent to significantly lower the % of the community pool that will be transferred to this wallet (this can later be increased). I also believe that any spend over 50K ARCH go through governance, as a community vote should be enacted for any large movement of liquidity into the ecosystem from the community pool. (These numbers can change over time, but I believe it most prudent to start smaller and work up from there after evaluating market effects, results, and impact). Finally, there should be some sort of parameters as to 1) which dapps can apply for this, 2) how many times they can receive a liquidity boost, 3) if they have to be new dapps to apply for this, and a few others.

Naturally, I am extremely keen on seeing the Archway ecosystem grow and flourish. However, considering the early stages of the protocol, I believe its best to approach all spends in a cautious manner.

Just as a side observation: It is important to note that while funds are not being spent directly, seeding liquidity does subject funds to impermanent loss and other risk factors. This should be considered a spend, not a permanently maintained injection of liquidity.

3 Likes
4

Thanks for the feedback!

Restricting spends to 50k ARCH is $5,200 worth at the current price as I’m writing this. If restrictions are set at a level so low then there’s no point in a liquidity council, as they couldn’t give any kind of meaningful liquidity. If you want to set a dollar-based cap on spends should dollar-based price increase, say a max of 250k ARCH or $50k, whichever is less, I’d be fine with that, and it’s also still a maximum, not minimum.

Great question about how to process applications. I think that the elected council should be the ones to dictate how they’d like to handle applications and use their discretion, which they should be elected to trustfully wield, and are obviously subjecting themselves to public scrutiny and feedback.

There are some circumstances when seeding liquidity that may lead to impermanent loss, though notably not all, and arguably not most. However there do need to be some kind of understandings in place, so that we’re not simply giving fake dapps $50k worth of ARCH to rug a fake token against. Again I look to the expertise and discernment of the elected council. It’s impossible to predict what all applications and use cases will seek help from the liquidity council, but I’m open to hearing more feedback on generalized framework for structuring things like this? However I certainly disagree that this should be considered a spend rather than a maintained injection of liquidity. Fundamentally, this allocation should actually increase in value by bootstrapping things like sARCH, or earning governance tokens from its positions, including many which don’t risk impermanent loss.

As for the overall amount I’m open to more feedback if 5% is considered high which I understand, though honestly getting a council together to go through all this extra work for something like $100k, with max asks of $5k would honestly be a waste of time in my opinion.

5 Likes
5

I tend to agree with Eric regarding a higher threshold for requiring a signaling proposal. In addition to the reason Eric mentioned regarding making a material impact, I think having a higher threshold will also help to avoid the administrative burden and voter fatigue that would come with having to put every CP spend over $5K through a signaling and voting period.

Happy to hear further community feedback but do think at current levels 50K ARCH is too small.

5 Likes
6

Great initial breakdown @Eric and based on the facts presented I’m here to signal my support to establish a liquidity council to utilize the Community Pool to improve the liquidity within the Archway ecosystem.

In my view, unlocking significant ARCH liquidity and utilizing it in this manner will improve the user experience and is an essential step towards promoting on-chain liquidity and fostering the growth of the Archway fly-wheel.

The transparent and responsible utilization of funds through a multisig controlled by core contributors in conjunction with community representatives helps to ensure community alignment and efficient decision-making. The proposed budget allocation of 5 Million ARCH or approx 5% of the current Community Pool, appears appropriate, but dispersal of funds should require careful planning and transparent roadmaps.

I commend the emphasis on routine analysis and reporting, enhancing accountability within the Archway DAO.

Overall, I’m happy with the current state of the proposal and again want to emphasize my support for the induction of a liquidity council.

5 Likes
7

Just wanted to check that this will be limited to DeFi protocols built on Archway?

Introduction section suggests “enabling liqudity for DeFi protocols”.

Proposal Details section elaborates “enables dapps and protocols launching on Archway to bootstrap some liquidity quickly”.

4 Likes
8

Excellent point when it comes to enabling liquidity availability. Perhaps the use of these liquid tokens must be agreed to with a cap per DeFi project.

One of the core things that I see as a problem for new users is getting the ARCH. Perhaps using liquidity council, we could craft out by providing the first transaction’s gas fee as a “loan”? And then it can be repaid. Or in some other form that is technically viable and user-friendly.
Also, the spending proposals perhaps could be even increased over time?

4 Likes
9

This is a fair point. I’d be in favor of supporting any application, not limited to just DeFi. With that said, @Eric, I think it may be worth rewording to avoid the specific use of the word DeFi so this can apply to all applications that may be able to utilize community funds to improve liquidity depth or UX.

4 Likes
10

Agree with this Chem, but additionally I think @Dodow’s question was more about for DeFi protocols NOT built on Archway.

I think we should reword it to just be to support applications built on Archway. Doesn’t have to be DeFi, probably should be just on-chain as that is what sells Archway blockspace, but I always would prefer to use broader language as we don’t know what all edge-cases may arise, and want to give as much freedom as possible for good intent within the council.

3 Likes
11

Hi @Eric & @CryptoChem0000, yes I meant type of protocol as well as liquidity NOT just limited to being on Archway. I often hear the mumurs of the disatisfied crowd asking about liquidity, often refering to CEX or even non native DEX.

Perhaps, there could be some wording to make it clear that the focus is to help bootstrap the applications on Archway. Given, this is the value capture chain, then the objective is to deliver value to token holders by supporting native applications, which drives demand and eventually those awesome tokenomic mechanics as laid out in the economic paper.

3 Likes
12

Setting them up specifically to better sell block space. Using any liquidity bootstrap to keep it in-house. Love it, and will adjust the wording accordingly in a final version!

3 Likes
13

Thanks for putting this proposal together @Eric - I’m here to signal my support of establishing the Liquidity Council to help bootstrap the Archway application layer.

A couple quick comments of mine:

I would be strongly against utilizing a subDAO instead of a multisig for the Liquidity Council. I think a subDAO would likely complicate a lot of the operational tasks of the council, introduce unnecessary bureaucracy and creates a ‘diffusion of responsibility’ where it is unclear who is responsible for doing due diligence on protocols, monitoring dApps, initiating spends, etc

Other problems this could present is the inability to act swiftly in an emergency situation. subDAO governance votes would (likely) take days to reach minimum quorum to enact a spend or move funds, which could be a problem if for example there is a known vulnerability in one of the protocols that the Liquidity Council had deployed capital to. Alternatively, the proposed multisig is much better prepared to handle these types of situations

I do think this is an interesting thought. Utilizing a spend to seed ‘fee grant’ modules for core dApps on Archway would take the subsidization burden off protocols and make onboarding easier for Archway dApps as well as make the efforts of the Marketing + Growth DAO stickier

4 Likes
14

Excellent comments! Noted on the Multisig, strong arguments for!

Also love the thoughts on fee grant seeding, I think that should be included for range of the liquidity council as well. Fee grants are still quite difficult to use properly, but Phi Labs and the foundation have done an excellent job in making them accessible for core IBC relayers, and I think it would make sense for initial onboarding for Dapps as well. Astrovault has one working currently but doesn’t get full remuneration of it, and it’ll be more difficult for dapps with less inherent liquidity to pull off.

Unless we hear more solid feedback suggesting an alternative, I agree that a multisig is the safest and most efficient way forward. It can always be changed/amended in the future.

2 Likes
15

Hey everyone,
Dropping by to signal support for the prop. I agree with the statements and concerns put forth regarding subDAOs and would much prefer to see a multisig approach. I think this is a great step towards supporting liquidity on Archway.

2 Likes
17

Hey guys, I would like to suggest deploying a subDAO with Chelo. This way, the main DAO maintains control over everything that the subDAO is doing and can revoke calls if needed. We’ve built a bloc - a subDAO within your current DAO. Currently, it’s on EVM, but we are in the process of transitioning things to Rust, which makes it more readable (Decentralized Autonomous Organizations Made Easy with Mini DAO v2 | by G. Lemus | Chelo Finance | Medium).

By the way, we’ve changed the name from mini DAO. Let me know what you think.

Ohad Bachner

4 Likes
18

Let’s make sure we do a temperature check with the updated version of the proposal! We should add this into our standard practice

2 Likes
19

Agreed. I’d propose a certain amount of engagement to allow this to be pushed to voting. I’d say around 15-20 likes would be a good measure here

2 Likes
20

Thanks guys, this is great to get the initial plans together for Liquidity Council. It’s crucial that users are able to access dApps and have the ability to gain access to the key assets within the Archway ecosystem.

I also agree there is value in completing a “temperature check” process before any signaling ideas/proposals are pushed to the chain. This way we can try and gain some initial understanding of community perspective and a minimum cohort size of the community before things populate as on-chain proposals.

2 Likes
21

BTW I am supporting the proposal

3 Likes