I was thinking too around these lines, but then again, do we really want to add on-chain oracles for permission-lessy authorize forfeiture?
Not only that, it also means binding a specific oracle vendor to a common protocol.
Additionally, this protocol is easy to DoS: an attacker can just send the bare minimum assets required to fill up these cells (3% -30% of cell value) and leave it there until forfeiture. New cells added, new asset sent until forfeiture.
When considering everything needed for a working prototype, it seems an over-complicated design.
Conversely, in the Rosen Bridge integration I’m aiming for the following:
- CKB → OUT: User sends UDT to Bridge’s ACP, Bridge maintain a pool of them which it owns
- OUT → CKB: Bridge sends UDT to user address (non-ACP usually), CKB is factored in as network fee
Say CKB price raises to over 1 USD we can always re-implement UDT transfers in the Rosen Bridge integration. Ideally new Token protocols will emerge in the meantime.
In this regard, my idea is that in the future a token standard will emerge that allows its token cells to be represented in two ways:
- UDT: sUDT-alike for backward compatibility
- non-UDT: a state rent aware representation
UDT cell representation can be transformed permissionlessy into non-UDT cell representation and backward.
This with a couple more ideas, I call interphase UDT or iUDT.
Love & Peace, Phroi %42