• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

D.E.E.P. A formalised Protocol for the DAO - Part 2 (The Protocol)



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 !).


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
0.4.2 Reasonable cases for adoption of 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 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
1.2.1 Direct Category

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
1.2.2 Strategic Category

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
1.2.3 Hybrids

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.


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

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)
3.4 Operational Verification

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.


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)
Retained liquidity should be reported in both Dash and National Currency where they are held independently.

Fig 4F1: Example Interim Liquidity Statement

  • 4.2.2 Expense Report
This summarises the nature and cost of goods and services consumed by the proposal since the last liquidity statement, in sufficient detail for an appraisal of reasonable justifiability to be made. For example, if "software development" costs are listed then the service consumed should also be quantified in terms of programming hours, days or salaried team size.

Fig 4F2: Example Expenses Account

  • 4.2.3 Capital Account
These are liquidations of DAO funding balances made for the purpose of capital expenditure as described in section 3. If the proposal originally specified any budgetary requirement under section 3, then they can be reported here to account for and discrepancy between successive liquidity statement balances and direct project expenses listed in 4.2.2.

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.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 Awarders
  • 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:
@toknormal -- Here I'll include some additional thoughts as they relate to your sections and sub-sections:

0.4.1 - The Nexus crew are working on the inclusion of some additional functionalities built in to the platform and potentially through added, trustless mechanisms to open up the possibility for different kinds of polling and even proposal types (bounties, requests for proposal, etc), which may both obviate the need for using the proposal system to gauge interest/reach consensus as well as expand the kinds of projects we fund and ways in which they can be funded.

1.1 - Nexus already has this included in the system, splitting and even organizing proposals in the system according to category and type, to allow for better analytics.

1.2 - I like this distinction, but if we implement different funding models/proposal types--or even in some already existing cases--it might be worthwhile to classify these types additionally by project status. For example, some projects haven't yet begun, others have been completed and they're seeking compensation, others still have completed some portion of the project (or maybe it's an ongoing project like the Dash Masternode Tool) but are seeking additional funding to achieve additional results.

2.1 - This is very important and much needed. Too much bloat, and too many proposals coming back to the trough unexpectedly for MNOs to be able to plan and strategically allocate budgets!

4.* - While this is an enormous departure from the way things have been done up to this point in most cases, I do think that despite stringent and seemingly overbearing, it's important for transparency, granularity, and attracting only the very best and most professional proposals and proposal owners. The DAO has suffered immensely from unprofessional, amateur efforts that are milking budgets for way more than is needed or deserved, and with little to no accountability. While this may intimidate or scare off some proposals, I think the net effect will be beneficial.

5.* - Yes, this, all of this. I might also add that I think it's important to create a clear delineation and separation between the formal, business-oriented spaces or platforms and the community-oriented spaces or platforms. The blurring of these two leads to a lot of unnecessarily hostility, mismatched priorities, tribalism, dogmatism, and misapplied algorithms. This will allow the creation of compartmentalized cultures and help reinforce the compartmentalization of roles, especially for those of us that fulfill several of them (MNO, PO, Moderator, etc).

6.* - This is probably the only truly controversial statute to me, simply because of the incredibly varied and nuanced nature of proposals. The DAO can fund literally anything, and with the expansion of potential capabilities of ways and methods of funding through Nexus, that's only going to expand further. I definitely agree, however, that once a set of best practices has been established, deviations from or violations of should definitely be much more closely scrutinized even if they're not automatic deal-breakers.
@Arthyron thanks for your comments.

Regarding 1.1, in general when designing "types" for things there are 2 options that work - extremely simple (covers everything) or extremely complex (covers everything). The idea of the explicit distinction between "direct" and "strategic" benefit was to establish a fundamental characterisation of the project at an early stage which would guide the priorities of both proposers during their execution as well as voters in their allocation of funds.

We already have a case in point on another thread at the moment - the Alt36 request for conference funds. This is clearly a strategic "classification" under those definitions because the benefit is indirect. If the project had been filed under the "direct" classification, the request could be immediately dismissed on purely a procedural basis as being inconsistent with the project's original Critical Classification. Forcing proposers to think about this and commit to a classification at an early stage will concentrate minds over delivery commitments. Conversely, filing a proposal under the "strategic" classification means that proposers need to provide a much deeper level of background due diligence support for the community as well as (ideally) committing to a more extensively scoped operational reporting schedule.

Re "project status", I see that also as being very useful but am not sure if it needs to actually form part of the core guidelines - unless what you're referring to is that the entire proposal itself may have a certain permanent "status". Then, yes I can see the case for it.