I notice that it is hard for people to imagine the workflow with Discreet Log Contracts and Oracles. I will try to explain it in less technical way.
Discreet Log Contracts (DLCs) allow two parties (or more) to enter into a trust-minimized agreement about the outcome of a real-world event—like the final score of a UEFA Champions League match, an asset price on a specific date, or any other verifiable fact. However, blockchains themselves don’t inherently know anything about the world outside their own network. They only validate the transactions and states that occur internally. This gap is where an oracle steps in. An oracle provides the verified data point—like the match winner or final price—so that the DLC can execute appropriately.
Bridging the Outside World to the Blockchain
In a DLC, both parties lock their funds in a contract that will pay out depending on an external event. Think of it like a bet on a match’s outcome: Alice wagers on Team A, Bob wagers on Team B. When the match concludes, they need an authoritative source to attest which team actually won. The oracle is that source. After the match, it publishes a cryptographic signature indicating the winner. If Alice’s team won, she uses the oracle’s signature to claim the funds in the contract; if Bob’s team won, he does the same. The key point is that the oracle does not hold the funds or control them—it merely offers the data to unlock them.
One of the most notable advantages of DLCs is that the oracle itself doesn’t know who is using its data. It also doesn’t need to sign off on every DLC individually. Instead, the oracle simply posts a signed statement of the event outcome—“Team A won” or “Team B won”—to a public location. It can be published on Blue Sky, this forum, Discord, IRC or anything else.
Anyone who follows that oracle can verify the signature with the oracle’s public key. The DLC’s terms are crafted in advance to trust that signature for settlement, but there is no formal or direct link between the oracle and each individual contract.
Twelve Monkeys
Imagine an oracle… This specific oracle is made of 12 individuals who collectively operate an oracle service - specializing in UEFA Champions League. They are football enthusiast and watch basically every single game, know all the players and love to track the stats. It is their hobby. They found out that they can earn few coins by running the oracle service and here we are.
From the outside, this oracle appears as a single public key on the blockchain. There’s no sign of the group’s internal structure or the multiple signatures hidden beneath. Yet behind that single public key, these 12 contributors coordinate to deliver real-time data: match outcomes, corner counts, red cards, and the Man of the Match.
Internally, the oracle can be organized by a simple - human to human consensus. Like, people just talk to each other and reach some conclusion. They can coordinate using a Discord chat, Telegram chat, they can be on the phone. They can sit in the same room and shout at each other. It does not matter, as long as they do have capability of reaching consensus. It can also be organized with a private blockchain, or just about anything else. We don’t care, and users don’t care either.
This Oracle doesn’t interact with end-users directly in any sense; it simply beams signed messages into the public space. People who are interested—bettors, data analysts, or sports fans—pay for access to this data feed. The Oracle itself neither knows nor cares about who subscribes and why, whether bets are placed or not, or how the data is ultimately used.
Internal Mechanics of the Distributed Oracle
ROAST Swarm Architecture
Internally, each participant in the 12-person collective holds a private key share. Any proposed broadcast—be it the final score of a match or the number of cards—needs a threshold of these key shares to produce one valid Schnorr signature. Let’s say this is 9-of-12. That means that at least 9 participants need to sign for signature to be valid.
The system’s robustness means that even if a few members drop out (time zones, device malfunctions, unavailability), the swarm can still function.
Proposals and Validation
When a major event occurs in a UEFA Champions League match—like a goal, or final whistle—any participant can propose an update via a Peercoin Flutter wallet.
This proposal circulates within the group. Members confirm the accuracy of the data (often referencing their sources) and then collectively decide whether to sign it.
If the threshold is met, the swarm produces a single signature. Outsiders see a single signature, but internally it represents distributed consensus among 12 individual operators.
Publication
Once signed, the data points are appended to a feed—a continuously updated record of match events and related stats.
End-users, having subscribed to this feed, monitor it for crucial updates like final results, discipline records, and other stats.
Verification is straightforward: if the signature is valid against the known public key, the data is genuine. Any tampered or fake update fails verification.
Commercialization and Access
People ask on how to monetize the oracle services, and here is my idea on how to best do that. By charging the subscription to a data feed.
Pay-to-Access Model
- The Oracle charges consumers for the right to read and verify its data stream. This can happen via on-chain payment, off-chain payment (LN), or any other method agreed upon.
- The feed might be offered at different tiers—ranging from basic final-score updates to premium stats, such as corners and man-of-the-match announcements.
Mutual Anonymity
- Because the Oracle does not require personal details, it remains agnostic about who is reading the feed. It only sees payment requests and subsequent transaction confirmations.
- Subscribers, in turn, see only a single public key known to have a track record for reliable sports data. They never learn who the 12 operators are or how they coordinate internally.
Operational Workflow in Practice
Publishing the Schedule of Fixtures
Before anyone can enter into a bet using a Discreet Log Contract, they need to know which events the oracle intends to cover. That’s why an oracle will typically publish a schedule of fixtures in advance—listing the dates, teams, and any other relevant details for upcoming UEFA Champions League matches. This schedule is made available through the oracle’s official feed possibly alongside a unique identifier for each match that the oracle will use when it eventually signs the outcome. By making this information public well before kickoff, prospective bettors can create DLCs around specific matches.
Creating DLCs Based on the Published Events
Armed with this schedule, two parties can negotiate the terms of their DLC. For instance, Alice might bet that Team A will win, while Bob takes Team B. They craft a DLC contract that references the oracle’s identifiers for the relevant match. If Team A wins, Alice can use the future oracle signature to claim her winnings; if Team B wins, Bob will do the same. Importantly, the oracle remains unaware of these individual DLCs. It does not approve or record them. Instead, all the oracle needs to do is reliably publish final data.
Match Day Routine
Matches occur, and each crucial event (goals, cards, corners) prompts an internal update if deemed important enough for the feed.
Multiple participants of oracle ROAST swarm verify the event data quickly—often relying on real-time viewing or online score trackers.
A threshold of signers confirms the data is correct, which produces the unified Schnorr signature.
Asynchronous Coordination
Operators don’t need to be in the same time zone or even online at the same moment. The ROAST protocol allows partial commitments—some sign right away, others sign after the fact. Once the threshold is reached, the signed update is published.
A handful of members temporarily offline does not grind the system to a halt. Robust.
Publishing Signed Results Post-Match
Once the match is complete, the oracle generates and posts the final result as a cryptographic signature. To outsiders, it appears as a single message. This signature is all that any DLC participant needs to resolve their contract. Since the oracle’s public key is known, anyone can independently verify the authenticity of the posted data. This public, one-to-many approach means the oracle isn’t sending tailored signatures to specific bettors—rather, it simply broadcasts one universally verifiable signature that anyone can reference.
Users Claiming Their Winnings (Manual Settlement)
DLCs are not self-executing. Once the signature is published by the oracle, it’s up to the winning party—Alice or Bob—to actively settle the contract. Suppose Alice bet on Team A, and the oracle’s published data indeed indicates that Team A won. Alice retrieves the Oracle’s signature from the public feed and uses it to craft the withdrawal transaction and claim the winnings. If everything lines up, the blockchain will verify the Oracle’s signature corresponds to “Team A wins,” allowing Alice to spend (or “withdraw”) the locked funds. Meanwhile, Bob can see the valid signature, verify the outcome, and recognize that he lost the bet. Nothing Bob can do at this point.
