Hey everyone,
I’m building CKScope, a local-first CKB explorer built on CCC. CKBadger already proved the local-first explorer model works. CKScope builds on that by creating a CCC-native version specifically designed for developers, with transaction simulation, script debugging, and CCC code generation built in.
The Problem
CCC developers working in TypeScript/Node.js have limited options for exploring and querying on-chain data:
- ckb-indexer is Rust-based — not accessible to CCC devs
- CKBadger is experimental, opinionated, and not built on CCC
- Lumos indexer is deprecated
- Public explorers don’t offer programmatic access for developers building on CCC
CKScope fills this gap by providing a local-first explorer built specifically for the CCC ecosystem.
What CKScope Is
A CCC-native, self-hostable CKB explorer that:
- Uses CCC as the foundation for all chain interactions
- Caches block, transaction, and cell data in PostgreSQL
- Exposes a REST API for programmatic queries
- Provides a clean React UI for browsing blocks, transactions, and cells
- Will integrate CCC wallet connection and transaction building (post-POC)
How It Works (Powered by CCC)
- Data layer: CCC’s RPC client fetches blocks and transactions
- Cache layer: PostgreSQL with indexes for fast querying
- API layer: REST endpoints for blocks, transactions, and cells
- Frontend: React with dark theme, block list, and detail views
Why CCC Shapes the Design
Everything in CKScope is built on CCC:
- CCC RPC Client — All chain data is fetched via
@ckb-ccc/coreand@ckb-ccc/ckb - CCC Transaction Parser — Transactions are parsed using CCC’s Transaction class
- CCC Cell Parser — Cells are parsed using CCC’s Cell class
- CCC Script Resolution — Lock scripts are resolved using CCC’s built-in lock parsers
- CCC Wallet Integration (future) — Wallet connection and transaction building via CCC connector
Current Status (POC)
What’s Working 
- Block polling loop via CCC
- Syncing blocks into PostgreSQL using CCC’s structured data
- Basic REST API with pagination
- React UI showing block list
- Incremental sync (resumes from last synced block)
- Reorg detection (halts on parent-hash mismatch)
- Sync state checkpointing
What’s Not Yet 
- Direct RocksDB reads (currently using CCC RPC)
- Transaction and cell detail views
- Search functionality
- CCC wallet integration
- Reorg rollback (detected but not handled)
Tech Stack
| Layer | Technology |
|---|---|
| Runtime | Node.js + TypeScript |
| Chain RPC | @ckb-ccc/core + @ckb-ccc/ckb (the engine) |
| Database | PostgreSQL |
| API | Hono |
| Frontend | React + Vite |
| Pagination | Cursor-based (keyset) |
Key Design Decisions
| Decision | Reasoning |
|---|---|
| CCC as the foundation | Lumos is deprecated; CCC is the future |
| PostgreSQL over SQLite | Recommended for CKB’s data volume |
| CCC RPC over direct RocksDB (POC) | Simpler for POC; RocksDB direct read will come in v1 |
| Cursor-based pagination | Scales better than OFFSET for large tables |
| JSONB for raw data | Survives CKB upgrades without schema changes |
Features Planned for v1
Cell-First Explorer (Understanding CKB’s Cell Model)
- Full Cell Lifecycle Timeline — Shows every event in a Cell’s existence from creation to consumption with visual indicators
- Cell Dependency Graph — Visualizes which Cells depend on which others using graph visualization
- Live Cell Monitoring — Watch a specific Cell or address in real-time with notifications
- “Who Owns This Cell?” Resolution — Resolves lock script to actual address or human-readable identity
Developer Debugger (For CCC Developers)
- Transaction Simulator — Paste a raw transaction, run it against current chain state, see cycles used and script execution results
- Script Debugger Integration — Connect to ckb-debugger, step through script execution, inspect registers and memory
- CCC Code Generator — For any transaction you’re viewing, generate the exact TypeScript code using CCC’s API
- Cell Lineage Timeline — Cell lifecycle with developer-focused additions (script execution info, cycles used)
Build Order
- Phase 1: Core Foundation (POC) — Block sync, PostgreSQL storage, API, UI
- Phase 2: Cell-First Explorer — Cell lifecycle timeline, ownership resolution
- Phase 3: Developer Debugger — Transaction simulator, CCC code generator
- Phase 4: Advanced Features — Cell dependency graph, live monitoring, script debugger integration
Questions for the Community
-
As a CCC developer, would a local-first explorer with these features be useful to you?
-
What features would you consider essential for v1? Search? Cell data decoding? CCC wallet integration?
-
Any concerns with the PostgreSQL + CCC RPC approach? I plan to replace RPC with RocksDB direct reads in v1.
-
RocksDB in Node.js: Has anyone successfully read CKB’s RocksDB directly from Node.js? What approach did you use?
-
Reorg handling: The POC detects reorgs but doesn’t roll back. What’s the best approach for handling reorgs in a local explorer?
Links
- GitHub Repo: GitHub - chidinmaik/CKScope · GitHub
- Architecture Doc: CKScope/docs/research/architecture.md at main · chidinmaik/CKScope · GitHub
Looking for feedback. Thanks for reading.
