DAOIP-5: Grants Management #51
Replies: 7 comments 2 replies
-
|
Hey all! Posting a couple of questions from my initial reading of the standard:
Also tagging @thelastjosh to keep track. |
Beta Was this translation helpful? Give feedback.
-
This standard doesn't actually assume that grant pools are DAO governed. We do expect any grants system administrator to report daoURI, which typically requires that they maintain control over some contract address that is registered with daoURI. Note that a foundation can have a DAO without being governed by that DAO. In this case, the DAO is just a smart contract that the foundation controls that it uses to interface with on-chain tooling such as a grants protocol. Part of the idea here is to force big foundations (and other entities) to have an on-chain entity, i.e. a DAO, to interact with this tooling. It does not change the centralization or governance of the foundation or grant program.
You're right that it may make tracking payouts harder. The reason we want We might end up removing
|
Beta Was this translation helpful? Give feedback.
-
|
good |
Beta Was this translation helpful? Give feedback.
-
|
good to be here ... further information required for adjustability |
Beta Was this translation helpful? Give feedback.
-
|
The new grants standard is (finally) up and officially published! 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
In conversation with Mahesh: it would be nice to have social links (Twitter, GitHub, etc.) as part of the project profile. Also, it might be nice to have "team members" attached to a project (or to a project), who can share reputation in some way. |
Beta Was this translation helpful? Give feedback.
-
|
The schemas actually align quite well to what we use at the Stellar Community Fund (just different naming), I think for the Cartographer Syndicate registry we may need to add "Funding Organization(s)" and "Ecosystem(s)" either per grant system or grant pool (grant pool may be more inclusive). Other things on projects that would be good to have added is their website and github. The payout schema is currently optional but that's the most important thing imo, the payment itself with a status indicator that it's paid or approved. In addition to what's currently listed in the payout schema, I'd also add a currency denominator in the payout schema (for instance, awards may be denominated in USD but paid out in crypto) and it also should have date field so it's possible to calculate roughly the USD value of the payment. |
Beta Was this translation helpful? Give feedback.
-
|
@thelastjosh hey i was also a contributor from daolens team.can you add my name in contributors. Github Repo Link from daolens - https://github.com/daolens/funding-protocol-contracts |
Beta Was this translation helpful? Give feedback.
-
|
Payout/No payout:
No payment made yet to syndicate.
"Great to hear that the schemas align with the Stellar Community Fund's
existing structure! For the Cartographer Syndicate registry, considering
the addition of:
- Funding Organization(s)
- Ecosystem(s) (per grant pool or grant system)
Makes sense.
Also, suggesting additional project fields:
- Website
- GitHub repository
And enhancements to the payout schema:
- Currency denominator (e.g., USD, crypto)
- Date field for calculating USD value
- Status indicator (paid/approved)
These modifications will provide valuable clarity and organization to the
grant and payout processes.
Looking forward to implementing these adjustments and improving the
Cartographer Syndicate registry!"
…On Monday, November 4, 2024, slice-amandata ***@***.***> wrote:
@thelastjosh <https://github.com/thelastjosh> hey i was also a
contributor from daolens team.can you add my name in contributors.
—
Reply to this email directly, view it on GitHub
<#51 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXV67YZQ475L22RCGTLI75TZ65263AVCNFSM6AAAAABK2GOB6CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJUGI4DANY>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
null
|
Beta Was this translation helpful? Give feedback.
-
Contributors: Tyler Sully, Kevin Olsen, Riccardo Lamanna, Aditya Anand, Balazs Nemethi, Apoorv Nandan, Tina He, and Joshua Tan.
This is a proposed grants management standard authored by the DAOstar Grants Management working group, including members of Gitcoin, DaoLens, OpenQ, and Station. It is a work-in-progress, but before we submit this as a DAOIP we would appreciate any comments or suggestions from the community.
To facilitate comments and discussion, we have italicized fields and decisions that we feel may require more discussion and development.
Simple summary
Common interfaces and structures for grants management.
Motivation
Grant programs have become a popular tool for DAOs and blockchain projects to accomplish tasks and build infrastructure. The explosion in the popularity of grants programs has been accompanied by an explosion of different approaches for managing grants. The diversity of approaches has led to innovative approaches for grants management but has also fragmented capital and reduced transparency.
This specification lays out a common set of on- and off-chain interfaces for grant programs looking to deploy funding and for projects looking to receive funding. It is intended to increase interoperability between grants tooling, standardize interactions with voting and payout systems, improve the transparency of grant programs, and ultimately make grant programs more efficient for funders, administrators, and grantees.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
This specification is organized into five main components:
While eligibility and compliance flows (including KYC) are important in grants systems, we decided to not include them within the scope of the current specification.
Grants system
The grants system module is intended to be a thin wrapper over one or more grant pools (see next section) that manages basic metadata and declares a relationship (e.g. of ownership) between a given DAO and a given grant system. Roles and permissions to manage a given grant system are not captured at this stage.
Grants System JSON-LD Schema
{ "@context": "http://www.daostar.org/schemas", "type": "grant-system", "id": "<a generic id of the DAO operating the grants system, e.g. its CAIP-10 contract address>", "daoURI": "<daoURI, see DAOIP-2 / EIP-4824>", "pool_id": "<id of the grant object>", }Grant pool
A grant pool is funding locked in a smart contract or other fundable object with the intention of being used to pay out grants. It is essentially a subDAO with off-chain metadata describing the purpose/process of the grant pool and on-chain methods for controlling the flow of funds from the pool.
The proposed grant pool design is designed to enable clear reporting of grant pool and application status while remaining flexible with respect to many different program designs including Gitcoin-style “rounds”, rolling application/funding period, custom refund logic, etc.
Grant Pool JSON-LD Schema
{ "@context": "http://www.daostar.org/schemas", "type": "grant-pool", "name": "<name of the Grant Pool>", "description": "<description>", "grantSystemURI": "<URI>", "tokenAllowList": ["<address>"], "funderAllowlist": ["<address>"], "fundingActive": "<boolean>", "appliationActive": "<boolean>", "applicationStartDate": "<date>", "applicationEndDate": "<date>", "applicationsURI": "<URI>", "lockedFunds": [ {"tokenAddress": "<address>", "amount": "<integer>"}], }We have not yet decided on the final on-chain grant pool. However, we have listed some of the potentially necessary on-chain methods below:
Applications
Projects (see below) are independent of any particular grant program, but when a project applies for a grant from a particular grant pool, it is called an application to that pool. The following schema defines
applicationsURI, which when queried returns all pending and past applications to a grant pool.Applications URI JSON-LD Schema
{ "@context": "http://www.daostar.org/schemas", "type": "grant-application", "name": "<name of the Grant Pool>", "applications": [ { "projectURI": "<URI>", "eligible": "<boolean>", "payout": [ {"tokenAddress": "<address>", "payoutAddress": "<address>", "amount": "<integer>"}] } ] }Projects
Projects are proposals that may be submitted to a grant pool or program.
Grant applications to a grant pool are very similar to generic proposals to a DAO. However, individual projects often apply to multiple grant pools or multiple times to a single grant pool, for example multiple Gitcoin rounds or a co-funding round for a public good supported by many DAOs). For this purpose, we define projects separately from applications.
An open question in this section is how we should attach the history of a project or application (see “previousSuccessfulProposalLinks” below). Secondary question here is how to attach history, or if we want to attach history to the project and if we want to expose that history when it applies to a grant pool.
Project URI JSON-LD Schema
{ "@context": "http://www.daostar.org/schemas", "type": "grant-project", "id": "<id>", "name": "<name>", "description": "<description>", "website": "<URL>", _"credentials": "<TBD>",_ "previousSuccessfulProposalLinks": [], "createdAt": "<Unix timestamp>", "status": "<text>", "fundsAsked": "<id>", "milestones": ["<deadlines and the like>"], "links": [], "roles": ["<access control, milestone reviewers, etc.>"], "walletAddress": [], "email": [], _"logoImg": [],_ _"logoImgData": [],_ "members": [ {"type": "EthereumAddress", "id": "JXxsnO9yqahgfwXg_C1nZ", "text": "Aman Sehrawat", "email": "[email protected]"}], _"smartContractCaller": "<what does this mean exactly?>"_ }Payouts
Once approved, there are many different ways that a grant pool may emit a payout to the project, including direct transfers, milestone-based payouts, time-based payouts, escrow, and other mechanisms. To support such payouts, an on-chain grant pool satisfying DAOIP-# MAY implement the following payout interface:
Voting
A on-chain grant pool will often be accompanied by a particular method for deciding projects, e.g. some form of voting. Where voting is encoded in a smart contract, a grant pool satisfying DAOIP-# MAY implement the following interface:
Rationale
The specification above was based on an extended study of different grant programs and grant tooling for DAOs and other Web3 projects. We have reproduced some of the diagrams associated with that research below. We will extend this section in future versions of this draft.
Gitcoin use-case for DAOIP-#.
OpenQ use-case for DAOIP-#.
DaoLens use-case for DAOIP-#.
Solana use-case for DAOIP-#.
Legend.
Copyright
Copyright and related rights waived via CC0.
Beta Was this translation helpful? Give feedback.
All reactions