Collective Grant Policies
These grant policies apply to all Governance Fund grants and all OP Chain grant programs stemming from Governance Fund grants. Failure to abide with the below policies may result in the refusal to deliver subsequent milestone based deliveries of a grant and/or the clawback of a locked grant.
In the event that an applicant misuses their grant in a way that does not constitute a violation of these policies, a report should be filed via the Grant Misuse Reports category and their grant will be uploaded to a public database.
Note that these grant policies do not apply to Retroactive Public Goods Funding (Retro Funding) grants.
These policies will not cover all possible scenarios and edge cases. We ask that Optimists please act in accordance with the spirit of the Grant Policies and refrain from exploiting loopholes that may exist.
Disclosures
(Violation 1a)
Grants-as-a-service arrangements, while not prohibited, must be disclosed prominently in any proposals utilizing such services. These services include arrangements to help teams write, review, or otherwise submit proposals in exchange for a portion of any grant received.
No Sale Policy for OP User Incentives
(Violation 1b)
OP received through OP User Incentives Grants, or any grants made to deliver OP directly on to end users, 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 OP for the purpose of selling (or if the grant recipient knows they intend to sell) the tokens.
- Includes the direct exchange of OP for crypto or fiat, whether done publicly or privately. Think selling OP in exchange for fiat or crypto, regardless of whether done on a CEX, DEX, OTC desk, at your local park, or otherwise.
- Includes any other transaction that is an “effective sale,” as defined below.
- Does not include using OP to incentivize usage. Providing OP as liquidity mining incentives is not restricted by these parameters.
- There is no expiration to this rule for OP User Incentive Grants.
- Grant recipients must be able to accept OP and/or use OP to execute their proposal.
Lock-Up
(Violation 1c)
OP received through all other grants, including Missions that do not pass OP directly on to end users, should not be sold by the grant recipient for a period of one year. The prohibition against selling includes any transaction that is an “effective sale,” as defined below. After a holding period of one year, Locked Grant recipients have full discretion over how they utilize OP, so long as it coincides with the objectives outlined in their proposal.
Effective Sale
(Violation 1d)
An effective sale includes selling, offering to sell, contracting or agreeing to sell, hypothecate, pledge, use as collateral, or creating derivatives of the OP tokens. It also includes entering into any arrangement that transfers to another person or entity, in whole or in part, any of the economic consequences of owning the OP tokens.
You can read more about the reasoning behind the token locks here .
Self-Delegation of Grants
(Violation 1e)
Grant recipients must not self-delegate user incentive grants for use in governance. Locked grants may be self-delegated during and/or after the one-year lock-up period. Delegations may be made or changed at the time a grant is received or at the start of a Season.
Changes to Proposals
(Violation 1f)
Grant recipients must execute the grant in accordance with what is outlined in the approved grant proposal. Grant recipients that wish to change the use of the grant from what is outlined in the proposal must submit a new proposal requesting approval for the change. To do so, they must follow the grants process in place at the time. If the change is not approved, the recipient must execute the grant as outlined in the original proposal or return the portion of grant affected by the unapproved change.
Grant recipients must give out user incentive grants within six months of the grant being made unless they give public notice to the community explaining any delay or request an extension approved by the Grants Council.
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 Optimism 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.
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.”
Grants to Other OP Chains
The Collective Grant Policies apply to all OP Chain grants programs. OP Chains who receive grants must: (1) abide by these Collective Grant Policies in their grant program (i.e., make grants that follow the requirements set forth in these policies); and (2) not use their grant to run programs that directly target users from any other OP Chain (e.g. making grants to migrate protocols from OP Mainnet to another OP Chain). OP Chains will be expected to provide a list of grants made, as specified by the Foundation, to the Grants Council upon completion of their grant. OP Chains that do not do so, will not be eligble for future Governance Fund grants.
Enforcement
Violation of these policies can result in grant clawback or refusal to deliver a milestone based portion of the grant. To report a violation of the grant policies, use this reporting form. Violations will be processed by the Grants Council, subject to optimistic approval by the Token House. Given the importance of these policies, the Optimism Foundation can also enforce them and claw back any grants found to be in violation.
For misuse that does not constitute a violation of these policies, please follow the Grant Misuse Reporting Process.
Change Process
The Grant Policies must only be updated during Reflection Periods or following extraordinary circumstances that require immediate updates. In all cases, a change log will be published for delegates.
