Witnet: A Decentralized Oracle Network Protocol

1.1. Motivation

• Smart contracts have little capability to interact with the outside world, while a single oracle creates a single point of failure and leaves claims open to contestation and repudiation.The proposed response is a decentralized oracle that relies on a plurality of participants rather than blind trust in one attesting party.Source: §1.1 · p. 5

1.2. Solution Overview

• Witnet’s claims combine potentially conflicting claims from anonymous miners, who are incentivized to tell the truth.The proposal compares the tally of volunteer peers’ claims to a decentralized prediction market.Source: §1.2 · p. 6
• The protocol is a blockchain-based Decentralized Oracle Network with a native token: clients pay for retrieved, attested, and delivered web content, and witnesses earn tokens for the work.Witnesses are computers running software that automatically receives and executes tasks.Source: §1.2 · p. 6

1.3. Key Components

• The reputation-based mining protocol uses task assignments instead of wasteful computation as proof of work.Witnesses also participate in creating new blocks, with mining likelihood tied to prior performance.Source: §1.2 · p. 6, §1.3 · p. 7
• The reputation-based task-assignment protocol is designed to assign tasks to miners in a decentralized, fair, uniform, unpredictable yet deterministic way.Witnesses gain reputation when their claims match the majority and lose it when their claims contradict the majority.Source: §1.2 · p. 6, §1.3 · p. 7
• Bridge nodes handle the Deliver part of RAD tasks, allowing Witnet to interact with other blockchains.They also monitor other blockchains for potential RAD requests to introduce into Witnet.Source: §1.3 · p. 7

2. Definition of a Decentralized Oracle Network

• A Decentralized Oracle Network is a peer-to-peer network that acquires external information, verifies and agrees on its veracity, and supplies it to applications or networks.The paper summarizes this as a P2P network capable of processing Retrieve-Attest-Deliver requests.Source: §2 · p. 8

2.1. Retrieve-Attest-Deliver (RAD) Requests and Tasks

• RAD requests specify how information must be retrieved, attested, and delivered; a request assigned to a participant becomes a RAD task.Participants retrieve the information, check that they have verbatim copies, and make it available to the requester.Source: §2.1 · p. 8
• Sharding can assign a RAD task to only a fraction of participants to reduce its computational, energetic, and monetary cost.The paper notes that participants may have conflicting interests and could submit false, biased, or fabricated claims, which may contradict the majority.Source: §2.1 · pp. 8–9
• A DON can use past honesty to vary task-assignment chances, rewarding participants whose claims match the majority and withholding rewards from claims that do not.A participant assigned a task receives a fraction of the attached tokens if its claim matches the majority.Source: §2.1 · pp. 8–9

• Witnet’s proposed network combines decentralized oracle services with algorithms and strategies intended to improve RAD results and detect and penalize collusion.The design draws on consensus, reputation-based voting, collusion-resistance, and witness-diversity approaches.Source: §3 · p. 10

3.1.1 Participants

• Clients pay Wit for retrieval, attestation, and delivery; witnesses earn for retrieval and attestation, while bridges deliver results and relay requests across blockchains.Bridges are witnesses, and witnesses are clients, though not every client is a witness.Source: §3.1.1 · pp. 12–13

3.1.2 The Network, N

• The protocol treats node-running users collectively as the Network, which runs Manage each block; their computers automatically execute RAD tasks using configured resources.Participants configure how much CPU and internet bandwidth to devote to RAD tasks.Source: §3.1.2 · p. 13

3.1.3 The Ledger, L

• Checkpoints occur every 90 seconds, snapshot the preceding ledger state, and mark epochs; pseudo-randomly elected witnesses may mine exactly one block per epoch.Miners choose how many transactions to include, with transaction fees incentivizing inclusion.Source: §3.1.3 · p. 14
• Witnet uses a DAG ledger in which multiple correctly formed blocks with valid leadership proofs may coexist for the same epoch.The protocol allows forked valid chains to merge without endangering double-spend protection.Source: §3.1.3 · pp. 14–15, Figure 3 · p. 14
• Transactions are independent hashed objects referenced by blocks; same-checkpoint blocks may share pointers, but different checkpoints cannot point to the same transaction.The pointer in the lowest-checkpoint block is the valid one.Source: §3.1.3 · p. 15
• When transactions spend the same UTXO in one checkpoint, its value is split equally among them, and outputs are expressed as percentages of input value.Each of n transactions spending a UTXO of value v can spend at most v/n coins.Source: §3.1.3 · p. 15

3.1.4 The Coin, Wit

• Block rewards start at 500 Wit and halve every 1,750,000 blocks, or about five years; issuance will never exceed 2,500,000,000 Wit.As inflation tends toward zero, miners' income comes from transaction fees.Source: §3.1.4 · p. 16

3.1.5 The Headless Browser, B

• Witnesses use headless browsers to visit requested URLs and run specified computations; parallel instances support cross-checking, and human-like browsing is said to prevent website tampering.A request may script which data units to retrieve; the browser closes when finished.Source: §3.1.5 · pp. 16–17

3.2.1 General Case

• Clients can choose the number of assigned witnesses to adjust attestation certainty, while request cost depends on retrieval complexity, expected certainty, and use of Retrieve clauses.The client encodes the RAD request as a Witnet transaction; an optional Deliver clause lets bridges send the result onward.Source: §3.2.1 · pp. 17–18
• Designated witnesses retrieve the requested web content, commit a nonced hash derived from their claim, the miner’s public key, and the latest block hash, then reveal claims for consensus.Valid pledges reserve a share of the request’s reward; truthful witnesses earn reputation, while liars lose reputation and cannot redeem their reward.Source: §3.2.1 · p. 17

3.2.2 Specific Data Units Retrieval

• A flow-based scripting language lets clients select a specific web-page element and apply basic transformations to it.The URL and script together form a retrieval path, whose computational complexity and returned-data size affect RAD cost.Source: §3.2.2 · p. 19

3.2.3 Multiple Sources Fact Cross-checking

• A single request can include multiple retrieval paths, using MapReduce-style normalization and aggregation to merge data from different sources despite format differences.Each path’s normalization script runs separately before an aggregation function processes the resulting values.Source: §3.2.3 · pp. 19–20

3.2.4 Future Facts

• A time lock can keep a request unresolved until its specified future point, when witnesses are incentivized to resolve it and collect its fees.Replace-By-Fee lets clients republish the request with a higher reward if its retrieval paths remain unchanged.Source: §3.2.4 · p. 21

3.3.1 Undecidability

• A statement is decidable if its truth can be assessed now or will become assessable; it is undecidable if no correct, determined value can be reached after finite time.Whether a statement is assessable can itself be undecidable, so future assessability cannot always be predicted or assured.Source: §3.3.1 · p. 21

3.3.2 Unverifiability

• Witnet cannot process some true facts lacking verifiability; attestation depends on valid retrieval paths, and requests pointing to nonexistent content or producing contradictory claims cannot be attested.The client is responsible for including valid, provable retrieval paths.Source: §3.3.2 · p. 23

3.4.1 Client Cycle

• Clients post RAD requests with a replication factor of at least 2; higher redundancy increases attestation certainty, and a factor around 6 is suggested for most cases while controlling costs.A client with an up-to-date ledger copy can read request results locally without transaction cost.Source: §3.4.1 · pp. 23–24

3.4.2 Witness Cycle

• Witnesses discover assignments, retrieve their tasks, and commit claims with proof of assignment before revealing claims and redeeming rewards.Requests with a precondition remain unresolved until that condition is met.Source: §3.4.2 · pp. 24–25

3.4.3 bridge Cycle

• Bridges discover delivery assignments and report attested results to other blockchains for allocated Wit rewards; they can also convert requests found on other chains into Witnet RAD requests.Bridge operators spend their own time and coins to send reports.Source: §3.4.3 · p. 25

3.4.4 Network Cycle

• At each epoch, participants validate received blocks and transactions, check for block-mining leadership, and elected miners may produce one block at the epoch’s end.Block validation includes checking leadership proofs and transaction Merkle roots.Source: §3.4.4 · p. 26
• A block miner’s right to produce a block depends on a valid proof of leadership, and blocks must be broadcast during the next epoch or may be rejected.Blocks are limited to 1MB.Source: §3.4.4 · pp. 26–27

4. Reputation

• Reputation scores determine participants’ chances of assignment to RAD tasks and block mining, while the total reputation supply is fixed and scores cannot be created or destroyed after checkpoint 0.Reputation points are liabilities as well as assets: participants lose them through demurrage if they hoard rather than witness tasks.Source: §4 · p. 28, §4.1 · p. 28

4.1. Reputation Protocol

• Honest witnesses gain reputation by agreeing with the majority, while witnesses that contradict or fail to agree lose it; epoch demurrage is redistributed to honest miners who fulfill tasks.Demurrage deducts reputation in proportion to each score, so larger scores decay more rapidly; the decay rate D controls how progressive the effect is.Source: §4.1 · p. 29

4.2. Truth-By-Consensus and SVD

• Truth-By-Consensus uses reputation-weighted claims and SVD to detect and remove outliers and coordination, redistributing reputation among timely witnesses.Reputation redistribution can become computationally expensive as the participant count increases; infrequent recomputation reduces cost but can defer punishment.Source: §4.2 · p. 31
• Truth-By-Consensus gives participants an incentive to perform assigned RAD tasks honestly because potential income depends on maintaining reputation.When claims are unanimous, reputation scores do not change apart from demurrage.Source: §4.2 · p. 31

5. Useful Work Consensus Algorithm

• Witnet elects miners and RAD-task participants in proportion to their reputation relative to the network’s total reputation, using randomness rather than purchasing power or electricity costs.A participant’s influence is its share of the reputation of the engaged set, avoiding an assumption that every possible key pair is an active competitor.Source: §5 · pp. 33–34

5.1. Reputation-Based Mining Protocol

• The mining protocol uses epoch randomness and a participant’s secret-key signature to make eligibility probabilistic, secret, and publicly verifiable, with selection probability proportional to reputation influence.The protocol expects one miner per epoch on average, but some epochs can have multiple eligible miners or none.Source: §5.1 · pp. 34–35
• If elected miners fail to produce valid blocks, backup miners can take over; among valid blocks, the network accepts and works on those with the lowest backup index B.Participants may broadcast blocks for multiple B values, but higher-index blocks are only useful if no valid lower-index block is produced.Source: §5.1 · p. 35

5.2. Reputation-Based Task Assignment Protocol

• RAD-task assignment uses reputation-based probabilistic selection, but a specified replication factor cannot guarantee the actual witness count; when assignments fall short, the protocol seeks vacant positions in later epochs.The request’s replication factor specifies the minimum number of witnesses, and the shortfall is pursued through repeated assignment rounds.Source: §5.2 · pp. 36–37

6. Transactions

• A Witnet transaction is a pure function that maps a valid ledger state to a different valid ledger state, and is valid over a state when that state belongs to its domain.Two transactions are independent over a state when both are valid there; g depends on f when g is invalid on the initial state but valid after f is applied.Source: §6.1 · p. 38
• For any two different valid states, the section asserts there is exactly one transaction that maps the initial state to the final state.This is stated as the completeness theorem.Source: §6.1 · p. 38
• For any valid initial and final states, infinitely many finite transaction sets can compose to transform the initial state into the final state.The section also states that each finite transaction set has a unique transaction equivalent to its composition.Source: §6.1 · p. 38
• Transaction composition is commutative if and only if all transactions in the set are independent of one another.Independence is defined over the state on which the transactions are applied.Source: §6.1 · pp. 38–39

6.2. Types of Transactions and Standard Outputs

• Value transfer transactions (VTTs) are roughly equivalent to Bitcoin’s P2PKH and P2SH transactions.Source: §6.2 · p. 39
• Client RAD request transactions encode retrieval paths, an aggregator function, and optionally one or more deliver clauses.Source: §6.2 · p. 39
• Witness commit-pledge transactions commit retrieval results without revealing the claims and pledge the witness’s portion of the reward.Source: §6.2 · p. 39
• Witness reveal-redeem transactions reveal previously committed claims and redeem the witness’s portion of the reward; all listed transaction types use the same serialization format and output scripting language.Source: §6.2 · p. 39

6.3.1 Miner fees

• Miner fees let transactors compete for limited block space, and rising demand can form a backlog that raises fees and discourages excess transactions until block space demand and fees reach a balance.While blocks have room, fees are expected to stay low; Witnet miners are not compelled by expensive mining operations to reject low- or zero-fee transactions when all pending transactions fit.Source: §6.3.1 · pp. 39–40

6.3.2 Witness fees

• Witness fees depend on acquisition-path count, normalization-script complexity, and the client’s replication factor, providing an absolute measure of a RAD request’s cost against limited network capacity.A witness’s reward is the request fee divided by the number of witnesses who commit solutions, which is at least the replication factor.Source: §6.3.2 · pp. 40–41
• Witnesses’ direct task costs are described as negligible relative to rewards, while commit-pledge and reveal-redeem miner fees are the significant costs; reputation can also make miner fees an indirect bonus for honest witnesses.Block rewards are periodically halved, so miner fees are expected to gain importance as mining becomes less subsidized.Source: §6.3.1 · p. 40, §6.3.2 · p. 41

6.3.3 Bridge fees

• Bridge fees follow the same criteria as witness fees.Source: §6.3.3 · p. 41

6.4. Outputs and Scripting

• WitScript locks tokens in outputs under redemption conditions, and segwit support is intended to accommodate other contract languages and signature schemes.Potential languages include EVM, Michelson, and Simplicity; Schnorr signatures are cited as an alternative to ECDSA.Source: §6.4 · pp. 41–42

6.4.1 MAST and Tail Call Execution

• MAST commits to possible script pathways while revealing only the path used at spend time; Tail Call Execution runs serialized scripts and inputs left on the stack.Tail-call results replace the remaining elements in the main stack.Source: §6.4.1 · p. 42

6.4.2 Covenants

• Covenants make spending transactions obey inherited output-script templates, enabling RAD requests to require commit-pledge transactions followed by reveal-redeem transactions.Wallets must check incoming value transactions for covenant clauses before treating their funds as freely spendable.Source: §6.4.2 · pp. 42–43

6.4.3 Bundled Macros

• WitScript macros reduce the storage and transmission footprint of frequent transaction formats, and precompiled implementations can also speed execution.Figure 17 describes an M_REQUEST example: elected miners may pledge part of locked funds if all transaction outputs start with M_PLEDGE; otherwise, the requester may seek a refund after 10 blocks.Source: §6.4.3 · pp. 43–44, Figure 17 · p. 43

7.1. Bridges: Interacting with other Platforms

• Bridge nodes connect Witnet with other platforms, including Ethereum, decentralized storage networks, and the web.Different platform bridges may use different values for the n parameter in task assignment.Source: §7.1 · p. 45

7.1.1 Ethereum Bridges

• Ethereum bridges convert requests found in Ethereum transactions into Witnet RAD requests and report specified results back to Ethereum.They spend Wits to introduce requests and ether for gas when reporting; Ethereum clients must fund both bridge roles.Source: §7.1.1 · p. 45

7.1.2 Decentralized Storage Networks (DSN) Bridges

• DSN bridges publish RAD results to decentralized storage networks and are intended to ensure those results persist there.The proposed use includes preserving access to truth and human knowledge.Source: §7.1.2 · p. 46

7.1.3 Web Bridges

• Web bridges offer public endpoints for submitting requests and reading results, plus WebHook or EventSource notifications for clients.Their components may be APIs, user interfaces, or both, and may also serve as block explorers.Source: §7.1.3 · p. 46

7.2. Native Smart Contracts

• Witnet's stateless smart contracts can read RAD results with OP_READ and make an output spendable by different parties according to whether the result is above or below 50,000.The paper describes this simple example as previously impossible to implement trustlessly.Source: §7.2 · p. 47

A.a. Motivation

• Centralized web archives offer limited guarantees of content and custody integrity, and a single source of truth can be a failure point for historical records.Digital content may become unverifiable as links break or sources disappear.Source: A.a. Motivation · p. 49

A.b. Knowledge Commons and Commons-based Peer Production

• The Ark is conceived as a peer-produced contribution to the knowledge commons, whose shared knowledge resources can be accessed by multiple users without diminishing them.The proposal aims to engage people in enriching and preserving that commons.Source: A.b. Knowledge Commons and… · p. 50

A.c. Preservation and its Principles

• The Ark adopts preservation principles including decentralized preservation, original content, perpetual access, affordability, and sustainability, using DONs, DSNs, and blockchain technologies.The listed principles are attributed to the LOCKSS program.Source: A.c. Preservation and its Principles · p. 51

A.d. Using Witnet to Agree on Facts to be Preserved

• To archive information, a client creates a RAD request with retrieval paths, adds a DSN delivery clause, funds rewards, and submits it directly or through bridges.If these conditions are met, Witnet retrieves and attests the information and bridge nodes publish it to the chosen DSN.Source: A.d. Using Witnet to Agree on Facts to… · p. 51

A.e. Persisting Facts and Contents in Perpetuity

• The proposed perpetual archive depends on storage contracts with defined durations, so maintaining data requires recurrent costs and continued funding.Clients or other interested parties can extend a contract by adding tokens; large data units are directed to decentralized storage solutions designed for high volumes.Source: A.e. Persisting Facts and Contents in… · pp. 52–53