This is exactly why this is an OTX protocol in the context of CoBuild. We are not designing a a standalone OTX, we are first introducing CoBuild, on top of it, we designed the OTX protocol.
If you look closer at the new Otx
structure(which will live in a witness), it actually has a Message
field, which is exactly the same Message
field defined in CKB Transaction CoBuild Protocol Overview.
This Message
field can then be used to provide those intents
in your discussion. For example, a DEX user can build an OTX containing for example 1000 USDT in exchange of, say, 1020 USDC. There are 2 ways to build the OTX:
- An output cell containing 1020 USDC can be put in the OTX directly to express the intention of the OTX
- For an AMM DEX(orderbook based DEX can also be designed this way but let’s simplify the discussion a bit), a user can create an OTX containing only an input cell of 1000 USDT, the user can insert a special
Action
for a particular AMM type script in theMessage
field. This veryAction
can contain information required by the AMM, such as slippage or sorts. Note this OTX now contains anAction
which do not have a matching type script in current OTX, but CoBuild validation rules require that allAction
object will have matching type script in the fully assembled CKB Transaction. This way, one can count on an AMM type script be present, which will handle validation logic for all the included OTX.
I think this would provide an answer to the issues raised here. By leveraging Action
as intents, we can also handle situations like partial fulfillments in DEX.