DASH: $
    
Rewards Output Rules Blog
Dash Incubator on GitHub Dash Incubator on Twitter Chat on the Dash Dev Discord More about Dash

View RULES HISTORY

Dash Incubator Rules v4.0.0 #

Contents #

  1. Dash Incubator
  2. Bounties
  3. Contributing
  4. Admins
  5. Funds
  6. Resources

1 Dash Incubator #

Dash Incubator is an open-source, blockchain-funded organization that redistributes Dash issued from Superblocks to users who produce open-source output that supports our Mission and Vision.

The Incubator uses a Bounty system to fund and manage the end-to-end delivery of a wide variety of projects proposed by the community, ranging from small jobs such as bug bounties, to ongoing services such as promotions or infrastructure provision, to mid-size development projects such as decentralized apps and development tools, to large development programmes involving multiple products that need to be developed and launched together.

Fund allocation and management is decentralized across Admin users and Strategists.

The Incubator is a Dash Funded Organization (DFO). All internal operations of the Incubator are conducted in the public domain at all times. This includes how work is proposed, selected, specified, developed, tested, approved, which users are completing or managing work, what rewards they are allocating or receiving and all internal decision making and governance.

All work produced by the Incubator, known as Output, is open-source and licensed under MIT License.

All handling and allocation of Incubator funds can be publicly verified down to user-task level via the Dash Blockchain in realtime.

1.1 Mission #

Our mission is to find, support and fund the most promising developers and entrepreneurs to build and grow the most innovative and user-friendly applications that maximize the usecases and utility of Dash.

1.2 Dash Vision #

Our vision is to grow Dash to become the number one cryptocurrency for everyday payments by constantly innovating the fastest, easiest-to-use and most cost-effective digital cash at global scale.

1.3 Strategy #

Strategy in the Incubator is defined by each individual Incubator Strategist. Each Strategist aims to achieve our overall Mission and Dash Vision.

The Incubator’s roadmap is the collection of Bounty priorities as stated in Proposals submitted by Incubator Strategists.

1.4 Full-Transparency #

To ensure that the Incubator’s processes and information remain fully open-source and encourage the same standard for other DFOs in Dash, we introduce the following criteria for an Open-Source DFO classification that the Incubator implements:

  1. All funding receipts and expenditure are tracked
  2. All work systems and their data are public
  3. All work preparation and pricing is public
  4. All work output is public
  5. All people’s work and rewards are public and verifiable
  6. All rules governing the Incubator and decisions on how to maintain those rules are public

1.5 Users #

There are several types of Incubator users, summarized as follows:

See linked sections for further detail regarding User roles.

1.6 Network Contract #

This document contains the Rules that define the terms between Dash Incubator and the Dash Network for how any funding awarded to the Incubator by the Network will be used.

When coupled with Incubator’s full transparency policy, anyone can audit how well the Incubator is meeting the commitments of these terms in realtime, including verifying the use of all funding via the Dash blockchain itself down to a user and task level.

We refer to the transparent implementation of the terms defined in this document in return for the funding provided from Dash Network as the Network Contract.

The Incubator is required to abide by the Network Contract at all times.

The authoritative source for the Rules are contained in a single document hosted on Github, with updates to the Rules (enacted as merged commits to the master branch) taking effect immediately.

The Incubator is not a legal entity and as such doesn’t own any assets, including any rights to any output, nor does the Incubator apply any restrictions on contributor’s usage of their own Task output, apart from the requirement that all output must be open-sourced under MIT license.

The only funding the Incubator receives is in the form of Dash issued directly from the Dash blockchain, which it redistributes to users who provide verifiable open-source output for defined tasks approved by Admins, who agree to operate in accordance with the Rules defined in this document.

The Incubator does not handle, hold or pay fiat currency. All rewards are issued in Dash as incentives for creating some open-source output, at the sole discretion of Incubator Admins, and without any agreement or action to purchase or procure any assets, intellectual property or labor.

2 Bounties #

A Bounty in the Incubator means a collection of work that can be completed by contributors for a reward, such as development or promotion of Dash or of the Incubator itself.

Bounties are first proposed as Concepts by the community, and there are four types of Bounty that can be funded, each containing a series of Tasks that are managed by the Bounty’s Admin, who earn a commission of all rewards that the Bounty generates.

2.1 Concepts #

All Bounties start as a Concept that is proposed to the Incubator by a community member.

Concepts are proposals for some work that the Incubator should fund as a Bounty, that provide enough detail about the value proposition and requirements of the work to enable Contributors to complete it.

Strategists create a Bounty for each Concept they accept that they then own, meaning they have the rights to manage and earn commission from its delivery. They accept Concepts that meet our Concept Acceptance Criteria on a first-come first-serve basis. Once accepted, the user who created the Concept is assigned as a Stakeholder of the corresponding bounty.

2.2 Bounty Types #

When a Bounty is created from a Concept by a Strategist, they assign one of four types for the new Bounty that determine how work will be structured:

All Bounties in the Incubator are represented by a Card on our Trello Board. The Bounty’s type is represented by the column the Card is in on the Board. Meta Bounties are shown with the pink label on the Card’s front cover.

2.3 Bounty Status #

Each Bounty can be set to have one of the following Statuses at any time:

2.4 Bounty Stakeholders #

For some bounties, Admins may wish to regularly solicit the views of subject area experts or other key stakeholders as part of the decision making process when defining bounty tasks.

Whilst bounty administration remains under the Admins of the bounty, a record of these Stakeholders, the nature of their interest, and the circumstances under which they should be consulted, may be added to the Bounty data.

Concept creators are automatically added as Stakeholders of any Bounty that derives from the Concept.

On Trello, the stakeholder usernames are added to the Card’s description in a Stakeholders section, including any additional information on the context for their involvement.

2.5 Tasks #

A Task is the basic unit of work in the Incubator and represents a unit of open-source output that a user can produce for a specified reward.

All work in the Incubator, and consequently any use of funds, is performed via completion of a Task by a user, or the management of that Task by an Admin, within a specific Bounty.

Tasks can be proposed by any Incubator User. If a task is created by an Admin, any user may request to reserve it with the Admin. Tasks created by Admins can be categorized as Job tasks to communicate that they may be completed without reservation or pre-approval.

Each Task includes a description of the quantifiable Output (a document, commit, etc) and the specified price denominated in Dash that a user can Claim.

There are four types of Task available within the Incubator:

Each Task Type is represented as a named Checklist on the Bounty’s Trello Card, except for Concept Tasks, which are implicitly completed when a Concept is Accepted by an Admin.

2.5.1 Concept Tasks #

A Concept Task is defined as the submission of new Concept by an Incubator user.

The Claim for a Concept Reward is considered to be implicit and approved as soon as a Strategist accepts the Concept.

2.5.2 Specification Tasks #

Specification Tasks define how Production Tasks should be completed and QA’d.

The output is usually a document such as a Design Requirements doc, Functional Specification, or any resource that enables output relating to achieving the Value Proposition of the Bounty to be produced effectively.

Admins measure the quality of the Specification in terms of its fitness for purpose and adequate detail level to define the Production Tasks a Contributor needs to implement it.

2.5.3 Production Tasks #

Production Tasks are the actual output of a Bounty that deliver the value proposition.

Usually Production Tasks output some code or a working product, but if the Bounty is for example a research project, the Production Tasks could output documents or analysis, or any format that satisfies the goals of the Bounty.

2.5.4 QA Tasks #

Quality Assurance tasks validate and test that Production Tasks meet their Specification. Production Tasks may require related QA tasks, particularly if prior Specification Tasks include QA criteria. QA Tasks must reference the relevant Specification or Production Task and produce some QA report output.

QA reports may use a QA Report Template, or any other format the admin requests or approves.

2.6 Claims #

A Claim is the process of a user signalling that they have completed a Task and wish to receive the Task’s stated reward.

Users can create Claims for Tasks they believe to be complete from the Admin who owns the Task using the Claims process.

Once a Task Claim is approved by an Admin, the Task Reward will be awarded to the Dash address the claimant specified in the Claim within 7 days.

2.7 Rewards #

The Incubator is a pure Dash fund, meaning all rewards are priced and paid in Dash.

Admins can price tasks up to the max price. Strategists can claim a commission up to the max commission listed in the table below. They can either keep the full claimed reward or split it with a non-Strategist admin who has assisted in the administration process.

2.7.1 Price List #

Task Type Approval Criteria Max Price Max Commission
Concept Task Accepted Concept 1 DASH 20%
Specification Task Valid Specification 100 DASH 20%
Production Task QA Complete 100 DASH 20%
QA Task Valid QA Report 10 Dash 20%

3 Contributing #

Contributing to the Incubator involves completing Tasks on Bounties to earn Rewards.

A reward can also be earned by proposing a Concept for new Bounties that get accepted by a Strategist.

All work produced at the Incubator must be open-sourced under MIT license before any rewards can be paid, to satisfy the Incubator’s full-transparency requirements.

3.1 Proposing Concepts #

Anyone can create a Concept by signing up to the Incubator and submitting a New Concept Template.

Any Strategist can accept a Concept that meets our Concept Acceptance Criteria, meaning they create a new Bounty for it that they become the owner of.

The Concept Reward is paid to the Dash address listed in the Concept when accepted.

  • To propose a Concept, add a comment on the New Concept Card on Trello.
  • To chat with Admins about a Concept or its acceptance, join the DashDevs Discord and ask on the #dash-incubator channel.

3.2 Completing Job Tasks #

Job Tasks on Bounties are open to be claimed by anyone without needing to reserve the task.

To claim a reward on a Job task, use the Claims process

3.3 Reserving Tasks #

Any tasks other than Jobs can be reserved. This means that you can agree with the Task’s Admin to have exclusive rights to claim the Task until the due date.

To reserve a task, leave a comment for the Admin of the Bounty that the Task is a part of, so that they can assign the task to you, and/or discuss the Task details and negotiate the reward.

Once you have completed the Task, use the Claims process to claim the reward.

If a claim isn’t made by the due date, the Admin can extend the date, alter the reward, and/or cancel the reservation.

To be able to Reserve a Task please join as a Member of our Trello Board by leaving a comment on our Member Signup Card.

3.4 Claiming Tasks #

Once you have completed the work for a Task you can make a Claim for the reward on the Task, by providing the following information:

  1. The task type and number you are claiming (e.g. production task 3)
  2. Link to the source for the tasks output (specific PR or commit for Github code)
  3. Link to any deploy links relevant to the output (e.g. a URL for a website)
  4. A valid Dash address to receive the reward, or set to NULL to decline the reward.

Once your Claim has been created it will be processed by an admin.

To create a Claim on Trello, leave a comment on the Bounty’s Trello Card specifying the number and type of the Task you are claiming, along with the source links and your Dash address

3.4.1 Null Claims #

In some cases, users wish to decline rewards for some reason.

This is strongly discouraged as incentives are how Incubator maintains a high level of creativity, productivity, and quality of output, and Claims themselves are how we track and account for work completion.

However, to support the requirement, we introduced the option to create a Null Claim.

Therefore users who wish to decline rewards still need to make a Claim to signify and enable tracking of a Task’s completion, but they can set the claim’s Dash address to ‘NULL’ to signify that the actual reward is declined and therefore won’t be awarded.

To create a Null Claim in Trello, simply enter the term ‘NULL’ in place of a Dash address on the relevant Claim comment.

4 Admins #

Admins are users in the Incubator who are authorized and permitted to manage Bounties in the Incubator. Strategists are a subset of Admins who assume extra responsibilities, and can carry out all Admin actions. All Bounties must be originally accepted and owned by a Strategist, but Admins can perform most administrative Bounty Management actions.

On Trello, the board is configured to only allow Admins to create and edit cards, including defining and assigning tasks to Board members. Any user can comment on cards to interact with Admins about the bounties they’re managing.

4.1 Accepting Concepts #

Bounties are created via the Acceptance of a user-submitted Concept by a Strategists.

4.1.1 Concept Acceptance Criteria #

Strategists must judge that Concepts they wish to accept meet all of the following criteria:

  1. Provide a clear Value Proposition that can return value to Dash that’s inline with our Dash Vision
  2. Provide enough detail on requirements to enable a Bounty to achieve the stated goals
  3. Be technically feasible using the current Dash Protocol or some unreleased but known iteration of it
  4. Be achievable in terms of costs compared to the Incubator’s current funding levels

4.2 Bounty Management #

4.2.1 Creating Bounties #

Bounties are created exclusively by Strategists who Accept a community-submitted Concept and consequently receive Ownership of the Bounty. Strategists can either administer the bounty themselves, or delegate administrative work to a separate Admin.

Admins must ensure the following information is correctly configured on new Bounties that they create:

  1. The creator of the Bounty is set as the Owner Admin of the Bounty
  2. The correct Type for the Bounty is selected field (either Project, Specification, Job or Programme)
  3. The Concept the Bounty was created from is linked in the Concept Doc field
  4. The Description text reflects the Value Proposition of the related Concept
  5. The Concept creator is listed as a Stakeholder

After creating the card in Trello the Strategist should assign themselves as the Member of the card on the top left below the card title. Assistant Admins are designated by putting their Trello username into the assistant Admin field on the card.

4.2.2 Bounty Ownership #

The Strategist who created a Bounty is considered the owner of that Bounty and has priority rights to edit the Bounty’s fields, define Tasks and process resulting Claims, and change the Bounty’s Status. The Strategist may transfer ownership to another Strategist at any time.

In Trello, Ownership is determined by the Strategist who is the Member of the Card (there should only be one).

4.2.3 Assistant Admins #

The Strategist can optionally appoint an assistant Admin to the Bounty, enabling a maximum of two Admins to manage a bounty at one time. Assistant admins can edit the Bounty’s details and carry out all administrative actions, but the Bounty is owned by the Strategist. Assistant Admin rewards are described in Admin Rewards.

In Trello, Bounty Owners can appoint an assistant on a Card by entering their name in the assistant Admin field and assigning them as a Member of the Card.

4.3 Task Management #

4.3.1 Creating Tasks #

Admins can create Tasks on any Bounty that they are an Assistant Admin on. When creating a Task, the Admin sets the Description, which must provide enough information to allow a Contributor to complete the work, either in the description itself or by linking a Specification.

The due-date is the date whereby if a Claim is not made for the Task, the Admin may edit the task (including changing the reward and/or description, extending the due date, or canceling it completely).

When defining a Task in Trello, the Admin will chose the correct Checklist for the task type, and specify the following information:

  1. A Task number, which is the sequential number of the Task in the relevant Checklist
  2. A Description, summarising the broad requirements by a short definition is needed, and a link to a Specification to provide further detail if needed.
  3. An amount of Dash for the Reward. This can be negotiated between the Admin and prospective users
  4. A due date and Task assignee

This information should be entered into the Task description in the following format:

[taskNumber]) [taskDescription] ([amount] DASH)

4.3.2 Pricing Tasks #

Pricing Tasks in the Incubator takes a different and more flexible approach to traditional methods of sourcing as it factors in externalities such as priority, time constraints, skills availability (or overheads due to sourcing additional resources) and productivity incentives, whilst factoring out notions that ignore these factors such as fixed hourly-rates, market-rates or salary-based arrangements that won’t necessarily achieve our goals at the speed we want or with the level of productivity we want to achieve for the value we want to deliver.

For example, if Tasks are urgent or highly specialized and resources are not available, or Tasks have existed for a long time without uptake, higher rewards can be set to achieve uptake on the Tasks, including the option to offer rewards for promoting those Tasks and/or placing the necessary resources, which can result in reward levels above traditional “market rates” to deliver the output we want in the time needed.

On the other hand, low priority tasks with multiple resources already on-boarded and available who could under-bid each other and without time-constraints can often provide output well below “market rates”.

In other words, Tasks should be priced via a process to discover what is the minimum reward level needed to incentivize a Contributor to deliver something and deciding whether externalities such as needing to find & onboard the necessary resources or meet a certain deadline need to be factored in based on the Bounty’s priority.

Fiat prices should be taken into consideration when a Task is created, but Tasks are typically not repriced based on fiat value changes after creation.

4.3.3 Reserving Tasks #

When Admins create tasks ahead of time, Members may request to reserve them and negotiate the Task’s terms (description, reward, due date) within the comments or via private communication, but once the Task is reserved to the user, the terms are considered agreed and are public information.

On Trello, Tasks are represented by Checklists on the Bounty’s Card, and are reserved by setting the Member setting to the user who reserved the Task and setting a date in the Due Date field.

4.3.4 Processing Task Claims #

When a user completes a Task, they create a Claim that the Admin needs to process to decide if the Claim is Approved, if QA is needed, or if there are issues that need to be resolved.

Approved Claims on Tasks go into the Incubator Accounting Spreadsheet from which the reward will be sent to the claimant.

If a Contributor wants to dispute a Claim decision, they can ask for a second opinion from the other Admin on the Bounty or the Lead Strategist.

Ultimately, decisions on whether some output meets the requirements specified in the Task definition are the sole discretion of the Strategist that owns the Bounty.

In Trello, Admins can Approve a Claim by ticking the Task’s Checkbox and leaving a comment on the Bounty card as follows:

[@username], claim Approved, [checklistName] [taskId])

For example:

Claim Approved: @somedev Production Tasks 1,2

Admins must then enter the details into the Incubator Accounting Spreadsheet, filling in all columns and double checking the user’s payment address and reward amount, to enable the claim to be awarded.

4.4 Admin Rewards #

Admins are rewarded with a commission based on approved task claims. In addition, strategists (a type of admin) are rewarded with a commission based on approved funding. See the commmission table below for details.

Each quarter all Strategists submit a network proposal with that quarter’s monthly budget request. Admins are rewarded as follows:

Reward calculations are shown in the Claims and Reserve Planning tabs of the Dash Incubator Accounting spreadsheet. Note that the Reserve Planning model and values change over time and may not be accurate depending on when the sheet is accessed. The Claims tab data is accurate when accompanied by transaction identification (TxId) values.

Current approved reward limits are found in the Price List and commission table.

Strategists can assign, complete, and claim Bounty Tasks for themselves, provided they carry out the task and claim processes and explictily assign themselves to the task for clear auditing purposes.

Task commission rewards don’t require separate claims, they are implicit claims recorded with their associated work Tasks in the Incubator Accounting Spreadsheet.

Note that Admin reward claims can be lower than the limits listed below. Admins simply claim a specific commission, up to but not exceeding the maximum claimable value.

4.4.1 Commissions #

Role Commission Limit Time of Award
Strategist 10% of MNO-approved budget After approved superblocks are paid out each month
Strategist 20% of task claim (10% if using Assistant Admin) When approved tasks are paid out
Assistant Admin 10% of task claim (half of Strategist's 20%) When approved tasks are paid out

4.5 Governance #

Strategists are responsible for governance and the strategic direction of the Incubator. They collectively form a group referred to as the strategic committee.

The Strategic Committee is responsible to:

Simple majority support is required for any of the above, meaning >50% of voting Strategists. Strategists may recuse themselves from voting by not registering a vote (within an agreed voting period) or selecting/commenting ‘Recuse’ against the vote itself.

The Lead Strategist can be replaced by masternode approval through a 1 DASH superblock proposal where the proposed new Lead Strategist is named and proves control over the proposal payout address. The normal passing criteria for funding proposals must be achieved to be considered valid. If that occurs, all funds under the Lead Strategist’s control must be transferred to the address given in the proposal. The new Lead Strategist assumes the role upon receipt of those funds.

4.6 Strategists #

Strategists are Admins who define and execute strategies for achieving the Incubator’s mission and vision. They ensure that the Incubator as a whole is delivering value to the Dash network.

Each Strategist submits a quarterly Dash network funding proposal, identifying priorites, updates, budget requests, etc related to the projects they own.

Strategists may also carry out the following:

4.7 Lead Strategist #

The Lead Strategist is the Strategist who handles (but isn’t liable for) custody of and transactions from the Dash received from the network. All proposal payout addresses for stategist proposals are controlled by the Lead Strategist to ensure that that all payouts adhere to Incubator rules.

The Lead Strategist agrees to use funds solely for the purposes of Task Claims and Admin Rewards.

The Lead Strategist also carries out the following:

5 Funds #

The Incubator is fully transparent about all incoming and all outgoing funds. Funds are received through proposals, managed through reserves, and spent on Tasks and commissions.

5.1 Proposals #

There are two types of proposals from the Incuabtor to the Dash Network:

The Incubator is funded from a series of Proposals submitted to the Dash Network on a quarterly basis. The Lead Strategist submits the first proposal of each quarter. After that, anyone can submit additional proposals to participate as an Incubator Strategist. Requirements for each type of proposal are shown in the following two sections.

5.1.1 Lead Strategist Proposals #

Each quarter’s proposal from the Lead Strategist includes:

Funding requested by the Lead Strategist is to support only their own projects, not the Incubator as a whole.

5.1.2 Additional Strategist Proposals #

Each existing and prospective Strategist submits quarterly proposals to the Dash network for funding of their own projects. These proposals should be submitted with the same cadence as the Lead Strategist’s proposal; it should be a three-month proposal submitted within one week of the Lead Strategist’s proposal being live on the Dash network. Strategist proposals should include:

5.2 Reserves #

There are two types of reserves in the Incuabtor:

Network proposal funds are received into the published Incubator Wallet address(es) for each Strategist (including the Lead Strategist). These addresses are referred to as reserves because funds for each strategist collect into and remain in (through coin control transactions) a single address. Once an individual is approved (through a sucessful Incubator proposal) to be a strategist they retain the same Dash address for their Incubator reserve (unless and until updated Incubator rules dictate otherwise).

All reserve addresses are under the control of the Lead Strategist. Funds are kept in separate reserves for accounting, auditing, and proposal funding purposes. The Incubator maintains Dash reserves only; no other assets are held.

5.2.1 Lead Strategist Reserve #

When any strategist decides to stop working for the Incubator their reserve is transferred to the Lead Strategist reserve. This is what differentiates the Lead Strategist reserve from all others. The Lead Strategist does not transfer funds to other Strategist reserves. Funds only leave the Lead Strategist reserve in one of two ways:

5.2.2 Strategist Reserves #

Funds from approved Strategist proposals are sent directly from superblocks to distinct addresses for each Strategist. These addresses are all controlled by the Lead Strategist.

Each Strategist’s published address carries funds in a rolling reserve. Strategists have full autonomy over their reserve spending, so long as they serve the Incubator’s vision and mission, and are accounted for according to the auditing rules.

When a Strategist leaves or is removed from the Incubator their reserve is transferred to the Lead Strategist’s reserve.

5.3 Auditing #

Anyone can perform a full public audit (#14-full-transparency) of the Incubator at any time to check that all work is being conducted as per these Rules, and verify the rewards issued to individual Incubator users for that work via the Dash blockchain.

5.3.1 Auditing Accounts #

All spending by the Incubator is tracked via Task Claims approved by Admins, with associated transactions accounted for in the Dash Incubator Accounting spreadsheet.

5.3.2 Auditing Work #

All work must be conducted inline with the Rules in this document and in the public domain. Therefore anyone can audit how well the work being conducted in the Incubator is adhering to these rules at any time.

As a guideline, the following aspects of work are key areas to ensure the Rules are being implemented effectively.

6 Resources #

Below are links to all resources needed to access, fork or audit every aspect of the Incubator, to satisfy our full transparency requirements.

6.1 General #

Resource Link
Website dashincubator.app
Website Source github.com/dashincubator/dash-incubator-app
Rules Source github.com/DashIncubator/dash-incubator-rules
Discussion DashDevs Discord

6.2 Data #

Resource Link
Trello Board Dash Incubator

6.3 Accounting #

Resource Link
General Reserve A (Andy as Proposal Owner) XbFb9b1qaoLykngDbUwBVBFwSHuwQRhSqc
General Reserve B (Rion as Proposal Owner) XoNcU93gE6yMegtTSQpzHGPfHMRUiLS8Ub
General Reserve C (Rion as Lead Strategist) XpVFECgympGyGwRLet2xy14BBhFCWLiXhW
Strategist Reserve 1 (Rion's Lead Strategist Reserve) XwxXr39ErU7CK5fPe6N3AnDTi1kK9iDSmm
Strategist Reserve 2 (Ash's Strategist Reserve) XdpS7kop2SowZvVqu7th9dRhZQAvSoJRL4
Strategist Reserve 3 (Tim's Strategist Reserve) XekTLjeHhtHzN3KNKBkA5hwCBRnftY5GMm
Task Rewards Incubator Accounting Spreadsheet

6.4 Proposals #

Proposal Link
2020 Q1 (Phase 1) dash-platform-incubator
2020 Q2 (Phase 2) dash-platform-incubator-phase-2
2020 Q3 (Phase 3) dash-platform-incubator-phase-3
2020 Q4 (Phase 4) dash-platform-incubator-phase-4
2021 Q1 dash-incubator-2021-q1
2021 Q2 dash-incubator-2021-q2
2021 Q3 dash-incubator-2021-q3
2021 Q4 dash-incubator-2021-q4
2022 Q1 dash-incubator-2022-q1
2022 Q2 dash-incubator-2022-q2
2022 Q3 dash-incubator-2022-q3
2022 Q4 dash-incubator-2022-q4
2023 Q1 dash-incubator-2023-q1
2023 Q2 dash-incubator-2023-q2