User defined token standards are a fundamental infrastructure component of a public blockchain network. ERC20 is the most famous and widely used protocol in the Ethereum platform. We need a cell model compatible UDT standard to support various token related applications on CKB. This thread is about the UDT standard proposal’s evaluation criteria.
Architecture
Interface or Implementation
The ERC20 standard actually defines the interfaces of a UDT smart contract. One of the most severe problems it faces is that other smart contracts like DeFi services cannot evaluate the security level of unfamiliar UDTs, because every UDT smart contract has its own implementation code.
If we deploy a general implementation of UDT on chain, and all UDTs are inherited from it, we can build a better infrastructure for UDTs.
Modification Capability
Does the standard support modification of basic information, like total supply, token name, token symbol, decimal length etc.
Upgradation Capability
Does the standard support upgradation in the future, and how.
Identity
The method to identify two different types of UDT.
Capabilities
Create
How to create a new UDT and how to avoid duplication.
Issue
- How to issue on new UDT creation
- How to issue dynamically
- Privilege management: roles, amounts, and time restrictions
Burn
- How to burn UDT
- Privilege management: roles, amounts, and time restrictions
Transfer
- Normal Transfer
- Support all kinds of locks.
- Delegation Transfer
- Identical functions to ERC20’s approve and transfer_from.
- Lock and Unlock
- How to “lock” UDTs into some contract? The “lock” logic may be totally different on CKB from that on account based systems like Ethereum. For example, we can use some independent lock script to constrict the ownership of a UDT cell.
Statistics
- Balance
- It seems hard to calculate user’s UDT balance on chain
- Total supply
- Issued subtract burnt
Partial TX
Partial TX (aka Open TX) is very important for transaction combination on CKB. The UDT standard should support Partial TX protocol. However, we need another thread to discuss Partial TX’s standard.
Function Extension
How to extend the basic functions of the UDT standard?
Overhead
Interaction Complexity
What is the routine to operate a UDT? How many steps we need to generate an issue / transfer / … transaction. Does the receiver need to prepare an empty cell ahead?
Cycle Overhead
How many extra cycles the standard needs to operate a UDT cell comparing with CKB transfer.
Cell Capacity Overhead
How much extra capacity the standard needs to store a UDT cell compared with a default cell.
Bandwidth Overhead
The witness size and the deps size that the standard needs.
Practicability
Transaction Generation
How to gather enough information to generate a UDT operation transaction.
Balance Calculation
How to calculate an account’s balance in a wallet or explorer, and how complex it is.
Airdrop
According to the proposal, is there any low cost solution to do UDT airdrop?
Exchange Deposit & Withdraw
The complexity of integration for exchanges.
| Catalogs | Features | Proposal A | Proposal B | Proposal C | ... |
|---|---|---|---|---|---|
| Architecture | Interface or Implementation | ||||
| Modification Capability | |||||
| Upgradation Capability | |||||
| Identity | |||||
| Capabilities | Create / Issue / Normal Transfer | ||||
| Burn | |||||
| Delegation Transfer |
|||||
| Lock & Unlock | |||||
| Built-in Statistics Functions | |||||
| Partial TX Support | |||||
| Function Extention | |||||
| Overhead | Interaction Complexity | ||||
| Cycle Overhead | |||||
| Cell Capacity Overhead | |||||
| Bandwith Overhead | |||||
| Practicability | Transaction Generation | ||||
| Balance Calculation | |||||
| Airdrop | |||||
| Exchange Deposit & Withdraw |