DCO: DEOS Computing Oracle

Verifiable off-chain computation for smart contracts

Version 1.0, January 2026

Summary

DCO is a verifiable computation layer for blockchain applications. The standard answer to "how do we trust off-chain computation" is redundancy: run the same job on N nodes and take the median or the majority. That works, but it pays N times the cost for one job's worth of output. DCO runs the job once and proves the result with deterministic replay, backed by an optimistic fraud-proof model with the same security profile as Arbitrum or Optimism. The cost difference is roughly an order of magnitude.

1. The problem

1.1 What smart contracts can and cannot do

Smart contracts have hard limits.

The combined effect is that nontrivial computation has to happen off-chain. Once it does, the on-chain contract needs some way to trust the result.

1.2 The oracle problem

Off-chain computation introduces a trust question: how does a smart contract know the off-chain answer is correct? The current answer is redundancy.

Traditional oracle model:
- N nodes independently compute the same result
- Results are aggregated (median, majority)
- Trust = economic stake + redundancy
- Cost  = N * computation cost

This is secure but inefficient. For every job, N machines do identical work.

1.3 What the market is paying

The market pays 100x to 1000x more than the compute itself costs. The premium is for verifiability, and most of it is wasted on redundancy rather than going to verification.

2. The DCO model

2.1 The shift

Computation only needs to happen once if it can be verified. So instead of N redundant executions:

DCO model:
- 1 node executes the computation
- Execution is deterministic and logged
- Anyone can replay and verify after the fact
- Fraud is cryptographically provable
- Cost  = 1 * computation cost

2.2 The substrate

DCO runs on DEOS, a deterministic event-sourced operating system. Four properties carry the model:

• Deterministic execution. Same inputs always produce the same outputs.
• Event sourcing. Every operation is logged to a tamper-evident chain.
• Replay capability. Any execution can be re-run from the log and produce the same result.
• Content addressing. All data is referenced by hash.

These properties together let computation be verified without being repeated.

2.3 Trust model

Optimistic fraud proof, the same model that secures Arbitrum and Optimism:

1. Operator executes the computation.
2. Operator posts the result, the execution hash, and a stake.
3. A challenge period opens (1 hour by default).
4. Anyone can challenge by initiating a replay.
5. If fraud is proven, the operator loses the stake.
6. If no challenge fires, the result finalizes.

Security comes from verifiability rather than redundancy. The honest operator gets paid. The dishonest operator gets slashed.

3. Architecture

3.1 Components

+-----------------------------------------------------+
|                User / Smart Contract                |
+-------------------------+---------------------------+
                          | Request
                          v
+-----------------------------------------------------+
|                     DCO Gateway                     |
|  - Request validation                               |
|  - Operator selection                               |
|  - Result aggregation                               |
+-------------------------+---------------------------+
                          |
                          v
+-----------------------------------------------------+
|                    DEOS Runtime                     |
|  +---------------------------------------------+    |
|  |          Computation Environment            |    |
|  |  - WASM execution                           |    |
|  |  - Deterministic scheduling                 |    |
|  |  - Event logging                            |    |
|  +---------------------------------------------+    |
|  +---------------------------------------------+    |
|  |          Verification Layer                 |    |
|  |  - Execution hash generation                |    |
|  |  - Replay capability                        |    |
|  |  - Fraud proof generation                   |    |
|  +---------------------------------------------+    |
+-------------------------+---------------------------+
                          |
                          v
+-----------------------------------------------------+
|                  On-Chain Contracts                 |
|  - Result registry                                  |
|  - Stake management                                 |
|  - Dispute resolution                               |
+-----------------------------------------------------+

3.2 Request flow

Step 1: Request submission
--------------------------
User or contract -> DCO Gateway
{
  "computation": "0x..." (WASM bytecode hash),
  "input":       "0x..." (input data hash),
  "callback":    "0x..." (callback address),
  "maxFee":      "0.1 ETH"
}

Step 2: Operator selection
--------------------------
Gateway picks an operator based on:
- Available stake
- Historical reliability
- Current load

Step 3: Execution
-----------------
DEOS runtime executes the computation:
- Load WASM module
- Execute with input
- Log all operations
- Generate execution hash

Step 4: Result submission
-------------------------
Operator -> on-chain registry
{
  "requestId":     12345,
  "result":        "0x...",
  "executionHash": "0x...",
  "stake":         "1 ETH"
}

Step 5: Challenge period
------------------------
- Window: 1 hour, configurable
- Anyone can challenge
- No challenge: result finalizes

Step 6: Callback
----------------
Registry -> user contract
callback(result, executionHash)

3.3 What the execution environment supports

Supported:
  WASM modules (compiled from Rust, C, AssemblyScript, etc.)
  Deterministic execution
  Memory isolation
  Bounded computation (gas metering)

Not supported:
  Network access during execution
  Non-deterministic operations
  Unbounded loops

3.4 Where determinism comes from

Any execution can be replayed and will produce the same result.

3.5 The execution hash

executionHash = hash(
  computationHash,   // WASM bytecode
  inputHash,         // input data
  outputHash,        // result
  eventChainHash     // hash of all logged events
)

The hash uniquely identifies the execution. If any aspect of the computation differs (different code, different input, different output, different intermediate events), the hash changes.

4. Security model

4.1 Threats and mitigations

4.2 Fraud proof mechanism

When a result is challenged:

1. Challenger posts stake.
2. Arbitration contract requests a replay.
3. Independent verifiers replay the execution.
4. If hashes match, challenger loses stake.
5. If hashes differ, operator loses stake.

4.3 Stake requirements

Operator stake has to exceed the potential gain from fraud:

Required stake = value at risk * safety margin

Example:
  Computation affects $10,000 in DeFi position
  Safety margin: 1.5x
  Required stake: $15,000

4.4 Challenge economics

The last case is mitigated by watchtowers and by economic incentives for monitoring high-value requests.

4.5 Comparison to Chainlink security

Both are secure. DCO is more efficient.

5. Economics

5.1 Fee structure

User pays:
  Base fee:     $0.01 to $0.10 (computation)
  Verification: $0.01           (on-chain costs)
  Priority:     variable        (faster execution)

Total: $0.02 to $0.20 per request

5.2 Operator economics

Operator:
  Stake:           $10,000 (example)
  Max concurrent:  100 requests at $100 value each
  Fee per request: $0.05
  Requests/day:    1,000
  Daily revenue:   $50
  Monthly revenue: $1,500
  Annual revenue:  $18,000
  ROI:             180%

5.3 Fee split

User fee
   |
   +-- 80% -> Operator
   |
   +-- 15% -> Protocol treasury
   |
   +--  5% -> Insurance fund

5.4 Staking tiers

5.5 No token needed

DCO uses ETH for staking and payments.

• Staking: operators stake ETH.
• Payments: users pay in ETH.
• Slashing: denominated in ETH.

This keeps the system simple and avoids regulatory exposure. A native token may be introduced later for governance if the community wants one.

6. Use cases

6.1 DeFi: complex risk calculations

Protocols need sophisticated risk models but cannot run them on-chain.

Protocol: "Calculate liquidation risk for position X"
   -> DCO runs the risk model with current market data
   -> Returns risk score plus proof
   -> On-chain: adjust collateral requirements based on the verified score

Targets: Aave, Compound, MakerDAO, GMX.

6.2 DEX: optimal trade routing

Finding the optimal route across many pools is computationally expensive.

User: "Swap 10 ETH for the maximum USDC"
   -> DCO computes optimal route across all pools
   -> Returns route plus proof of optimality
   -> On-chain: execute the proven route

Targets: Uniswap, 1inch, Paraswap.

6.3 NFT: verifiable rarity

Rarity scores are calculated off-chain today with no proof attached.

Marketplace: "Calculate rarity for NFT #1234"
   -> DCO analyzes traits against the collection
   -> Returns rarity score plus proof
   -> On-chain: verified rarity in listing

Targets: OpenSea, Blur, Rarible.

6.4 Gaming: anti-cheat and fairness

Game logic runs on untrusted clients.

Game: "Verify this player action sequence"
   -> DCO replays the game logic against the inputs
   -> Returns valid/invalid plus proof
   -> On-chain: award or reject rewards

Targets: on-chain games, prediction markets.

6.5 DAO: verifiable vote counting

Complex voting schemes (quadratic, conviction) are expensive on-chain.

DAO: "Count votes with quadratic weighting"
   -> DCO processes all votes with the algorithm
   -> Returns results plus proof
   -> On-chain: execute the proposal based on the verified result

Targets: Snapshot, Tally, governance contracts generally.

6.6 AI agents: verifiable decision trails

AI agents make decisions today with no accountability trail.

Agent runs on DEOS
   -> Every decision is logged
   -> Execution hash is generated
   -> Result: provable trail of what the agent did and why

Targets: DeFi protocols using AI, automated trading.

7. Comparison to alternatives

7.1 DCO vs Chainlink

DCO is roughly 10x to 30x cheaper at equivalent security.

7.2 DCO vs Gelato

Gelato is trusted. DCO is verified.

7.3 DCO vs ZK coprocessors

ZK is more trustless but slower and more constrained. DCO offers the practical tradeoff for most workloads. ZK and DCO can coexist for different security tiers.

7.4 Summary

8. Roadmap

Phase 1: Foundation (Q1 2026)

• WASM runtime integration in DEOS
• Basic DCO Gateway API
• Solidity verifier contract
• Testnet deployment (Sepolia)
• Documentation and SDK

Phase 2: Launch (Q2 2026)

• Mainnet deployment (Ethereum)
• First operator onboarding
• Integration with 2 or 3 DeFi protocols
• Basic monitoring and analytics
• Bug bounty program

Phase 3: Scale (Q3 and Q4 2026)

• Multi-chain deployment (Arbitrum, Base, Optimism)
• Operator marketplace
• Advanced dispute resolution
• Performance optimizations
• Enterprise features

Phase 4: Ecosystem (2027)

• Third-party operator network
• Developer grants program
• Governance framework
• AI agent integrations
• Cross-chain verification

9. Conclusion

DCO is an attempt to fix one specific inefficiency in the off-chain computation market. The market today pays for verifiability by paying for redundancy: N machines do the same work because that is the only way the contract can trust the result. The cost is real.

If the computation is deterministic and replayable, redundancy is unnecessary. Run it once. Hash it. Let anyone challenge by replaying. Pay for the work that was actually done, not for N copies of it.

For most off-chain workloads where ZK proofs are too expensive and trusted execution is too risky, DCO is the right shape: provable, cheap, fast, and flexible enough for any WASM computation.

References

1. DEOS Determinism Model: /whitepapers/determinism-model
2. DEOS Floating-Point Determinism Specification: /whitepapers/fp-determinism
3. Cryptographic Verification of Deterministic Replay in Multi-Core Operating Systems: /whitepapers/replay-proof
4. Chainlink 2.0 Whitepaper
5. Optimism Fraud Proof Specification
6. Arbitrum Nitro Technical Documentation
7. WebAssembly Specification