T
toknormal
Guest
This is the protocol itself referred to in "Part 1". If you want to have an input, please use this thread to post technical commentary/suggested amendments on the document itself. (You can also PM me if you don't want your comments to be public). Input from proposers/potential proposers is also of course essential.
Use the other thread "Part 1" for broader discussion, conversation/flame wars. I may update the document based on comments in this thread. (People are of course also welcome to start their own entire versions of it !).
0. BACKGROUND AND DEFINITIONS
0.1 The Dash proposal mechanism, popularly referred to as the Decentralised Autonomous Organisation (DAO), is a blockchain based trustless funding source which helps to support the growth and sustainability of Dash as a cryptographic asset.
0.2 The process by which funding is solicited and awarded involves the engagement of potential contractors (the proposers) with the masternode voting contingent of the Dash stakeholding community (the awarders) directly, as well as with wider interested parties such as Dash asset holders, merchants, and developers (the community) indirectly.
0.3 The DAO Elective Engagement Protocol (DEEP) describes a set of structured guidelines which can be used by both proposers and awarders to mitigate ambiguity from the proposal process in key areas. These include the nature of the benefits to the community, operational reporting, assignment of funds, legal entities involved, potentially conflicting equity interests and relevant metrics.
0.4 The voluntary nature of the protocol makes it possible for non DEEP-compliant proposals to successfully acquire funding from the DAO in cases where the guidelines are overly restrictive or unnecessary, such as:
0.4.1 Reasonable Exceptions from DEEP Protocol Compliance:
The DAO is becoming more competitive as the number of projects requesting funding increases and their nature becomes more diverse. For large budgets involving significant risk, the community may request DEEP protocol compliance as a condition for funding, or alternatively the applicant may voluntarily support it pre-emptively as part of their proposal specification in order to boost its competitiveness.
THE PROTOCOL
1.0 PROPOSALS AND THEIR PRESENTATION
1.1 The proposer should present as comprehensive as possible a description of their initiative including the nature of the benefits (e.g. commercial adoption, marketing, education, integrations) to the Dash community.
In particular, the proposal should classify itself into one of two groups which will influence the criteria by which its progress towards objectives will be measured and appraised:
1.2 Critical Classification
A proposal may classify itself in the "direct" category when the benefits are unambiguous and measurable. Examples of these include:
A proposal may classify itself in the "strategic" category when the benefits are not directly measurable and subject to higher risk. These are generally "game changer" type proposals which absorb significant capital costs and resources. Examples in the strategic category include:
In some cases a project may embody a mix of activities which come under both the direct and strategic categories. In this event, the respective budgets should EITHER be split and applied for independently OR the "strategic" classification should prevail for the entire consolidated budget.
1.3 The critical classification (2.2) should ideally be established at a pre-proposal stage following an informal consultation with the community.
2. BUDGET AND REPORTING
2.1 The proposal should clearly specify two items of budgetary projections:
If the proposal spans multiple funding cycles, some degree of clarity regarding contingencies in the event of defunding at an interim stage is required. As a bare minimum, the project may be described as continuity "critical" or "non-critical" as described below:
3.1 The protocol attributes special significance to areas of ambiguous benefit to the Dash network, in particular network-supplied funds which are used to cover capital costs, or to capitalise the balance sheets of private corporate entities.
3.2 Examples of "Section 3" qualifying budget deployments include conversion of Dash to privately held long-term bank deposits not in operational use to cover reported project expenses; similarly dormant Dash denominated holdings; investment in the creation of privately owned intellectual property; investment in privately owned land and buildings; purchase of machinery & equipment not immediately written off to cost and the use of DAO funds generally as shareholding equity in the capitalisation of private businesses.
3.3 Budget allocations which would not qualify under section 3 are costs of goods and services directly associated with executing the proposal and reported as such under section 4.2.2. These include direct salary costs, contracted out professional services, regulatory fees and equipment, machinery or software immediately written off to cost.
While the protocol does not make any mandatory reporting requirement on the detail of section 3 budget allocations, the proposal should as a minimum classify itself in of three categories in this regard:
Any reporting shortfall between the expense report and liquidity statements described in section 4 is assumed to be absorbed by the "Section 3.3 B" category and therefore unaccounted for.
4.0 OPERATIONAL REPORTING
For protocol compliance, the proposer does not need to account for non-DAO originated funds or otherwise disclose sensitive corporate or individual information. However they are required to deliver a minimum level of accountability for the funding specifically sourced from the Dash proposal mechanism in the form of 3 documents per funding cycle or month (whichever is the shorter):
4.2 Monthly Statements
This is a structured report showing the opening and closing balance of the residual funding budget, including any interim movements in 3 categories:
Fig 4F1: Example Interim Liquidity Statement
Fig 4F2: Example Expenses Account
4.4 Reconciliation
4.4.1 Any funding balances not reported under either sections 4.2.2 or 4.2.3, may reasonably be assumed by the community to have been consumed under the classification of category B in section 3 of this protocol specification.
5.0 INTERACTION WITH THE COMMUNITY
5.1 Channels
The protocol makes a distinction between formal and informal channels. "Formal" channels are community and online forums or official correspondence vehicles designated by community stakeholders (website owners, forum managers) for the express purpose of proposal appraisal. The guidelines described here cover communications made in formally designated channels specifically.
5.2 Responsabilities
The protocol endows both awarders and proposers with the responsibility of upholding the integrity, efficiency and reputation of the proposal process. This responsibility should be executed in accordance with a set of elemental ethics guided by the "play the ball, not the man" principle. In particular, the respective parties should observe the following minimum guidelines:
5.2a Proposers
Partial compliance to this protocol shall be regarded as non-compliance. However, proposers are free to use it as a guideline to improve the scope and structure of their presentations to the DAO as they see fit
Use the other thread "Part 1" for broader discussion, conversation/flame wars. I may update the document based on comments in this thread. (People are of course also welcome to start their own entire versions of it !).
0. BACKGROUND AND DEFINITIONS
0.1 The Dash proposal mechanism, popularly referred to as the Decentralised Autonomous Organisation (DAO), is a blockchain based trustless funding source which helps to support the growth and sustainability of Dash as a cryptographic asset.
0.2 The process by which funding is solicited and awarded involves the engagement of potential contractors (the proposers) with the masternode voting contingent of the Dash stakeholding community (the awarders) directly, as well as with wider interested parties such as Dash asset holders, merchants, and developers (the community) indirectly.
0.3 The DAO Elective Engagement Protocol (DEEP) describes a set of structured guidelines which can be used by both proposers and awarders to mitigate ambiguity from the proposal process in key areas. These include the nature of the benefits to the community, operational reporting, assignment of funds, legal entities involved, potentially conflicting equity interests and relevant metrics.
0.4 The voluntary nature of the protocol makes it possible for non DEEP-compliant proposals to successfully acquire funding from the DAO in cases where the guidelines are overly restrictive or unnecessary, such as:
0.4.1 Reasonable Exceptions from DEEP Protocol Compliance:
- direct incidental expenses that the community may incur which are unambiguous in nature
- small budget projects where the community considers that the applicant has already demonstrated viability
- non-funding proposals such as opinion polling
The DAO is becoming more competitive as the number of projects requesting funding increases and their nature becomes more diverse. For large budgets involving significant risk, the community may request DEEP protocol compliance as a condition for funding, or alternatively the applicant may voluntarily support it pre-emptively as part of their proposal specification in order to boost its competitiveness.
THE PROTOCOL
1.0 PROPOSALS AND THEIR PRESENTATION
1.1 The proposer should present as comprehensive as possible a description of their initiative including the nature of the benefits (e.g. commercial adoption, marketing, education, integrations) to the Dash community.
In particular, the proposal should classify itself into one of two groups which will influence the criteria by which its progress towards objectives will be measured and appraised:
1.2 Critical Classification
- direct
- strategic
A proposal may classify itself in the "direct" category when the benefits are unambiguous and measurable. Examples of these include:
- an exchange listing where the prevailing exchange trading volumes and reach are known integrations with existing payment networks
- a merchant adoption program with measurable signups
- an education/promotional workshop activity with a predictable number of attendees
- the operational costs of an ongoing community service such as web site maintenance, or data processing service
A proposal may classify itself in the "strategic" category when the benefits are not directly measurable and subject to higher risk. These are generally "game changer" type proposals which absorb significant capital costs and resources. Examples in the strategic category include:
- the development of new software tools to facilitate large scale adoption in specific industry or geographical sectors
- growth initiatives for new monetary tiers or derivative products in the financial sector
- social media projects involving Dash as a payment medium where there is no existing precedent for predicting adoption
- legal/political initiatives to facilitate adoption via some regulatory vehicle where the extent of success is not predictable
In some cases a project may embody a mix of activities which come under both the direct and strategic categories. In this event, the respective budgets should EITHER be split and applied for independently OR the "strategic" classification should prevail for the entire consolidated budget.
1.3 The critical classification (2.2) should ideally be established at a pre-proposal stage following an informal consultation with the community.
2. BUDGET AND REPORTING
2.1 The proposal should clearly specify two items of budgetary projections:
- the overall anticipated funding requirement
- the budget for the current funding round
If the proposal spans multiple funding cycles, some degree of clarity regarding contingencies in the event of defunding at an interim stage is required. As a bare minimum, the project may be described as continuity "critical" or "non-critical" as described below:
- critical: the project's success is dependent on all funding cycles being approved and no significant network benefit will accrue from partial funding
- non-critical: the project's benefits are cumulative. Failure to secure funding at an interim stage will not render previous progress valueless
3.1 The protocol attributes special significance to areas of ambiguous benefit to the Dash network, in particular network-supplied funds which are used to cover capital costs, or to capitalise the balance sheets of private corporate entities.
3.2 Examples of "Section 3" qualifying budget deployments include conversion of Dash to privately held long-term bank deposits not in operational use to cover reported project expenses; similarly dormant Dash denominated holdings; investment in the creation of privately owned intellectual property; investment in privately owned land and buildings; purchase of machinery & equipment not immediately written off to cost and the use of DAO funds generally as shareholding equity in the capitalisation of private businesses.
3.3 Budget allocations which would not qualify under section 3 are costs of goods and services directly associated with executing the proposal and reported as such under section 4.2.2. These include direct salary costs, contracted out professional services, regulatory fees and equipment, machinery or software immediately written off to cost.
While the protocol does not make any mandatory reporting requirement on the detail of section 3 budget allocations, the proposal should as a minimum classify itself in of three categories in this regard:
- Category A: Declared (an element of the budget will cover private capital costs and these interests are declared in the proposal specification)
- Category B: Undeclared (an element of the budget will cover private capital costs and these interests will not be declared in the proposal)
- Category C: Not applicable (no part of the budget will be invested in privately held capital. All will be reported according to section 4 expense reporting requirements)
Any reporting shortfall between the expense report and liquidity statements described in section 4 is assumed to be absorbed by the "Section 3.3 B" category and therefore unaccounted for.
4.0 OPERATIONAL REPORTING
For protocol compliance, the proposer does not need to account for non-DAO originated funds or otherwise disclose sensitive corporate or individual information. However they are required to deliver a minimum level of accountability for the funding specifically sourced from the Dash proposal mechanism in the form of 3 documents per funding cycle or month (whichever is the shorter):
4.2 Monthly Statements
- 4.2.1 Liquidity Statement
This is a structured report showing the opening and closing balance of the residual funding budget, including any interim movements in 3 categories:
- liquidations from Dash to fiat
- direct expenditures (detailed in the expenses report)
- capital expenditures (detailed in the capital account for the funding budget)
Fig 4F1: Example Interim Liquidity Statement
- 4.2.2 Expense Report
Fig 4F2: Example Expenses Account
- 4.2.3 Capital Account
4.4 Reconciliation
4.4.1 Any funding balances not reported under either sections 4.2.2 or 4.2.3, may reasonably be assumed by the community to have been consumed under the classification of category B in section 3 of this protocol specification.
5.0 INTERACTION WITH THE COMMUNITY
5.1 Channels
The protocol makes a distinction between formal and informal channels. "Formal" channels are community and online forums or official correspondence vehicles designated by community stakeholders (website owners, forum managers) for the express purpose of proposal appraisal. The guidelines described here cover communications made in formally designated channels specifically.
5.2 Responsabilities
The protocol endows both awarders and proposers with the responsibility of upholding the integrity, efficiency and reputation of the proposal process. This responsibility should be executed in accordance with a set of elemental ethics guided by the "play the ball, not the man" principle. In particular, the respective parties should observe the following minimum guidelines:
5.2a Proposers
- 5.2a.1 public communications with awarders should be conducted in a manner consistent with the values of the DAO and best-practice professional public conduct in general
- 5.2a.2 proposals should be promoted on their own merit
- 5.2a.3 where direct, adverse appraisals of competing proposals are presented as a basis for funding then this may be viewed as being in breach of compliance with this protocol
- 5.2a.4 the original specification document should clearly state which parties are authorised to represent the proposal in communications with the community, including their "known as" aliases on anonymous platforms
- 5.2a.5 such parties should identify themselves uniquely, even in anonymous exchanges. They should refrain from using using multiple aliases or other deceptive techniques unless a clearly declared basis exists for doing so (for example the proposer is known by a different alias on a distinct communications platform)
- 5.2b.1 public communications with proposers should be conducted in a manner consistent with the values of the DAO and best-practice professional public conduct in general
- 5.2b.2 proposals should be evaluated primarily on the basis of proposal content, execution and direct potential benefit to the community
- 5.2b.3 where adversity exists between parties, recourse to well founded due-diligence arguments should be pursued in preference to inter-personal priorities which may be a matter of subjective diversity and difficult to arrive at a consensus over
- 5.2b.4 notwithstanding the items required for compliance with this protocol, awarders should respect the privacy and confidentiality of proposers
- 5.2b.5 awarders acknowledge that proposers bring a significant level of reputational risk to the table. They should therefore refrain from engaging in exchanges which may bring proposers into disrepute with their respective business partners
Partial compliance to this protocol shall be regarded as non-compliance. However, proposers are free to use it as a guideline to improve the scope and structure of their presentations to the DAO as they see fit
Last edited:
