# [dlc-dev] Support for Conjunctive Contracts

Matthew Black matthew at atomic.finance
Sun Jan 2 21:00:21 UTC 2022

```Happy New Year everyone!

Nadav and I were recently chatting about an idea to allow for more advanced
contracts that extends upon existing functionality for disjoint union. It
was inspired by this scenario:

Oracle 1: Attests whether a stop loss got hit on a particular contract
Oracle 2: Attests to bitcoin price upon maturity of a contract
Oracle 3: Attests to a different numeric value (say mark price of an option
for example) upon maturity of a contract

A scenario where a contract uses bitcoin price from oracle upon maturity to
execute unless it hits a stoploss before expiry is already possible with
disjoint union, but adding a "second leg" which uses different conditions
for payout upon maturity in the case that a stoploss is hit for example, is
not.

In disjunctive normal form, this scenario could be represented by:
(O1_true AND O2) XOR (O1_false AND O3)

As Nadav mentioned to me, should be possible to add to the spec with an
extension of the current disjoint union scheme if we introduce a
"conjunctive contract" (i.e. an AND contract) because then we can do a
disjoint union DLC where each element of the union is one of these AND
contracts.

To achieve this we can use aggregate adaptor points (similar to what is
used for n-of-n oracles in multi-oracle scheme)

For example:
O1 False Adaptor Point: s1_false*G = R1 + H(X, R1, “false”)*x
O1 True Adaptor Point: s1_true*G = R1 + H(X, R1, “true”)*x
O2 Adaptor Point: s2*G = R2 + H(X, R2, m)*x
O3 Adaptor Point: s3*G = R3 + H(X, R3, m)*x

O1_true AND O2 Adaptor Point: s1_true*G + s2*G = R1 + H(X1, R, “true”)*x1 +
R2 + H(X2, R2, m)*x2
O2_false AND O3 Adaptor Point: s1_false*G + s3*G = R1 + H(X1, R,
“false”)*x1 + R3 + H(X3, R3, m)*x3

(for m1, m2, m3...)

One of way of adding this to the specification might be to add a new
contract_info type (v2 perhaps) that allows for an ENUM oracle (O1) where
each disjoint event corresponds to a value reported in O1. However this
wouldn't allow more complicated contracts that could use a different
combination of oracles.

For now I think it would be fine to enable the simplest case with one
oracle with ENUM events that each correspond to disjoint events.

Looking forward to hearing people's thoughts!

Cheers,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20220102/bc1dc455/attachment.htm>
```