@ckb-firewall/cli

CLI for inspecting and governing the CKB Transaction Firewall blacklist registry.

Node 20+. ESM only.

Install

npm install -g @ckb-firewall/cli

Or use the one-line installer (handles Node version checks and PATH setup):

curl -fsSL https://raw.githubusercontent.com/digitaldrreamer/ckb-transaction-firewall/main/scripts/install-cli.sh | bash

Commands

Inspect and check

# Show all current entries with status
ckb-firewall inspect

# Check whether a specific address is blacklisted
ckb-firewall check --lock-args 0xabc123...

Governance flow

The auditable path — cryptographically signed votes, 72-hour review window, and on-chain multisig execution.

# 1. Create a proposal
ckb-firewall propose

# 2. Export and share with other participants
ckb-firewall export --proposal <id> --out proposal.json

# 3. Each participant imports
ckb-firewall import proposal.json

# 4. Each validator votes with their private key
ckb-firewall vote --proposal <id> --vote yes
#   (prompts for 32-byte private key)

# 5. Track status
ckb-firewall proposals

# 6. Anchor the proposal on-chain as a PBLK cell
ckb-firewall anchor --proposal <id> --to-address <proposal-cell-owner-address>
# after the transfer is accepted, record it once if you did not use --submit
ckb-firewall anchor --proposal <id> --proposal-tx <anchor-tx> --proposal-index <data-output-index>

# 7. Execute on-chain after review window and vote threshold
ckb-firewall execute \
  --proposal <id> \
  --tx-out gov_tx.json

Proposal state lives in ~/.ckb-firewall/proposals/. Use export/import to share between participants — import merges rather than overwrites.

anchor creates the on-chain PBLK proposal cell and stores its outpoint on the proposal when submitted directly or when you later pass --proposal-tx and --proposal-index. GOV1 v4 execution spends that cell with a relative timestamp since delay, so the review window is enforced by CKB consensus.

Full reference

https://ckb-firewall.drreamer.digital/reference/cli/