|
|
|
|
|
by cadillion
1827 days ago
|
|
Good question, we've answered a couple times in this thread already, so please forgive the copypasta: You are correct, for this smart contract to work you need defined rules around how the money is released should either party falsely claim success or failure, so you need to rely on automation or some third party to validate fulfillment of the contract. So you're back to an oracle problem, how do I know I can trust the validator? The nice advancement here is that anyone can be that third party! Your smart contract can explicitly identify a third party for multisig, or you can rely on a validator pool of mechanical turks instead of a licensed escrow agent, and accordingly the cost of escrow can decrease. The nice part is that this is customizable, and built into the very rails that move money. It's a much lower barrier to entry than trying to build something like that for ACH, and that's what excites us about cryptocurrency. |
|
With DLT it seems trust and predictability is virtually the same thing. "Everybody loses everything" is predictable but not efficient. DLT is a proposal for efficiency.
We need to automatically negotiate contracts or we shift all the cost of fixing it later in courts up front. There will have to be a lot of smart defaults for the contracts to be smart, and very deep integration of tech so that the algorithms can be fed with enough data to negotiate in a very high-dimensional space. That requires infrastructure, but the DeFi culture does not seem to be interested in funding infrastructure.