See #8745 PR comment for best current explanation. In general, if holding an object confers valuable rights to do things, making those objects into ownables may usefully make that value ownable and thereby exclusively tradable, if
the right is cleanly revoked by denying access to the object
the object's own description of its state at that time is adequate for invitation legibility, i.e., that it can be used in a proposal want pattern to express a right that is meaningfully wanted.
https://github.com/Agoric/agoric-sdk/pull/4080 explains a plan to refactor the essence of Zoe to have a separable escrow service into a new Zoe2 design. As applied to current Zoe, we can think of the result of making an offer as creating two distinct bundles of rights:
UserSeat: The right to collect the outcome of the offer, with guaranteed offer safety + the right to request exit, subject to the offer's exit terms. This is already represented by the UserSeat. Making the UserSeat into an ownable means that the right to collect the outcome becomes exclusively tradable. As a tradable asset it has much in common with trading the right to collect on a loan -- where the outcome will be either the lent amount or the collateral as of the deadline, where someone else (the borrower) is in control of which one. If the offer's want is unsatisfiable, this degenerates into a covered-call option.
ZCFSeat: The right to determine how a live offer resolves, subject to offer safety + the right to exit the offer at any time. This is already represented by the ZCFSeat. Making the ZCFSeat into an ownable means that the right to determine the outcome, initially exclusively held by the contract, can be transferred by the contract to other contracts that might better satisfy the offer. This lets the first contract act as a router, routing the offer to the place it is likely to be best satisfied. Unlike offerTo, such order-routing does not have to duplicate the escrowed give amount, avoiding the capital costs of our current offer-delegation mechanism.
It is interesting to compare this with "intents", which also try to provide offer-safety constrained order-routing, but without the expressiveness of interacting with behavioral contracts along the way. Hopefully, we can bridge between these two worlds, giving each a window into the other.
https://github.com/Agoric/agoric-sdk/pull/8745 defined Ownables, implemented at https://github.com/Agoric/agoric-sdk/blob/master/packages/zoe/src/contractSupport/prepare-ownable.js with expository example at https://github.com/Agoric/agoric-sdk/blob/master/packages/zoe/test/unitTests/contracts/ownable-counter.js . This is designed so that we can often retrofit existing exos to be ownables.
See #8745 PR comment for best current explanation. In general, if holding an object confers valuable rights to do things, making those objects into ownables may usefully make that value ownable and thereby exclusively tradable, if
wantpattern to express a right that is meaningfully wanted.https://github.com/Agoric/agoric-sdk/pull/4080 explains a plan to refactor the essence of Zoe to have a separable escrow service into a new Zoe2 design. As applied to current Zoe, we can think of the result of making an
offeras creating two distinct bundles of rights:UserSeat. Making the UserSeat into an ownable means that the right to collect the outcome becomes exclusively tradable. As a tradable asset it has much in common with trading the right to collect on a loan -- where the outcome will be either the lent amount or the collateral as of the deadline, where someone else (the borrower) is in control of which one. If the offer'swantis unsatisfiable, this degenerates into a covered-call option.ZCFSeat. Making the ZCFSeat into an ownable means that the right to determine the outcome, initially exclusively held by the contract, can be transferred by the contract to other contracts that might better satisfy the offer. This lets the first contract act as a router, routing the offer to the place it is likely to be best satisfied. UnlikeofferTo, such order-routing does not have to duplicate the escrowedgiveamount, avoiding the capital costs of our current offer-delegation mechanism.It is interesting to compare this with "intents", which also try to provide offer-safety constrained order-routing, but without the expressiveness of interacting with behavioral contracts along the way. Hopefully, we can bridge between these two worlds, giving each a window into the other.