Lewiscowles1986
commented
2 years ago In both flows, the PFI is the entity with the privilege to interact with the contract, so it either transfers or withdrawals funds (I do not see any mention of the User being able to do this).
Its worse. The regular user becomes the untrustworthy agent of the PFI, which I'm fairly certain shifts risk onto the regular user for wrongdoing, insulating a bad-actor PFI.
Hi yall, the white paper suggests some asymmetry of risk between regular users and PFIs that merit discussion.
The paper clarifies that the protocol will be permissionless with regards to who can be a PFI. That means anyone, including bad actors, can become PFIs. Given this, it makes sense to think about PFIs as a threat vector.
So just a couple of observations:
These observations suggest that PFIs are freely able to a) receive fiat funds without triggering the on-ramp contracts transfer-method or b) trigger the Users' off-ramp contracts withdrawal-method without transferring the fiat. So in both directions, the User is at a disadvantage with regard to transaction risk.
The off-ramp example acknowledged User transaction risk but not in the on-ramp example. We should clarify this as a holistic problem.
The paper does suggest that a "bank-monitoring oracle" could be a solution to this. A service like Plaid would be a well-positioned company to play that role as they are already a trusted third party used for this purpose. The smart contract would become a full escrow in that case. Is that the right idea? If so, what would the incentive structure look like for the oracle? How would bank account monitoring be decentralized? Wouldn't that be a potential security hole/data leak for the User? How does the User benefit in this scenario over a centralized exchange (doesn't this feel like a "centralized intermediary and/or trust broker")?
Suppose we ditch the "bank-monitoring oracle" and focus solely on the 2 point transaction (user <-> PFI), and we lean hard on the whole reputation system. The User needs to "trust" the PFI based on their reputation rating and accept that they have all the power in this transaction. In that scenario, the need to have a smart contract at all is questionable. Presumably, Users and PFI's would have a public blockchain address that makes the availability of crypto funds apparent. Since the User needs to trust that the PFI will follow through on the fiat side in either use-case, the smart contract does not fulfill a purpose for either counterparty. For on-ramps, the PFI can wait for the fiat to be received to initiate the crypto transfer, and for off-ramps, they wait for the crypto to initiate the fiat transfer. So why is a smart contract necessary?
Relying on a bank-monitoring-escrow-oracle or a reputation system seems like two very different directions for the design of this protocol. Any thoughts on where this should go?