Proposal “dash-platform-merchant-directory“ (Active)Back

Title:Dash Merchant Directory Dapp
Monthly amount: 65 DASH (6187 USD)
Completed payments: no payments occurred yet (2 month remaining)
Payment start/end: 2020-02-14 / 2020-04-13 (added on 2020-02-08)
Final voting deadline: in 18 hours
Votes: 339 Yes / 98 No / 11 Abstain
Will be funded: No. This proposal needs additional 223 Yes votes to become funded.
External information:
Manually vote on this proposal (DashCore - Tools - Debugconsole):
gobject vote-many a48b1d11dbb1d038e1427b8af0505ea223a3579c83f95fedc16f9131a60f84ee funding yes

Please login or create a new DashCentral account for comfortable one button voting!

Proposal description

PROPOSAL UPDATE (Feb 22, 2020)

This proposal has been modified, a copy of the original is available for anyone interested.  I just trimmed the fat in some areas, and put some meat on the bones in others.  The proposal scope, schedule, and budget remain mostly unaltered.

Value Proposition

  1. An open ("permissionless" and "trustless"), community-maintained directory of Dash-accepting merchants, with searchable, sortable, and filterable data stored on Dash Platform, accessible by both end users directly with a reference web app GUI, as well as from 3rd party merchant directories through an API.
  2. Documentation, guidance, and reference material for current and future Dash Platform developers, including a YouTube video series demonstrating the process of creating a real-world decentralized application ("dapp") on Dash Platform.


Dash needs a merchant directory/service that is accessible to anyone, controlled exclusively by nobody, has reliable and comprehensive data, and is built to be self-maintaining and self-sustaining.  This is possible with the right design and incentives.

In addition to those simply looking for how they can spend their Dash, there is demand from third-party merchant directories who would like access to Dash merchant data. Amanda B. Johnson recently asked in the r/dashpay subreddit if anyone could provide this data to so that they could get an improved picture of Dash's merchant count. Several people in that thread expressed an interest in having accessible data. u/giorgiom92 also mentioned having what seemed to be a separate (and more accurate) directory for Venezuelan merchants. It's likely that other merchant directories exist on top of these as well.

Dash Core Group (DCG) does not have plans to build a merchant directory. However, Bob Carroll (DCG CTO) mentioned that he “would love to see [one] come from the community". (see Reference 1 below)

An additional motivation here is to create supporting tools and document the process of making Dash Platform dapps for 3rd party developers. Both independent and DCG developers benefit from this. Developers unfamiliar with the inner workings of Dash learn how to use it, and DCG learns where the official documentation falls short (sometimes developers who create a tool overlook knowledge gaps in how to use it).

Scope of Work

I have two main goals with this proposal.  1) build a merchant service with the qualities stated above, and 2) document the process and provide resources for other developers.  I think the best approach for this is to build the merchant service as a traditional app (web app and API), and then convert it to a Dash Platform dapp.  I will make a YouTube video series documenting the whole process.  The goal is to attract outside developers with a video series that demonstrates how to use modern but traditional technologies (e.g. AWS, Terraform, Docker, Ansible, Node.js, GraphQL, React, etc), and then show how to integrate it with Dash Platform (Dash Drive and DAPI).

From a user’s perspective, this project can be understood as a merchant “directory”, but technically, my design is to make this more of a “service”.  In software, a service is more about the data and the API server than the front end client that consumes (uses) them.  This project will include both the API service and a reference client web app, but the focus will be the backend service.

Project features and deliverables:
  • Backend service
    • API server (REST or GraphQL) giving open access to merchant data
    • Elasticsearch functionality for returning sorted, search-term-relevant data
  • Reference client app
    • HTML/CSS/JavaScript web app built using React
  • Infrastructure deployment tools
    • Terraform/Ansible/Docker configuration code for easy application deployment
    • Developer-oriented command line interface (CLI) tool for interactive project setup

I have already started the process.  Most of the initial planning and architecture is complete.  Data from is also now available in JSON format. This is a static snapshot that (or anyone else) can already use. Here’s the roadmap for the merchant service minimum viable product (MVP) and developer documentation:

Merchant service roadmap:
  • Acquire data from existing merchant directories (complete for MVP)
  • Plan and develop data model (complete for MVP)
  • Plan and develop infrastructure deployment tooling
  • Plan and develop API to access and modify data
  • Plan and develop Elasticsearch component
  • Plan and develop DAPI and Dash Drive integration
  • Plan and develop community and merchant participation incentive model
  • Implement self-sustainability plan to remove reliance on treasury funding in the future

Tooling and documentation roadmap:
  • Refine and document the process of setting up a Dash Platform devnet, using and building on existing resources
  • Develop a tool to scaffold Dash Platform applications using an interactive command-line application
  • Keep in close communication with community and DCG developers

Note regarding that last bullet point: I am in ongoing communication with Andy Freer, Dash Platform chief architect, who has offered technical guidance for the Dash Platform-related aspects of this project.  He has also helped with this proposal revision.  I have and will continue to communicate my plans and progress with community developers regarding this project in the Dash Dapp Developers Discord server.  I’m happy to collaborate with anyone and everyone who wishes to be involved in this.

Schedule, Budget, and Terms

I am asking for 65 DASH/month for two (2) months to cover time (my own and those I employ), expenses, and the proposal submission fee. This will result in a minimum viable product (MVP) with features described above.

My aim is to provide as much value as possible before being funded.  As of now (Feb 22, 2020) I have worked nearly full time this month planning and preparing this project, with some progress on initial coding as well. I’m a bit behind on where I’d like to have been by now, but still plan to complete as many of the deliverables and features above as possible before the voting deadline for the 2nd month of funding.

The goal is to build a product that becomes self-sustaining. This will likely not be finished in two months, but that’s the aim.  Because I’m being paid by the superblock, I consider what I produce to be “owned” (in terms of understanding, not necessarily legally) by Dash.  When the product becomes self sustaining I will not need to ask for superblock funds in order to maintain it.  Until then, I’d be happy to open source everything I produce.  The challenge is that it’s sometimes not clear what the community wants in this respect.  I will do my best to gauge whether people want this open source or not (please comment if you have a preference).  I will likely err on the side of opening everything up, and will only consider keeping it closed if I see clear support for that.

Dash can expect full transparency into the accounting (costs and revenues) of the project while it is superblock funded. We would continue to ask for treasury funding until the project can pay for itself, tapered off gradually until revenues exceed costs. At that point we can come up with a profit-sharing plan with the network, potentially leveraging the Dash Investment Foundation.

Note: The items in the scope of work will be built using Evonet (testnet for Dash Platform) to the degree possible.  I will use traditional technologies for features not supported by Dash Platform.  The (d)app will ultimately be transferred to Livenet when that lands, but this is not scheduled yet.

Voting and Feedback

I am trying to build the product that I personally need in order to better support Dash-accepting merchants (most of my income is in Dash right now, so I need this product). I’d also like your feedback, so I can incorporate features that you want. The best place to direct feedback, particularly for longer conversations, is the #merchant-directory channel in the "Dash Dapp Developers" Discord server.


Dash is meant to be digital cash. It can only fulfill that role if people spend it regularly, and for that they need to know where it is accepted. With payments and merchants being such an integral part of Dash and its mission, it makes sense to put merchant data on Dash Platform, so that it can be accessed freely.  Although it’s in the early phases still, Dash Platform needs testing, with real-world applications.  So we have a nice match here; this is the perfect time to be building a merchant dapp on Dash Platform.


(1) Q and A regarding merchant directory from DCG Q4 2019 conference call (time-stamped video with transcript below):
Question (Rion): 
"Is a decentralized merchant directory part of the scope of Dashpay"?
Answer (Bob): 
"I'll answer that in two parts, one on the client side, in a mobile wallet, would that be part of the functionality, and then also from the platform perspective, dashPay as a data contract or as a dApp that lives on the the platform layer. A decentralized merchant directory is a perfect example of a dApp to be built on top of the platform. It leverages our payment chain, it leverages the people that are using the ecosystem and the network today. Who is going to -- right now that's not part of a defined scope of work to be built. Merchant features are definitely expected to be added to the dashPay wallet, in the DashPay dApp. However something like a merchant directory I think is a perfect example for our community to get involved and have a race to the finish on that and say now that we see the base capabilities of DashPay, wouldn't it be great to write a merchant directory type of dApp that then any wallet could plug into. Because why should DashPay as a wallet, if we're now talking about the mobile app, be the only one to take advantage of the merchant directory, you'd want not only desktop wallets but also third party wallets to take advantage of that as well. So it's not part of our current roadmap, definitely aligned with our product capabilities and I'll just use that as kind of a -- maybe one thing I didn't say today which is, this is why we're building it, right, it's to enhance the community let the community get involved and build applications and solutions on top of the platform, and so I would love to see more of that come from the community than looking and saying DCG what else are you doing for us now, by the way, throw item number 50 or 100 or 200 on the list to then prioritize with, as we've talked about today, a limited set of funding that's available so great question, these types of solutions are what keeps us excited every day"

(2) Request for Discover Dash merchant data (Reddit thread):

(3) Data from in JSON format:

(4) Dash Dapp Developers Discord server:

Show full description ...

Discussion: Should we fund this proposal?

Submit comment
1 point,2 days ago
Hi there,

FYI Rion reached out to me on Discord and we had several meetings about how this proposal for a Merchant Directory service could be implemented as a Dapp and how to specify it.

Essentially a Dapp in Dash is when a centralised application (such as a merchant directory running on a server/browser frontend) decentralizes all or part of its state to the Dash (l2) blockchain, removing the need for trust or centralized provision of that data...In this case I explained that I thought the value proposition would be to have a trustless merchant directory, where both merchant and review data was created and signed by Dash Usernames via DAPI/Drive, so end-user wouldn't need to trust the provider (Rion) for the data they are consuming from the service.

We also talked about the implementation, i.e. not everything would be ready out-the-box on the EvoNet side so Rion would have to work in tandem with the Core devs to implement the decentrlaized state.

I also wasn't 100% clear on whether this would be a centralized app first or built as a Dapp from the ground-up (which is more something I would support) but Rion assured me that the roadmap here is firmly as a Dapp (aka centralized) Merchant Directory so I assume that's the intention.

In which case, although I can't comment on the reputation/delivery of Rion or the pricing of the proposal, I think the value proposition is interesting (as a Dapp on Dash Platform) and i'm happy to work with him to help this implementation if the proposal passes.

Andy Freer
1 point,1 day ago
Thanks for your comment and assistance, Andy.
0 points,1 day ago
"...both merchant and review data was created and signed by Dash Usernames via DAPI/Drive, so end-user wouldn't need to trust the provider (Rion) for the data they are consuming from the service."

So this has nothing to do with Discover Dash. DD is an Evolutionary dead end (pun intended) . Forget about loading this thing with DD data. This is not going to be curated. Right?
0 points,1 day ago
Not sure if this question is directed at me, or Andy. The data will be curated in a similar fashion to how Google AdWords keeps relevant information closest to the user. Think of this more as a search engine than pages of listings, where listings are fed to a user based on search terms, and listing order is based on both relevance and amount paid for specific keywords (e.g. “food”, “vpn”, etc).
0 points,3 hours ago
My point is this. If you load data into your system from an existing source (DD), YOU have to maintain it (keep it up to date). If you want to TRANSITION to a system where the business owners control their own data, you will need a "claim this business" process like they have at YELP.

I cannot support simply cloning DD and moving the centralized data (which you have to maintain) onto the Evo second layer.
1 point,2 hours ago
There will be no need for a “claim this this business” function in my currency design. It’s much better than that.
0 points,2 hours ago
*current design
0 points,1 day ago
I would like to see this proposal managed/supervised under your proposal and be more collaborative with multiple teams working on different parts that can eventually all plug in together. If that means doubling or tripling your proposal ask going forward I would support that.
2 points,9 days ago
Anypay have a great merchant map that also exhibits sites and how current they are. Many maps get out of date too easily.
1 point,2 days ago
Right. Hopefully we can work together with them to share merchant information. One of my main goals with this project is to design this so that the system remains up to date, with the proper incentives to do so (which will eventually involve Dash payments to those who help curate and maintain the data.
0 points,10 days ago
I am not convinced that a decentralized solution for a merchant directory is needed. It sounds like a lot of overhead development work for little added benefit. Can't we just use a normal database? Have it owned by the DIF or something.
1 point,2 days ago
I understand your concern. The purpose of having the data stored on Dash Platform is to allow open, "permissionless/trustless" access to the raw data at all times.

By the way, I updated the proposal today. Perhaps it helps to clarify the vision. Thanks for your input.
-1 point,9 days ago
Curated directories don't scale, so we're in a Catch-22. If Dash fails to be adopted, the directory is useless. If Dash succeeds in being adopted, the the directory is unmanageable.

Plus the payment processors are not going to hand over their customer data, so we're stuck with a mom-and-pop directory. BFD.
2 points,11 days ago
I cannot upvote this proposal as it stands. There are too many unknowns and not enough cooperation and coordination with people here that should be involved. Here is what I would like to see...

I would like to see Rion huddle with the DiscoverDash folks and also Andy Freer to figure out if there is indeed a viable product or use case here (not just something for PR or for Matthijs to go on a vacation scavenger hunt). The DD folks already have a directory up and running, and IIR they were planning to do exactly what you are doing. And now that Andy Freer is back, he should be advising you every step of the way.

Then come back with a new proposal.
0 points,10 days ago
In that case I recommend an abstain vote.

I have, in fact, huddled with the discoverdash folks - I offered to work for them to convert the data into a Dash Platform app. They did not act on that offer, and have not acted in response to others who have requested access to the merchant data. Also, will be more than welcome to use the API I propose to build out for their frontend. This project is all about collaboration.

Andy and I have spoken, both publicly (on Dapp Developers Discord) and privately. He is happy to advise the project from a technical standpoint, but remains neutral with regards to proposal campaigning.
2 points,14 days ago
This is something that will definitely be needed in the future and I really like your idea about documenting the process as a template for other developers.

I like a lot of the things proposed here and understand there are many teams looking to do this work. I don’t know your qualifications or team size nor theirs and it would be nice to structure this endeavor differently. I would like to see more of a competition style initiative to build this out rather than just give it all to the first person who puts in a DAO proposal. Not sure the ins and out of how that might work but large projects are done like that often enough that the DIF should be able to put something together in those regards. That would be the most efficient way to get projects like this done. I don’t think there is any hurry and we have plenty of time to think this through and do it properly.

One thing I worry about is the cost and completion timelines, I see no roadmap timelines. I would also hate for us to spend tons of money on this for the community to end up not using it, like Nexus. I could also easily see this project turning into a money pit that never gets finished like Kuva, in fact I see many parallels…

“We would continue to ask for treasury funding until the project can pay for itself.”

At 8k plus a month that could get very expensive just to sit around and do basic maintenance for years after the project has been built. It will take years for this to become profitable if not decades IMO. If this project or others are profitable that would be another reason to go through the DIF and give equity, that is one of the main reasons we set up the DIF.
0 points,13 days ago
Thanks for your feedback, Mastermined. I will update this proposal later today with more detail regarding timeline and future funding requests. I will do what I can to ensure that development efforts are accessible to the wider community to build on top of. So far it seems the scope of work is something people want, and as mentioned in the proposal, MNOs should vote based on what I deliver, not just what I promise to deliver.
0 points,11 days ago
Rion, you are a MNO, why does DC not show the MNO tag for you? I don't believe in general MNOs should be going to the DAO for funds, I won't be supporting this in the first instance.
3 points,17 days ago
I am completely in favor of the concept of having a decentralized merchant directory and running it on dash platform, and if that's all this was, you would easily get my support.

However, the way you just scraped the merchant data from the using an undocumented API without even consulting the folks (to my knowledge at least) is completely unacceptable. Some might even argue that you just doxxed all the merchants.

The merchant listings do not belong to Dash Force nor the DAO (despite ignorant claims to the contrary) but to the merchants themselves. By submitting their data to the website they had to setup accounts so they could manage / update / delete those listings, effectively asserting their ownership and control, and they all (hopefully) consented to this by taking the trouble to setup the account and descriptions or having an agent do it on their behalf.

So what's your plan here? Just take all their data without asking and stick it on a blockchain? This is incredibly reckless.

To re-cap, not everyone is a legal expert, and your heart is probably in the right place, but you need to get consent from the merchants to post that data anywhere (including on github). Fix this, and you will get my confidence and support.
-2 points,15 days ago
Glad you support the general idea of having merchant data hosted on Dash Platform. As I said to geert, we're going to face challenges regarding who owns data, and how that is updated (including deleted). This is a challenge with Dash Platform in general, not just this application/data contract. What do you suggest is the best approach to seeding and maintaining data? I'd appreciate a longer conversation with you about it on the Dash Dapp Developers discord if you are on there. Best place is the #merchant-directory channel there.
1 point,17 days ago
This is a bit tricky. First of all, each vendor should control their own entry, and this means that the service is simply indexing and filtering those records. What happens if someone uses the directory and then pays the wrong entity either out of confusion or because someone has put in a fraudulent entry? Is the service liable legally?
0 points,15 days ago
Right. This is tricky in the same sense that all Dash Platform data is tricky. We'll have to wade through the challenges of who controls data, how is it updated, etc, just like every other Dash Platform app. Fortunately this is one of the more innocuous apps in terms of data sensitivity.
0 points,16 days ago
More thoughts. Please prove me wrong...

Not that long ago, before there was a World Wide Web, there was something called the "Thomas Registry." This was a series of books kind of like an encyclopedia that was published each year. It was simply a directory that listed many thousands of companies that provided various goods and services. You could find it in your local library.

Fast forward to the World Wide Web. The first thing people did was make a directory called Yahoo. It grew and grew and users loved it.

Fast forward to today. There are no directories. People use search engines to find things. My point is that curated directories are obsolete.
0 points,15 days ago
The point here is to have searchable and filterable data. Call it a directory, or whatever, but the main point is to have reliable, accurate, accessible data from which to search, filter, sort, etc. The initial focus is on the backend data structure and updating process. Frontends can compete on the best way to display subsets of the data.
0 points,17 days ago
I like the idea and I think it is absolutely necessary. I'd like to hear some specifics on how you plan to make sure it doesn't turn into another discover dash with tons of bad data that someone has to wade through to find active merchants.

Also how will you parse the discover dash data to find what is actually useful?

Also I'm curious how this can be started on immediately, my understanding of the tools DashCore has released so far are just being able to connect to the DAPI and create usernames, you'll need much more functionality than to build out a merchant directory unless I'm mistaken.
2 points,15 days ago
Regarding parsing data, it wouldn't be just me or any one group. The idea is to allow anyone to be able to help curate the data, and pay them for it. Again, nothing is firmly decided yet, but I have ideas. One possibility is to charge someone to post a listing, or an update to an existing listing. That addition or update would then be sent to an "unconfirmed updates" pool, where other curators could verify the data. As more verifications/confirmations accrue money is sent back to prior curators such that the first curators start seeing profit from their updates rather than losses. There are other ideas. We need to vet these ideas publicly so the best ideas can rise to the top.
2 points,15 days ago
Specifics about data maintenance haven't been decided yet, just a lot of ideas with pros and cons to discuss so far. One initial thought is to allow anyone to upvote (and possibly downvote) a merchant by sending it some Dash. Then lay a Reddit-like algorithm on top of that data to rank merchants. This could either be done as a frontend library that clients could use, or built into the backend (pros and cons to each approach). Anyone could send Dash "to" these merchants, either the merchant themselves or just some happy customer. The Dash wouldn't actually go to the merchant, rather it would go to the platform and the collective group of decentralized curators maintaining the data. But it would go towards giving that merchant a higher or lower "rank" (specifics to be ironed out still). In this approach, "sponsoring" merchants is a thick gray line, rather than a clear black/white divide. Anyone (including the merchant themselves) can "sponsor" a merchant, to any degree. This is just one approach. Join us in the #merchant-directory channel of the Dash Dapp Developers discord to converse with us if you'd like. Would be great to get your ideas.
1 point,15 days ago
Regarding how to start now, there's a lot of work to be done with designing features and architecting the technology to serve them. Right now we already have a functional testnet to start implementing and testing both the technology and the incentive models (see my other replies for details about that). A lot more features are available on DAPI if you set up your own testnet, which I plan to do so that I can start playing around with setting up data structures/contracts.
1 point,12 days ago
Thanks for the thorough replies
0 points,15 days ago
1 point,15 days ago
(this is with regards to the last part of your question)