“Republican_win”; “Democratic_win.” These are the parameters (and call functions) for the first smart contract escrowed bet placed on Bitcoin’s mainnet.

On Sept. 8, BTCPay Server founder Nicolas Dorier and Suredbits founder Chris Stewart entered the bet on the 2020 U.S. presidential election outcome using a discrete log contract (DSL), a form of smart contract that became feasible on Bitcoin just this year, thanks to independent Bitcoin developer Lloyd Fournier’s technical advancements in the realm of so-called “scriptless-scripts” on Bitcoin’s blockchain.

As for who took which side of the bet, Dorier and Stewart didn’t say. Even after Election Day when the votes are tallied we still won’t know who won the bet. And that’s very much the point.

Otherwise, the contracts wouldn’t be discrete.

What are discrete log contracts?

Described by developer Gert-Jaap Glasbergen as “invisible smart contracts,” discrete log contracts are structured to look like standard multi-signature transactions on Bitcoin’s blockchain. If someone were searching for the transaction on the ledger, they would have no way of knowing it’s a smart contract or, in Dorier and Stewart’s case, the details of the bet.

These smart contracts have theoretically been feasible since Bitcoin’s inception, but groundbreaking work with ECDSA adapter signatures (a cryptographic signature scheme that enables “scriptless scripts” to execute smart contracts without relying on Bitcoin’s scripting language) in the past year has brought them from theory to application. 

Read more: RGB Continues Its Work to Bring Better Smart Contracts to Bitcoin

“Technically DLCs could have been done since the original release, but a lot of the building blocks weren’t known back then. For instance, for DLCs we use ECDSA adapter signatures, whose application for this use case wasn’t discovered until this year [by Lloyd Fournier],” Suredbits developer Ben Carman told CoinDesk.

Suredbits is one of the primary actors pioneering DLC development along with Crypto Garage, Atomic Loans, Square Crypto-funded independent developer Loyd Fornier, and Chaincode Labs developer Antoine Riard.

The structure of a DLC transaction is pretty straightforward. Building on the bet between Dorier and Stewart, two parties send funds to a multi-signature address. In order to settle the transaction, an oracle would sign the contract with a signature that corresponds to the hash of the winning outcome (in this case, either Republican_Win or Democrat_Win).

The person with the hash that corresponds with the oracle’s signature can then withdraw the funds from the contract.

In Carman’s words, “It’s fancy cryptography to show that your contract is based on the oracle signature and you can only spend the funds if you have that valid oracle signature.”

DLC development is young but promising

Carman said DLCs are “still super early,” so much so that the teams working on them are still creating libraries for coding specifications.

He added that DLCs could even find a home on the Lightning Network, but this would take some advancements considering that current implementations are not hard coded to accommodate ECDSA adapter signatures. 

Accommodating ECDSA on Lightning would require the addition of point-time-lock-contracts (PTLCs), an in-the-works upgraded version of the hash-time-lock-contracts that currently operate on Lightning.

Schnorr signatures would be an ideal base for implementing PTLCs. The long-awaited Schnorr/Taproot upgrade is essential still for DLCs in general, Carman said. Even though DLCs can be executed today, more advanced use cases will be much easier to implement if Bitcoin’s codebase receives a boost from the Schnorr/Taproot softfork. 

Read more: Bitcoin’s Future: Exactly How a Coming Upgrade Could Improve Privacy and Scaling

DLC use cases

“Betting will be the primary use-case in the beginning – so, elections, sports and what-have-you,” Carman told CoinDesk. “Once it’s more established and we have a market for defining counterparties for trades, there will be use-cases for hedging or synthetic assets.”

The hedging use case is outlined by Glasbergen in his “Invisible smart contracts on the Bitcoin blockchain” blog post. The “forward contracts” would entail two parties entering a DLC, with one party agreeing to purchase a certain amount of bitcoin (BTC) for an agreed-upon price, and the other party providing the liquidity for this purchase.

When the time comes for the contract to settle, the contract pays the buyer the amount of bitcoin per the price specified at the time the contract was formed, not per the current exchange rate. In essence, these forward contracts are a way to long or short bitcoin.

These same forward contracts could be used to settle synthetic commodities (DLC contracts that represent commodities like gold and/or silver, for example) in bitcoin-denominated terms, as well.