CKB Escrow: a decentralized escrow app for goods and services on Nervos CKB

Applications & Ecosystem
, , , ,
1

Hi everyone,

I have been building CKB Escrow, a decentralized escrow app for goods and services on Nervos CKB, and I would like to share the current progress with the community for feedback.

The idea is simple: create a wallet-first escrow workflow for real deals between known parties.

This is not a marketplace, storefront, listing platform, or reputation system. The goal is to focus on the escrow flow itself:

  1. Buyer creates and funds an escrow.
  2. Seller marks the goods or service as delivered.
  3. Buyer releases funds if satisfied.
  4. Buyer or seller can open a dispute if something goes wrong.
  5. Arbitrator reviews the dispute and resolves the escrow to buyer or seller.

Why I Am Building This

A lot of online work and goods/service transactions still rely on trust between strangers or semi-known parties. Escrow helps reduce that trust problem, but many escrow systems are centralized.

CKB feels like a good fit for this because of the cell model. Each escrow can exist as its own cell, with explicit state transitions and participant rules. This makes the flow easier to reason about:

  • who funded the escrow
  • who is the seller
  • who can mark delivery
  • who can release funds
  • when refund is allowed
  • how disputes are resolved

Current Features

The project currently includes:

  • Rust CKB contract for escrow state validation
  • Buyer, seller, and arbitrator roles
  • Escrow states:
    • funded
    • delivered
    • disputed
    • completed
    • cancelled
    • refunded
    • resolved
  • Buyer-first frontend app
  • Wallet-first identity
  • Testnet/mainnet network selection
  • Role-aware escrow discovery
  • Active and past escrow views
  • Escrow detail page / deal room
  • Dispute evidence flow using off-chain evidence metadata and hashes
  • Arbitrator review and resolution flow
  • Indexer-backed escrow history direction
  • /studio route for protocol/debug/deployment tooling

Tools Used

Some of the tools and technologies used:

  • Rust
  • CKB scripts
  • CKB cell model
  • ckb-testtool
  • Docker reproducible builds
  • OffCKB CLI
  • CCC wallet integration
  • TypeScript
  • Next.js
  • Tailwind CSS
  • shadcn-style UI primitives
  • Postgres-ready indexer storage
  • Vercel

Current Design Direction

The app is designed around wallet-first identity.

There is no email/password registration in v1. A connected wallet determines whether the user is:

  • buyer
  • seller
  • arbitrator
  • viewer

For escrow history, I am moving toward an indexer-backed approach because terminal escrows are consumed on-chain and should still be visible as past history across devices.

For dispute evidence, v1 uses off-chain evidence with hashes. The contract still handles the actual escrow state transitions and settlement. Evidence anchoring on-chain may be explored later.

Areas Where I Would Like Feedback

I would really appreciate feedback from the Nervos community on:

  1. Is the escrow state machine approach reasonable for CKB?
  2. Is the buyer/seller/arbitrator model implemented in a CKB-native way?
  3. Is indexer-backed history the right production direction for recovering completed/cancelled/refunded/resolved escrows?
  4. Should dispute evidence stay off-chain in v1, or should evidence cells be introduced earlier?
  5. Are there important CKB cell-model edge cases I should be thinking about?
  6. What should be improved before public testnet usage?
  7. What security or UX issues would you check before mainnet?

Planned Next Steps

The next things I want to work on are:

  • full hosted testnet end-to-end validation
  • continuous indexer sync
  • production Postgres/Neon setup
  • better transaction confirmation UX
  • explorer links
  • stronger arbitrator dashboard
  • improved dispute evidence review
  • more wallet compatibility testing
  • mainnet readiness review after testnet is stable

I would be grateful for any feedback, criticism, or guidance. I am especially interested in whether the architecture feels correct for CKB and what I should improve before pushing this further.

1 Like