[in progress] Grants Policies - feedback requested

📌 Policies and Templates
, ,
1

Grant Policies

No Sale Policy

COLLAB received for Journeys around the Community Orientation should not be sold by the grant recipient. This “no sale” rule:

  • Includes the grant recipient, their affiliates and any other related persons. These persons cannot receive COLLAB for the purpose of selling (or if the grant recipient knows they intend to sell) the tokens.
  • Includes the direct exchange of COLLAB for crypto or fiat, whether done publicly or privately. Think selling COLLAB in exchange for fiat or crypto, regardless of whether done on a CEX, DEX, OTC desk, at your local park, or otherwise.
  • Does not include using COLLAB to incentivize usage. Providing COLLAB as liquidity mining incentives is not restricted by these parameters.
  • There is no expiration to this rule for Growth Experiments Grants

Lock-Up

COLLAB received through Journey Proposals should not be sold by the grant recipient for a period of one year. After a holding period of one year, Journey Proposal recipients have full discretion over how they utilize COLLAB, so long as it coincides with the objectives outlined in their proposal.

You can read more about the reasoning behind the token locks here.

No Self-Delegation of Grants

Token grants must not be self-delegated for use in governance. The primary purpose of these token grants is to incentivize sustainable usage and growth of the Collab.Land ecosystem. Accordingly, for partners interested in increasing their voting power, the preferred route is by encouraging users to delegate their rewards to your governance representatives.

Critical Milestones and Clawback

Critical milestones demonstrate good faith effort to accomplish the aims set forth in a proposal.

Critical milestones are meant to provide the Collab.Land community with satisfaction that the proposer has taken actions consistent with those outlined in an approved proposal.

Non-completion of critical milestones will be grounds for clawback of any remaining locked tokens, as outlined in the Collaboration Guide.

On-chain data or other publicly verifiable information is favored for the determination of critical milestones.

An example of a critical milestone is: “We will deploy X smart contract on Y date.”

Violation of these policies are violations of the Code of Conduct.

Attribution

Optimism Grant Policies

3

community feedback needed

sale rules:

y/n
if yes, how enforce?

lockup

y/n
if yes, how long?
if yes, how enforce? (tokenLock function?)

self-delegation

y/n
if yes, how enforce?

Clawback
how? – admin-revokeable locked tokens via Hedgey
y/n

5

Thanks @iSpeakNerd

The OP policies make sense since 50% of the seasonal funding is paid retroactively via https://pairwise.generalmagic.io/ The retro component does not have any restrictions and hence having restrictions on the proactive part makes sense.

In my experience with DAO governance, upfront allocation is not the best approach and I’d be in favor of retroactive allocations. That being said upfront payments are great to keep people motivated and give them assurance.

I’d suggest starting S1 with 50% proactive allocations and 50% retroactive allocations. From the upfront allocations, I’d suggest keeping 50% vested. All upfront allocations should be made with KPIs and Milestones in mind. Additionally I’d also recommend applicants to submit some Proof of Work along with their applications.

Over time we can increase the share of retroactive allocations since it’s easier to judge impact retroactively than proactively. Proactive allocations in any way either a delegated group making decisions or a prop.house style auction, have a very low conversion rate in terms of actual impact.

1 Like
6

Thanks for your input @jengajojo. We’ve actually been working with a project that would easily enable this kind of vested allocations.

To sum up for my own understanding, from the total you are suggesting:
25% vested upfront (sellable in 1 year?)
25% free token upfront
50% retro delivered on completion

I’d also recommend applicants to submit some Proof of Work along with their applications.

what does that mean to you? :point_up:

easier to judge impact retroactively than proactively.

I agree absolutely, have you seen any flexible frameworks for quantifying that impact?

7

That Pairwise app is super cool ux too, thanks for sharing that