4 ms·

If I want to send money to someone via square cash, they have to have the square cash app. Same with Venmo, and PayPal, and everything else... Venmo and PayPa

by beaner 8y ago

If I want to send money to someone via square cash, they have to have the square cash app. Same with Venmo, and PayPal, and everything else... Venmo and PayPal are even owned by the same company. Have you ever asked why they're not interoperable? The ACH system underneath links all US bank accounts, but it's so slow and burdensome that private companies need to build apps on top of it that abstract away all of its problems. None of them work together because regulation makes the operation of money so difficult that you need an entire company to run such an app, and they're all walled gardens applying their own versions of KYC/AML. When you have a unified protocol, all of that melts away and the opportunity for money to have a higher velocity and greater ease of use is upon us. This is what blockchain, and in this case USD Coin based on it, provide. It seems silly to me that such a system would not become popular. Interoperability and protocols are good. They are something HN is typically in love with. When google tried to remove basic support for one protocol for contacts from Gmail, people were up in arms because it broke interoperability. Imagine being in that world with money. I don't know why you wouldn't want it. It's superior by all measures. And it would be silly for anyone in that world to create a wallet that didn't support such currencies. It would be like creating an email client that only lets you read email from other users of the same service. That's not email, that's just a private messaging platform. I think you have to look towards the future and see how, if adopted, things like this would make money easier to use. Rallying against that is silly indeed.

JumpCrisscross 8y ago
> ACH system underneath links all US bank accounts, but it's so slow and burdensome that private companies need to build apps on top of it that abstract away all of its problems ACH is for cheap, remote batch transfers. Fedwire is for real-time, remote transfers. Cash is for cheap, real-time, in-person transfers. (FX exchanges, as centralized databases, are faster and safer than stablecoins.)
- beaner 8y ago
  A system which makes no distinction between any of these use cases and treats them all the same sounds very appealing to me.
  - JumpCrisscross 8y ago
    > A system which makes no distinction between any of these use cases and treats them all the same sounds very appealing to me It's a bad compromise. If you want the cheapest transfers, you batch them. (This is the logic of Lightning.) If you want the most reliable transfer, you wire it. If you want to be sneaky, you use cash. (There are other reasons to use these modes.) Batching being cheaper and slower than RTGS is fundamental to payment economics, irrespective of whether in an electronic database, armored car or blockchain. I go into this in a comment from about a year ago [1]. [1] https://news.ycombinator.com/item?id=16154956#16155708 https://news.ycombinator.com/item?id=16154956#16155708
    - beaner 8y ago
      That modern economics has programmed in accountability for slow, large payments doesn't mean the system wouldn't be better off if it changed.
      - JumpCrisscross 8y ago
        > That modern economics has programmed in accountability for slow, large payments doesn't mean the system wouldn't be better off if it changed It's more fundamental than accounting. If a transaction costs X, aggregating N transactions into a single transaction reduces the per-transaction cost to X/N. The latter, batched process will always be slower and cheaper than the former. (If a transaction costs Y%, aggregating bilateral transactions allows for "netting out," thereby reducing costs while increasing latency. For example, suppose Bank A sends Bank B $10, Bank B sends Bank A $5 and the Bank B sends Bank A $2. Real-time systems would see 3 transactions of $17. Net-settlement systems would see as few as 1 transaction for $3.)
        beaner 8y ago
        Payments are generally batched because individual payments are slow and/or have restrictions applied, like time of day they can be sent or received, which are easier to reason about when aggregated. If you remove these burdens by having a technology that is cheap and nearly instant for all payments, then there's no real need to batch. We're not quite at cheap + instant with crypto, but there's nothing preventing it in principle. And when we get there, there's no reason batching needs to continue to be part of the equation, at least not with the same tradeoffs.
arcticbull 8y ago
Venmo and Cash use push-to-debit, which is instant, and fall back on ACH only if the bank you use doesn’t support it. There’s your common unified protocol.
- beaner 8y ago
  How is that a common unified protocol? I can't send between the apps. Additionally, I need a debit card or bank account to use them at all. With crypto, you don't.
- arcticbull 8y ago
  @beaner. Come on. Where will you get your Crypto from if you don’t have a bank account and debit card? The common protocol is that they both link to your bank account (“wallet”).
velosol 8y ago
Zelle works quite nicely between (bank) apps and has been as fast as Venmo etc in my experience (in the US). https://www.zellepay.com/ https://www.zellepay.com/ I think the interoperability is nearly solved for the quick transfer world as well. Cross-border is solved through remittance schemes as mentioned up/down thread.

by beaner 8y ago

JumpCrisscross 8y ago

> ACH system underneath links all US bank accounts, but it's so slow and burdensome that private companies need to build apps on top of it that abstract away all of its problems ACH is for cheap, remote batch transfers. Fedwire is for real-time, remote transfers. Cash is for cheap, real-time, in-person transfers. (FX exchanges, as centralized databases, are faster and safer than stablecoins.)

beaner 8y ago
A system which makes no distinction between any of these use cases and treats them all the same sounds very appealing to me.
- JumpCrisscross 8y ago
  > A system which makes no distinction between any of these use cases and treats them all the same sounds very appealing to me It's a bad compromise. If you want the cheapest transfers, you batch them. (This is the logic of Lightning.) If you want the most reliable transfer, you wire it. If you want to be sneaky, you use cash. (There are other reasons to use these modes.) Batching being cheaper and slower than RTGS is fundamental to payment economics, irrespective of whether in an electronic database, armored car or blockchain. I go into this in a comment from about a year ago [1]. [1] https://news.ycombinator.com/item?id=16154956#16155708 https://news.ycombinator.com/item?id=16154956#16155708
  - beaner 8y ago
    That modern economics has programmed in accountability for slow, large payments doesn't mean the system wouldn't be better off if it changed.
    - JumpCrisscross 8y ago
      > That modern economics has programmed in accountability for slow, large payments doesn't mean the system wouldn't be better off if it changed It's more fundamental than accounting. If a transaction costs X, aggregating N transactions into a single transaction reduces the per-transaction cost to X/N. The latter, batched process will always be slower and cheaper than the former. (If a transaction costs Y%, aggregating bilateral transactions allows for "netting out," thereby reducing costs while increasing latency. For example, suppose Bank A sends Bank B $10, Bank B sends Bank A $5 and the Bank B sends Bank A $2. Real-time systems would see 3 transactions of $17. Net-settlement systems would see as few as 1 transaction for $3.)
      - beaner 8y ago
        Payments are generally batched because individual payments are slow and/or have restrictions applied, like time of day they can be sent or received, which are easier to reason about when aggregated. If you remove these burdens by having a technology that is cheap and nearly instant for all payments, then there's no real need to batch. We're not quite at cheap + instant with crypto, but there's nothing preventing it in principle. And when we get there, there's no reason batching needs to continue to be part of the equation, at least not with the same tradeoffs.

arcticbull 8y ago

Venmo and Cash use push-to-debit, which is instant, and fall back on ACH only if the bank you use doesn’t support it. There’s your common unified protocol.

beaner 8y ago
How is that a common unified protocol? I can't send between the apps. Additionally, I need a debit card or bank account to use them at all. With crypto, you don't.
arcticbull 8y ago
@beaner. Come on. Where will you get your Crypto from if you don’t have a bank account and debit card? The common protocol is that they both link to your bank account (“wallet”).

velosol 8y ago

Zelle works quite nicely between (bank) apps and has been as fast as Venmo etc in my experience (in the US). https://www.zellepay.com/ https://www.zellepay.com/ I think the interoperability is nearly solved for the quick transfer world as well. Cross-border is solved through remittance schemes as mentioned up/down thread.