Zoe is our new platform that provides an innovative, much safer approach for building and interacting with smart contracts. Elsewhere we talk about “offer safety” in Zoe: the assurance that on payout, a client of a contract either gets what they want or gets a refund. Here, I’m going to dig into another feature of Zoe, “payout liveness” (also referred to as “exit safety” in early presentations), in which the system ensures that a payout happens, independent of misbehavior of other clients or the contract itself.
Zoe will payout an offer after the offer exits. There are three participants, each triggering an exit in different ways relative to their role:
Contract Wants Out: The contracthas satisfied or rejected the offer.
Client Wants Out: The client who submitted the offer wants out.
System Error: The system terminates the target contract due to e.g., an error.
The payout liveness assurance is that, once the exit of an offer is triggered, Zoe ensures that the payout of that offer will be made promptly, no matter what the contract code does at that point. No misbehavior, crash, etc. of a contract can prevent the payout to contract participants.
Contract Wants Out
The simplest scenario for exiting an offer is that the contract triggers it: the contract can always and for any reason trigger the exit of any offer to the contract. For example, an auction may directly satisfy the offers from the seller and the highest bidder, and refund all the other offers. To accomplish this, it swaps the goods and the appropriate funds from the highest bidder (using reallocate), and then triggers the exit of all offers. Zoe will then ensure that the payouts (winnings and refunds) are delivered.
Zoe ensures the payout liveness: once the contract triggers the exit of an offer, Zoe will allow no further reallocation of the offer’s assets, and the offer will be paid out, independent of any future behavior of the contract code. Since Zoe only ever allows reallocations of the offer’s assets consistent with the offer’s constraints, the offer payout will necessarily preserve offer safety.
Client Wants Out
A client’s request to exit an offer has more options. Each offer includes the terms under which the client may exit it. A client that makes an offer gets the authority to exit that offer, subject to the included terms. There are three cases initially supported that support a broad range of use cases:
onDemand:
The client can exit the offer at any time.
afterDeadline:
The offer automatically exits after a deadline.
waived:
The client cannot exit the offer.
The onDemand Case
In the onDemand case, when the client that made an offer requests that it be exited, that request goes directly to the Zoe infrastructure of the contract, and not to the contract code. The Zoe infrastructure acts on the request promptly, and the contract code can never obstruct its execution.
It is important to note that the client’s exit request does race with the normal progress of the contract. In an example auction, a bidder may try to withdraw their bid just as the gavel comes down. As noted above, Zoe only ever allows reallocations of the offer’s assets consistent with the offer’s constraints, so the offer payout will contain either a full refund or the winnings resulting from the successful reallocation.
The afterDeadline Case
With the afterDeadline case, a client can make an offer in which the associated assets are committed until the deadline. For example, if a seller wants to make a covered-call option (the right to buy an underlying asset at a fixed price before some future time) with an expiration date of next Thursday, Zoe must credibly lock up those assets until next Thursday — but after next Thursday, the seller gets them back unless the covered-call was actually exercised.
Similarly, an auction might require that sellers be willing to list their auction for at least a day. In that case, the sellers in the auction would submit offers with a deadline of a day. In such cases, the contract itself may specify that it only accepts offers with deadlines after a certain date, and automatically trigger the exit (and thus refund) of offers that expire too early.
Time References
A crucial question in defining deadlines is “the time according to whom?” Zoe deadlines are always with respect to a time reference. This doesn’t have to be half past midnight in Greenwich Mean Time. The reference might be block height, or it might be the time on the Clock of the Long Now; the specific reference doesn’t matter, so long as it is a reference that the contract and the participants in the contract understand and have agreed on. A clarifying example is that a contract on one chain might use as a time-reference the block height of a different chain (e.g., because the assets being transacted come from that other chain).
Events
Though not currently supported, this case generalizes to supporting exit upon events. For example, the appropriate event reference could trigger exit for an offer after a token’s price exceeds a specific dollar figure on a particular exchange. These kinds of events could be very useful for DeFi smart contracts.
The Waived Case
Then third there’s the Waived case, in which the client visibly gives up their ability to exit. This is like posting an item for auction without a reserve price: participants can see that the offer is committed until the contract satisfies or rejects it.
System Error
The final scenario is when the system detects an irrecoverable error and terminates the contract’s execution, for example if the contract divides by zero, uses too many resources, loops infinitely, etc. Zoe is designed to provide payout liveness even in this extreme circumstance. When the contract is abruptly terminated, Zoe detects the termination and triggers the exit and thus payout of all offers. As with other scenarios, Zoe only ever allows reallocations that were consistent with the offer constraints, and so offer safety is preserved. We all go home, and everyone’s happy. Or, at least all the clients are happy because they got offer safety, and they got it executed right when there was a failure, rather than getting stuck in limbo waiting to be paid back. (Note: this protection feature is designed but not yet implemented in our testnet.
What’s to Come
We’ll highlight more details of Zoe’s unique features in the future. Next you might want toread the code and the documentation, and perhaps even install Zoe:
npm install @agoric/zoeEnjoy!
