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

arXiv:2610.30183 · cs.CR, cs.SE · Submitted 2026-10-20 · Read on arXiv

Listen

Radio episode about this paper

Transcript

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.

Common Knowledge Base Association · Baoliang Education (HK) Group Ltd.

cs.CR, cs.SE

Submitted: 2026-10-20

Updated: 2026-10-20

Comments: 2 pages, 1 figure, 1 table. Poster paper at IEEE ICDLT 2026, Alcobaca, Portugal, December 3-4, 2026

Code: https://github.com/nervosnetwork/rfcs

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 78/100

The gist: 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

Key concepts

Extended-UTXO Model
Unlike Ethereum's account model, this system uses unspent transaction outputs (UTXOs) called 'cells'. Each cell must hold enough capacity to cover its data size. This means transactions must balance inputs and outputs based on byte capacity, not just monetary value.
Script-Pluralistic Chain
In this model, the locking script can encode any signature scheme. Consequently, different owners of UTXOs might require entirely different signing pipelines or cryptographic methods to validate their units within a single transaction.
Transaction Composer (Pattern A)
This pattern shifts complexity from the application developer to the SDK. The caller declares desired outputs, and the SDK automatically handles resolving inputs, calculating change units, and estimating fees based on capacity in one declarative step.

Summary

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.

Background: UTXO-Family Wallet Constraints

Extended-UTXO chains impose three qualitative differences on walletside SDK design compared to the EVM case. 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. 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. Third, fee estimation is coupled to transaction byte size and lock-script choice, a feedback loop absent from the EVM gas model.

Three Design Patterns in CCC

The CKBers’ Codebase (CCC) SDK extracts three recurring patterns from its release history and exported APIs to address these constraints. These patterns are:

A. Pattern A: Transaction Composer, where Caller supplies to/value/data, SDK fills nonce and gas. This pattern resolves the coupling between inputs, change units, and fee estimation by accepting Declarative outputs, SDK resolves inputs, change, and fee in one pass.

B. Pattern B: Unified Signer Abstraction, which normalizes signing across different schemes because secp256k1 ECDSA (covering Bitcoin, CKB, EVM, and Dogecoin conventions), WebAuthn passkeys, and Schnorr keys (Nostr) coexist on one chain. This pattern ensures One Signer interface encapsulating per-scheme differences.

C. Pattern C: Connector UI, which addresses the need for Per-wallet detection, chain switching, and account-change handling. This pattern ships Drop-in Web Component or React wrapper around the Signer.

Transferability and Conclusion

The paper concludes that these patterns generalize to other extended-UTXO ecosystems, such as Cardano, where declarative composition and reusable connectors already appear. The most distinctive contribution is Pattern B’s unification across signing primitives, which lifts wallet abstraction out of the application layer. The central lesson is that an SDK in this regime should hide routine complexity by default while keeping the manual path open. Future work will test whether these patterns reduce integration time or defects.

--- Page 1 ---

When EVM Defaults Break:

Three SDK Patterns for UTXO-Family Wallets

Hanzheng Zhang

Common Knowledge Base Association

China

0@hanssen0.com

Hongzhou Chen Hongzhou Chen Common Knowledge Base Association Baoliang Education (HK) Group Ltd. Hong Kong SAR hongzhouchen@ieee.org Abstract—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 (here, the Cell model on Nervos CKB), and once the wallet population spans heterogeneous cryptographic primitives (secp256k1, WebAuthn, Schnorr). Using CKBers’ Codebase (CCC), a TypeScript SDK, this retrospective case study extracts three recurring patterns from release history and exported APIs: a Transaction Composer that makes capacity-aware input completion and fee estimation declarative, a Unified Signer Abstraction that normalizes signing across heterogeneous wallets behind one interface, and a Connector UI component that ships per-wallet onboarding as a drop-in. The contribution is the articulation of these patterns as transferable design lessons for SDKs targeting UTXO-family ledgers and heterogeneous wallet populations. Index Terms—Web3 SDK, wallet abstraction, extended UTXO, key management, design patterns.

I. INTRODUCTION

The dominant client-side Web3 toolchain is shaped by Ethereum. Libraries such as ethers.js and viem encode three load-bearing defaults [1]–[3]: state lives in accounts rather than unspent outputs [4], a single secp256k1 key behind an externally owned account (EOA) signs every transaction, and a transaction is a nonce-ordered payload constructed without selecting concrete inputs. On extended-UTXO chains, these defaults fail together. Extended-UTXO chains [5], including the Cell model of Nervos CKB [6] studied here, place state inside typed UTXO-like units (cells) guarded by user-defined scripts, with capacity rather than gas as the scarce resource. Such chains also serve a heterogeneous wallet population: deployed CKB wallets sign with secp256k1 ECDSA, WebAuthn passkeys, or Schnorr keys (Nostr), each with its own signing path and key-management model [7], [8]. Through CKBers’ Codebase (CCC), a TypeScript SDK with over 330 tagged releases, this poster identifies and contributes three reusable design patterns.

II. BACKGROUND: UTXO-FAMILY WALLET CONSTRAINTS

Three features of the extended-UTXO setting make walletside SDK design qualitatively different from the EVM case. 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, and producing a change unit. 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 [6]. Third, fee estimation is coupled to transaction byte size and lock-script choice, a feedback loop absent from the EVM gas model.

Fig. 1. EVM SDK versus CCC SDK on extended-UTXO chains. Patterns A, B, and C are co-resident modules.

--- Page 2 ---

TABLE I

THREE SDK PATTERNS FOR UTXO-FAMILY WALLET INTERACTION, AS INSTANTIATED IN CCC.

Pattern EVM-centric assumption UTXO-family requirement CCC mechanism User-facing effect

A. TX Composer Caller supplies to/value/data, SDK fills nonce and gas. Inputs, change units, byte size, and fee are mutually coupled. Declarative outputs, SDK resolves inputs, change, and fee in one pass. No manual capacity iteration in application code.

B. Unified Signer Single secp256k1 signer behind an EOA. secp256k1, WebAuthn, and Schnorr coexist on one chain. One Signer interface encapsulating per-scheme differences. One codepath drives eight heterogeneous wallet adapters. C. Connector UI DApps re-implement wallet detection and onboarding. Per-wallet detection, chain switching, and account-change handling. Drop-in Web Component or React wrapper around the Signer interface ships as a reusable Web Component (@ckb-ccc/connector) and a React wrapper (@ckb-ccc/connector-react).

--- Page 3 ---

Pattern A: Transaction Composer In an EVM SDK, transaction construction centers on the user’s intent, without selecting concrete spendable inputs. By contrast, to enable concurrent transaction execution, cell-model transactions require first resolving input units, change, and the byte-size-dependent fee off-chain. CCC absorbs this coupling behind a Composer that accepts declarative outputs and resolves // Transfer 100 CKB to ‘receiver’ with the SDK const tx = ccc.Transaction.from(outputs: [lock: receiver, capacity: ccc.fixedPointFrom(100)],); await tx.completeInputsByCapacity(signer); await tx.completeFeeBy(signer); await signer.sendTransaction(tx); Listing 1 A demo transfer with CCC Three awaited calls complete inputs by capacity, set the fee, and sign and send

--- Page 4 ---

TABLE I

THREE SDK PATTERNS FOR UTXO-FAMILY WALLET INTERACTION, AS INSTANTIATED IN CCC.

Pattern EVM-centric assumption UTXO-family requirement CCC mechanism User-facing effect

A. TX Composer Caller supplies to/value/data, SDK fills nonce and gas. Inputs, change units, byte size, and fee are mutually coupled. Declarative outputs, SDK resolves inputs, change, and fee in one pass.

Improvements for AI systems

  1. Improved Transaction Construction via Declarative Composition

The SDK can now allow developers to construct transactions declaratively by supplying only declarative outputs such as Transfer 100 CKB to ‘receiver’ with the SDK. This removes manual capacity iteration in application code and allows the SDK to handle complex logic like input resolution, change calculation, and fee estimation in one pass.

  1. Improved Wallet Abstraction via Unified Signer Interface

The system can normalize signing across heterogeneous wallets by exposing a single Signer interface whose concrete implementations encapsulate differences. This ensures that different unit owners require different signing pipelines even within one transaction while allowing downstream protocols to see every wallet as the same object.

  1. Improved Onboarding via Drop-in Infrastructure

The AI system can ship wallet connection and onboarding as a reusable component, treating it as infrastructure whose per-wallet cost is paid once by the SDK. This allows DApps to simply declare which wallets to enable using a Drop-in Web Component or React wrapper around the Signer, eliminating the need for DApps to re-implement wallet detection.

Related papers