Unfulfillable offer pattern #7274
-
Having experienced the convenience of Zoe and Offer-safety for smart contract development, I find myself attempting to use it whenever possible. But one particularly common use-case requires using offers in a way that (at least to me) feels "hacky". I want to start a discussion around the pattern and tackle the following questions:
Use-caseAllow users to prove ownership of ERTP assets to a smart contract while being certain the contract won't take the assets from the user Current limitationsFrom a user's pov, escrowing assets on Zoe using an Offer implies the intention of giving them away, but in this case the user wants only to show them. One way to go about it would be to match the Current workaroundInstead of requesting the same assets back in the offer's Security ConsiderationsIf the offer were to be set up to disallow users from exiting, the assets could be locked up in Zoe ThoughtsAlthough the workaround works well per my testing, it feels like I'm using offer safety in a way that it wasn't meant to be used, and adds overhead when explaining why you would form an offer in such a way. It would be nice if on top of an offer's I'd love to hear your thoughts on this |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
We have explicitly talked about this possibility ( In order for this to be helpful, a contract would have to be written to expect that it should assay the want, but not expect to reallocate it. Contracts set up this way might experiment with different ways of expressing the unmatchable We experimented with similar techniques (assaying goods) in order to support voting schemes based on ownership of shares. For voting, we also wanted to ensure that only one vote could be cast per share, but there are probably cases where repeated use of the same asset don't matter as much. |
Beta Was this translation helpful? Give feedback.
-
I've advocated the current pattern in a few cases, but another limitation is that you cannot have a thing that you show, while then allowing a reallocate among give/want. The However an important limitation of Two notes wrt the security consideration:
|
Beta Was this translation helpful? Give feedback.
-
Great! Glad to hear this would be an acceptable use of offer safety. The voting scenario is also interesting, maybe I can explain our use-case for some context. We would like to use nfts to grant access to private content, here's a draft of the intended flow:
There are two places where this pattern would be useful in this scenario:
For this use-case we want to use nfts as you would a physical key, meaning a single key can only be used in one place at once, yet there is no limit to the amount of times it can be used. Should the content owner want multiple users to access the content simultaniously, they would need to register multiple keys (nfts) |
Beta Was this translation helpful? Give feedback.
We have explicitly talked about this possibility (
{ want: 3 unobtanium }
) and it seems perfectly reasonable.show
is a plausible alternative, but one we hadn't contemplated before.In order for this to be helpful, a contract would have to be written to expect that it should assay the want, but not expect to reallocate it. Contracts set up this way might experiment with different ways of expressing the unmatchable
want
. They might have their own issuer that allows amounts but never mints anything, or they might just ignore thewant
and leave it up to the client to create a relevant mint.We experimented with similar techniques (assaying goods) in order to support voting schemes based on …