BIP: 89 source
  Layer: Applications
  Title: Chain Code Delegation
  Authors: Jesse Posner <jesse@vora.io>
           Jurvis Tan <jurvis@block.xyz>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0089
  Status: Draft
  Type: Specification
  Assigned: 2025-12-03
  License: BSD-3-Clause
  Discussion: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837
  Requires: 32, 340, 341

Chain Code Delegation (CCD) is a method for multi-signature wallets in which a privileged participant withholds BIP32 chain codes from one or more non-privileged participants, and supplies per-input scalar tweaks at signing time. This allows non-privileged participants to co-sign transactions without learning wallet-wide derivations, balances, or signing activity from other spending combinations. CCD defines the tweak exchange needed for verification and signing behavior when the signer does not possess a chain code.

In multisig deployments, sharing extended public keys (xpubs) or descriptors enables all participants to scan the chain and infer counterparties' activity. CCD limits that visibility by ensuring non-privileged participants only ever hold a non-extended keypair and only receive the minimum per-spend data needed to sign. The procedure keeps policy enforcement feasible for the non-privileged signer while preserving balance privacy, which is particularly useful in collaborative custody arrangements where the wallet owner wants balance privacy from their custodian.

In CCD, the chain code is the object of delegation—not signing authority. A participant who gives up their chain code delegates it to another.

• A "Delegator" is a participant who delegates their chain code to another party. They hold only a non-extended keypair and receive scalar tweaks from the delegatee when asked to sign.
• A "Delegatee" is a participant who receives and retains a delegated chain code for another participant's public key, and computes derivation tweaks for that participant.
• A "Participant" is any key holder that can co-sign for UTXOs in the wallet (including delegators and delegatees).
• A "Non-hardened derivation" is a BIP32 child derivation where index < 2^31.

CCD operates by having Delegatees deprive Delegators of BIP32 chain codes during setup and later conveying the aggregated scalar tweak computed as the sum of non-hardened derivation tweaks along the remaining path to the child key used by a given input or change output. A Delegator uses the tweak to compute the child keys for verification and signing without being able to derive or recognize keys for other paths.

• Delegator key: Each delegator generates a standard (non-extended) secp256k1 keypair and provides the public key to the counterparties. A delegator MUST NOT retain or be provided a chain code for this key.
• Delegated chain code: A designated delegatee computes and retains a BIP32 chain code bound to the delegator's public key, forming an xpub that MUST NOT be disclosed to the delegator. The delegatee MAY share this xpub with other delegatees.
• Other participants: Non-delegator participants use conventional extended keys and share the public half as appropriate for the wallet descriptor.
• Derivation constraints: The delegatee holds an extended public key for the delegator. All derivation from this extended key MUST be non-hardened, as hardened derivation requires the private key, which the delegatee does not possess.

The following conventions are used, with constants as defined for secp256k1. We note that adapting this proposal to other elliptic curves is not straightforward and can result in an insecure scheme.

• Lowercase variables represent integers or byte arrays.
  • The constant p refers to the field size, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F.
  • The constant n refers to the curve order, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.
• Uppercase variables refer to points on the curve with equation y² = x³ + 7 over the integers modulo p.
  • is_infinite(P) returns whether P is the point at infinity.
  • x(P) and y(P) are integers in the range 0..p-1 and refer to the X and Y coordinates of a point P (assuming it is not infinity).
  • The constant G refers to the base point, for which x(G) = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 and y(G) = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8.
  • Addition of points refers to the usual elliptic curve group operation.
  • Multiplication (⋅) of an integer and a point refers to the repeated application of the group operation.
• Functions and operations:
  • || refers to byte array concatenation.
  • The function x[i:j], where x is a byte array and i, j ≥ 0, returns a (j - i)-byte array with a copy of the i-th byte (inclusive) to the j-th byte (exclusive) of x.
  • The function bytes(n, x), where x is an integer, returns the n-byte encoding of x, most significant byte first.
  • The constant empty_bytestring refers to the empty byte array. It holds that len(empty_bytestring) = 0.
  • The function xbytes(P), where P is a point for which not is_infinite(P), returns bytes(32, x(P)).
  • The function len(x) where x is a byte array returns the length of the array.
  • The function has_even_y(P), where P is a point for which not is_infinite(P), returns y(P) mod 2 == 0.
  • The function with_even_y(P), where P is a point, returns P if is_infinite(P) or has_even_y(P). Otherwise, with_even_y(P) returns -P.
  • The function cbytes(P), where P is a point for which not is_infinite(P), returns a || xbytes(P) where a is a byte that is 2 if has_even_y(P) and 3 otherwise.
  • The function int(x), where x is a 32-byte array, returns the 256-bit unsigned integer whose most significant byte first encoding is x.
  • The function lift_x(x), where x is an integer in range 0..2²⁵⁶-1, returns the point P for which x(P) = x^[1] and has_even_y(P), or fails if x is greater than p-1 or no such point exists. The function lift_x(x) is equivalent to the following pseudocode:
    • Fail if x > p-1.
    • Let c = x³ + 7 mod p.
    • Let y' = c^(p+1)/4 mod p.
    • Fail if c ≠ y'² mod p.
    • Let y = y' if y' mod 2 = 0, otherwise let y = p - y' .
    • Return the unique point P such that x(P) = x and y(P) = y.
  • The function cpoint(x), where x is a 33-byte array (compressed serialization), sets P = lift_x(int(x[1:33])) and fails if that fails. If x[0] = 2 it returns P and if x[0] = 3 it returns -P. Otherwise, it fails.
  • The function hash256_tag(x) where tag is a UTF-8 encoded tag name and x is a byte array returns the 32-byte hash SHA256(SHA256(tag) || SHA256(tag) || x).
  • The function hash512_tag(x) where tag is a UTF-8 encoded tag name and x is a byte array returns the 64-byte hash SHA512(SHA512(tag) || SHA512(tag) || x).
• Other:
  • Tuples are written by listing the elements within parentheses and separated by commas. For example, (2, 3, 1) is a tuple.

To produce CCD tweak data, a delegatee computes a per-participant scalar that aggregates the non-hardened derivation tweaks along the remaining path. Let the extended key retained by the delegatee be P at depth d, and let the target index vector be I = (i_d+1, …, i_n) with each i_k < 2³¹.

Any attempt to apply a hardened derivation (index ≥ 2³¹) MUST fail. Delegatees MAY discard P′ after extracting t if it is not otherwise required.

CCD requires the delegatee to provide per-participant tweaks for inputs and (optionally) change outputs. Tweaks for change outputs are only required if a delegator wants to be able to compute the amount of bitcoin they are spending.

A delegatee MUST provide each delegator with, for every signing context, a collection of tuples (P_i, t_i) where P_i is the participant's base public key disclosed to the delegator and t_i is the aggregated tweak returned by ComputeBIP32Tweak. The scalar t_i MUST be encoded as a 32-byte big-endian integer.

The transport that carries this bundle is out of scope for this proposal; implementers MAY use PSBT proprietary keys, RPC payloads, or bespoke messages as long as the delegator can authenticate the origin of the data. Delegatees SHOULD attach the witness script (or sufficient script template information) built with the tweaked keys when the delegator is expected to verify the input or enforce spending policy on change outputs.

Delegators use the supplied CCD tweak bundle during verification (see Delegator input and change verification) and signature generation (see DelegatorSign). The message to be signed is provided separately as part of the standard signing protocol and is not part of the CCD-specific bundle.

This BIP supports two modes:

• Non‑blinded. The delegator receives the tweak for the child public key and the message. The delegator learns only about the specific child keys and transactions it signs for; it does not learn the wider address space.
• Blinded. The delegator receives only a blinded challenge and parity bits. The delegator learns nothing about the message or child key for which it produces a signature.

For non-blinded signing, the delegator can produce signatures as usual using the tweaked key.

A delegator MAY validate the data it receives before producing signatures.

For example, input verification reassures the delegator that every tweaked key they are asked to sign for corresponds to a wallet input they recognise. Change verification lets them establish the net outflow and enforce spending policy.

Both checks rely on the same delegated tweak bundle described above.

For each input, the delegatee SHOULD disclose the descriptor template, the untweaked participant keys, the input witness script, and the per-participant tweaks. The delegator then applies the following procedure.

Successful verification of an input confirms that the delegator is signing for a script that belongs to the wallet and that the aggregate tweak values align with the expected policy.

When change outputs are disclosed, the delegator can perform an analogous check to ensure the destination script matches their policy template and to calculate outflows. Let D be the descriptor expressed in untweaked keys, W the provided witness script, and T the tweak mapping:

Successful verification ensures the change output commits to the tweaked participant keys implied by the CCD tweaks, preserving the intended policy.

The delegator may perform additional application-specific verification on the transaction (e.g., recipient addresses, amounts, compliance checks) using the message m. In the concurrently secure blinded mode, such policies can be enforced via zero-knowledge proofs that encode predicates about m. Specification of such policies is outside the scope of this BIP.

A delegator that holds only its base secret key x and public key P uses the delegated tweak bundle to derive per-input signing keys. The delegator MAY first call InputVerification and ChangeOutputVerification on any input and change output that provides a tweak in order to confirm outflow or policy requirements before signing.

The delegatee is responsible for inserting σ into the surrounding protocol (e.g., a PSBT, transaction witness, or adaptor signature exchange).

The delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'.

This blind‑signing protocol specifies how a delegator can produce a blind partial Schnorr signature that a delegatee can unblind into a standard BIP340 signature under a possibly tweaked X‑only public key. The notation, algorithmic patterns, and test‑vector style are adapted from [BIP‑327] and from the FROST Signing BIP. The design follows the “plain” blind Schnorr flow described in Concurrently Secure Blind Schnorr Signatures (ePrint 2022/1676), but without the concurrency hardening from that work.

The output signature is a BIP340 Schnorr signature valid under an X‑only key obtained by applying a sequence of plain (e.g. BIP32) and X‑only (e.g. Tapscript) tweaks to the signer’s plain public key. Consequently the protocol is compatible with BIP341. The delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'.

The plain protocol here is not concurrently secure. A signer MUST NOT run multiple blind signing sessions in parallel or interleave state across sessions. A signer MUST refuse any new blind‑nonce requests while a previous blind‑signature request is outstanding, or MUST irrevocably discard (and never reuse) any in‑flight blind nonce commitments that have not resulted in a signature, before accepting new ones.

To obtain concurrency security as in (ePrint 2022/1676), the delegatee first sends an encryption of (m, a, b) before the signer commits to the blind nonce; later, the delegatee includes a zero‑knowledge proof binding the produced challenge to that encrypted tuple. That proof can additionally encode policy predicates about m (spend limits, velocity controls, etc.). A complete specification of this variant is outside the scope of this BIP.

The following sections fully specify the non-concurrent blind signing protocol.

• Round 1 (blind nonce). The delegator runs BlindNonceGen to produce blindsecnonce and blindpubnonce and sends blindpubnonce to the delegatee.
• Round 2 (challenge). The delegatee runs BlindChallengeGen using the message m, blindpubnonce, the base public key pk, and a list of ordinary and X-only tweaks, to produce a session context (kept locally for unblinding), a blindchallenge, and two booleans pk_parity and nonce_parity. The delegatee sends blindchallenge, pk_parity, and nonce_parity to the signer.
• Round 3 (blind signature). The delegator runs BlindSign with sk, blindchallenge, blindsecnonce, pk_parity, and nonce_parity and returns blindsignature. The delegatee completes by calling UnblindSignature with the stored session context and blindsignature to obtain the final BIP340 signature sig.

The Tweak Context is a data structure consisting of the following elements:

• The point Q representing the potentially tweaked public key: an elliptic curve point
• The accumulated tweak tacc: an integer with 0 ≤ tacc < n
• The value gacc : 1 or -1 mod n

The Session Context is a data structure consisting of the following elements:

• The base public key pk: a 33-byte array
• The blind factor blindfactor: a 32-byte array
• The challenge hash challenge: a 32-byte array
• The public nonce pubnonce: a 33-byte array
• The number v of tweaks with 0 ≤ v < 2^32
• The tweaks tweak_1..v: v 32-byte arrays
• The tweak modes is_xonly_t_1..v : v booleans

• Exposure of any delegated tweak scalar t enables signing only for the specific child key(s) that scalar was derived for, and is typically short-lived if disclosed immediately before spending.
• Delegatees MUST ensure every delegated path remains non-hardened and that ComputeBIP32Tweak yields the correct tweak t; incorrect scalars could render the delegator incapable of producing a signature.
• Delegators MUST verify change outputs when tweak data is provided (for example via ChangeOutputVerification) to avoid authorizing unexpected scripts.
• Reusing the same k' (first 32 bytes in blindsecnonce) across two BlindSign calls allows recovery of the base secret key.
• When using blinded signing, opening multiple sessions concurrently against the same signer can allow an attacker to learn the base secret key. If concurrency is required, use the concurrently secure variant (encryption + ZK) instead (not specified in this BIP).

A collection of JSON test vectors are provided, along with a python reference implementation. It uses a vendored copy of the secp256k1lab library (commit https://github.com/secp256k1lab/secp256k1lab/commit/a265da139aea27386085a2a8760f8698e1bda64e a265da139aea27386085a2a8760f8698e1bda64e).

You may also find example code of CCD in action here.

• 0.1.3 (2026-02-02): Upgrade secp256k1lab and add license file; fix type checker and linter issues; clarify Delegator/Delegatee terminology, derivation constraints, signing modes, and verification scope.
• 0.1.2 (2025-12-03): Updated to reflect BIP number assignment.
• 0.1.1 (2025-11-30): Fix acknowledgments spelling, BIP3 formatting, and use "Chain Code" with a space throughout.
• 0.1.0 (2025-10-14): Publication of draft BIP

• Arik Sosman and Wilmer Paulino for the initial discussions and validation of this idea.
• Sanket Kajalkar, Jordan Mecom, Gregory Sanders, ZmnSCPxj, Yuval Kogman, and John Cantrell for code and design review.

This BIP is licensed under the BSD 3-Clause license.