npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@ckb-firewall/sdk

v0.3.2

Published

TypeScript pre-flight checks for CKB transaction firewall blacklist enforcement (Layer 1 agent and wallet flows).

Downloads

1,180

Readme

@ckb-firewall/sdk

npm Tests License

Pre-flight blacklist enforcement for CKB transactions. Works in AI agent runtimes, wallets, dapps, and any service that builds CKB transactions before signing.

Install

npm install @ckb-firewall/sdk

Node 20+. ESM only (import; no require).

Usage

import { TransactionFirewall } from "@ckb-firewall/sdk";

const firewall = new TransactionFirewall({
  registries: [
    {
      codeHash: "0x...",
      hashType: "type",
      typeIdValue: "0x...", // 32-byte hex, bytes 34..66 of the v2 registry type args
      required: true,
    },
  ],
});

// registryScriptType: the type script of the registry cell dep (code_hash, hash_type, args)
// registryData: the hex-encoded BLKL v2 payload from the registry cell's data field
// Both are available from fetchRegistryPayload or the live cell via get_live_cell.
const result = firewall.checkTransaction({
  cellDeps: [{ type: registryScriptType, data: registryData }],
  outputs: [{ lockArgs: "0x..." }],
});

if (!result.ok) {
  // result.code and result.reason are narrowed by the discriminated union
  console.error(result.reason); // e.g. "BlacklistedLockArgs"
}

checkTransaction is synchronous and makes no RPC calls. You fetch the live registry cell from your CKB node and pass it as a cellDep — the SDK parses the BLKL payload and checks every output in the transaction.

How the SDK and the lock script fit together

This SDK is the pre-flight half of a two-part system.

The other half is the Firewall lock script — a CKB lock deployed on-chain. When a cell uses the Firewall lock, every CKB node enforces the same blacklist check at consensus, regardless of what the application layer does. A compromised agent that skips the SDK call entirely cannot bypass the lock.

The SDK catches bad transactions before you sign, saving fees and giving your runtime a structured error to act on. The lock catches anything that makes it to the network anyway. Used together, neither layer can be bypassed independently — the SDK alone can be skipped by compromised code, and the lock alone gives you no early feedback before broadcasting.

If your cells don't use the Firewall lock, the SDK still works as a standalone pre-flight check — but the consensus-level guarantee doesn't apply.

Testnet

The canonical testnet registry values are in notes/deployments/testnet.registry.json. The registrySpec object in that file maps directly to a RegistrySpecLike entry in the registries array.

Result codes

checkTransaction returns { ok: true } or { ok: false, code, reason }:

| Code | Reason | Meaning | |------|--------|---------| | 8 | MissingRegistryCellDep | No registry cell dep matched | | 9 | InvalidRegistryData | Registry payload failed to parse | | 10 | RegistryNotSorted | Registry entries are out of order | | 11 | BlacklistedLockArgs | An output's lock args are blacklisted | | 12 | BlacklistedTypeArgs | An output's type args are blacklisted | | 17 | AmbiguousRegistryCellDep | More than one registry cell dep matched |

Typed errors

Registry parsing errors are exported as typed classes for instanceof checks in your own error handling:

import {
  isFirewallSdkError,
  MissingRegistryCellDepError,
  InvalidRegistryDataError,
  RegistryNotSortedError,
  AmbiguousRegistryCellDepError,
} from "@ckb-firewall/sdk";

More