# Cascading DLCs: Chaining Bitcoin Contracts with Oracle Attestation Scalars

**URL:** <https://delvingbitcoin.org/t/cascading-dlcs-chaining-bitcoin-contracts-with-oracle-attestation-scalars/2473>\
**Category:** Protocol Design\
**Created:** [May 1, 2026, 2:35pm UTC](https://delvingbitcoin.org/t/cascading-dlcs-chaining-bitcoin-contracts-with-oracle-attestation-scalars/2473 "2026-05-01T14:35:55Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Pedro\_Martins\_Novaes](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/pedro_martins_novaes/32/2046_2.png) [@Pedro\_Martins\_Novaes](https://delvingbitcoin.org/u/Pedro_Martins_Novaes)\
**Post date:** [May 1, 2026, 2:35pm UTC](https://delvingbitcoin.org/t/cascading-dlcs-chaining-bitcoin-contracts-with-oracle-attestation-scalars/2473/1 "2026-05-01T14:35:55Z")

</div>

# Cascading Discreet Log Contracts: Oracle Signatures as Contract-Activation Secrets

Hello Delving Bitcoin,

I’m sharing a whitepaper proposing **Cascading Discreet Log Contracts** , or **cDLCs**.

The main claim is narrow:

> A DLC oracle signature scalar can be used not only to settle a parent DLC, but also as the hidden scalar of adaptor signatures that activate a child DLC funding transaction.

Let the oracle’s attestation for outcome x be

s\_x = r\_o + H(R\_o \| V \| x)v \pmod n

with public attestation point

S\_x = s\_xG = R\_o + H(R\_o \| V \| x)V.

For a bridge transaction B\_e spending a parent outcome output into a child DLC funding output, each required signature is prepared as a Schnorr adaptor signature using

T\_e = S\_x.

With e = H(R^\* \| P \| m\_e), the adaptor verifies before oracle resolution:

\hat{s}G = R^\* - S\_x + eP.

After the oracle publishes s\_x, any holder of the required adaptor state computes

s = \hat{s} + s\_x \pmod n,

and obtains a valid Schnorr signature:

sG = R^\* + eP.

So the same scalar s\_x does two things:

1. completes the parent DLC outcome signatures;
2. completes the bridge transaction that funds the child DLC.

Before s\_x is known, completing B\_e requires either forging the required Schnorr signatures or finding \log\_G(S\_x). After s\_x is published, the bridge is completable by any party holding the complete prepared adaptor state.

This gives a native Bitcoin construction:

\mathrm{Funding}\_i \rightarrow \mathrm{CET}\_{i,x} \rightarrow B\_e \rightarrow \mathrm{Funding}\_j.

No new opcode, covenant, or consensus change is required. Bitcoin validates only ordinary signatures and timelocks; the cascading semantics are carried by the oracle scalar and pre-signed adaptor state.

The attached paper formalizes the construction, the security boundary, the required state-retention assumptions, and the machine-checked algebra in Ada/SPARK.

The specific review request is:

> Under the stated assumptions, is the claim correct that a DLC oracle attestation scalar can serve as the adaptor secret for a child-funding bridge transaction, thereby allowing one DLC outcome to activate another DLC without consensus changes?

repo: [GitHub - dev865077/NITI · GitHub](https://github.com/dev865077/NITI)

Whitepaper: [NITI/Cascading Discreet Log Contracts (cDLCs).pdf at ab9363f2d118f799a6d80e77519527ef07aff7d6 · dev865077/NITI · GitHub](https://github.com/dev865077/NITI/blob/ab9363f2d118f799a6d80e77519527ef07aff7d6/Cascading%20Discreet%20Log%20Contracts%20(cDLCs).pdf)

---

<div class="post-metadata">

**Author:** ![nkohen](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/nkohen/32/1792_2.png) [@nkohen](https://delvingbitcoin.org/u/nkohen)\
**Post date:** [May 5, 2026, 2:46pm UTC](https://delvingbitcoin.org/t/cascading-dlcs-chaining-bitcoin-contracts-with-oracle-attestation-scalars/2473/2 "2026-05-05T14:46:05Z")

</div>

Perhaps I’m missing something obvious, but I’m confused as to why you can’t just have the parent CET act as the child funding tx, and then avoid all other complexity? Since the CET is locked using an adaptor signature I don’t see why you would need to further use s\_x in locking the child DLC since it can already only be funded if the parent CET is unlocked.