Skip to content
CKB Transaction Firewall CKB Transaction Firewall

Step 5: Where to Go Next

We built a pre-flight checker that:

  • Discovers the live registry cell using the CKB indexer
  • Parses and validates the BLKL v2 blacklist payload
  • Checks transaction outputs synchronously before signing
  • Recovers from a stale outpoint after a governance update

This is the pre-flight half of the two-layer model. The other half — the on-chain lock that enforces the same rule at consensus — runs automatically on every node when a firewall-protected cell is spent. You do not need to do anything to activate it; it activates when a cell is created with the firewall lock args.

Next steps by task

Section titled “Next steps by task”
Wrap a wallet cell with the firewall lock Build the lock args for a cell that enforces blacklist checking at consensus.
Assemble cell deps for spending The exact cell deps required when spending a firewall-protected cell.
Pre-flight patterns reference All pre-flight SDK patterns — preflightCheck, TransactionFirewall.checkTransaction, isBlacklisted.
Handle time-based entries Include header_deps so temporary blacklist entries are evaluated correctly.

Understand what you built

Section titled “Understand what you built”
The two-layer model Why both layers are necessary and what each one actually guarantees.
Registry design Why the registry is a single cell, why entries are sorted, and what fail-closed means operationally.

Full API reference

Section titled “Full API reference”
TypeScript SDK API All exported types, functions, and classes — complete signatures and descriptions.
Error codes All codes returned by the SDK and the on-chain contracts.