Proposal “DashMoney-New-Pay-Contracts-Q4-2024“ (Active)Back
Title: | DashMoney - New Pay Contracts (Oct-Dec 24) |
Owner: | DashMoney |
Monthly amount: | 149 DASH (3234 USD) |
Completed payments: | 1 totaling in 149 DASH (2 month remaining) |
Payment start/end: | 2024-10-08 / 2025-01-05 (added on 2024-10-02) |
Final voting deadline: | in 16 days |
Votes: | 377 Yes / 54 No / 26 Abstain |
Will be funded: | No. This proposal needs additional 2 Yes votes to become funded. |
Manually vote on this proposal (DashCore - Tools - Debugconsole): gobject vote-many c29b0a31c012b98d6ff10068c188c4ed516ec863e4d88f28ca3c5b584355c8dc funding yes Please login or create a new DashCentral account for comfortable one button voting! |
Proposal description
UPDATE (29OCT2024) - 2-Party Pay is available on ProofOfDash.com and ready for testing!
DashMoney - New Pay Contracts and Dash 2-Factor
Greetings, Dash Platform is live on Mainnet. Congrats to everyone!
Before I dive into this proposal, I want to say something about the Decentralized Frontend (DashMoney.io) and Platform Mainnet Launch.
- The Decentralized Frontend was built to test and experiment with Dash Platform, because nothing like Platform has been made before. No one knows the best way to use it. And, I didn’t want there to be nothing on Platform when it launched. The launch was what the Decentralized Frontend was made for. Platform is for using and creating new possibilities. But having said that, in the last several months, I have turned toward a new path. The direction remains the same, “Dash as Money”. But the path is different from the Decentralized Frontend. So I am setting aside the Decentralized Frontend for now, but anyone can pick it up and/or launch it if they like. So if I put something else at DashMoney.io, don’t be alarmed. If you have your 12 words, you have everything. That is all I wanted to say, so onto this proposal and the new path.
As a reminder, my last proposal detailed the different “Approaches” and the use of Proxy Accounts(https://www.dashcentral.org/p/DashMoney-New-Approaches-Q3-2024). Early on with that work I realized, I had presented an incomplete picture.
So to complete the picture of Name Wallets and Proxy Accounts (Dash 2-Factor), I first need to present 2 new ‘Pay Contracts’ (Data Contracts for making payments for market exchanges.)
New "Pay Contracts"
Motivation: Money is medium of exchange. Exchange involves 2 sides. To focus on just “sending” or “payments” is to only look at half the picture. How do we facilitate the entire exchange? The sending of the payment AND the sending of the good/service?
‘2-Party’ Pay – Facilitate transactions between 2 parties who are at a distance that don’t trust each other, but want too. They just need somewhere, they can meet in the middle.
How it works:
- You sign into a Merchant Frontend with your Proxy account. You place an order to the merchant, let’s say for 2.5 Dash. The merchant then accepts the order and sends a payment request to “2-Party” Pay in a Name-Wallet.
- Instead of the customer sending funds directly to the merchant, they form a multisig wallet together! The multisig wallet is a 2 of 2. This is where it gets interesting. You, the customer, send 2.5 Dash to the multisig wallet.
- The merchant can then see in their Name-Wallet that you(the customer) have sent the Dash to the multisig, and the merchant can send the good or service to you.
- And once you receive whatever you have ordered, you sign a multisig TX, so the merchant can then receive the 2.5 Dash.
All this is peer to peer.
Additionally: This is all just push button for the users. (e.g., Send Payment Request (Merchant), Send Dash to 2-Party (Customer), after receiving from merchant, Release Funds (Customer), and finally Receive funds (Merchant). It's straightforward.All this is peer to peer.
2-Party Pay is not restricted to just online exchange, but also for property rentals as well or anything else.
(The version of 2-Party Pay that I intend to implement will be a public version. So TXs are public. There is a version that is more private and looks similar to Dash Pay with encrypted public keys. If there is a large demand for this functionality then more time and money can go into developing the more private version.)
‘Quick’ Pay – to facilitate the quickest and easiest way for a customer to create an order, the merchant accept the order, and then the customer pay the merchant. And its all on Platform, so there is no need for the wallet to finish loading prior to conducting the transaction.
This could be for something small like ordering a coffee or a meal.
User Experience:
You place an order on the merchant’s frontend with your proxy account. When the merchant sees the order, they accept it.
Then you go to your Name-Wallet and go to ‘Quick’ Pay. You see there is an order awaiting payment. You tap the order and hit pay.
What is actually happening: The customer and merchant don’t know that they are using NFTs. It just looks like orders and payment application details.
How it works:
- The customer creates an NFT (Dash Platform Document) with the order data and the Dash Name connected to the Proxy Account, thus creating the order, and then transfers(NFT part) it to the merchant.
- The merchant queries and sees there is an order and accepts it. The merchant is creating a different NFT, which has a price set to match the cost of the order, and has a property that references to the “order” NFT.
- Finally, the customer goes to their Name Wallet and sees an order waiting for payment. This is actually the NFT created by the merchant. The customer is simply purchasing the NFT, and this completes the TX and gives them a receipt.
Additionally:
There is also a version of this where you can designate order-facilitators, so that multiple people can approve orders. This would make not only for quick transactions, but high throughput as well. Or there is a possibility of smart contracts facilitating orders also.
-End of New Pay Contracts-
So what value do these new Pay Contracts offer and how would someone use them?
This is where the Name Wallet and Proxy Accounts become much more interesting.
So for any market exchange to occur, 2 parties in an exchange must meet somewhere. The Approach #2 Frontends using Proxy Accounts are like the public areas where people meet with minimum risk.
So the entrepreneur putting up the frontend and their offerings is a large first step to starting a market exchange.
The customer then has a place they can interact with the entrepreneur. Proxy Accounts allow the customer to then inform the entrepreneur what they want.
Finally, the market exchange can move to the Name-Wallet, and the Name-Wallet is a distinct, neutral software(I think mobile or desktop) that only takes input from Dash Platform, so the customer and entrepreneur can meet as equals, and the new Pay Contracts are how the customer and entrepreneur work together to close the deal.
The “2-Party” Pay and “Quick” Pay need a Name-Wallet. So what does a Name-Wallet look like and how do we get there?
******
So what does a Name-Wallet need:
1) DPNS “Name” Document and Proxy Controller. (Enable/Disable Proxy Accounts).
2) Ways to pay anyone.
3) Integrated ways to make the purchasing and order handling easy for the customer and the merchant.
******
What I did last proposal:
You can visit DashGetPaid.com and DashPayRentals.com to checkout the Approach #2 frontends.
If you want to use them as a customer, you have to sign in with a Proxy Account which you can create on the Approach #2 frontends. But you will need a Name-Wallet, because Proxy Accounts have to be connected to a name:
ProofOfDash.com
(A Name-Wallet prototype implementated to test with, BUT it is not the final goal of the Name-Wallet.. see below step 3)
(A Name-Wallet prototype implementated to test with, BUT it is not the final goal of the Name-Wallet.. see below step 3)
What I plan on doing for this proposal(estimates):
1) Create an implementation of “2-Party” Pay in the Name-Wallet at ProofOfDash.com (1 month)
So you can just send “2-Party” Pay Requests to others and try out.
2) Pull orders placed by Proxy Accounts on other Dash Frontends (DashGetPaid.com and DashPayRentals) into the Name-Wallet and integrate the “2-Party” Pay into the order for ease of use.(2 weeks)
3) Move the Name-Wallet to React Native/Expo. So an Android and iOS App.(No Estimate)
Then going from there:
a) Add “Quick” Pay to the Name-Wallet like “2-Party” Pay. This would require heavy modification to a Approach #2 to actually use, probably would be a new, separate Approach #2.
b) Integrate encrypted messages into the orders in the Name-Wallet. (for shipping addresses, etc)
-In closing, I just want to offer some broader thoughts.-
This new 2-Factor with Name-Wallets and Proxy Accounts, say a dapp were developed as an iOS or Android app, you could easily use the Proxy Accounts for that too.
Dash 2-Factor allows for any developer to create an application that any user can login to with minimal risk, even if the most malicious operator were to run a website/mobile app the only thing that they could get is the proxy account with about 0.02 Dash of value. And a real merchant would value their reputation much more, and the internet would spread the information of a malicious actor quickly.
Dash 2-Factor is directly competing with a MetaMask-like approach, and I believe Dash 2-Factor is far superior. There is no 3rd Party API and 3rd party servers needed, you use Dash Platform directly for both sides of Dash 2-Factor. No Consensys is needed, it is completely disintermediated. And the data contract for Proxy Accounts is dead simple.
I think the path forward for people building on Dash Platform is developers creating frontends/mobile dapps and getting others to use them. So I will briefly describe 3 types and their different capacities
Opening Web3 Possibilities:
- Full Platform – Inventory, Orders, and Payments like DashGetPaid and DashPayRentals (Requires Name-Wallet and Proxy Accounts) With full Platform usage, if a premade Dash Frontend fits a entrepreneur’s use-case, they can get started very quickly.
- Order and Payments – Inventory is maintained by the merchant, so they have their own backend. Proxy Accounts are still used to place orders and the payments are done in the Name-Wallet. (Requires Name-Wallet and Proxy Accounts) I see this as where “Quick” Pay could be used more.
- Payments Only – the merchant handles the inventory and orders on their own backend and the only thing you need to do is add your Dash Name to the order. (Requires Name-Wallet Only) This may be the fastest way to get people who already have online stores to accept Dash. I see this as using more “2-Party” Pay.
-
-
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
No comments so far?
Be the first to start the discussion! |
I think the multisig is certainly needed and thus this gets a YES from me, however, I'd love for you to start considering wallet reputation, As online sellers like to filter out problematic customers also, and a way for a jointly trusted 3rd party to send their acceptance for an 'ajudicator' to decide on their behalves for a small fee, this could also be a timed parameter of the multisig/smartcontract I guess? For example if the funds are not unlocked within 4 weeks, they will be sent to ajudicator 'CRYPTOSI' along with adjuicators website where the next steps can be taken (uploading evidence etc)
Finally, also sellers may be worried about excluding huge numbers of customers by opening up to DASH and not the rest of the crypto ecosystem, are there any ways to have some sort of in payment cross chain exchange, I understand this is a WILD request, but how do you see something like this working out?
Thanks for all of your hard work, please keep it up!
There really isn't anything like 2-Party Pay that I know of in crypto. The questions you raise are warranted.
To be clear for this version, this is like a wallet that you and some other person on the internet have full control of, so you both have to agree. There is no 3rd party to override or decide what happens.
I dislike building for 3rd party solutions, but most of the dispute issues could be settled with smart contract functionality.
1) Buyer forgets to release funds after receiving the goods.
This could be as simple as an expiration smart contract, so that if the buyer doesn't dispute in a month or two. The smart contract just sends the funds to the merchant. (Not really a 3rd party, so this would interest me to build.)
2) What if there is a genuine warranted dispute.
(WITHOUT SMART CONTRACT) This is true peer to peer payment. Lets say someone stole the goods off the mail truck, the buyer didn't get it but the sender did send it. The funds would just stay in the 2-Party. Sometimes things do go wrong. The merchant should have a policy.
(WITH SMART CONTRACT) I won't get into ajudicators or arbitrators, but if you can build it with a smart contract, you could use that to control the 2-Party. People can build whatever they want. (I guess then you would need to call it "3-Party")
3) What about wallet reputation?
So I do have the Reviews dapp, where you can write reviews about others in the decentralized frontend. I could include it in the Name-Wallet.
It is simple, but I find a reputation system to be the best path forward. I think people are most likely to resolve issues sensibly if they know that both people have reputation involved. Also it's a decentralized, open reputation system that runs on Platform. People could create multiple accounts and try to manipulate it, but they would have to pay credits and no one has central control of it.
Lastly, about the rest of the crypto ecosystem. 2-Party Pay really shows just how special Dash Platform can be. 2-Party Pay involves searching with DAPI to see the TX on Core for the participants to verify, and because the coordination data is stored on Dash Platform, the only place that this 2-Party Pay takes place is in the browser/mobile app of the users and on the Dash Network(Core and Platform).
Any other crypto ecosystem would require the participates to run nodes of the chain to verify TXs.
I plan to release the first testnet version by the middle of next week. I will post on discord to let everyone know when that happens, so they can try it out.
This first version has all public data which is not all bad as it could be used in validating a user's reputation. But a private version of this that functions similarly to DashPay is also possible. It is more involved.
It could also be possible to form complex TXs so that perhaps if there were a need to you could create a TX that pays out 50:50. Instead of 100%.
But I think people need to incorporate more than just one strategy and I will outline a few.
Let's say a customer says the goods were damaged or just don't work. A merchant could suggest that they release the funds from the multisig, and they will resend a new item. As most transactions should work this should end satisfactorily. The customer should get a satisfactorily result, and the merchant recoups most of the transaction.
I think most of the problems will arise with brand new users with no purchase history. There should be limits on how much risk a merchant extends on a order for an unknown purchaser. The merchant may say nothing costing more than 1 Dash. OR They may require a greater 2-Party amount say 120% of the total cost just to help ensure that the customer is not trying to defraud them. Once the exchange has occurred satisfactory the merchant can refund the extra 20%.
This really all needs to be discovered in the free market, but there are many possibilities.
>You sign into a Merchant Frontend with your Proxy account. You place an order to the merchant, let’s say for 2.5 Dash. The merchant then accepts the order and sends a payment request to “2-Party” Pay in a Name-Wallet.
>Instead of the customer sending funds directly to the merchant, they form a multisig wallet together! The multisig wallet is a 2 of 2. This is where it gets interesting. You, the customer, send 2.5 Dash to the multisig wallet.
>The merchant can then see in their Name-Wallet that you(the customer) have sent the Dash to the multisig, and the merchant can send the good or service to you.
>And once you receive whatever you have ordered, you sign a multisig TX, so the merchant can then receive the 2.5 Dash.
And for what damned reason, we have to use Evo names instead of simple Dash addresses, in order to follow the above protocol?
Evo is a stupidity. Thats all.
This Data Contract is expanded upon when using Proxy Accounts, as the orders placed on other Dash Frontends can have "2-Party" Pay integrated directly into the order for the users for ease of use.
STUPIDS!
Vote the numbers!