Thank you @chenyukang, always good vibes with you, I really appreciate 
Allow me to go on a short tangent: I tried making a on-chain voting system out of iCKB. It doesn’t work (unless we wrap iCKB xUDT). Hence the UDT-less voting proposal.
The issue is adding custom additional validation logic for Vote Logic to the xUDT cell in a way that is non-forgeable:
- xUDT would support this with extension scripts, but my research shown you can’t transfer a xUDT cell without extension logic into one with extension logic, you need to burn & mint again such xUDT cell
- xUDT by being included is using the script slot able to prevent data forgery
- xUDT output cells locks do not trigger validation. See:
This leads to one question: are we able to make a better UDT?
Some time ago, @janx proposed a solution which I liked a lot:
B.i create a lock/type script composing standard, e.g. is it possible for a lock script to have certain callback functions, and a standard-compliant type script will always spawn those callback functions if they exist in the lock scripts in related cells?
This (hypothetical but very workable) standard would naturally make betterUDT the best candidate for adoption, and (by lowering adoption barriers) it would open new venues of betterUDT adoption in DeFi, voting and generally any UDT application.
Personally, I would personally be happy to adopt betterUDT in Rosen Bridge and iCKB v2. OFC this still depends on other stakeholders and on the goodness of the betterUDT standard itself.
A consequence would be that with iCKB v2 on-chain voting would be trivial: it would follow the same flow presented in the non-UDT proposal.
Whatever your team choice, I’ll be happy to audit.
Phroi