Standard Guidelines to judge Liquidity Treasury Proposals on the governance side - Kusama and Polkadot

Based on the income to the treasuries, the amounts getting burned and the amounts going to proposals, the treasury can be utilized more: this includes spending more funds, extending the categories of proposals, experimenting more and encouraging more participation. We are at a point where we should think about ways to scale this and incorporate additional means of supporting nascent parts of the ecosystem.

Many other ecosystems have started funds to deploy to their ecosystems: both for the purpose of funding new teams but also to deploy to initiatives like liquidity programmes that try and encourage adoption. The end goal is to encourage value accrual: either for the treasury itself, the projects building in the ecosystem or the communities and end users participating in the Kusama and Polkadot ecosystems.

The Treasuries As Liquidity Providers

One thing that other ecosystems have started are initiatives around liquidity incentives to kickstart projects. What this might look like is approving allocations towards DeFi protocols (or parachains, in Polkadot's case) to encourage an increase in user metrics. Considering a lot of the use cases and features that cross-chain interoperability brings to Polkadot, it would be extremely useful to kickstart projects with liquidity for borrowing / lending, money markets, derivatives/options, synthetics, DEX / AMM pools, protocol owned liquidity and other primitives that allow for applications to attract end users. These sorts of programmes have worked extremely well for other ecosystems and Polkadot / Kusama is missing out on a lot of opportunities in their absence.

However, this won’t come without some paired risks: therefore some considerations in place for any sorts of proposals related to liquidity provisioning is needed: mainly for the purpose of mitigating potential downsides. This document aims to provide specific guidelines for governance participants to review and vote on liquidity proposals, as well as proposers to draft their submissions.

Considerations for Proposals

A key expected outcome of launching such programs will be to substantially increase on-chain activity in the form of increasing active users, transaction volume and TVL in the long-term. These proposals should have the goal to primarily achieve increasing levels of TVL resulting as well in increasing active users, transaction volume but also specifically attracting more builders to Polkadot and Kusama ecosystems. While liquidity subsidies proposals have been dominant among parachain teams' proposals (direct participation in a protocol to increase market depth and lower transaction costs by reducing slippage), proposals might also focus on:

1. Reward Subsidies (direct rewards used to incentivize users to add liquidity to protocols)
2. Bridge subsidies (rewards paid to incentivize users who hold tokens on other base-layer ecosystems to bridge them over to the target ecosystem).

These guidelines are intended to target parachains proposals that seek liquidity subsidies as well as protocols building on top of them. Liquidity proposals should ideally incorporate the following elements:

• How large is the requested rewards subsidy? Are there any matching conditions from the protocol? This ensures commitment and is an objective and quantifiable metric to determine reward subsidy amounts.
• Audit report and proving working record of the protocol.
• Time horizons: with regards to when the ecosystem can see the first results on the proposal and when the allocation or its accrued value will be returned (if any);
• Projected yield: ideally a specific definition to take as success metric is needed for the community to judge the final result of the proposal. Make sure to include what is the current traction of the protocol (MAU, TVL, trading volume, fees). This will allow the community to assess future metrics. Ideally, the project can also provide data source for auditable tracking the usage and success of reward subsidies.
• On-chain instruments in which the funds will be used, along with a description and the way these will be deployed: what are the planned use cases for the subsidies?
• Any potential risks resulting in the loss of funds;
• Projected incentives to the wider ecosystem and how the allocation will help increase adoption: what is the mechanism and timeline for distributing rewards to users?
• Other success metrics.

When drafting a proposal and when reviewing it, participants should judge the proposals based on these specific requirements:

• When thinking about liquidity proposals we should ask ourselves: "is this proposal aiming to increase DOT velocity and utility? And is this compatible with the treasury requesting some sort of accrued value over time from this proposal?".
• These proposals should be designed with the partial goal of accruing qualitative value to the treasury and thinking of this instrument as a sort of loan that will be returned to the community via network effects: showing that these funds result in profit for the overall network. This might not be a requirement for all use-cases but it can be included and requested as one by the community.
• Funds given for liquidity provisioning should be done in a completely trust minimized or trustless way: ideally where the treasury itself can directly put and withdraw liquidity into these opportunities (What this might look like practically is in the form of XCM related transactions). Alternatively, and if limited by the current tech stack, the team requesting the funds can open the management of these funds to their community in a transparent way.
• A specification on how the beneficiary address is set up, who controls it and how will be the management work for the address is to be described in the proposal.
• Has there been any on-chain events which stop the parachain from progressing for at least 1 week in the last 3 months? Stability is important in the ecosystem, and we need to make sure parachain teams are prepared to deal with stalling issues.

All of this should happen in a trust-minimized environment, if possible. Once granted, subsidies will be deployed from the Treasury to the grantee’s protocol. The logic will hold the tokens and distribute them to users according to the parameters of the contract.

This proposal template has been designed to help teams provide all information to the community: a copy of the template can be made to complete with all requirements above.