Skip to content
Cardano Client Lib Cardano Client Lib

What's next

You can now build, sign and submit every common kind of Cardano transaction: payments, native tokens, NFTs, multi-sig, Plutus script calls and staking certificates. That covers most of what an application needs.

What follows is not a reading list to work through in order. Pick the row that matches the problem you actually have.

Choose by what you’re building

Section titled “Choose by what you’re building”
What you’re buildingGo to
More transaction shapes — governance, pool registration, reference scriptsQuickTx overview
Transactions defined as config rather than codeTxPlan
Several transactions that depend on each other’s outputsTxFlow
A service submitting transactions continuouslyTxStream
DRep registration, voting, proposalsGovernance API
Type-safe datums and redeemers from a CIP-57 blueprintBlueprint code generation
Proofs an Aiken validator can verify on-chainVerified structures
Wallet integration (CIP-30)CIP-30
An AI agent writing CCL code for youUsing CCL with AI

The three preview APIs, and when each earns its place

Section titled “The three preview APIs, and when each earns its place”

TxPlan, TxFlow and TxStream solve genuinely different problems. The most common mistake is reaching for the largest one first.

Start with plain QuickTx. One Tx, one completeAndWait(). It handles far more than people expect — including multi-asset outputs, certificates, governance and script spending. Move up only when you hit a specific wall.

You hit this wallBecauseUse
“The transaction shape is fixed, but the values change per run — and operators want to review them”The decision belongs in config, not codeTxPlan
“Transaction B needs to spend an output that transaction A creates”UTXO chaining, ordering and rollback handling are genuinely hard to do by handTxFlow
“I’m submitting a continuous stream and must never double-submit, even across a restart”Exactly-once delivery and durable recovery need real machineryTxStream

They compose: a TxFlow step can execute a TxPlan, and TxStream runs on the TxFlow engine.

Test against a local devnet

Section titled “Test against a local devnet”

The single biggest speed-up when learning this library is not reading — it is a fast feedback loop. Yaci DevKit runs a local Cardano devnet with pre-funded accounts and one-second blocks:

BackendService backend = new BFBackendService("http://localhost:8080/api/v1/", "dummy-key");
Account sender = Account.createFromMnemonic(Networks.testnet(), devkitMnemonic); // see the DevKit page

No API key, no faucet, and epochs that last minutes rather than days, so it’s the practical way to test a full staking or governance lifecycle. The same code runs against Preview with the backend swapped.

Understanding what the library did

Section titled “Understanding what the library did”

When a transaction does something you did not expect, inspect it before it goes out:

TxResult result = new QuickTxBuilder(backendService)
        .compose(tx)
        .withSigner(SignerProviders.signerFrom(account))
        .withTxInspector(txn -> System.out.println(JsonUtil.getPrettyJson(txn)))
        .completeAndWait();

withTxInspector hands you the fully built transaction — inputs chosen, fee calculated, change output added — just before submission. It is the fastest way to answer “why is the fee that number” or “which UTXOs did it pick”.

Reference material

Section titled “Reference material”

Where to get help

Section titled “Where to get help”