Designing and Deploying a Production-Ready xUDT Fungible Token on Nervos CKB
Hello Nervos Community,
I’m excited to present CKB xUDT Token — a fully deployed fungible token built natively on Nervos CKB using the xUDT (Extensible User Defined Token) standard. This project was developed as part of the CKBuilders program and represents my first deep dive into Web3 infrastructure.
Project Overview
This project demonstrates the full lifecycle of a fungible token on CKB:
- Smart contract development (Rust → RISC-V)
- Token deployment on testnet (Aggron)
- Transaction tooling via Lumos
- Frontend dashboard with wallet integration
- Modular SDK for token operations
Token Identity
- Name: Axon
- Symbol: AXN
- Standard: xUDT (Extensible User Defined Token)
- Network: Nervos CKB (Aggron Testnet)
Why xUDT?
Choosing xUDT over plain UDT was a deliberate architectural decision.
Key Advantages:
-
Standardization (RFC-0052)
xUDT provides a unified interface, enabling compatibility across wallets and protocols without custom integrations. -
Extensibility
Supports extension scripts for:- Transfer restrictions
- Vesting mechanisms
- Compliance rules
- Governance logic
-
Interoperability
Works seamlessly with ecosystem tooling that already supports xUDT.
In contrast, plain UDT implementations are fragmented and require bespoke integrations.
System Architecture
The system is composed of on-chain contracts and off-chain infrastructure.
On-Chain Layer (Rust → RISC-V)
-
xUDT Type Script
- Enforces token rules:
- Controlled minting
- Supply preservation during transfers
- Authorized burning
- Token balances stored as
Uint128(16-byte little-endian)
- Enforces token rules:
-
Owner Lock Script
- Governs minting authority
- Owner lock hash embedded in Type Script arguments
- Clean separation of concerns between logic and control
Off-Chain Layer (TypeScript + Lumos)
-
SDK abstraction for:
- Minting
- Transfers
- Burning
- Balance queries
- Deployment
-
Frontend features:
- Wallet connection (JoyID)
- Token balance visualization
- Indexer-based data retrieval
Project Structure
contracts
xudt-type-script/src/main.rs— Core xUDT token validation logicowner-lock-script/src/main.rs— Mint authority (owner lock) script
frontend
src/App.tsx— Token dashboard UI
Root Files
README.md— Project documentation
Tech Stack
| Layer | Technology |
|---|---|
| On-chain | Rust, ckb-std v1.0, RISC-V |
| Transaction Layer | @ckb-lumos/lumos v0.22 |
| Wallet Integration | JoyID (CCC Connector) |
| Frontend | React, Vite, Tailwind CSS |
| Hosting | Vercel |
Implemented Features
- Deployment on CKB Aggron Testnet
- Initial mint of 1,000,000,000,000 tokens
- Wallet-based transaction signing (JoyID)
- Token balance tracking per Type Script hash
- Fully tested contract logic:
- Mint authorization validation
- Transfer balance preservation
- Unauthorized mint prevention
- Burn validation
Security Considerations
- Strict Mint Authorization via Owner Lock Script
- Supply Integrity Enforcement during transfers
- Explicit Burn Validation Rules
- Modular design reduces risk when adding extensions
- Test coverage for critical transaction flows
Design Decisions
- Chose xUDT over UDT for ecosystem compatibility
- Implemented Owner Lock pattern for clear permission control
- Built an SDK layer to simplify developer interaction
- Used indexer-based querying for scalable frontend performance
Notable Challenges
1. RISC-V Cross-Compilation on Windows
Establishing a functional RISC-V toolchain on Windows presented an initial challenge. The riscv64-unknown-elf-gcc compiler had to be installed via MSYS2, properly configured, and added to the system PATH. Additionally, the .cargo/config.toml required precise configuration to enable successful cross-compilation of Rust contracts to the RISC-V target.
2. Incorrect Binary Referencing in Test Configuration
The test suite initially referenced source files instead of compiled contract binaries:
include_bytes!("../../xudt-type-script/src/main.rs")
3. TypeScript SDK API mismatches with Lumos v0.22
The generated SDK used method names that don’t exist in @ckb-lumos/lumos v0.22 — utils.addressToScript instead of helpers.parseAddress, .call() on the RPC client, and incorrect TransactionSkeletonType usage. All required targeted fixes.
4. Resource Constraints During Compilation
The contract test suite introduced a substantial dependency tree, including packages such as:
ckb-testtoolbulletproofstokio- Windows-specific system crates
The issue was managed through periodic cleanup of build directories and optimized dependency handling.
Potential Use Cases
- Stablecoins and payment tokens
- DAO governance tokens
- Reward and incentive systems
- Tokenized assets with compliance layers
- DeFi protocol integrations
Roadmap
- Token metadata registry (human-readable token info)
- Multi-token portfolio support
- xUDT extension implementation:
- Transfer restrictions
- Vesting schedules
- Mainnet deployment
- Developer documentation expansion
Resources
| Resource | Link |
|---|---|
| Live Demo | https://ckb-token.vercel.app |
| GitHub | GitHub - willy264/ckb-token · GitHub |
| Documentation | GitHub - willy264/ckb-token · GitHub |
Contribution & Feedback
Feedback is highly appreciated, especially on:
- Minting authority design (Owner Lock vs alternatives)
- Metadata standards within CKB
- Practical xUDT extensions worth implementing
Contributions, issues, and suggestions are welcome.
Appreciation
A special appreciation to the ever-supportive Nervos community, @neon.bit for contributions and support throughout the process.
Also, appreciation to everyone who continues to contribute to my growth as a builder and to the advancement of the CKB ecosystem. I look forward to contributing more, collaboraing and sharing even more interesting builds in the near future.
Thank you for reading.
