Cardano Client Lib · native · offline

One battle-tested SDK.
Four languages.
No JVM.

Cardano Client Lib compiled to a native shared library with GraalVM. Offline key derivation, transaction building, signing, Plutus, and governance — from Python, Go, Rust, and JavaScript.

libccl GraalVM native-image Cardano Client Lib C ABI JavaScript Go Rust Python TxPlan YAML → → tx_cbor sign_tx → offline ✓ no JVM
4
first-class languages
9
API groups, identical everywhere
20+
devnet-verified tx intents
0
JVMs at runtime

Same semantics in every language

Same API groups, same error codes, same TxPlan YAML — kept at parity and enforced by CI.

$ bun add @bloxbean/cardano-client-lib
import { CclBridge, TESTNET } from '@bloxbean/cardano-client-lib';

const bridge = new CclBridge();
const account = bridge.account.create(TESTNET);
const result = bridge.quicktx.build(yaml, utxos, params);
const signed = bridge.account.signTx(mnemonic, TESTNET, 0, 0, result.tx_cbor);
// fully offline — submit signed cbor with any HTTP client

Why these bindings

⚙️

No JVM at runtime

Cardano Client Lib compiled to a native shared library with GraalVM native-image. Native startup, small footprint, a plain C ABI.

🔌

Fully offline by design

Key derivation, transaction building, signing, Plutus data — no network calls, no submission, no secrets in the library. You bring chain data; optional providers fetch it for you.

📄

One YAML transaction format

Describe payments, staking, governance, minting, and Plutus operations as TxPlan YAML — identical across all four languages, with a verified intent catalog.

🧮

Offline Plutus costing

The embedded Scalus UPLC evaluator computes execution units in-process. Override with explicit units or a remote evaluator when you want node-backed costing.

🤝

Four first-class wrappers

Python, Go, Rust, and JavaScript (Bun) are kept at strict parity — same API groups, same error codes, enforced by CI. No second-class language.

🤖

AI-friendly from day one

llms.txt, a full-docs dump, and an AI Starter Pack distilled for agents: point Claude Code or Cursor at one URL and generate correct code immediately.

Where this fits

Cardano already has excellent native libraries — pycardano, MeshJS and Lucid Evolution, pallas, gOuroboros, Apollo, and more. If one of them serves you well, use it. These bindings shine when it doesn't quite: when a native library is missing a capability you need, or its API doesn't fit how you work, you get Cardano Client Lib's exact, well-tested semantics — identically in four languages — without leaving your stack. Being offline and stateless, they slot in alongside an existing library for just the missing pieces.

Choose these bindings when…

  • your native library is missing functionality you need — e.g. Conway governance operations, offline Plutus costing, HD-wallet or DRep key derivation — use these bindings for just those pieces, alongside it
  • you're not happy with an API and prefer CCL's model — declarative TxPlan YAML instead of imperative builders
  • you want identical transaction-building behavior across several languages or services, or already use CCL on the JVM
  • you want offline building backed by CCL's test suite and devnet-verified intent shapes, and insurance against a library going unmaintained

Choose a native library when…

  • you prefer a pure-language dependency — these bindings ship a ~50 MB native binary
  • you need node protocols / chain sync — deliberately out of scope here
  • your platform isn't covered (e.g. macOS Intel)
  • an idiomatic library already fits your stack — no need to switch

Bring your AI agent

The docsite ships llms.txt, a full-docs dump, and a distilled Starter Pack. One curl and Claude Code, Cursor, or any agent writes correct code against the bindings.

$ curl -o CLAUDE.md https://pages.bloxbean.com/cardano-client-bindings/ai/starter-pack.md
Set up your tool →