> If I pay for a good or service via crypto and it is not delivered satisfactorily
In this vague hypothetical situation, what a lot of crypto folk would tell you is that you should use a smart contract, and not a regular transaction, to pay. Hypothetically the contract/network will act as an escrow agent, and would only complete the transaction when all input parameters are true AKA all parties are "satisfied". The successful input parameters and their truth sources would be agreed upon before hand.
I could argue more specific scenarios around fraud (buyer receives a good/service and pretends it was not satisfactory), but that can go on forever and I would encourage readers to go search for answers to specific edge cases because they are out there.
That only works if all "input parameters" involved in the transaction are verifyably on chain. If I'm buying a physical good with crypto there's no way you can write a smart contract that verifies I did indeed get the good I paid for. Oracles don't count because that's just kicking the can to a different level (how do I dispute the oracle saying something happened that didn't).
Exactly. On top of that and the high transaction fees, it's more complicated to do a Patreon like service with Crypto than just work with the imperfect financial systems we have now....
It’s really not that hard to build a Patreon style service on crypto and web3. It’s also far easier to build a new payment processing platform on crypto than it is to build an alternative to PayPal or Stripe.
Many Patreon payments are simple donations, or gated access to digital media. These can be achieved with smart contract functionality to mitigate the need for costly payment processing.
Yes, a theoretical crypto-Patreon would have to be coded in Solidity and frontend interfaces built around it for the web. This might be OSS or just a private enterprise.
But the users of this platform do not need to know how to code.
In this vague hypothetical situation, what a lot of crypto folk would tell you is that you should use a smart contract, and not a regular transaction, to pay. Hypothetically the contract/network will act as an escrow agent, and would only complete the transaction when all input parameters are true AKA all parties are "satisfied". The successful input parameters and their truth sources would be agreed upon before hand.
I could argue more specific scenarios around fraud (buyer receives a good/service and pretends it was not satisfactory), but that can go on forever and I would encourage readers to go search for answers to specific edge cases because they are out there.