The Hidden UX Strengths of CKB: A Designer’s Take

yuqi · August 1, 2025, 2:30am

Hey all – I’m a UX designer working with the CKB ecosystem. This article was originally published on Yakihonne, but I wanted to share it here too. It explores how CKB’s use of type hash and data hash quietly reinforces trust and improves user experience. Would love to hear what others think — especially from different parts of the ecosystem.

Designing for Trust: How Type Hash and Data Hash Empower CKB Users

Introduction

As a UX designer working in the CKB ecosystem, I’ve spent a lot of time thinking about transparency and user control. One of the most underrated design choices I’ve come across is CKB’s use of type hash and data hash for referencing Scripts.

A Script on CKB is identified by a code_hash and a hash_type. The hash_type determines how the code_hash is interpreted:

A data hash means the hash of the Script’s actual binary — frozen and immutable.
A type hash means the hash of a Type Script (commonly a Type ID), which can point to updated logic over time.

From a design perspective, it’s a bit like working with design tokens:

Using a data hash is like directly referencing the raw value #1A1A1A in your design.
Using a type hash is like referencing a token — say, --color-primary — which may point to #1A1A1A today, but could be updated to #FFFFFF in the future.

At first glance, these might seem like low-level implementation details. But in practice, they offer a powerful UX affordance:

The ability to choose what code you want to trust — and to see that choice clearly.

Who Gets to Decide What You Trust?

Let’s say you’re signing a long-term contract to store your savings. You could:

Print and sign a hard copy, sealing the terms forever.
Or keep a live Google Doc link that always shows the latest version.

One gives you certainty. The other offers convenience.

On most blockchains, that choice isn’t yours to make.

In Bitcoin, you’re handed the hard copy – and that’s your only option. The scripting system is intentionally minimal and fixed. All the logic is baked directly into the protocol, and it can’t change unless there’s a hard fork – a non-backward-compatible upgrade that everyone must accept to stay in sync. This makes Bitcoin stable and secure, but it also means users have no way to opt into different versions of logic. Everyone follows the same path.

Ethereum offers more flexibility: developers can deploy either upgradable or immutable smart contracts, and users can choose which ones to interact with. However, even if a user selects an immutable contract, the contract still runs on the Ethereum Virtual Machine (EVM) – and the EVM itself can change through a system-wide hard fork. In other words, even when the contract doesn’t change, the environment it runs in might.

This puts users in a tricky position: they may think they’ve locked in a contract’s behavior, but behind the scenes, system upgrades can still affect how that contract behaves. In practice, users rely on the assumption that future system changes won’t break the contract they chose.

This creates a subtle imbalance: users appear to have autonomy, but they’re still bound by system-wide decisions. In a P2P network, that mindset feels out of place. These systems are meant to give everyone equal power and the freedom to make independent decisions. That means respecting differences in trust models, preferences, and risk tolerance.

In that light, hiding trust decisions behind protocol or developer defaults isn’t just limiting – it’s a missed opportunity for real user autonomy.

Designing for User Autonomy

CKB gets this right. By introducing both data hash and type hash, it doesn’t just support version control — it enables a UX of autonomy.

At a glance, this may seem similar to Ethereum, where developers can deploy either upgradable or immutable Scripts. But CKB goes further: Scripts can also be tied to a specific virtual machine version, thanks to data, data1, and data2. This gives users two distinct options:

Use a data hash (data, data1, data2) to lock in both the exact Script and the VM it runs on. Even if the CKB-VM evolves in a future hard fork, your Script will still behave exactly as it did – the way you trusted in the same VM.
Use a type hash (via type ID) if you prefer to stay current — trusting the developer or protocol to upgrade responsibly.

This decoupling of Scripts from system upgrades is what truly empowers users. It ensures users are not implicitly opting into changes just because the system moves forward.

No one is forced to upgrade. No one is left behind. Multiple versions of the same Script can coexist — and it’s entirely up to you when, or whether, to switch.

From a UX perspective, that’s rare. We often talk about user control in terms of interface-level interactions — things like showing a back button to let users undo an action, or adding a “Skip” button during onboarding so they’re not trapped in a flow. These patterns reflect a core design heuristic:

“User control and freedom” — the idea that users should be able to make choices, recover from missteps, and move at their own pace.

What CKB offers through data hash and type hash goes much deeper. It’s not just about interface — it’s about control at the protocol level.

It’s not just versioning. It’s self-determination.

And to me, that’s the essence of good UX in decentralized systems.

Making the Invisible Visible

Right now, most interfaces in the CKB ecosystem don’t surface whether a Script is referenced by data hash or type hash. That means the autonomy built into the protocol often stays hidden from the user.

As a design exercise, I created a few mockups to explore how we might make that distinction visible — and help users make more informed choices.

These aren’t production UIs (yet), but I hope they spark ideas.

Imagine a dApp that lets users choose which version of a Script to use — either the latest version (referenced by type hash), or the one they’ve manually selected and trust (referenced by data hash). By making this choice explicit, we turn a low-level protocol detail into a clear, user-driven decision. The left screen shows the default behavior — always following the latest Script. The right screen shows the manual selection mode, where users compare and choose from multiple trusted versions.

And with the rise of AI, this kind of transparency becomes even more powerful. Instead of expecting users to read raw code or verify hashes, we can use AI to summarize what each Script version does in plain language. That means even non-technical users can make trust decisions based on understandable, human-readable insights.

In this light, CKB’s design doesn’t just support autonomy — it enables usable autonomy. The protocol gives users freedom. AI gives them the clarity to act on it.

But this level of flexibility at the protocol level also comes with tradeoffs. It can lead to a subtle but serious UX problem: address inconsistency.

Choosing different Script versions — even with the same private key — produces different addresses. To the user, this feels inconsistent. Users naturally expect one key to always yield the same address. But without visibility into how addresses are derived, that expectation quietly breaks. A user might import their private key into a new wallet and see an unfamiliar address, simply because the app made a different (and invisible) decision about which Script to use.

If we care about transparency, this is an area worth revisiting. While the protocol empowers users to choose, that choice needs to be visible, understandable, and portable across the ecosystem. Otherwise, we risk turning flexibility into fragmentation.

References

Would love to hear ideas on how we can surface these trust choices more clearly at the interface level — and help make this technical design choice easier for the general public to grasp.