Proposal “dash-platform-incubator-phase-4“ (Completed)Back

Title:Dash Platform Incubator - Phase 4
Owner:andyfreer2020
Monthly amount: 275 DASH (11437 USD)
Completed payments: 3 totaling in 825 DASH (0 month remaining)
Payment start/end: 2020-11-13 / 2021-02-10 (added on 2020-11-18)
Votes: 1070 Yes / 11 No / 4 Abstain

Proposal description

Dash Proposal: Dash Platform Incubator - Phase 4

1. Summary

This proposal provides a “Phase 4” to the Dash Platform Incubator Phase 3 proposal (https://www.dashcentral.org/p/dash-platform-incubator-phase-3) to extend bounty funding for the development of tools, resources, Dapps and Protocol enhancements for Dash Platform on EvoNet and leading to Testnet for a further 3 months.

2. Phase 3 Review

As per Phase 3 goals to improve Dev onboarding, as well as continuing and expanding existing bounty work, we’ve completed a set of bounties to upgrade the Incubator itself as a standalone open-source / open-data App, to make it more effective in onboarding devs and flesh out the incentive structure to help us  scale, with all existing funds and bounties migrated to the new system:

https://dashincubator.app

How this will work going forward is that my series of proposals will provide funds into the App (its input) and a group of Admins will create and manage Bounties that provide incentives to users to produce work via the App (its output).

This is V1 of the App and still uses Trello on the backend for Bounty management and a Gdoc for accounting so its far from fully automated, but work will be ongoing now on V2 to implement our own (public) backend wired to the site ASAP, followed by a Dapp version once Platform is on mainnet (and ultimately i’d like to Dappify the funding side too using smart code if our protocol allows).  

The goal of the App is to provide an optimal way to translate blockchain funds into valuable human labor for Dash (with a focus on Dapp development), built on the principles that maximizing transparency in decision making and operations can also maximize productivity, accountability and ROI to the Dash network, with the right tools and incentive structures in place.

The App is essentially governed by a set of Rules implemented by both the App’s code and the Admins governing it, who i’m appointing today as we soft launch the App.  Each Admin has the ability to create, manage, and earn commission from their own set of Bounties within the App and operate within their own budget.  These rules represent the full terms of how these Proposals and the App itself will be implemented as of today:

https://dashincubator.app/rules

Whilst eventually we’ll move to full decentralized control by Admins (via quorum based decision, election, review and removal mechanisms), for the time being as Proposal Owner I will retain overall control/veto on decisions until I’m happy that the system is mature enough to decentralize completely.

List of the Admins i’m appointing is as follows:

  • Andy Freer (Proposal Owner)
  • Cloudwheels (Community Dev)
  • Rion Gull (Community Dev)
  • Readme (Community Dev)
  • Pasta (DCG Dev, L1)
  • Ivan Shumkov (DCG Dev, L2)

I’ve selected this group to have a wide range of skills / experience / interests and with positive reputations within the Incubator already, including some DCG devs to give them access to help expedite or flesh out some peripheral parts of their work that might help Community devs get what they need faster.  

3. Phase 3 Highlights

Instead of manually listing all the progress this past Phase, we’ve created a page now that shows the Bounties produced by Incubator users in realtime:

https://dashincubator.app/output

4. Phase 4 Strategy

Now that we have a group of Admins, each will have their own strategy for the output they want to incentivize within the context of the overall Incubator strategy which is stated in the rules as follows:

https://dashincubator.app/rules#14-strategy

My own strategy as an Admin during this Phase is:

  •  Continue to work with other Admins and devs to improve processes within the Incubator App itself, as laid out in the roadmap https://dashincubator.app/rules#7-roadmap
  •  Focus on completing current high-value Dapps into a fully demoable state ready for Testnet, such as our first Social Media Dapp (Jembe, the Twitter alternative), including surrounding work needed to easily on-board users to Dash (Evolution) and get them using these Dapps with minimal friction and the best UX.  I’ll be working with Dashameter and TheDesertLynx to achieve this.
  •  Continue to raise proposals and represent the Incubator, providing the baseline funding and strategy as we grow, and mentor and guide the Admins and developers involved.

In terms of funding, I've increased the ask slightly to factor in the additional work we are taking on to develop and improve the Incubator App itself (referred to in the App as Meta Bounties).   This being said, there are some upcoming Bounty projects that could easily accelerate our burn rate beyond these levels (for example, some new work connecting ETH to Dash in the form of externalizing smart contract storage, providing Oracles to the ETH network and wrapped-Dash on ETH, which are larger projects than we usually take on and involving Ethereum developers).  In such cases, from some discussions with the Admins, I or another Admin could raise some supplemental ‘top-up’ proposals to ask the Network to provide more funding for specific projects and let those stand on their own merit; In either case I will continue to raise my proposals as a baseline to keep the core Incubator strategy funded on a quarterly (ie. 3 superblock cycle) basis.

5. Terms

You can read the full Rules aka ‘protocol’ for the App here, these are comprehensive and supercede the rules from my previous proposals:

https://dashincubator.app/rules

6. Auditing

All resources required to publicly audit all information, source and output of the Incubator are available here:
https://dashincubator.app/rules#6-resources

Thanks

Andy Freer
Dash Developer

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
 
0 points,4 years ago
Its proposals like this that keeps my faith in dash strong. Great work Andy.
Reply
0 points,4 years ago
thanks :)
Reply
1 point,4 years ago
Yes
Reply
1 point,4 years ago
Cryptographically verify the Proposal Description text using the sig of the Proposal Address (that's serialized in the GObject's URL 'txtsig' qstring parameter)

https://pastebin.com/wgJuEwww
Reply
-3 points,4 years ago
It's important to me that any protocol changes to L1 and L2 are signed-off on by our wonderful DCG CTO Bob Carroll. I don't want a PIVX-style free-for-all here with regard to the basic protocol. What are your thoughts on this?
Reply
3 points,4 years ago
Not sure if you're aware but I designed the Evo protocol we have today (State Transitions were moved to a new L2 chain but essentially its the same in fact DPP is a fork of my code) so it's hardly a free for all :)

Bob is awesome and he's visited my place many times during my handover of CTO role to him, along with lot of the devs. The role I took from Evan was protocol design dev manager, so I was very happy to hand this to Bob once we could find the right person and also see him really get implementation work organized in DCG and the fruits of that are coming now as we can all see.

In terms of how we agree protocol changes, that's a collaborative process in Dash via DIPs, which I introduced specifically for that purpose. Bob has a role, as do lot of the devs and Ryan who leads DCG, but also any external stakeholders with the knowledge / interest in how we improve Dash, such as myself.

It's worked great up until now so I don't see any reason to change that.

BTW this proposal isn't proposing any protocol changes - I just mention an (obvious) addition that could be done later given the protocol we have today and now addition of L2.
Reply
2 points,4 years ago
Saying that I don't want to detract from the work done since I completed my design role - addition of L2 chain was no small feat, decoupling of Identities from Usernames (both of which I think are big improvements to my design at this point and now that we've ironed out how to retain global uniqueness for names). And lot of other improvements - credit for that goes to key devs like Ivan Shumkov, Anton, QuantumExplorer, Cofresi on L2, backed up by Codablock and UdjinM6 on L1. What I left DCG with was essentially a prototype, they've made that into a real working protocol/client implementation so big props for that (and is why i'm able to do what i'm doing now from the community side)
Reply
1 point,4 years ago
**protocol design NOT dev manager,
Reply
-6 points,4 years ago
"Smart funding; MNOs (Masternode Operators) fund the Incubator DApp directly from the block reward without an intermediary Proposal Owner."

I don't understand why this is necessary. We already have a system whereby proposals such as this one gets funded by the Dash block reward if the DAO deems them worthy. How do you envision "smart funding" working and why is it needed?
Reply
5 points,4 years ago
Today superblocks pay to an address owned by a single person with a private key. The network then needs to trust that person will do what they said they'd do with those funds and also not lose them or get hacked. Those people often create organizations around those funds that are centralized in nature because spending is controlled by that private key holder

What i'm proposing is ti add the option that the superblock pays to a contract (a Dapp) and smart code in the dapp spends those funds autonomously not dependant on an intermediary private key holder.

It's similar to how Dash as a whole pays proposals - superblocks are autonomous, the miner doesn't hold the private key to proposal funds and we trust them to pay proposals manually, they get paid automatically (qualifying Dash as a DAO) without a centralized intermediary. It's just extending that trustless execution down to proposal organizations.

If superblocks paid to Dapps autonomously each proposal organization would be a DAO in it's own right and spending could be conditional and trustless and no individual private key holder would be responsible for the funds.

For example I could make a proposal to say my Dapp will get 1 Dash per 1000 user signups for 3 months, and that could be implemented in smart code. Or in the case of Dash Incubator, you could distribute control to the 6 admins, and condition payments based on a majority vote from them, instead of trusting a centralized intermediary PO (myself) to enact the reward payouts to make the operation of the organization truly decentralized (at the end of the day each PO can always decide what they do with the proposal funds as they hold the private key giving POs a lot of centralized control within their organizations).

It's not something we can do today anyway, i'm just floating it as something I think is a good feature we should add in the future.
Reply
3 points,4 years ago
That's a tricky solution but I like the idea.
Andy for the future please consider submitting the proposal earlier and not 5 days before the voting cycle end.
Anyway you have my support man! :)
Reply
1 point,4 years ago
Actually someone has pointed out to me that this late submission isn't healthy for other proposals (apologies i've never actually checked the overall state e.g. on Dash Nexus). Hope this hasn't caused too many issues.... in future i'll bring the date forward.
Reply
1 point,4 years ago
Hey man. Ok yep, will do. thanks
Reply
0 points,4 years ago
Thank you Andy. I understand now what you are proposing and it is not unreasonable.
Reply
3 points,4 years ago
Welcome, thanks for the question.
Reply
-5 points,4 years ago
A bedrock principle of Dash is that NO ONE gets funded without a proposal. You want to change this?
Reply
2 points,4 years ago
no its like how you couldn't pay proposal to HD address before, you can't pay proposal to dash contract right now, this is something i would support with testing
Reply
4 points,4 years ago
It wouldn't change anything on the proposal side. It would just add the option to pay winning proposals into contracts not single addresses controlled by a single person we need to trust.
Reply