When EVM Defaults Break: Three SDK Patterns for UTXO-Family Wallets

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: We're looking at the paper: "When EVM Defaults Break".

Elias: Here's the gist of the paper. The gist Mainstream Web3 SDKs (e.g., ethers.js, viem) bundle three coupled assumptions: an account-based ledger, a single secp256k1 signer, and input-selection-free transaction construction; these assumptions fail once a chain adopts an extended-UTXO model and spans heterogeneous cryptographic primitives like secp256k1, WebAuthn, or Schnorr keys.

Nadia: Extended-UTXO chains impose three qualitative differences on walletside SDK design compared to the EVM case.

Elias: First, "every UTXO-like unit (a cell) must carry enough capacity to cover the byte size of its serialized output and data, so transaction construction requires balancing inputs and outputs against capacity, not only value".

Nadia: Second, "the chain is script-pluralistic: a lock script can encode any signature scheme, so different unit owners require different signing pipelines even within one transaction".

Paper summary: Nadia: So wrapping up the paper "When EVM Defaults Break: Three SDK Patterns for UTXO-Family Wallets," the authors are essentially showing how to build a modern SDK that can handle the realities of extended UTXO chains and varied crypto primitives >

Elias: They’re pointing out that because of those three coupled assumptions failing, we need specific structural patterns—the Composer, the Unified Signer, and the Connector UI—to manage inputs, signing schemes, and wallet integration separately >

Priya: What this means practically is that developers should look for SDKs that have these kinds of abstractions built in rather than trying to write all that capacity balancing and heterogeneous signing logic from scratch >

Nadia: It suggests that the future of interacting with UTXO-family ledgers won't be about writing custom transaction builders every time, but about using these reusable patterns provided by SDKs like CCC >

Elias: I agree. The paper emphasizes that the most valuable contribution is Pattern B’s unification across those different signing primitives, which really simplifies wallet abstraction >

Conclusion: Nadia: So, we’ve looked at how mainstream tools built for Ethereum are actually not equipped for these new UTXO chains, and this paper shows three specific patterns to fix that mismatch.

Elias: Yeah, the authors look at things like ethers and viem—the default assumptions they bake in—and show exactly where those assumptions fall apart when you move to extended UTXO models.

Priya: And what they found is that because of those failures, there are these recurring design patterns emerging from actual codebases like CKBers’ Codebase, which the paper calls CCC.

Nadia: Exactly. They identify three things that keep showing up across the history of this SDK—a Transaction Composer, a Unified Signer Abstraction, and a Connector UI component.

Elias: I think Pattern B, the Unified Signer Abstraction is pretty interesting because it tackles that problem of having different crypto schemes coexisting on one chain.

Priya: It really does. It moves the complexity away from where the application developer has to worry about juggling secp256k1 versus WebAuthn keys manually.

Nadia: Right, and Pattern A, the Transaction Composer, it makes figuring out inputs and fees declarative so you don't have to do that heavy lifting in your main application code.

Elias: That coupling between inputs and fees is what trips up a lot of developers on these new systems because the fee calculation isn't just gas anymore; it depends on the entire transaction structure.

Priya: The paper suggests that by separating input resolution from capacity balancing, you can make those systems much more predictable for measurement purposes.

Nadia: So, if we look at the authors and what they’ve done here—Hanzheng Zhang and Hongzhou Chen—the main point is that these aren't just academic ideas; they are patterns extracted from real SDK evolution.

Elias: It’s a practical contribution to how we think about building wallets for these new ledger types, moving away from the old EVM-centric mindset.

Priya: It changes things by showing how to build tooling that respects the unique constraints of UTXO models and mixed cryptographic environments right out of the gate.

Nadia: It really frames it as a set of transferable lessons for anyone building tools for these complex decentralized systems.

Elias: And they hint that these kinds of declarative compositions are already appearing in other ecosystems, which is what makes this research relevant beyond just one chain.