I was wondering, Iet’s say I need to release a new token standard WUDT that wraps other tokens to have additional functionality such as “for each output cell with WUDT, it's corresponding lock will be spawn for additional validation”.
Output Cell : { type : WUDT, lock } ← Idea: spawn this lock for every WUDT output cell
At this point WUDT args determine which other token is being wrapped by including the underlying UDT type hash as args, so the underlying token becomes the owner of WUDT.
Different args means different WUDT
At this point, each WUDT metadata is very similar to its Underlying UDT, for example:
UDT name: iCKB becomes WiCKB
UDT symbol: iCKB becomes WiCKB
UDT decimals are the same
UDT icon is the same
Question: Could you propose how should the SSRI UDT metadata being handled by this hypothetical WUDT?
Suggestion: Feel free to propose a solution for when the Underlying UDT is legacy (most current tokens) and then focus on what should actually happen when wrapping an actual native SSRI UDT.
Note: this is a hard problem, no kidding, even more since the solution being worked on, @ckb-ccc/udt, may or may not help in this scenario. In general, I’m interested in SSRI composition and WUDT is such an example
In this case you can just implement the “verify_transfer” and “verify_mint” to spawn the lock verification, as well as the metadata interfaces as you wish in the UDT trait since SSRI does not limit the actual logic.
In your specific case, the issue comes from the fact that iCKB as an xUDT doesn’t come with the metadata in itself but I remember you used a metadata cell, so you can implement the metadata interfaces by referencing to (and also requiring) the metadata cell from cell_dep. The bindings might be tricky but there should be a way to do so either like hardcoding it in the args as well (referencing to the initial transaction might be another one but it might be less intuitive).
I think in this way you can wrap your iCKB in WiCKB, or even you can release a new UDT contract that can wrap any form of UDT with a specifications on the structure of args, all thanks to SSRI, but there’s no need to release a new token standard and demands more global effort since SSRI can facilitate all kinds of action while the expected behaviours might be different for all forms of wrapping: e.g. Your wrapping is more specific to your need of spawning lock as well, but for example, WBTC is just wrapping BTC into ERC-20 while WCKB is just expecting capacity=udt amount.
With regards to ccc, it would treat your WiCKB as a new SSRI-compliant token, and not in need of using the compatibility module (since WiCKB should have its own SSRI implementation)
As for the lock/type issue, in my understanding they are both the same kind of Scripts (i.e. a verification logic that must pass to allow transaction) that safeguards transactions, and “lock” script is just an isolation or decoupling of a specific use case of user authentication module which intuitively should allow skipping the output lock check when you’re just unilaterally giving away Cells.
In this understanding, there’s no need to restructure the basic framework or allow a specific use case on a low level, but just bring them back to the “type” script as you don’t want to isolation/decoupling, if you want the “lock” not skipped in the whole process of verification.
Hope these help! If you need so, I might try to spend some time to write a recipe skeleton for better illustrations.
