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.
\nIn 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.
\nIn CCD, the chain code is the object of delegation—not signing authority. A participant who gives up their chain code delegates it to another.
\nCCD 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.
\nThe 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.
\nGiven a candidate X coordinate x in the range 0..p-1, there exist either exactly two or exactly zero valid Y coordinates. If no valid Y coordinate exists, then x is not a valid X coordinate either, i.e., no point P exists for which x(P) = x. The valid Y coordinates for a given candidate x are the square roots of c = x3 + 7 mod p and they can be computed as y = ±c(p+1)/4 mod p (see Quadratic residue) if they exist, which can be checked by squaring and comparing with c. 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:
\nTo 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 = (id+1, …, in) with each ik < 231.
\nAny attempt to apply a hardened derivation (index ≥ 231) MUST fail. Delegatees MAY discard P′ after extracting t if it is not otherwise required.
\nCCD 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.
\nA delegatee MUST provide each delegator with, for every signing context, a collection of tuples (Pi, ti) where Pi is the participant's base public key disclosed to the delegator and ti is the aggregated tweak returned by ComputeBIP32Tweak. The scalar ti MUST be encoded as a 32-byte big-endian integer.
\nThe 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.
\nDelegators 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.
\nThis BIP supports two modes:
\nBoth modes produce valid BIP340 signatures.
\nFor non-blinded signing, the delegator can produce signatures as usual using the tweaked key.
\nA delegator MAY validate the data it receives before producing signatures.
\nFor 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.
\nBoth checks rely on the same delegated tweak bundle described above.
\nFor 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.
\ntrue if W′ = W, otherwise false.\nSuccessful 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.
\nWhen 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:
\ntrue if W′ = W, otherwise false.\nSuccessful verification ensures the change output commits to the tweaked participant keys implied by the CCD tweaks, preserving the intended policy.
\nThe 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.
\nA 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).
\nThe delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'.
\nThis 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 (MuSig2)] 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.
\nThe 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'.
\nThe 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.
\nTo 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.
\nThe following sections fully specify the non-concurrent blind signing protocol.
\nBlindSign MUST NOT be executed twice with the same blindsecnonce. As a defense, implementations SHOULD overwrite the first 64 bytes of blindsecnonce with zeros after they have been read by BlindSign.
\nThe Tweak Context is a data structure consisting of the following elements:
\nWe write \"Let (Q, gacc, tacc) = tweak_ctx\" to assign names to the elements of a Tweak Context.
\nThe blindsecnonce is effectively a local data structure of the signer which comprises the value double (k', pk), and implementations may choose any suitable method to carry it from BlindNonceGen (first communication round) to BlindSign (third communication round). In particular, implementations may choose to hide the blindsecnonce in internal state without exposing it in an API explicitly, e.g., in an effort to prevent callers from reusing a blindsecnonce accidentally.
\nThe Session Context is a data structure consisting of the following elements:
\nWe write \"Let (pk, blindfactor, challenge, pubnonce, v, tweak1..v, is_xonly_t1..v) = session_ctx\" to assign names to the elements of a Session Context.
\nt enables signing only for the specific child key(s) that scalar was derived for, and is typically short-lived if disclosed immediately before spending.\nt; incorrect scalars could render the delegator incapable of producing a signature.\nA collection of JSON test vectors are provided, along with a python reference implementation. It uses a vendored copy of the secp256k1lab library (commit a265da139aea27386085a2a8760f8698e1bda64e).
\nYou may also find example code of CCD in action here.
\nThis BIP is licensed under the BSD 3-Clause license.
","toc":[{"id":"abstract","title":"Abstract","level":2},{"id":"motivation","title":"Motivation","level":2},{"id":"terminology","title":"Terminology","level":2},{"id":"overview","title":"Overview","level":2},{"id":"specification","title":"Specification","level":2},{"id":"key-material-and-setup","title":"Key material and setup","level":3},{"id":"notation","title":"Notation","level":3},{"id":"tweak-calculation","title":"Tweak Calculation","level":3},{"id":"delegation-bundle","title":"Delegation Bundle","level":3},{"id":"signing-modes","title":"Signing Modes","level":3},{"id":"non-blinded-signing","title":"Non-Blinded Signing","level":4},{"id":"blinded-signing","title":"Blinded Signing","level":4},{"id":"security-considerations","title":"Security Considerations","level":2},{"id":"test-vectors","title":"Test Vectors","level":2},{"id":"changelog","title":"Changelog","level":2},{"id":"footnotes","title":"Footnotes","level":2},{"id":"acknowledgements","title":"Acknowledgements","level":2},{"id":"copyright","title":"Copyright","level":2}],"history":{"totalCommits":3,"firstCommit":"2026-02-05T04:58:08+08:00","lastUpdated":"2026-09-15T02:56:36+04:00","events":[{"sha":"3a13d60ff202b94b9e02e7c58d6a7e87a94f3899","date":"2026-09-15T02:56:36+04:00","author":"Kanan","message":"bips 89/114/441: add missing Footnotes and references tag (#2289)","url":"https://github.com/bitcoin/bips/commit/3a13d60ff202b94b9e02e7c58d6a7e87a94f3899","kind":"edit"},{"sha":"b7bf6dda11d0d537bfaf951c36a2cc1d431f7e41","date":"2026-08-12T21:09:25-07:00","author":"Jurvis Tan","message":"docs: advance bip89 to deployed","url":"https://github.com/bitcoin/bips/commit/b7bf6dda11d0d537bfaf951c36a2cc1d431f7e41","kind":"status"},{"sha":"57869d524abb9143ba96aa9f53fab906ec309383","date":"2026-02-05T04:58:08+08:00","author":"Jurvis Tan","message":"BIP 89: Chain Code Delegation for Private Collaborative Custody (#2004)","url":"https://github.com/bitcoin/bips/commit/57869d524abb9143ba96aa9f53fab906ec309383","kind":"edit"}]}}