Discussion on UDT Standard Evaluation Criterion

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
7 Likes

12 days passed, 149 views and so far no reply.

How about a hackathon or a dev competition on UDT? Developers might get more ideas when they are trying to implement something.

That’s a great idea and we’ll be working towards that. Thank you for the suggestion!