Limited Risk from Bad Issuers

Limited Risk from Bad Issuers

Zoe's guarantees of offer safety are only meaningful when the issuers of the assets in question are well behaved. The participants in a Zoe decide for themselves what issuers they assume are well behaved. If the moolah issuer behaves arbitrarily badly, the notion of offer safety for moolah assets is meaningless anyway. The participants who have chosen moolah have chosen badly, and Zoe provides no meaningful protection of their moolah from their bad choice.

However, Zoe itself does not rely on any of these issuers being well behaved. Zoe will still enforce offer safety for all offers involving only well behaved issuers. Despite #1271 I believe that Zoe already enforces payout liveness for offers involving only well behaved issuers. This should be true (and I believe it is true) even if bad issuers are involved in the contract as a whole. An offer that does not directly mention a bad issuer will still have offer safety.

What #1271 is about is the mixed case: For an offer that involves both well behaved and badly behaved issuers, what guarantees should Zoe still provide for the portions of the offer involving the well behaved issuers? #1271 makes a strong assumption about what payout liveness guarantees Zoe should provide for such mixed offers, and points out that Zoe does not yet provide those guarantees.

The corresponding offer safety question is interesting and unexamined. Currently, Zoe enforces partial offer safety for such mixed issuers. I believe this partial offer safety is meaningful for multi-good offers --- as long as there are any well behaved issuers on both sides of the proposal. However, we have not yet stated these partial offer safety guarantees.

This all gets interesting when we try to formalize offer safety and payout liveness, and then try to verify that Zoe enforces it under stated conditions. In fact, the motivating problem of Reasoning about Risk and Trust in an Open World is exactly the precursor to this problem --- what guarantees does the escrow exchange agent of Distributed Electronic Rights in JavaScript provide, given that the participating issuers might be ill behaved? I think the risk-and-trust paper's approach will apply directly to Zoe's offer safety. However, the approach of that paper makes no contribution towards reasoning about liveness.

To one Zoe, another Zoe is simply an untrusted issuer of alleged invites; no different that any other untrusted issuer participating in the first Zoe. When Fred uses a swap on Zoe A to try to pay Alice with M for a covered call on Zoe B, where the covered call is an option to buy X in exchange for Y, Fred's guarantee that he would get what he thinks he's buying depends on issuers A, M, B, X, and Y all being well behaved. And on Zoes A and B each being well behaved as a Zoe in addition to being well behaved as an issuer. And on the swap contract meaning what Fred thinks it means. And on the covered call contract meaning what Fred thinks it means. A,M,B,X,Y might each be running on a different chain. Fred's assumption that any one of these is well behaved also assumes that the chain it runs on is well behaved.

What if Fred does not assume he's understood either the swap contract or the covered call contract, but still makes all the other assumptions? Offer safety and payout liveness bound his risk. He doesn't know what he's actually getting in exchange for M. But if he then exercises the alleged option, trying to buy X in exchange for Y, he knows he won't lose his Y unless he gets X. Of course, if he doesn't get X, he wasted M. After offer safety and payout liveness, this is Fred's residual risk in the meaning of the contracts.

Long term, one of the reasons we desperately need formalism is to ensure that we've fully enumerated all of Fred's reliance assumptions. The secure UI challenge is to help Fred avoid actions that unknowingly exceed his actual reliance assumptions, even though these are mostly tacit.

See discussion at https://github.com/Agoric/agoric-sdk/pull/2016#discussion_r537892876 for a subtle form of this issue.