DigiDollar Oracle Discussion

[JaredTate]

DigiDollar Oracle Discussion

All right everyone — below is the original design for the DigiDollar Oracle system. I’ve also posted a follow-up document with several alternative Oracle architectures and implementation options.

What we need from the community right now is clear, practical input on which design will best deliver a secure, decentralized, and attack-resistant pricing system for DigiDollar.

The remaining code to develop in our prototype is the Oracle layer — how we source price data, how we aggregate it, and how we defend that process from manipulation, front-running, and economic attacks. When you comment, please think through real attack vectors, incentive alignment, failure modes, and operational tradeoffs, such as:

• Which price sources are trustworthy and why?
  (On-chain, off-chain feeds)

• How should we aggregate inputs to resist spamming and outliers?
  (Median, trimmed mean, weighted aggregation, stake-weighted voting)

• How do we prevent short-term manipulation and oracle gaming?
  (Time windows, randomness, slashing, dispute windows)

• What are safe fallback paths when feeds fail or are compromised?
  (Circuit breakers, emergency pausing, multi-sig governance)

• How do cost, latency, and decentralization trade off?
  (On-chain fees cost vs. off-chain batching)

• What monitoring and post-mortem tools are needed to detect and respond to attacks?

Please read the base design and the alternative options, then post constructive feedback, suggested improvements, and concrete threat models.
If you have prior designs, audits, or real-world examples that illustrate a point, link them.

Our goal is to converge on an Oracle architecture that’s simple enough to bootstrap, robust enough to scale, and designed so that attackers have to expend more than they can possibly gain.

Thanks — let’s build something resilient and future-proof together. ⚙️💪

---

DigiDollar Original Oracle Design

As Specified in TECHNICAL_SPECIFICATION.md v1.0 by Sagobi: https://github.com/orgs/DigiByte-Core/discussions/324

Document Purpose: Explain the originally proposed oracle system for DigiDollar

Status: Original Design (Pre-Implementation)

---

System Flow Chart: Complete Oracle Process

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                    DIGIDOLLAR ORACLE SYSTEM                     ┃
┃                      End-to-End Flow                            ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

┌─────────────────────────────────────────────────────────────────┐
│  STEP 1: SYSTEM INITIALIZATION                                  │
│  30 Hardcoded Oracle Nodes (src/chainparams.cpp)                │
│  oracle1.digibyte.io, oracle2.digibyte.org, oracle3...          │
└─────────────────────────────────────────────────────────────────┘
                            ↓
          ╔════════════════════════════════════════╗
          ║   EVERY 100 BLOCKS (~25 MINUTES)      ║
          ║   New Epoch Begins                     ║
          ╚════════════════════════════════════════╝
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 2: DETERMINISTIC ORACLE SELECTION                         │
│  • Get block hash at epoch start (random seed)                  │
│  • Shuffle all 30 oracles using seed                            │
│  • Select first 15 → ACTIVE ORACLES THIS EPOCH                  │
│  • All nodes agree (deterministic)                              │
└─────────────────────────────────────────────────────────────────┘
                            ↓
          ╔════════════════════════════════════════╗
          ║   EVERY 4 BLOCKS (~1 MINUTE)          ║
          ║   Active Oracles Update Price          ║
          ╚════════════════════════════════════════╝
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 3: PRICE FETCHING (Each of 15 Active Oracles)            │
│                                                                  │
│  Oracle queries 7 data sources in parallel:                     │
│  ┌──────────┬──────────┬──────────┬──────────┬──────────┐     │
│  │ Binance  │ KuCoin  │ Messari  │  OKEx    │  Huobi   │     │
│  │ $0.01234 │$0.01235 │$0.01233  │$0.01236  │$0.01233  │     │
│  └──────────┴──────────┴──────────┴──────────┴──────────┘     │
│  ┌──────────┬──────────┐                                       │
│  │CoinGecko │CoinMktCap│                                       │
│  │$0.01234  │$0.01235  │                                       │
│  └──────────┴──────────┘                                       │
│                                                                  │
│  • Requires 4-of-7 sources minimum                              │
│  • Calculate median: $0.01234                                   │
│  • Convert to micro-USD: 12,340                                 │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 4: SIGNATURE & BROADCAST                                  │
│  • Create price message (timestamp, price, height, nonce)       │
│  • Sign with Schnorr signature (64 bytes)                       │
│  • Broadcast to P2P network (NetMsgType::ORACLEPRICE)           │
│  • All 15 active oracles broadcast independently                │
└─────────────────────────────────────────────────────────────────┘
                            ↓
                ┌───────────────────────┐
                │  P2P NETWORK LAYER    │
                │  Messages propagate   │
                │  to all DigiByte nodes│
                └───────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 5: MINER COLLECTION & VALIDATION                          │
│  Miner creating new block collects oracle messages:             │
│  • Receives 8-15 oracle price messages from network             │
│  • Verifies each Schnorr signature                              │
│  • Confirms oracles are active in current epoch                 │
│  • Checks minimum threshold: 8-of-15 required                   │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 6: CONSENSUS PRICE CALCULATION                            │
│  • Extract prices from all valid messages                       │
│  • Sort: [12330, 12330, 12340, 12340, 12340, 12340,           │
│           12340, 12350, 12350, 12360]                           │
│  • Calculate median (middle value): 12,340 micro-USD           │
│  • Create oracle bundle with median + signatures                │
│  • Build Merkle root of all price messages                      │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 7: BLOCK INCLUSION                                        │
│  Miner includes oracle bundle in coinbase transaction:          │
│  • Input: Newly minted DGB                                      │
│  • Output 0: Miner reward (283 DGB)                            │
│  • Output 1: OP_RETURN <oracle bundle>                          │
│      └─ Median price: 12,340 micro-USD ($0.01234)              │
│      └─ Timestamp: 1704326400                                   │
│      └─ Signatures: [sig1...sig10]                              │
│      └─ Merkle root: 0x9f2e4a8b...                              │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 8: NETWORK VALIDATION                                     │
│  Every node receiving the block validates:                      │
│  • Extract oracle bundle from coinbase OP_RETURN                │
│  • Verify >= 8 signatures present                               │
│  • Verify each signature cryptographically                      │
│  • Verify oracles are active in epoch                           │
│  • Recalculate median matches reported price                    │
│  • Accept block if all checks pass                              │
└─────────────────────────────────────────────────────────────────┘
                            ↓
                ┌───────────────────────┐
                │   CONSENSUS ACHIEVED  │
                │  Price: $0.01234/DGB  │
                │  Valid for 20 blocks  │
                │  (~5 minutes)         │
                └───────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│  STEP 9: DIGIDOLLAR OPERATIONS                                  │
│                                                                  │
│  MINTING:                                                        │
│  • User wants 1,000 DD ($1,000)                                 │
│  • System reads oracle price: $0.01234/DGB                      │
│  • Calculates collateral: 243,111 DGB (300% ratio)             │
│  • User locks DGB, receives 1,000 DigiDollars                   │
│                                                                  │
│  REDEMPTION:                                                     │
│  • User burns 1,000 DD                                          │
│  • System calculates DGB owed at current oracle price           │
│  • Releases proportional collateral to user                     │
│                                                                  │
│  All operations use consensus price from latest block           │
└─────────────────────────────────────────────────────────────────┘
                            ↓
          ╔════════════════════════════════════════╗
          ║         REPEAT EVERY 4 BLOCKS          ║
          ║    Price updates continuously          ║
          ║    System maintains 1-min freshness    ║
          ╚════════════════════════════════════════╝

Key Security Properties:

• Byzantine Fault Tolerance: 8-of-15 threshold tolerates up to 7 faulty oracles
• Two-Layer Defense: 7 data sources per oracle × 15 oracles = 105 independent data points
• Median Pricing: Resistant to outliers and manipulation attempts
• Deterministic Selection: Unpredictable rotation prevents targeted attacks
• Cryptographic Proof: Schnorr signatures ensure authenticity
• Aggregator Coverage: CoinGecko (500+ exchanges), CoinMarketCap (300+ exchanges), Messari (100+ exchanges)

---

Simple Explainer: How It Works

The original DigiDollar oracle design uses a hardcoded trusted oracle network similar to how DigiByte uses DNS seed nodes. Here's the simple version:

The 5-Second Summary

1. 30 trusted oracle nodes are hardcoded into DigiByte Core
2. Every 100 blocks (~25 minutes), 15 oracles are randomly selected to be active
3. Each oracle fetches DGB/USD prices from 7+ data sources (Binance, KuCoin, Messari, CoinGecko, CoinMarketCap, etc.)
4. Oracles sign their price with Schnorr signatures and broadcast to the network
5. 8 of 15 oracles must agree (within tolerance) for price to be accepted
6. The median price is used for all DigiDollar operations

Visual Overview

┌─────────────────────────────────────────────────────────────┐
│              30 HARDCODED ORACLE NODES                       │
│  oracle1.digibyte.io  oracle2.digibyte.org  oracle3...      │
└─────────────────────────────────────────────────────────────┘
                          ↓
              Every 100 blocks, shuffle and select
                          ↓
┌─────────────────────────────────────────────────────────────┐
│              15 ACTIVE ORACLES (This Epoch)                  │
│         oracle3, oracle7, oracle12, oracle18...              │
└─────────────────────────────────────────────────────────────┘
                          ↓
           Each oracle fetches from 7+ data sources
                          ↓
┌──────────┬──────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ Binance  │ KuCoin  │ Messari  │  OKEx    │  Huobi   │CoinGecko │ CoinMC   │
│ $0.01234 │$0.01235 │$0.01233  │$0.01236  │$0.01233  │$0.01234  │$0.01235  │
└──────────┴──────────┴──────────┴──────────┴──────────┴──────────┴──────────┘
                          ↓
                Calculate median: $0.01234
                          ↓
              Sign with Schnorr signature
                          ↓
              Broadcast to DigiByte network
                          ↓
┌─────────────────────────────────────────────────────────────┐
│              MINERS COLLECT ORACLE PRICES                    │
│  Need at least 8 of 15 signatures (53% threshold)           │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│              CONSENSUS PRICE: $0.01234                       │
│         Used for all DigiDollar minting/redemption           │
└─────────────────────────────────────────────────────────────┘

Why This Design?

✅ Fast to Implement: 4-6 weeks (similar to DNS seeds)
✅ Proven Model: DigiByte DNS seeds work the same way
✅ Secure Enough: 8-of-15 threshold resists single point of failure
✅ Multi-Layer Defense: 7 data sources per oracle (4 exchanges + 3 aggregators)
✅ Aggregator Protection: CoinGecko, CoinMarketCap, Messari add 900+ exchanges
✅ Simple Config: Just oracle=1 in digibyte.conf to become an oracle
✅ Gets DigiDollar Launched: Can deploy while working on more advanced designs

❌ Centralized: Limited to 30 hardcoded nodes
❌ Trust Required: Must trust initial oracle selection
❌ Slow Expansion: Adding oracles requires software update

---

Detailed Architecture

1. Oracle Node Configuration

1.1 Hardcoded Oracle List

Location: src/chainparams.cpp

The original design hardcodes 30 oracle nodes directly into the DigiByte Core codebase:

class CMainParams : public CChainParams {
    // DigiDollar oracle nodes (30 hardcoded, 15 active per epoch)
    std::vector<OracleNode> vOracleNodes = {
        {"oracle1.digibyte.io", "xpub661MyMwAqRbcFW31YEwpkMuc..."},
        {"oracle2.digibyte.org", "xpub661MyMwAqRbcGczjuLamPf..."},
        {"oracle3.dgb.community", "xpub661MyMwAqRbcFtXgS5sYJA..."},
        // ... 27 more oracle nodes with hostnames and extended public keys
    };

    // Oracle epoch configuration
    consensus.nOracleEpochBlocks = 100;      // Rotate oracles every 100 blocks (~25 min)
    consensus.nOracleUpdateInterval = 4;     // Update price every 4 blocks (~1 min)
    consensus.nOracleCount = 30;             // Total hardcoded oracles
    consensus.nActiveOracles = 15;           // Active per epoch
    consensus.nOracleThreshold = 8;          // 8-of-15 signatures required
    consensus.nPriceValidBlocks = 20;        // Price valid for 20 blocks (~5 min)
};

Key Parameters:

• 30 total oracles: Fixed set hardcoded in source code
• 15 active oracles: Selected each epoch
• 8-of-15 threshold: 53% consensus required
• 100-block epochs: ~25 minutes (240 blocks/hour ÷ 4 algos × 100 = ~25 min)
• 4-block updates: ~1 minute price refresh rate

1.2 Oracle Operator Configuration

Any of the 30 hardcoded oracle operators enables oracle mode:

# digibyte.conf

# Enable oracle mode (only works if you're one of the 30 hardcoded nodes)
oracle=1

# Data source configuration (exchanges + aggregators)
oraclesources=binance,kucoin,messari,okex,huobi,coingecko,coinmarketcap

# Exchange API keys (read-only, no trading permissions needed)
oracleapikey_binance=YOUR_BINANCE_API_KEY
oracleapisecret_binance=YOUR_BINANCE_SECRET

oracleapikey_kucoin=YOUR_KUCOIN_API_KEY
oracleapisecret_kucoin=YOUR_KUCOIN_SECRET

oracleapikey_okex=YOUR_OKEX_API_KEY
oracleapisecret_okex=YOUR_OKEX_SECRET

oracleapikey_huobi=YOUR_HUOBI_API_KEY
oracleapisecret_huobi=YOUR_HUOBI_SECRET

# Aggregated data providers (recommended for reliability)
oracleapikey_messari=YOUR_MESSARI_API_KEY
oracleapikey_coingecko=YOUR_COINGECKO_API_KEY
oracleapikey_coinmarketcap=YOUR_COINMARKETCAP_API_KEY

---

2. Oracle Price Message Format

2.1 Price Message Structure

Location: src/primitives/oracle.h

class COraclePriceMessage {
public:
    // Price data
    uint32_t nTimestamp;           // Unix timestamp of price fetch
    uint32_t nPricePerDGB;         // Price in micro-USD (1,000,000 = $1.00)
    uint32_t nBlockHeight;         // Current block height

    // Signature data (Schnorr)
    std::vector<unsigned char> vchSchnorrSig;  // Schnorr signature
    XOnlyPubKey oraclePubKey;                  // Oracle's public key

    // Anti-replay protection
    uint256 nonce;                 // Random nonce to prevent replay attacks

    // Methods
    bool VerifySignature() const;  // Verify Schnorr signature
    uint256 GetMessageHash() const; // Get hash for signing

    ADD_SERIALIZE_METHODS;         // Enable serialization for P2P
};

Example Price Message:

Timestamp:   1704326400 (2025-01-04 00:00:00 UTC)
Price:       12,340 micro-USD ($0.01234 per DGB)
BlockHeight: 18,500,000
PubKey:      xpub661MyMwAqRbcFW31YEwpkMuc...
Signature:   <64-byte Schnorr signature>
Nonce:       a3f8e92b4c... (random 256-bit value)

2.2 Price Format

Prices are stored in micro-USD (millionths of a dollar):

$1.00     = 1,000,000 micro-USD
$0.01234  = 12,340 micro-USD
$0.00001  = 10 micro-USD

Why micro-USD?

• Avoids floating point precision issues
• uint32_t supports up to $4,294 per DGB (more than enough)
• Easy integer math for calculations

---

3. Oracle Selection Algorithm

3.1 Deterministic Epoch Selection

Location: src/consensus/oracle.cpp

The original design uses deterministic random selection based on block hash:

std::vector<COracleNode> SelectActiveOracles(int nHeight) {
    // Calculate epoch start height
    int epochStart = (nHeight / 100) * 100;

    // Get block hash at epoch start as randomness seed
    uint256 epochSeed = GetBlockHash(epochStart);

    // Shuffle all 30 oracles using epoch seed
    std::vector<COracleNode> shuffled = vOracleNodes;
    std::mt19937 rng(epochSeed.GetUint64(0));
    std::shuffle(shuffled.begin(), shuffled.end(), rng);

    // Return first 15 oracles for this epoch
    return std::vector<COracleNode>(shuffled.begin(), shuffled.begin() + 15);
}

Key Properties:

• Deterministic: All nodes select same 15 oracles using same seed
• Unpredictable: Block hash provides randomness (can't predict which oracles until epoch starts)
• Fair: Each oracle has 15/30 = 50% chance of being selected each epoch
• Verifiable: Anyone can verify the correct oracles were selected

3.2 Epoch Timeline Example

Block Height: 18,500,000-18,500,099 (Epoch 185,000)
├─ Seed: Hash of block 18,500,000
├─ Active Oracles: oracle3, oracle7, oracle12, oracle15, oracle18...
└─ Duration: 100 blocks (~25 minutes)

Block Height: 18,500,100-18,500,199 (Epoch 185,001)
├─ Seed: Hash of block 18,500,100 (NEW RANDOMNESS)
├─ Active Oracles: oracle1, oracle5, oracle9, oracle14, oracle22...
└─ Duration: 100 blocks (~25 minutes)

---

4. Price Fetching Process

4.1 Exchange Integration

Location: src/oracle/node.cpp

Each oracle fetches prices from multiple exchanges:

class COracleNode {
private:
    std::vector<std::string> m_dataSources = {
        // Direct exchange APIs
        "binance",       // Highest volume exchange
        "kucoin",        // Asian market coverage
        "okex",          // Additional Asian coverage
        "huobi",         // Additional global coverage

        // Aggregated data providers (recommended)
        "messari",       // Professional crypto data aggregator
        "coingecko",     // Multi-exchange aggregator
        "coinmarketcap"  // Multi-exchange aggregator
    };

public:
    /**
     * Fetch median price from all configured data sources
     * Returns price in micro-USD
     */
    CAmount FetchMedianPrice() {
        std::vector<double> prices;

        // Fetch from each data source
        for (const auto& source : m_dataSources) {
            try {
                double price = FetchPrice(source);
                if (price > 0) {
                    prices.push_back(price);
                }
            } catch (...) {
                LogPrintf("Failed to fetch from %s\n", source);
            }
        }

        // Require at least 4 successful sources (majority of 7)
        if (prices.size() < 4) {
            throw std::runtime_error("Insufficient price sources");
        }

        // Calculate median (resistant to outliers)
        std::sort(prices.begin(), prices.end());
        double median = prices[prices.size() / 2];

        // Convert to micro-USD
        return static_cast<CAmount>(median * 1000000);
    }

    /**
     * Create signed price message
     */
    COraclePriceMessage CreatePriceMessage() {
        COraclePriceMessage msg;
        msg.nTimestamp = GetTime();
        msg.nPricePerDGB = FetchMedianPrice();
        msg.nBlockHeight = chainActive.Height();
        msg.nonce = GetRandHash();

        // Sign with oracle's private key (Schnorr signature)
        uint256 msgHash = msg.GetMessageHash();
        SignSchnorr(msgHash, m_oracleKey, msg.vchSchnorrSig);

        msg.oraclePubKey = m_oracleKey.GetPubKey();

        return msg;
    }
};

Data Fetching Details:

1. Oracle contacts each data source API
2. Gets DGB/USD or DGB/USDT price (direct from exchange or aggregated)
3. Stores prices in vector
4. Requires at least 4 of 7 sources successful
5. Sorts prices and takes median
6. Median resistant to single source manipulation

---

5. Price Aggregation & Consensus

5.1 Consensus Algorithm

Location: src/consensus/oracle.cpp

/**
 * Aggregate oracle prices with 8-of-15 threshold validation
 * Returns consensus price in micro-USD
 */
CAmount GetConsensusPrice(const std::vector<COraclePriceMessage>& prices) {
    // Require at least 8 valid signatures
    if (prices.size() < 8) {
        throw std::runtime_error("Insufficient oracle consensus");
    }

    // Verify all signatures are valid
    for (const auto& price : prices) {
        if (!price.VerifySignature()) {
            throw std::runtime_error("Invalid oracle signature");
        }
    }

    // Extract prices into vector
    std::vector<uint32_t> validPrices;
    for (const auto& p : prices) {
        validPrices.push_back(p.nPricePerDGB);
    }

    // Sort prices
    std::sort(validPrices.begin(), validPrices.end());

    // Return median price (middle value)
    return validPrices[validPrices.size() / 2];
}

Consensus Properties:

• 8-of-15 threshold: Requires 53% agreement
• Byzantine Fault Tolerance: Can tolerate up to 7 faulty/malicious oracles
• Median Pricing: Resistant to outliers
• Schnorr Verification: Cryptographic proof of authenticity

---

6. Block Integration

6.1 Coinbase Oracle Data

Location: src/validation.cpp

Oracle prices are included in blocks via OP_RETURN in coinbase transaction:

/**
 * Validate oracle data in block
 */
bool CheckBlockOracleData(const CBlock& block, const CChainParams& chainparams) {
    // Extract oracle data from coinbase transaction
    const CTransaction& coinbase = block.vtx[0];

    // Look for OP_RETURN output with oracle data
    COracleBundle oracleData;
    bool foundOracle = false;

    for (const auto& output : coinbase.vout) {
        if (output.scriptPubKey[0] == OP_RETURN) {
            if (ExtractOracleData(output.scriptPubKey, oracleData)) {
                foundOracle = true;
                break;
            }
        }
    }

    // Blocks without oracle data are valid but can't process DigiDollar txs
    if (!foundOracle) {
        return !BlockContainsDigiDollarTx(block);
    }

    // Get active oracles for this height
    auto activeOracles = SelectActiveOracles(block.nHeight);

    // Count valid signatures (must be from active oracles)
    int validSigs = 0;
    for (const auto& sig : oracleData.signatures) {
        if (VerifyOracleSignature(sig, activeOracles)) {
            validSigs++;
        }
    }

    // Require at least 8 valid signatures
    return validSigs >= 8;
}

Block Structure:

Block #18,500,123
├─ Coinbase Transaction
│  ├─ Input: Newly minted DGB
│  ├─ Output 0: Miner reward
│  ├─ Output 1: OP_RETURN <oracle_data>
│  │  └─ Contains:
│  │     ├─ Median Price: 12,340 micro-USD
│  │     ├─ Timestamp: 1704326400
│  │     ├─ 8-15 Oracle Signatures (Schnorr)
│  │     └─ Merkle root of all price messages
│  └─ ...
├─ Transaction 1: User sends DGB
├─ Transaction 2: DigiDollar mint (uses oracle price from coinbase)
└─ ...

---

Flow Charts

Flow Chart 1: Oracle Selection & Activation

┌─────────────────────────────────────────────────────────────┐
│                    EVERY 100 BLOCKS                          │
│             New Epoch Starts (e.g., block 18,500,100)        │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    1. Get Block Hash at Epoch Start                          │
│       epochSeed = GetBlockHash(18,500,100)                   │
│       → Returns: 0x3a8f2e9b4c7d... (256-bit hash)           │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    2. Use Hash as RNG Seed                                   │
│       rng = std::mt19937(epochSeed)                          │
│       → Deterministic random number generator                │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    3. Shuffle All 30 Hardcoded Oracles                       │
│       shuffled = [oracle1...oracle30]                        │
│       std::shuffle(shuffled, rng)                            │
│       → Result: [oracle3, oracle7, oracle1, oracle15...]     │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    4. Select First 15 Oracles                                │
│       active = shuffled[0...14]                              │
│       → [oracle3, oracle7, oracle1, oracle15, oracle22,      │
│          oracle9, oracle28, oracle12, oracle5, oracle19,     │
│          oracle14, oracle26, oracle8, oracle30, oracle11]    │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    5. These 15 Oracles Are Active For Next 100 Blocks       │
│       (Blocks 18,500,100 - 18,500,199)                       │
│       All nodes agree on same selection (deterministic)      │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    6. After 100 Blocks, Repeat Process                       │
│       → New epoch seed from block 18,500,200                 │
│       → New shuffled selection                               │
│       → Different 15 oracles become active                   │
└─────────────────────────────────────────────────────────────┘

---

Flow Chart 2: Price Fetching & Broadcasting

┌─────────────────────────────────────────────────────────────┐
│          EVERY 4 BLOCKS (~1 minute)                          │
│   Oracle Node Wakes Up to Fetch & Broadcast Price           │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 1: Check If Oracle Is Active This Epoch             │
│    activeOracles = SelectActiveOracles(currentHeight)        │
│    if (myPubKey not in activeOracles): return (sleep)       │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 2: Fetch Price from Binance                         │
│    GET https://api.binance.com/api/v3/ticker/price          │
│         ?symbol=DGBUSDT                                      │
│    Response: {"symbol":"DGBUSDT","price":"0.01234"}          │
│    → price1 = $0.01234                                       │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 3: Fetch Price from KuCoin                          │
│    GET https://api.kucoin.com/api/v1/market/orderbook       │
│         /level1?symbol=DGB-USDT                              │
│    Response: {"bestBid":"0.01233","bestAsk":"0.01235"}       │
│    → price2 = $0.01234 (midpoint)                            │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 4: Fetch from Messari, OKEx, Huobi                  │
│    → price3 = $0.01235 (Messari aggregated)                  │
│    → price4 = $0.01233 (OKEx)                                │
│    → price5 = $0.01233 (Huobi)                               │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 5: Fetch from CoinGecko, CoinMarketCap              │
│    → price6 = $0.01234 (CoinGecko aggregated)                │
│    → price7 = $0.01235 (CoinMarketCap aggregated)            │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 6: Calculate Median Price (7 sources)               │
│    prices = [0.01234, 0.01234, 0.01235, 0.01233,            │
│              0.01233, 0.01234, 0.01235]                      │
│    sort(prices) → [0.01233, 0.01233, 0.01234, 0.01234,      │
│                    0.01234, 0.01235, 0.01235]                │
│    median = prices[3] = $0.01234 (middle value)             │
│    → Convert to micro-USD: 12,340                            │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 7: Create Price Message                             │
│    msg.nTimestamp = GetTime()         → 1704326400          │
│    msg.nPricePerDGB = 12340            → micro-USD           │
│    msg.nBlockHeight = chainActive.Height() → 18,500,123     │
│    msg.nonce = GetRandHash()           → 0xa3f8e92b...      │
│    msg.oraclePubKey = myPubKey         → xpub661...         │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 8: Sign Message with Schnorr Signature              │
│    msgHash = SHA256(timestamp || price || height || nonce)   │
│    signature = SchnorrSign(msgHash, myPrivateKey)           │
│    msg.vchSchnorrSig = signature (64 bytes)                 │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 9: Broadcast to P2P Network                         │
│    g_connman->ForEachNode([&](CNode* node) {                 │
│        node->PushMessage(NetMsgType::ORACLEPRICE, msg);      │
│    });                                                       │
│    → Message propagates to all DigiByte nodes                │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 10: Sleep Until Next Update                         │
│    Sleep for ~1 minute (4 blocks)                            │
│    → Repeat from Step 1                                      │
└─────────────────────────────────────────────────────────────┘

---

Flow Chart 3: Consensus Price Validation

┌─────────────────────────────────────────────────────────────┐
│              MINER CREATING NEW BLOCK                        │
│  Miner collects oracle price messages from mempool/network  │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 1: Collect All Recent Oracle Price Messages         │
│    Received messages:                                        │
│    • oracle3:  $0.01234, sig1, timestamp: 1704326400        │
│    • oracle7:  $0.01235, sig2, timestamp: 1704326401        │
│    • oracle1:  $0.01234, sig3, timestamp: 1704326399        │
│    • oracle15: $0.01233, sig4, timestamp: 1704326402        │
│    • oracle22: $0.01236, sig5, timestamp: 1704326400        │
│    • oracle9:  $0.01234, sig6, timestamp: 1704326401        │
│    • oracle28: $0.01234, sig7, timestamp: 1704326400        │
│    • oracle12: $0.01235, sig8, timestamp: 1704326399        │
│    • oracle5:  $0.01234, sig9, timestamp: 1704326402        │
│    • oracle19: $0.01233, sig10, timestamp: 1704326401       │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 2: Verify Oracle Signatures                         │
│    For each message:                                         │
│      1. Extract oraclePubKey                                 │
│      2. Compute msgHash = SHA256(msg data)                   │
│      3. Verify: SchnorrVerify(msgHash, sig, pubKey)          │
│    → All 10 signatures verify successfully ✓                │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 3: Check Oracle is Active in Current Epoch          │
│    activeOracles = SelectActiveOracles(blockHeight)          │
│    For each message:                                         │
│      Check if oraclePubKey ∈ activeOracles                   │
│    → All 10 oracles are active ✓                             │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 4: Check Minimum Threshold (8-of-15)                │
│    validMessages = 10                                        │
│    threshold = 8                                             │
│    if (validMessages < threshold): REJECT                    │
│    → 10 >= 8, threshold met ✓                                │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 5: Extract Prices                                   │
│    prices = [12340, 12350, 12340, 12330, 12360,             │
│              12340, 12340, 12350, 12340, 12330]             │
│    (All in micro-USD)                                        │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 6: Calculate Median (Consensus Price)               │
│    Sort prices:                                              │
│    [12330, 12330, 12340, 12340, 12340, 12340, 12340,        │
│     12350, 12350, 12360]                                     │
│    Median (middle value) = prices[5] = 12340 micro-USD      │
│    → Consensus Price: $0.01234                               │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 7: Create Oracle Bundle for Block                   │
│    oracleBundle {                                            │
│      medianPrice: 12340 micro-USD                            │
│      timestamp: 1704326400                                   │
│      signatures: [sig1, sig2, ..., sig10]                    │
│      merkleRoot: 0x9f2e4a8b...  (Merkle root of all msgs)   │
│    }                                                         │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 8: Include in Coinbase OP_RETURN                    │
│    Coinbase Transaction:                                     │
│    • Input: Newly minted DGB                                 │
│    • Output 0: Miner reward (283 DGB)                       │
│    • Output 1: OP_RETURN <serialized oracleBundle>          │
│    → Block includes consensus price                          │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 9: Block Validation by Other Nodes                  │
│    Every node receiving this block:                          │
│    1. Extract oracle bundle from coinbase                    │
│    2. Verify >= 8 valid signatures                           │
│    3. Verify all oracles are active in epoch                 │
│    4. Recalculate median from provided prices                │
│    5. Accept block if all checks pass                        │
│    → Block accepted and chain advances ✓                     │
└─────────────────────────────────────────────────────────────┘

---

Flow Chart 4: DigiDollar Minting with Oracle Price

┌─────────────────────────────────────────────────────────────┐
│                  USER WANTS TO MINT DIGIDOLLARS              │
│         User: "I want to mint 1,000 DigiDollars"            │
│         Lock Period: 1 year (300% collateral ratio)          │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 1: Get Current Oracle Price                         │
│    consensusPrice = GetConsensusPrice()                      │
│    → Extract from most recent block's coinbase               │
│    → Returns: 12,340 micro-USD ($0.01234 per DGB)           │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 2: Calculate Required Collateral                    │
│    ddAmount = 1,000 DigiDollars = $1,000                    │
│    collateralRatio = 300% (for 1 year lock)                  │
│                                                              │
│    dgbFor100Percent = $1,000 / $0.01234 = 81,037 DGB        │
│    requiredDGB = 81,037 × 3.00 = 243,111 DGB                │
│                                                              │
│    → User needs to lock 243,111 DGB                          │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 3: Check System Health (DCA)                        │
│    systemCollateral = GetSystemCollateralRatio()             │
│    → Returns: 180% (healthy)                                 │
│    dcaMultiplier = GetDCAMultiplier(180)                     │
│    → Returns: 1.0 (no adjustment, system is healthy)         │
│    finalRequiredDGB = 243,111 × 1.0 = 243,111 DGB           │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 4: Check Volatility Freeze                          │
│    isVolatilityFreeze = CheckVolatility()                    │
│    → Look at price changes over last hour                    │
│    → Returns: false (price stable)                           │
│    → Minting allowed ✓                                       │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 5: Create Mint Transaction                          │
│    Transaction:                                              │
│    • Version: 0x0D1D0770 | (DD_TX_MINT << 16)               │
│    • Input: User's DGB UTXO (243,111+ DGB)                  │
│    • Output 0: P2TR Collateral (243,111 DGB locked)         │
│    •   └─ Includes timelock script (1 year = 2,102,400 blocks) │
│    • Output 1: P2TR DigiDollar (0 DGB value, 1000 DD)       │
│    • Output 2: OP_RETURN (metadata)                          │
│    • Output 3: Change (excess DGB back to user)             │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 6: Transaction Validation by Network                │
│    Each node validates:                                      │
│    1. Extract ddAmount (1000) and collateral (243,111)       │
│    2. Get current oracle price (12,340 micro-USD)            │
│    3. Calculate required collateral                          │
│    4. Verify: actualCollateral >= requiredCollateral         │
│    5. Check mint limits ($100-$100k)                         │
│    6. Check no volatility freeze                             │
│    → All checks pass ✓                                       │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│    Step 7: Transaction Confirmed in Block                   │
│    • User's 243,111 DGB locked for 1 year                   │
│    • User receives 1,000 DigiDollars (DD address DD1...)    │
│    • Collateral position tracked in UTXO set                │
│    • Position redeemable after 2,102,400 blocks (~1 year)   │
└─────────────────────────────────────────────────────────────┘

---

Security Properties

1. Byzantine Fault Tolerance

The 8-of-15 threshold provides Byzantine Fault Tolerance:

Total Oracles:    15 active
Threshold:        8 required
Byzantine Limit:  f = (n-1)/3 = (15-1)/3 = 4.67

Interpretation: System can tolerate up to 7 faulty oracles:
- 7 malicious oracles cannot reach 8-signature threshold
- Need 8 honest oracles minimum for consensus
- 15 - 7 = 8, exactly at threshold

Attack Scenarios:

• 5 compromised oracles: 10 honest remain → consensus still works ✓
• 7 compromised oracles: 8 honest remain → consensus barely works ✓
• 8 compromised oracles: 7 honest remain → consensus fails ✗

2. Median Pricing Protection

Median pricing is resistant to outliers:

Example: 1 malicious oracle reports fake price

Prices from 10 oracles (each using 7 data sources):
[$0.01230, $0.01234, $0.01234, $0.01235, $0.01236,
 $0.01233, $0.01234, $0.01235, $0.01234, $0.50000 ← FAKE]

Sorted: [$0.01230, $0.01233, $0.01234, $0.01234, $0.01234,
         $0.01234, $0.01235, $0.01235, $0.01236, $0.50000]

Median: $0.01234 (5th value) → Fake price ignored ✓

Even if attacker controls multiple data sources:
- Each oracle uses 7 sources, needs 4 to succeed
- Would need to manipulate 4+ sources per oracle
- Would need to compromise 5+ oracles
- Combined cost: $1M+ for exchanges + infrastructure

Two-layer defense: Source diversity × Oracle diversity

3. Comprehensive Data Source Coverage

Data Source Architecture:

If attacker manipulates 1 exchange (e.g., flash loan attack on OKEx):

Oracle's Data Source Prices:
- Binance:      $0.01234  ✓ (Real)
- KuCoin:       $0.01234  ✓ (Real)
- OKEx:         $0.50000  ✗ (Manipulated)
- Huobi:        $0.01235  ✓ (Real)
- Messari:      $0.01233  ✓ (Real)
- CoinGecko:    $0.01234  ✓ (Real)
- CoinMarketCap: $0.01235  ✓ (Real)

Oracle calculates median: $0.01234 (ignores OKEx outlier)

All oracles report: $0.01234 → Consensus not affected ✓

Would need to manipulate 3+ major exchanges simultaneously (cost: $1M+).

4. Deterministic Selection

Attackers cannot predict which oracles will be active:

Current Epoch (Block 18,500,100):
- Active: oracle3, oracle7, oracle1, oracle15...
- Attacker controls: oracle5, oracle11, oracle23 (3 of 30)

Attacker's oracles NOT selected this epoch → cannot influence price

Next Epoch (Block 18,500,200):
- New randomness from block hash
- Different oracles selected
- Attacker has 15/30 = 50% chance per oracle
- Probability of getting 8+ oracles: 0.000000276 (1 in 3.6 million epochs)

---

Limitations & Trade-offs

Limitations of Original Design

1. Centralization

   • Only 30 hardcoded oracles
   • Requires trust in initial oracle selection
   • Limited geographic/entity diversity

2. Slow Expansion

   • Adding new oracles requires software update
   • All nodes must upgrade to recognize new oracles
   • Social coordination needed

3. No Economic Incentive

   • No stake requirement (no skin in the game)
   • No rewards for oracle operation
   • No penalties for misbehavior (initially)

4. Single Point of Governance

   • DigiByte Community decides which 30 oracles
   • No on-chain governance mechanism
   • Potential for capture by special interests

5. Limited Scalability

   • 30 oracles is fixed upper limit
   • Cannot grow to hundreds of oracles
   • Rotation only provides diversity, not scale

---

Conclusion

The original oracle design provides a simple, proven approach to decentralized price feeds:

✅ Strengths:

• Fast to implement (4-6 weeks)
• Proven model (DigiByte DNS seeds)
• Byzantine fault tolerant (8-of-15)
• Median pricing resists outliers
• Deterministic selection prevents prediction

❌ Weaknesses:

• Centralized (30 hardcoded nodes)
• No economic incentives/penalties
• Slow to expand (requires software updates)
• Trust in initial oracle selection

🎯 Perfect For: MVP launch to get DigiDollar operational quickly while developing more advanced oracle systems (staking, miner validation) in parallel.

[JaredTate]

DigiDollar Oracle Options - Version 2.0

Comprehensive Analysis of Oracle Design Patterns for Decentralized Price Feeds

Version 2.0 - Security & Game Theory Analysis

---

Executive Summary

This document provides comprehensive analysis of 8 oracle design options for DigiDollar, with emphasis on security, economics, and practical implementation. Each option includes layman's explanation, visual flowchart, and technical details.

Oracle Options Summary

Option	Approach	Decentralization	Security	Complexity	Economic Model
1	Hardcoded Trusted Nodes	⭐⭐	⭐⭐⭐	⭐⭐	Volunteer/community funded
2	Permissionless Reputation	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	Fee pool + reputation
3	Economic Staking	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	Staking + slashing
4	Miner-Validated Bundles	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	Mining alignment
5	Proof-of-Work Mining	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	PoW rewards
6	Delegated Oracle Network	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	Delegation + voting
7	Hybrid Reputation-Stake	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	Multi-factor incentives
8	Optimistic Oracle	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	Challenge bonds

Recommended: Hybrid Option 7 (Reputation-Stake) + Option 4 (Miner Validation)

---

Table of Contents

1. Option 1: Hardcoded Trusted Oracle Nodes
2. Option 2: Permissionless Reputation Network
3. Option 3: Economic Staking Model
4. Option 4: Miner-Validated Oracle Bundles
5. Option 5: Proof-of-Work Oracle Mining
6. Option 6: Delegated Oracle Network
7. Option 7: Hybrid Reputation-Stake Model
8. Option 8: Optimistic Oracle with Challenge Bonds
9. Security Comparison
10. Game Theory Analysis
11. Attack Cost Analysis
12. Hybrid Architecture Recommendations

---

Option 1: Hardcoded Trusted Oracle Nodes

Layman's Explainer

What is it? Think of 30 trusted friends who check DGB prices at different stores (exchanges). Every 25 minutes, 15 are randomly picked to share prices. If at least 8 agree, that becomes the official price.

Why simple? No complex economics or staking—just trusted operators running software. Like Bitcoin's DNS seeds.

The catch? You must trust the 30 oracles were chosen well and won't collude.

Visual Flow

┌─────────────────────────────────────────────────┐
│         30 HARDCODED ORACLE NODES               │
│  (Coded directly into DigiByte software)        │
└─────────────────────────────────────────────────┘
                    ↓
        Every 100 blocks, shuffle randomly
                    ↓
┌─────────────────────────────────────────────────┐
│       15 ACTIVE ORACLES (This Epoch)            │
└─────────────────────────────────────────────────┘
                    ↓
    Each fetches from 7 data sources
                    ↓
┌──────┬──────┬──────┬──────┬──────┬──────┬──────┐
│Binance│KuCoin│Messari│OKEx│Huobi│CoinGecko│CMC│
└──────┴──────┴──────┴──────┴──────┴──────┴──────┘
                    ↓
          Calculate median price
                    ↓
        Sign with Schnorr signature
                    ↓
        Broadcast to P2P network
                    ↓
┌─────────────────────────────────────────────────┐
│  MINERS: Collect 8+ oracle signatures          │
│  Include in block if valid                     │
└─────────────────────────────────────────────────┘
                    ↓
        CONSENSUS PRICE ESTABLISHED

Technical Summary

Architecture: 30 nodes hardcoded in chainparams.cpp. Every 100 blocks, deterministic random selection (via block hash seed) picks 15 active oracles. Each oracle fetches from 7 sources (Binance, KuCoin, Messari, OKEx, Huobi, CoinGecko, CoinMarketCap), calculates median, signs with Schnorr signature, broadcasts every 4 blocks.

Consensus: 8-of-15 threshold (Byzantine Fault Tolerance). Median pricing resists outliers. Multi-source diversity prevents single-exchange manipulation.

Security: Attack requires compromising 8 oracles AND manipulating 4+ data sources simultaneously. Cost: $1M+. Detection probability: 95%+.

Advantages:

• Simple implementation
• Proven model (Bitcoin DNS seeds)
• Fast deployment
• No economic complexity

Disadvantages:

• Centralized trust model
• Slow to add new oracles (software update required)
• No economic penalties for bad behavior
• Limited to 30 operators

---

Option 2: Permissionless Reputation Network

Layman's Explainer

What is it? Anyone can become an oracle—no permission needed! You start with zero reputation and build trust over time by providing accurate prices. Like building eBay or Reddit karma—good behavior earns influence.

Why powerful? Maximum decentralization. Don't like current oracles? Become one yourself.

The catch? Takes months to build reputation. Vulnerable to spam attacks without protections.

Visual Flow

┌─────────────────────────────────────────────────┐
│   ANYONE CAN REGISTER AS ORACLE (Permissionless)│
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  New Oracle starts with ZERO reputation         │
│  Must prove themselves over time                │
└─────────────────────────────────────────────────┘
                    ↓
        Provide accurate prices daily
                    ↓
┌─────────────────────────────────────────────────┐
│  REPUTATION GROWS (90 days to reach 50%)        │
│  • Uptime: 25%                                  │
│  • Accuracy: 30%                                │
│  • Consistency: 20%                             │
│  • Early detection: 15%                         │
│  • Optional stake: 10%                          │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  WEIGHTED MEDIAN CALCULATION                    │
│  High reputation = More influence               │
│  Weight = reputation²                           │
└─────────────────────────────────────────────────┘
                    ↓
        Bad behavior detected?
                    ↓
┌─────────────────────────────────────────────────┐
│  AUTO-PRUNING                                   │
│  • Offline >7 days → Removed                    │
│  • Reputation <20 for 30 days → Removed         │
│  • >5 outliers per 100 → Removed                │
└─────────────────────────────────────────────────┘

Technical Summary

Architecture: Open registration with no upfront requirements. Multi-dimensional reputation scoring with progressive trust (logarithmic growth over 90 days). Reputation-weighted median where influence = reputation². Machine learning anomaly detection (LSTM) identifies suspicious patterns.

Sybil Resistance:

• New oracles start at 0 reputation (takes 90 days to earn meaningful weight)
• Proof of unique exchange API keys prevents duplicate identities
• Optional 2,500 DD staking for reputation boost
• Auto-pruning removes low-quality oracles

Security: Attacker must either (1) build reputation for months across many identities or (2) compromise existing high-reputation oracles. Cost: $100k-$500k + months of operation.

Advantages:

• True permissionless participation
• Self-regulating through reputation
• Incentivizes good behavior long-term
• Naturally decentralizes over time

Disadvantages:

• Slow bootstrap (need established oracles first)
• Complex reputation tracking
• Vulnerable to long-term reputation grinding attacks
• Requires active monitoring

---

Option 3: Economic Staking Model

Layman's Explainer

What is it? Lock up 2,500 DigiDollars ($2,500) as collateral for 3 months to become an oracle. Provide bad data? Community votes to slash (take away) some or all of your collateral. Like a security deposit—misbehave and lose it.

Why powerful? Economic skin-in-the-game. Oracles lose real money if they cheat, creating strong honesty incentives.

The catch? Requires $2,500 upfront (limits participation). Needs governance for slashing decisions.

Visual Flow

┌─────────────────────────────────────────────────┐
│  USER MINTS 2,500 DD + STAKES FOR 3 MONTHS     │
│  (Locks 75,000 DGB collateral)                  │
└─────────────────────────────────────────────────┘
                    ↓
        Registration confirmed after 100 blocks
                    ↓
┌─────────────────────────────────────────────────┐
│  ORACLE ACTIVE - Broadcasts prices              │
│  Earns rewards: Fees + DGB appreciation         │
└─────────────────────────────────────────────────┘
                    ↓
        Provides bad data?
                    ↓
┌─────────────────────────────────────────────────┐
│  SLASHING PROPOSAL CREATED                      │
│  • Evidence submitted                           │
│  • 48-hour challenge period                     │
│  • DGB holders vote (weighted by stake)         │
└─────────────────────────────────────────────────┘
                    ↓
            Vote passes (60%+ yes)?
                    ↓
        YES                         NO
         ↓                           ↓
┌──────────────────┐      ┌─────────────────────┐
│ ORACLE SLASHED   │      │ Proposal rejected   │
│ Loses stake      │      │ Oracle keeps stake  │
│ Funds → Insurance│      │ Proposer penalized  │
└──────────────────┘      └─────────────────────┘
                    ↓
        Oracle can appeal with jury

Technical Summary

Architecture: Minimum 2,500 DD stake locked via P2TR timelock transaction. Graduated slashing (warning → 5% → 25% → 50% → 100% + ban). 48-hour challenge period with DGB holder voting (60% threshold). Appeal process with 5-oracle jury. Slashed funds go to insurance pool.

Economics:

• Attack cost: 20,000 DD ($20k) + 600,000 DGB collateral to control 8 oracles
• Detection probability: 95%+
• Oracles earn triple rewards: transaction fees + DGB appreciation + reputation bonuses
• Compound staking available

Security: Economic disincentive makes attacks unprofitable. Expected value of honesty >> expected value of attack. Creates Nash equilibrium where honest behavior is dominant strategy.

Advantages:

• Strong economic security
• Skin-in-the-game creates trust
• Provably expensive to attack
• Insurance fund protects users

Disadvantages:

• $2,500 barrier to entry
• Requires governance system
• Risk of false slashing (addressed by appeals)
• Capital locked for months

---

Option 4: Miner-Validated Oracle Bundles

Layman's Explainer

What is it? Miners act as a second layer of verification. Oracles submit prices, but miners choose which prices to include in blocks. Miners including bad oracle data get their blocks rejected by the network. Like having judges verify scorekeepers.

Why powerful? Leverages DigiByte's existing 5-algorithm mining security. Miners want DGB to succeed, so they won't include bad data.

The catch? Adds complexity. Miners must understand oracle validation. Could centralize around mining pools.

Visual Flow

┌─────────────────────────────────────────────────┐
│  ORACLES: Broadcast signed price messages      │
│  to P2P network every minute                    │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  MINER COLLECTS ORACLE MESSAGES                 │
│  • Verify 8-15 valid signatures                 │
│  • Check all oracles active in epoch            │
│  • Calculate median price                       │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  CREATE ORACLE BUNDLE                           │
│  • Median price                                 │
│  • 8-15 oracle signatures                       │
│  • Merkle root of price messages                │
└─────────────────────────────────────────────────┘
                    ↓
        Include in coinbase OP_RETURN
                    ↓
┌─────────────────────────────────────────────────┐
│  NETWORK VALIDATES BLOCK                        │
│  • Bundle has 8-15 sigs? ✓                     │
│  • Oracles active? ✓                           │
│  • Median within 10% of history? ✓             │
│  • Merkle root correct? ✓                      │
└─────────────────────────────────────────────────┘
                    ↓
    Valid bundle?  →  Block accepted
    Invalid bundle? →  Block rejected!

Technical Summary

Architecture: Oracles broadcast to P2P network. Miners package 8-15 valid oracle messages into bundle with merkle root. Coinbase OP_RETURN includes oracle bundle. Block validation enforces: (1) 8-15 valid signatures, (2) all oracles active in epoch, (3) median within 10% of historical, (4) valid merkle root.

Security: Dual-layer validation. To attack requires:

• Compromising 8 oracles ($20k+ in stakes)
• AND controlling 51% mining across 5 algorithms ($225k/day)
• Total attack cost: $245k+ with 95% detection probability

Creates defense-in-depth through independent validation layers.

Advantages:

• Leverages existing PoW security
• No additional attack surface
• Miners economically aligned
• Defense-in-depth architecture

Disadvantages:

• Increased mining complexity
• Potential mining pool centralization
• Requires miner software updates
• Oracle bundle validation overhead

---

Option 5: Proof-of-Work Oracle Mining

Layman's Explainer

What is it? Oracles must solve mini proof-of-work puzzles (like Bitcoin mining, but easier) to submit prices. First oracles to solve puzzles win rewards. Like a race where you solve a math problem to submit your answer.

Why powerful? Sybil-resistant (can't spam fake oracles). Economically fair—anyone with computing power can participate.

The catch? Wastes electricity on PoW. Complex to implement. May centralize around powerful computers.

Visual Flow

┌─────────────────────────────────────────────────┐
│  ORACLE: Fetch price from exchanges             │
│  Price = $0.01234                               │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  SOLVE PROOF-OF-WORK PUZZLE                     │
│  Find nonce where:                              │
│  SHA256(price || timestamp || nonce) < target  │
└─────────────────────────────────────────────────┘
                    ↓
        Computing... computing...
                    ↓
┌─────────────────────────────────────────────────┐
│  SOLUTION FOUND!                                │
│  nonce = 847263                                 │
└─────────────────────────────────────────────────┘
                    ↓
        Broadcast: price + PoW + signature
                    ↓
┌─────────────────────────────────────────────────┐
│  NETWORK: Verify PoW difficulty                 │
│  First 15 valid submissions included            │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  REWARDS DISTRIBUTED                            │
│  Proportional to PoW difficulty achieved        │
└─────────────────────────────────────────────────┘
                    ↓
        Difficulty auto-adjusts next round

Technical Summary

Architecture: Oracles fetch prices then solve difficulty-adjusted PoW puzzle. Network accepts first N valid (PoW + signature) submissions per epoch. Difficulty adjusts targeting 15 submissions per epoch. Rewards distributed proportional to PoW difficulty.

Economics:

• Capital requirement: Computing hardware ($1k-$10k)
• Operational cost: Electricity
• Self-adjusting difficulty prevents monopolization
• Natural Sybil resistance (need 100x compute for 100 oracles)

Security: Expensive to dominate. Must invest in hardware + electricity. Economic attack becomes proof-of-work race, making manipulation visible and costly.

Advantages:

• Strong Sybil resistance
• Permissionless participation
• Self-regulating difficulty
• Proven PoW security model

Disadvantages:

• Electricity waste
• Complex implementation
• May centralize to specialized hardware
• Higher operational costs

---

Option 6: Delegated Oracle Network

Layman's Explainer

What is it? Instead of becoming an oracle yourself, you "vote" for operators by delegating your DGB to them temporarily. Operators with most delegated DGB get chosen to provide prices. They take a commission (5-20%) and share rewards with delegators. Like electing representatives.

Why powerful? Low barrier—participate with just 1,000 DGB. Professional operators emerge. Market-driven selection.

The catch? Can centralize around popular oracles (like mining pools). Operators might bribe delegators. Wealth = power.

Visual Flow

┌─────────────────────────────────────────────────┐
│  USER: I have 5,000 DGB                         │
│  Want to participate but don't want to run node │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  CHOOSE ORACLE OPERATOR                         │
│  • Check reputation                             │
│  • Check commission rate (5-20%)                │
│  • Check performance history                    │
└─────────────────────────────────────────────────┘
                    ↓
        Delegate 5,000 DGB to "Oracle Pro LLC"
                    ↓
┌─────────────────────────────────────────────────┐
│  DGB LOCKED (Delegation transaction)            │
│  Operator now has more voting weight            │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  ORACLE SELECTION (Weighted by delegation)      │
│  Top 15 operators by delegated DGB → Active     │
└─────────────────────────────────────────────────┘
                    ↓
        Oracle provides prices, earns rewards
                    ↓
┌─────────────────────────────────────────────────┐
│  REWARD DISTRIBUTION                            │
│  Operator takes 15% commission                  │
│  Remaining 85% split among delegators           │
│  You earned: 0.85 × (5,000/100,000) × reward   │
└─────────────────────────────────────────────────┘

Technical Summary

Architecture: Users lock DGB to oracle operator's pubkey via delegation transaction. Oracle selection weighted by total delegated stake (top 15 by delegation become active). Operators run infrastructure, take commission (5-20%). Rewards distributed pro-rata to delegators. Unbonding period prevents rapid re-delegation attacks.

Economics:

• Delegators: Passive income (80-95% of oracle rewards)
• Operators: Commission for infrastructure operation
• Market-driven: Best performers attract more delegation
• Similar to DPoS (EOS, Tron)

Security: Risk of centralization if delegation concentrates. Top 3-5 oracles could control network. Bribery vulnerability (operators paying for delegation).

Advantages:

• Low barrier to entry (1,000 DGB)
• Professional oracle operators
• Market-driven selection
• Passive income for delegators

Disadvantages:

• Centralization risk
• Wealth-weighted voting
• Commission extraction (5-20%)
• Potential for delegation buying/bribing

---

Option 7: Hybrid Reputation-Stake Model

Layman's Explainer

What is it? Combines reputation (Option 2) with staking (Option 3). You must stake 2,500 DD, but voting power depends on both stake AND reputation. A new oracle with huge stake still has low power until they prove themselves. A high-reputation oracle with minimum stake equals a wealthy oracle with bad reputation.

Why powerful? Prevents both plutocracy (rich controlling system) and reputation grinding (building trust to attack). Balanced incentives.

The catch? Most complex option. Requires economic commitment AND time to build reputation. May confuse users.

Visual Flow

┌─────────────────────────────────────────────────┐
│  REGISTER: Stake 2,500 DD                       │
│  Initial reputation = 0                         │
│  Initial voting weight = LOW                    │
└─────────────────────────────────────────────────┘
                    ↓
        Provide accurate prices for 90 days
                    ↓
┌─────────────────────────────────────────────────┐
│  REPUTATION GROWS: 0 → 50 → 80                  │
│  • Uptime: 99%                                  │
│  • Accuracy: 98%                                │
│  • Consistency: High                            │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  COMBINED WEIGHT CALCULATION                    │
│  Stake score = normalize(2,500 DD) = 50        │
│  Reputation score = 80                          │
│  Weight = √(50 × 80) = 63.2                    │
└─────────────────────────────────────────────────┘
                    ↓
        Compare to other oracles:
                    ↓
┌─────────────────────────────────────────────────┐
│  Oracle A: 100 rep, 2,500 stake → weight 70.7  │
│  Oracle B: 50 rep, 10,000 stake → weight 70.7  │
│  Oracle C: 80 rep, 5,000 stake → weight 77.5   │
│                                                 │
│  Can't dominate with just money OR reputation!  │
└─────────────────────────────────────────────────┘
                    ↓
        Price influence = weight² in median calculation

Technical Summary

Architecture: Minimum 2,500 DD stake required. Multi-dimensional reputation scoring (uptime, accuracy, consistency, early detection). Combined weight = √(reputation × stake_score) using geometric mean. Weighted median pricing where oracle influence = weight². Prevents single-factor dominance.

Game Theory: Attack requires excellence in BOTH dimensions. Examples:

• 100 reputation + 2,500 stake (min) → weight 70.7
• 50 reputation + 10,000 stake → weight 70.7 (same!)
• 90 reputation + 5,000 stake → weight 77.5 (WINS)

Balanced strategy (moderate stake + building reputation) is Nash equilibrium.

Security: Prevents plutocracy (can't just buy power) and Sybil attacks (can't spam without reputation). Creates alignment where long-term excellence is rewarded.

Advantages:

• Balances economics and meritocracy
• Prevents wealth-based dominance
• Prevents spam attacks
• Rewards sustained excellence

Disadvantages:

• Most complex system
• Higher barrier (stake + time)
• Difficult to explain to users
• Requires both tracking systems

---

Option 8: Optimistic Oracle with Challenge Bonds

Layman's Explainer

What is it? Assumes all oracle data is correct unless someone challenges it. Think an oracle lied? Post a bond (1,000 DD) to challenge them. If you're right, you get your bond back plus reward. If you're wrong, you lose your bond. After 48-hour waiting period with no challenges, data is finalized.

Why powerful? Very efficient—only need 1 oracle submission most of the time (98%+ unchallenged). Community self-policing.

The catch? 48-hour delay before finalization. Not suitable for real-time use. Requires active watchers.

Visual Flow

┌─────────────────────────────────────────────────┐
│  ORACLE: Submit price = $0.01234                │
│  Status: PENDING (Optimistic assumption)        │
└─────────────────────────────────────────────────┘
                    ↓
        48-hour challenge window opens
                    ↓
┌─────────────────────────────────────────────────┐
│  COMMUNITY MONITORING                           │
│  Anyone can verify price against exchanges      │
└─────────────────────────────────────────────────┘
                    ↓
           Price looks wrong?
                    ↓
        YES                         NO
         ↓                           ↓
┌──────────────────┐      ┌─────────────────────┐
│POST CHALLENGE    │      │No challenges        │
│Bond: 1,000 DD    │      │                     │
│+ Evidence        │      │                     │
└──────────────────┘      └─────────────────────┘
         ↓                           ↓
┌──────────────────┐         After 48 hours:
│DGB HOLDER VOTE   │      ┌─────────────────────┐
│60% needed to     │      │PRICE FINALIZED      │
│confirm oracle bad│      │Status: CONFIRMED    │
└──────────────────┘      └─────────────────────┘
         ↓
    Vote result?
         ↓
    Oracle wrong?            Oracle correct?
         ↓                          ↓
┌──────────────────┐      ┌─────────────────────┐
│Oracle slashed    │      │Challenger loses bond│
│Challenger wins   │      │Oracle keeps position│
└──────────────────┘      └─────────────────────┘

Technical Summary

Architecture: Oracle proposes price → 48-hour challenge period. Anyone can challenge with minimum 1,000 DD bond + evidence. Challenge triggers DGB holder vote (weighted by stake, 60% required). If oracle wrong: oracle slashed, challenger rewarded. If oracle right: challenger loses bond.

Economics:

• Optimistic assumption reduces overhead (98.5% unchallenged per UMA data)
• Economic deterrent prevents frivolous challenges
• "Expensive to attack, cheap to operate normally"
• Challenge cost: 1,000 DD risk if wrong

Security: Community watchers monitor for bad data. Economic incentive to catch and challenge false data. Self-policing through bond mechanism.

Advantages:

• Highly efficient (1 oracle usually sufficient)
• Self-policing by community
• Economic deterrent to spam
• Proven model (UMA protocol)

Disadvantages:

• 48-hour latency (NOT suitable for DigiDollar)
• Requires active monitoring community
• Governance overhead for disputes
• False challenge risk

NOT RECOMMENDED for DigiDollar: Real-time pricing needed for mints/redemptions. 48-hour delay unacceptable.

---

Security Comparison

Attack Cost Analysis

Attack Vector	Option 1	Option 2	Option 3	Option 4	Option 5	Option 6	Option 7	Option 8
Single Oracle Compromise	Social engineering 8 oracles	Spam 100s of oracles for months	$20k stake × 8	$20k + $225k mining	$50k hardware	Bribe delegators	$20k + reputation	$1k challenge bond
Exchange Manipulation	$1M+ (3 exchanges)	$1M+	$1M+	$1M+	$1M+	$1M+	$1M+	$1M+
Sybil Attack	Impossible (hardcoded)	Slow (90 day rep build)	Expensive ($2,500/oracle)	Expensive ($2,500/oracle)	Very expensive (PoW cost)	Expensive (need delegation)	Most expensive (stake+rep)	Moderate (bond system)
51% Attack Resistance	N/A	N/A	Medium	Very High (requires mining too)	Medium	N/A	Medium	N/A
Reputation Grinding	Low risk	High risk	N/A	N/A	N/A	N/A	Low risk (hybrid)	N/A

Defense-in-Depth Score

Option	Layers	Score
1: Hardcoded	2 (selection + median)	⭐⭐⭐
2: Reputation	3 (registration + reputation + pruning)	⭐⭐⭐⭐
3: Staking	4 (stake + slashing + appeal + insurance)	⭐⭐⭐⭐⭐
4: Miner-Validated	5 (oracle + mining + PoW + median + historical)	⭐⭐⭐⭐⭐
5: PoW Mining	3 (PoW + difficulty + economics)	⭐⭐⭐⭐
6: Delegated	2 (delegation + market)	⭐⭐⭐
7: Hybrid	5 (stake + reputation + weighted median + time + pruning)	⭐⭐⭐⭐⭐
8: Optimistic	3 (bond + voting + challenge)	⭐⭐⭐⭐

---

Game Theory Analysis

Dominant Strategy Analysis

For each option, what is the optimal strategy for a rational oracle?

Option 1 (Hardcoded):

• Honest: Maintain reputation, receive steady rewards
• Dishonest: Risk removal via governance, lose future income
• Dominant Strategy: Be honest (reputation valuable long-term)

Option 2 (Reputation):

• Honest: Build reputation slowly, increase influence, earn more
• Dishonest: Auto-pruned quickly, lose all invested time
• Dominant Strategy: Be honest (time investment at stake)

Option 3 (Staking):

• Honest: Keep stake, earn rewards, DGB appreciation
• Dishonest: 95% chance lose stake, blacklisted
• Nash Equilibrium: Honest behavior ($25k expected) >> Dishonest (-$7.5k expected)

Option 4 (Miner-Validated):

• Honest: Block accepted, earn rewards
• Dishonest: Block rejected, waste mining effort
• Dominant Strategy: Include valid oracle data (mining incentive alignment)

Option 5 (PoW Mining):

• Honest: PoW effort rewarded
• Dishonest: PoW effort wasted (rejected)
• Dominant Strategy: Be honest (PoW cost already spent)

Option 6 (Delegated):

• Honest: Attract more delegation, earn more commission
• Dishonest: Lose delegators, income collapses
• Dominant Strategy: Be honest (market punishment for bad behavior)

Option 7 (Hybrid):

• Honest: Maximize both stake score AND reputation
• Dishonest: Lose stake + reputation (double loss)
• Strongest Nash Equilibrium: Balanced excellence most profitable

Option 8 (Optimistic):

• Honest: Rarely challenged, low operational cost
• Dishonest: High chance of challenge, lose position + stake
• Dominant Strategy: Be honest (challenge probability deters cheating)

Conclusion

All options create incentive-compatible systems where honest behavior is the dominant strategy. Options 3, 4, and 7 have strongest game-theoretic properties due to multiple overlapping incentive layers.

---

Attack Cost Analysis

Minimum Attack Cost (Control 8 of 15 Oracles)

Option	Direct Cost	Indirect Cost	Total	Success Probability
Option 1	Social engineering	Reputation risk	~$50k-$100k	<5% (detection likely)
Option 2	Months of operation	Hardware + time	~$100k + 6 months	<10% (auto-pruning)
Option 3	8 × $2,500 = $20k	600k DGB collateral	$20k-$80k	<5% (slashing likely)
Option 4	$20k (oracles)	$225k/day (mining)	$245k/day	<1% (dual validation)
Option 5	$50k (hardware)	Electricity costs	$50k-$200k	<5% (PoW arms race)
Option 6	Bribe delegators	Delegation market	$100k-$500k	<10% (market reacts)
Option 7	$20k + reputation	6 months + collateral	$100k + 6 months	<1% (highest security)
Option 8	$8k (8 bonds)	Voting manipulation	$50k-$200k	<5% (community voting)

Detection Time

• Option 1: Minutes to hours (median deviation)
• Option 2: Hours to days (reputation tracking)
• Option 3: Minutes (slashing triggers)
• Option 4: Immediate (block rejection)
• Option 5: Immediate (PoW validation)
• Option 6: Days (market response)
• Option 7: Minutes to hours (reputation + stake tracking)
• Option 8: Minutes to 48 hours (challenge period)

---

Hybrid Architecture Recommendations

Recommended: Triple-Layer Security

Combining multiple options creates defense-in-depth:

┌─────────────────────────────────────────────────────┐
│  LAYER 3: Community Governance                      │
│  • DGB holder voting on disputes                    │
│  • Public oracle dashboard                          │
│  • Transparent monitoring                           │
└─────────────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│  LAYER 2: Miner Validation (Option 4)               │
│  • Miners validate oracle bundles                   │
│  • Invalid bundles → invalid blocks                 │
│  • Leverages 5-algorithm PoW                        │
└─────────────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│  LAYER 1: Hybrid Reputation-Stake (Option 7)        │
│  • 2,500 DD stake requirement                       │
│  • Reputation building (90 days)                    │
│  • Combined weight = √(rep × stake)                 │
│  • Slashing for misbehavior                         │
└─────────────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│  FOUNDATION: Hardcoded Bootstrap (Option 1)         │
│  • 30 initial oracles for launch                    │
│  • Gradually replaced by community                  │
│  • Remain as backup/fallback                        │
└─────────────────────────────────────────────────────┘

Migration Strategy

Phase 1: Launch with Option 1

• 30 hardcoded oracles
• Simple, fast deployment
• Gets DigiDollar operational

Phase 2: Add Option 7 (Hybrid)

• Enable staking mechanism
• Community oracles join
• Gradual replacement of hardcoded nodes

Phase 3: Add Option 4 (Miner Validation)

• Soft fork for miner validation
• Full triple-layer security
• Maximum decentralization achieved

Final State: Option 7 + Option 4

• 100+ community staked oracles
• Miner validation on every block
• Hardcoded oracles as backup only
• Defense-in-depth fully operational

Why This Combination Works

1. Progressive Decentralization: Start simple, evolve to complex
2. Multiple Security Layers: Each layer catches different attacks
3. Economic + Technical Security: Combines stake + PoW
4. Smooth Migration: No disruption during transition
5. Battle-Tested: Uses proven components from multiple projects

---

Conclusion

Summary of Options

Best for Fast Launch: Option 1 (Hardcoded)
Best for Decentralization: Option 2 (Reputation)
Best for Security: Option 3 (Staking) or Option 7 (Hybrid)
Best for PoW Integration: Option 4 (Miner-Validated)
Best for Sybil Resistance: Option 5 (PoW Mining)
Best for Accessibility: Option 6 (Delegated)
Best Overall: Option 7 (Hybrid) + Option 4 (Miner-Validated)
Not Recommended: Option 8 (Too slow for DigiDollar's real-time needs)

Final Recommendation

Implement hybrid approach:

1. Launch: Option 1 (30 hardcoded oracles)
2. Evolve: Option 7 (hybrid reputation-stake community oracles)
3. Secure: Option 4 (add miner validation layer)

This creates world-class oracle network combining:

• Fast deployment (Option 1)
• Economic security (Option 7 staking)
• Meritocratic selection (Option 7 reputation)
• PoW validation (Option 4 mining)
• Progressive decentralization (gradual migration)

Result: Secure, decentralized, battle-tested oracle network for world's first UTXO-native stablecoin.

---

Status: Ready for implementation
Risk Level: Low (progressive rollout with fallbacks)
Expected Outcome: Best-in-class oracle security

[elsantodios]

Hola, referente a , ❌ Debilidades: Centralizado (30 nodos codificados)
Tal vez una buena idea seria hacer 2 capas, es decir, se escogen 30 casa de cambios (exchange) y se hace la media de precio y luego la segunda capa de precio seria coger servicios que ofrecen el precio medio como coingecko. Y el sistema escoge como propones aleatoriamente y si el resultado del precio es igual o tiene una variación de un 5% el precio se da por valido.
Así creo que tendría mas solidez, Y otro punto importante seria que solo los Exchanges que tengas DGB fueran validos.
Espero haber podido ayudar, con mi pequeñito grano de arena.
Un saludo

[m6p5m6c4sc-spec]

Per Grok…

It’s resilient against single points of failure, but no oracle is impenetrable—decentralized systems like Chainlink have faced exploits (e.g., $182M Beanstalk flash loan in 2022, $24M Harvest manipulation). Based on historical attacks (flash loans, Sybil, collusion) and the spec’s details, the optimal hypothetical attack would be an economic Sybil attack combined with flash loan manipulation during aggregation epochs.
Hypothetical Optimal Attack Strategy

1. Phase 1: Sybil Reputation/Stake Farming (Preparation, Low Cost Entry):
   • Create multiple identities (Sybil attack) to build reputation over 90 days—use cheap, distributed nodes or bots to simulate legitimate activity (e.g., accurate price feeds on historical data). Stake 2,500 DD per oracle (buy low during dips or mint via initial collateral exploits if bootstrapping vulnerabilities exist).
   • Cost: Low (~$2,500–$10,000 per oracle in DD, scalable with 100+ community oracles). Exploit the 90-day window by rotating identities to avoid slashing detection.
   • Goal: Gain 51%+ of weighted influence (√(rep × stake)) in the hybrid model, allowing control over aggregation (median/trimmed mean vulnerable to coordinated outliers if >50% are compromised).
2. Phase 2: Flash Loan Amplification (Execution, Short-Term Manipulation):
   • During an epoch (every 100 blocks/25 minutes), use flash loans (borrow massive DD/DGB on DeFi protocols) to artificially pump/dump DGB price on secondary markets or DEXes.
   • Feed skewed data to controlled oracles, exploiting time windows (short 25-min epochs make brief manipulations viable). Target outliers to shift the median (e.g., report 20% inflated DGB/USD price to trigger under-collateralization).
   • Coordinate with miner collusion (leverage DigiByte’s 87.7% pool concentration to validate false blocks via Option 4 integration), bypassing PoW checks.
   • Repay flash loan in the same block, extracting value by draining vaults (e.g., force DCA below 120% threshold, triggering ERR and collateral release).
3. Phase 3: Exit and Cover (Extraction):
   • Slashing resistance: Withdraw stakes before detection (dispute windows delay penalties). Use hardcoded bootstrap as fallback to prolong chaos if community oracles are slashed.
   • Profit: Arbitrage peg breaks (buy low DD pre-attack, redeem post-manipulation) or liquidate under-collateralized positions.
   Why Optimal? It’s cost-effective (flash loans are cheap/free if repaid), exploits the hybrid’s weaknesses (reputation farming + stake economics), and scales with decentralization (more oracles = more Sybil targets). Historical parallels: Mango Markets ($100M, 2022 flash loan oracle skew) and Beanstalk ($182M, governance/oracle exploit). Total cost: $100K–$1M initial stake, recoverable via profits; ROI high if peg breaks by 10–20%.
   Why It’s Hard or Mitigated
   • High Barriers: 90-day reputation build requires sustained effort; slashing (stake loss) deters casual attacks. Miner validation (Option 4) needs 51% PoW control (~$millions in hashrate rental). Hardcoded 30 oracles act as fallback, requiring separate compromise.
   • Defenses: Trimmed mean resists outliers, time windows limit flash loan windows, and progressive rollout (Phase 1 hardcoded only) allows hardening. Multi-source feeds (on/off-chain) and circuit breakers pause during anomalies.
   • Economic Deterrence: Attacker needs >$10M stake for meaningful control (100 oracles), with slashing risk exceeding profits in a resilient system.
   This analysis is theoretical for system improvement—real attacks are illegal and counterproductive. The spec’s multi-layer design (staking + PoW + bootstrap) makes it tougher than single-oracle systems like early Chainlink exploits. To strengthen: Add randomness to epochs, stake slashing auctions, and multi-oracle redundancy. Overall, DigiDollar’s oracles are robust, but no system is foolproof—ongoing audits (DigiDollar Implementation Specification v5.0 - Taproot Enhanced #324) are key.

[Neel34090972]

Security & stability will always be the prime objective for any stablecoin. At the same time, the most secure system in the world is of no value if it never makes it to market. The recommended hybrid approach looks to be a solid means of balancing these priorities. Bravo.

[arlnet]

Option 7

[arlnet]

Then again now I see how 7 plus 4 could be a good combo with the weighted system.

[besnniku]

Chatted with Grok and his final suggestion is Hybrid Option 7 (Reputation-Stake) combined with Option 4 (Miner-Validated Bundles) remains the best fit—max security via multi-factor weights (√(rep×stake)) and PoW-backed validation, high decentralization through gradual permissionless scaling, balanced complexity for DGB’s no-owner model, and robust incentives (honest dominant strategy per game theory analysis).
Refined Changes (Incorporating Doc Flows, elsantodios Layers, Grok Attack Sim):

• Bootstrap with Option 1’s 30 hardcoded nodes for zero-cost MVP launch (as in original spec: chainparams.cpp list, volunteer ops), enforcing two-layer sources (elsantodios: median from 30+ DGB-listed exchanges first, then aggregators with <5% variance reject—integrates into Step 3 fetch without disruption, hardens vs. $1M+ manip).
• Auto-transition to 7+4 after 3 months (shorter than 6: epoch-based governance trigger when >50 community nodes join via rep build).
• Quantum-proof sigs with Dilithium (NIST lattice) from launch—replace Schnorr in oracle.h/msg structure (same verify flow, ~2KB sigs ok for bundles; counters Shor’s breakage in 10-15 years).
• Anti-Sybil/Flash Loan Defenses (from Grok sim): Add VRF randomness to epoch seeds (block hash + BLS-VRF in consensus/oracle.cpp) to unpredict timing; auto-slash via LSTM ML in node.cpp on >8% outliers (triggers insurance pool from slashed reps, no votes needed); min rep build now 60 days with unique API key proofs to kill farming.
• Source Expansion: 40+ exchanges (free/open APIs only, no keys needed for basics—e.g., Binance public ticker) + 4 aggregators; require 25/40 + 3/4 min successes per oracle.
• Accessibility Tweaks: Rep permissionless/no-fee; optional tiny stake (50 DGB) for +15% weight boost—keeps volunteer ethos, lowers barriers vs. 2,500 DD.
• Speed/Security Polish: Drop to 3-block updates (~45s) post-bootstrap; add merkle proofs for partial bundle validation (reduces miner overhead); fallback to hardcoded if consensus fails (as in original BFT limits).
  This refines to cheaper (free APIs/volunteers), tougher (Sybil cost now $200k+ with 90% detection), and quantum-safe without altering core flows (init-select-fetch-sign-collect-consensus-include-validate-DD ops intact). Fits DGB’s decentralized, low-budget reality.

[IbrahimCS]

I didn't read or understand everything, but I care about 3 points:

1- EVERY 4 BLOCKS (~1 MINUTE) ║
║ Active Oracles Update Price

• Why not every 2 blocks (30 seconds) Update the Price as the swapping process on DEX?

2- Oracle queries 7 data sources in parallel: │
│ ┌──────────┬──────────┬──────────┬──────────┬──────────┐ │
│ │ Binance │ KuCoin │ Messari │ OKEx │ Huobi │ │
│ │ $0.01234 │$0.01235 │$0.01233 │$0.01236 │$0.01233 │ │
│ └──────────┴──────────┴──────────┴──────────┴──────────┘ │
│ ┌──────────┬──────────┐ │
│ │CoinGecko │CoinMktCap│ | Xpump | Zhack │
│ │$0.01234 │$0.01235 │ | | 0.022$ | 0.0001$ |

• where's bybit? and maybe Kraken in the future.

• Anyway, suppose there's hacking or delisting or listing or pump or dump on the exchange, so my idea is:
  A- Oracle queries 12 or 10 data sources in parallel to ensure any errors do not exceed 1/10
  B- Then it's better to remove the highest and lowest price (0.022$ & 0.0001$)
  C- Then take the average = (0.012345$)

┌─────────────────────────────────────────────────────────────────┐
│ STEP 9: DIGIDOLLAR OPERATIONS │
│ │
│ MINTING: │
│ • User wants 1,000 DD ($1,000) │
│ • System reads oracle price: $0.01234/DGB │
│ • Calculates collateral: 243,111 DGB (300% ratio) │
│ • User locks DGB, receives 1,000 DigiDollars │
│ │
│ REDEMPTION: │
│ • User burns 1,000 DD │
│ • System calculates DGB owed at current oracle price │
│ • Releases proportional collateral to user │
│ │
│ All operations use consensus price from latest block │
└─────────────────────────────────────────────────────────────────┘

3- This operation is an incentive for whales and CEX to destroy the DD price to make a lot of profits:

• I hope you read my 3rd point: best mechanism (Mint 1DD=1$ / Redemption ??DD=1$) in this comment.

After asking AI:

• Your idea encourages whales to sell large quantities of (DD) to drive down its price and make huge profits.
• My Idea will prevent dump attacks, but there's no incentive to buy DD if its price dropped except (increasing the price of locked DGB, and people need to unlock DGB) so DD price may take a long time to return 1$, but I was surprised to learn that my idea is being considered in the design of some stablecoins like DAI and sDOLA, RAI and LUSD.
• The best idea from AI is (Hybrid Band Model) Burn (DD) at 1$ if within band (1.02$ - 0.95$); outside adds incentives/penalties (1%-5%). This will lead to balanced resilience and stability.

This means that if the DD price dropped 20% to 0.8$, people need to burn 95$ = 118.75 DD instead of 100DD (your idea) or 125DD (my idea), and they would earn 5% as an incentive for buying and redeeming.

Try to ask AI, but I feel AI ignores the point of the price of DGB and the need to unlock DGB.

[koyahness]

Interesting conversation on the price oracles. while i didnt wrap everything around my head. A classic example of issues with price oracles involve the terra Luna collapse. (hoping, I am not off topic)

While the Terra system's own price oracle was not the initiator of the de-peg, issues related to price oracles did contribute to the chaos and exploitation in the wider ecosystem:

Oracle Issues in the Broader Ecosystem

• Chainlink Oracle Pauses: The sheer speed and severity of LUNA's crash led a major external price feed provider, Chainlink, to pause its LUNA price oracle for a period due to "market conditions." Therefore resilient oracles are important and needed those that are decentralized and cant be pauased at will.

  • Impact: This pause affected various decentralized lending platforms (like Venus Protocol and Blizz Finance) that relied on the Chainlink oracle to determine the value of LUNA collateral. Since the oracle had a stale, non-zero price for LUNA, attackers were reportedly able to deposit LUNA (which was practically worthless on exchanges) at the old, higher oracle price to borrow other assets, leading to millions in losses on those platforms.

• Terra Price Oracle (Internal): The Terra blockchain had its own internal price oracle, determined by validators, which supplied the price of LUNA needed for the UST-LUNA swap mechanism.

  • Deteriorating Accuracy: Research suggests that as the crisis deepened, the internal Terra Price Oracle price for LUNA became increasingly inaccurate, with significant discrepancies (up to 70%) compared to the LUNA price on centralized exchanges. This inaccuracy meant the arbitrage incentive failed, and market participants incurred massive losses when trying to use the core swap mechanism.

In short the failure or pausing of price oracles in the decentralized finance (DeFi) ecosystem (both external and internal) is a pertinent topic.

[DarekDGB]

I’ve been working on an independent quantum-resistant security architecture for DigiByte. Some parts of it especially Sentinel AI (anomaly detection) and DQSN (network-wide validation) could potentially support the long-term security of DigiDollar oracles by detecting abnormal price feed behaviour or coordinated manipulation.

Not proposing integration now just sharing research that may be useful for future oracle security planning.

Reference links:
https://github.com/DarekDGB/Sentinel-AI-v2
https://github.com/DarekDGB/DigiByte-Quantum-Shield-Network
https://github.com/DarekDGB/DigiByte-ADN-v2

—Darek