Contract Execution Transaction (CET)

A Contract Execution Transaction (CET) is one of a set of pre-signed Bitcoin transactions created when two parties open a Discreet Log Contract (DLC). Each CET spends from the contract's shared funding transaction and encodes the exact payout split for one possible outcome of the event the contract is about. Before any funds are committed, both parties build every CET that could ever be needed — one per outcome, or one per interval when a numeric range is being covered — and exchange specially encrypted signatures for all of them. The CETs are the contract: whatever the parties agreed on, it is enforced entirely by which of these transactions can eventually be completed and broadcast.

How CETs settle a contract

The signature each party gives the other on a CET is not an ordinary signature but an adaptor signature: an encrypted, half-finished signature that can only be completed using a secret the oracle will later publish. When the real-world event resolves, the oracle releases an attestation — a signature over the outcome — and that attestation acts as the decryption key for exactly one CET: the one matching what actually happened. Either party can then complete that single transaction and broadcast it to claim the corresponding payout. Every other CET in the set remains permanently unspendable, because the secret that would complete its signature is never revealed. No cooperation is needed at settlement time; whichever party cares to collect simply does so.

Why the design matters

Because all the contract logic lives in off-chain pre-signed transactions, the Bitcoin blockchain only ever sees an ordinary-looking funding output and an ordinary-looking spend. There is no on-chain evidence that a contract existed, what its terms were, or what event it referenced — a meaningful privacy property. The oracle, meanwhile, occupies a deliberately weak position: it never touches the funds, never learns who is using its attestations or for what terms, and only signs a generic statement about an outcome it was already going to publish. It cannot steal, and if it lies, it lies publicly and identically to everyone relying on it, making dishonesty detectable and reputation-destroying. A separate, time-locked refund transaction returns both parties' collateral if the oracle vanishes or fails to attest, so even total oracle failure cannot strand funds forever.

Practical shape of a CET set

For a simple binary event, two CETs suffice. For numeric outcomes — a hashrate value, a price — the outcome space is decomposed so that a manageable number of CETs covers the full range at the agreed resolution, with adaptor signatures computed for each. Wallets handle this mechanically; the parties experience it as agreeing on a payout curve. Everything is enforced by Bitcoin's ordinary consensus rules on multisig spends and timelocks — no new opcodes, no smart-contract virtual machine, no trusted intermediary holding the money.

Why sovereignty builders care

DLCs demonstrate that meaningful conditional contracts fit inside Bitcoin as it exists today, provided you accept an oracle for the fact being contracted on. For miners, the structure is a plausible foundation for hedging instruments — difficulty or hashprice contracts settled without a custodian, aligned with the same self-custody principle that puts your keys in a hardware wallet rather than an exchange account. CETs are the settlement engine behind oracle attestation; for the data-publishing side of the same system, see oracle announcement.

The size of the pre-signed set is the design's main scaling cost — a finely resolved payout curve can mean thousands of CETs to compute and store — but the signing happens once, at setup, entirely off-chain, and DLC tooling handles the bookkeeping mechanically. What the parties keep on disk is small; what the chain ever learns is smaller still. That asymmetry, heavy preparation for a featherweight settlement, is the recurring signature of good off-chain protocol design.