Public Reporting Requirements for Grantees

[lavande]

One of the main focuses of governance is creating more accountability for grant recipients and transparency into how grants are actually being deployed. Delegates have begun taking steps towards providing this oversight in the #gov-monitoring channel and on the Forum. The Foundation would like to support these efforts by suggesting standardized reporting requirements for grant recipients.

Those submitting proposals are responsible for providing the below data in an easy to input format. This data should be publicly accessible and usable by the community. This process is easily adaptable, so it can be managed by the Grants Council, or any alternative structure that prevails.

Grant recipients agree to these reporting requirements in the grant application template. There are two obvious opportunities to collect this data from grant recipients: when the Foundation collects KYC info at time of grant approval and when milestone-based grant distributions are evaluated. On an ongoing basis, proposers are incentivized to provide updates as delegates may actively monitor this data, which will be accessible via a public dashboard.

The goal is to create a set of reporting requirements that results in consistently structured and easy to ingest disclosures without creating a level of friction that deters projects from building on Optimism.

Proposed Reporting Fields

Our goal is to collect all information in a way that:

• Any delegate/analyst can accurately track grant distributions
• Governance can effectively evaluate growth experiments and continue to iterate
• Requirements are thorough but lightweight enough to avoid overburdening proposers

*The following information may be entered by proposers in a Google Form. Additionally, completed milestones should be reported via the Grants Council Milestone Hub and on the Forum under “Grants Updates” tab.*All entries will be publicly viewable by anyone (and updatable by the Foundation or Grants Council, as applicable)

For Growth Experiment Grants

OP Incentive Distribution Schedule: Up-to-date schedule of OP planned, in-flight, and completed OP incentives. There should be one entry for each distinct distribution strategy (i.e. Row 1: retroactive airdrop, Row 2: liquidity mining on Pool A, Row 3: liquidity mining on Pool B).

1. Project Name: Name of project giving out OP
2. Affiliated Project (if applicable): Top-Level project that received OP (i.e. Thales <> Overtime, Gamma/Arrakis/xToken <> Uniswap)
3. Distributor contract address: What address(es) are tokens distributed from?
4. Announcement Date: Date a program was announced
5. Announcement Link: Link to program announcement and details
6. Start Date: Date a program started
7. End Date: Date a program ended
8. Distribution Type: i.e. Liquidity mining, Trading mining, Competition, Retroactive airdrop, Other (explain)
9. OP per Epoch: If a scheduled program, how much OP goes out per epoch (i.e. 500 OP)
10. Epoch Length: If a scheduled program, how long is the epoch (i.e. 1 week = 500 per week)
11. App Incentivized: Is usage incentivized on the native app, an external liquidity pool (i.e. DEX pool), something else?
12. Contract(s) Incentivized: What address(es) are incentivized (i.e. DEX Router, LP Pool)
13. Action(s), Pool(s), etc. Incentivized: What type of action is incentivized (i.e. NFT Purchases, stETH/ETH pool liquidity)
14. Eligible Addresses: Is this limited to a specific address list? If so, how many (i.e. retro airdrop) and/or what is the eligibility requirement (i.e. holders of a specific NFT)?
15. Extra Notes: Any other information that helps us accurately understand token distribution - Or an explanation if the program’s structure does not fit this structure

OP Internal Transfer Record: List of internal transfers of a project’s OP token grant (i.e. transferring tokens between wallets). This will provide visibility into which tokens have left the project’s provided L2 address, but are not yet distributed.

1. Project Name: Name of project giving out OP
2. Affiliated Project (if applicable): Top-Level project that received OP (i.e. Thales for Overtime)
3. Transaction Hash: Transaction hash of the transfer
4. Sender Address: Address sending the OP (i.e. the project’s wallet)
5. Recipient Address: Address receiving the OP (i.e. the project’s wallet)
6. Recipient Address Name: What is the recipient address’ purpose (i.e. entity name, address label)

For Builders Grants

Grant Program Distributions: List of grant payouts for projects who used their OP governance grant to run their own grants program. This helps us understand the impact of governance distributions to project grants programs (i.e. what super cool things came out of the grants programs?)

1. Project and Grant Name: Name of grant and project transferring OP
2. Affiliated Project (if applicable): Top-Level project that received OP (i.e. Thales for Overtime)
3. Transaction Hash: Transaction hash of the transfer
4. Sender Address: Address sending the OP (i.e. the project’s wallet)
5. Recipient Address: Address receiving the OP (i.e. the project’s wallet)
6. OP Transferred: Amount of OP Tokens Transferred
7. Recipient Address Name: What is the recipient address’ purpose (i.e. entity name, address label)
8. Grantee Name: Name of the entity receiving the grant (could be generic, i.e. bug bounty, if relevant)
9. Grantee Website/Github/Twitter: Where can we keep up with the grantee’s progress?
10. Grant Description: Information about the grant (i.e. purpose, milestones, grant program information)

[HCNAT0_NEU_Blockhain]

I very much agree and support the Public Reporting Requirement for Grantees, I think we just have to make sure to enforce these updates and make sure we have everything (being finalization and confirmation) that we would like so that we don’t have to consistently go back and forth with proposers on adding more information.

I think this is a great start, I think before enacting and enforcing it, we should call and discuss if there are any discrepancies or adjustments we’d like to make before it goes to a vote, not after and we’re having proposers scramble to find requested information.

[Axel_T]

Following on from @HCNAT0_NEU_Blockhain and sorry in advance if I haven’t kept up to speed…

Are these reports made publicly available? And what has the response from grantees been like, in 2023?

Or, on the other hand, has this reporting and accountability now been shifted to the Milestones Council? I.e. Is this similar to the type of work they were always going to complete?

Cheers.

[lavande]

Tagging in @MSilb7 to help answer questions on response rate and public availability

The idea was that this reporting information would be publicly available, so the Milestones Council could use this information to complete their responsibilities (but distribution of the form and compliance with the form is the not something the Milestone Council is expected to monitor)

[MSilb7]

Hi, responses to this form were used to generate addresses lists to appropriately tag token transfers as “internal transfers” vs “distributions.”

This populates data on a token distributions dashboard & rewards tracking github repo. This outputs of these (along with onchain usage metrics) were applied in this incentive tracker dashboard and presented in monthly grant performance reporting (since deprioritized).

[Axel_T]

Thank you very much for the full explanation. Much appreciated, especially for the linked resources. Cheers!