Hi. When I pondered atomic swaps I thought about them being implemented as off-chain contracts that the receiving party can optionally execute on-chain… “Options”. On chain would also be awesome too, definitely wouldn’t rule it out but it feels way more complex and harder to get right. Anyways… Just food for thought my comments are below.
Think about them as options also open up the idea that a failed execution of an option could trigger another action (e.g. think insurance).
Also, conditional options should be a thing.
It wasn’t my intent but now that I think about it stacking options in this way is kind of like an off-chain smart contract . What other features might we need to support this off chain Turing machine
. The more I think about it the more I likey
!
Edit
From an implementation perspective we could pass the contracts/options around in JWTs, CWTs, and/or ZWTs. There are a couple of benefits I see here:
-
The options receive all the privacy features of a memo but are only optionally executed by the receiver. I assume ZWTs are simply CWTs that only need to store the payload as they rely on the underlying cryptographic properties of the memo. The main reason I call them ZWTs is because the APIs and terminology would match and there would be a clear/clean conversion between JWTs, CWTs and ZWTs.
-
ZWTs don’t exist yet but the benefit here is if the memo field is big enough for V1 but not big enough for future complex claims then that work could be offloaded to the others to solve.
-
If we want more complex system such as on-chain exchanges then the problem that needs to be solved is simply making some memos optionally transparent (and possibly labelling/categorising them). The ZWT memo stays the same we just allow a special kind of transaction that’s transparent. Again, optionally could be offloaded to other teams.