DappLink Oracle Documentation

Overview

DappLink Oracle provides decentralized, verifiable, and auditable off-chain data services for Web3 applications. The system adopts a multi-node collaboration mechanism combined with a ZK (Zero-Knowledge) commitment-signature scheme to construct a robust data-security framework. From data collection and aggregation to verification and final on-chain submission, every step is fully traceable and strongly consistent. Before any data is written on-chain, it undergoes multi-node cross-validation, ZK integrity proofs, and signature confirmation—ensuring authenticity, tamper-resistance, and high availability at the source.

As a future-oriented data infrastructure for Web3, DappLink Oracle aims to become the trusted bridge connecting on-chain smart contracts with real-world information. Whether it is price feeds, RWA data, cross-chain messages, event-prediction data, or off-chain computation results, DappLink delivers on-chain–consumable data with low latency, high security, and strong reliability. It provides a solid data foundation for a wide range of applications, including DeFi, GameFi, RWA, event-prediction markets, oracle networks, and infrastructure protocols—accelerating the large-scale adoption of Web3.

1.DappLink Oracle System Architecture Explanation

This diagram illustrates the complete data flow of the DappLink Oracle, from off-chain data sources to the decentralized oracle network, on-chain delivery, and final consumption by Web3 applications. It highlights DappLink’s design principles of decentralization, multi-source data integration, verifiability, and high availability.

1.1.Data Source Layer

The leftmost section represents the various off-chain data sources that DappLink Oracle can access, including:

• CEX/DEX: Real-time market data such as prices, trading volume, and asset quotes.
• Stock & Fund Services: Financial data for stocks and funds, supporting RWA or TradFi-integrated applications.
• Sports Data Services: Sports scores and event results for prediction markets or game scenarios.
• RWA Data Services: Real-world asset valuations, pricing, and notarization data.
• KYC/KYB Data Providers: For decentralized identity (DID) or compliance-related use cases.

These sources cover a wide range of use cases including DeFi, GameFi, RWA, prediction markets, and multi-chain financial applications.

1.2.DappLink Oracle (Core Layer)

The central section shows the core structure of the DappLink Oracle, composed of oracle nodes, data-processing modules, and application-level oracle services.

1.2.1.Oracle Node Network

Nodes labeled node-1 to node-n represent a decentralized network that provides:

• Multi-node collaboration
• Decentralized data collection and verification
• No single point of failure
• Higher data consistency and security

Each node independently fetches data, performs cross-verification, and applies ZK-based commitment signatures.

1.2.2.Oracle Modules

Once the data is validated, it flows into different types of oracle modules:

• Price Oracle: On-chain price feeds for token markets and asset indices.
• ZKId Oracle: Zero-knowledge–based identity verification for DID, KYC, and KYB use cases.
• Event Oracle: Sports events, real-world results, news triggers, and other event-based data.
• VRF Oracle: Verifiable random numbers for GameFi and NFT lotteries.
• RWA Oracle: Verification and valuation of real-world assets.

All oracle modules operate on the same decentralized node network and ZK verification framework.

1.2.3 DappLink Oracle (Unified Output Layer)

All oracle outputs pass through the unified DappLink Oracle gateway, which ensures:

• Standardized output
• Multi-chain compatibility
• Integrity-verified signatures
• High-availability routing

This layer prepares the data for efficient delivery across multiple blockchains.

1.3.Public Chain Layer

The right section displays several chains supported by DappLink Oracle, including:

• RootHash Chain – DappLink’s ecosystem chain
• CP Chain – Chain for the CoinUp platform
• Dolphinnet – EVM-compatible partner chain
• Manta – Chain optimized for privacy and ZK applications

The system supports simultaneous submission to multiple chains depending on application requirements.

1.4.DApp Layer (Application Layer)

Finally, validated oracle data is consumed by a wide variety of Web3 applications:

• Event Prediction Market DApp
• RWA DApp
• DeFi DApp (lending, liquidation, derivatives, etc.)
• GameFi DApp (randomness, event triggers)
• Other DApps (DID, cross-chain protocols, AI + Web3, etc.)

This is where the value of the oracle system is fully realized.

2.Summary: A Trustworthy Bridge Between Off-Chain Data and On-Chain Applications

The entire diagram demonstrates the full lifecycle of DappLink Oracle data:

Multi-source off-chain data → Multi-node validation → ZK commitments → Oracle modules → Multi-chain publishing → DApp consumption

It embodies:

• Decentralization
• Verifiability
• Multi-chain interoperability
• Strong scalability
• High security

making DappLink Oracle a foundational data infrastructure for connecting Web3 to the real world.

All services share a unified architecture

This diagram illustrates the complete lifecycle of DappLink Oracle, from off-chain data acquisition, processing, and signing, to on-chain smart contract management, and finally consumption by Web3 applications.

1.Offchain Oracle Network

• Data Source

  • Includes CEX/DEX, financial data, RWA data, event data, etc.
  • Oracle nodes fetch raw off-chain data from these sources.

• Oracle Node

  • Each node receives raw data and signs it, producing verifiable off-chain commitments.
  • Multi-node mechanisms provide decentralized validation, ensuring data security and tamper-resistance.

• Aggregator

  • Aggregates data from multiple nodes to produce a unified, verified output.
  • The aggregated data is sent to on-chain contracts for further management and distribution.

2.Onchain Oracle Contracts

The on-chain layer consists of smart contract modules that handle verification, management, and distribution:

• BlsApkRegistry

  • Stores and manages node public keys for on-chain signature verification.
  • Supports the checksignature process to ensure data provenance and authenticity.

• StakingRewardContract

  • Manages node rewards and staking.
  • After data verification, nodes are incentivized based on their contributions.

• ServiceManager

  • Manages different oracle service modules (Event, ZKID, VRF, Price, RWA).
  • Ensures that data types and service logic are correctly executed.

• PodManager

  • Oversees and schedules outputs from various service modules.
  • Uses the checkpass process to ensure data has passed verification before routing to the corresponding pod.

3.Pod Modules (Data Distribution Units)

Pods are the functional units of the on-chain oracle, distributing verified data to DApps:

• event-pod → Event data
• zkid-pod → Zero-knowledge identity data
• vrd-pod → VRF random numbers
• price-pod → Price feeds
• rwa-pod → Real-world asset data

Pods ensure that different data types are independently verified, categorized, and ready for DApp consumption.

4.DApp Consumption Layer

Finally, verified data from the pods is consumed by Web3 applications, including:

• DeFi protocols (price feeds, liquidations, derivatives)
• GameFi applications (randomness, event triggers)
• RWA applications (asset valuation, risk control)
• Event prediction markets
• Zero-knowledge identity and compliance use cases

5.Summary Flow

The DappLink Oracle data lifecycle can be summarized as: Off-chain data fetch → Multi-node signing and validation → Aggregation → On-chain smart contract verification and management → Pod-based categorization → DApp consumption

Key Features:

• Decentralized validation: Multi-node cross-checks prevent single points of failure.
• Verifiable data: On-chain contracts verify node signatures and data integrity.
• High scalability: Multiple pods handle different data types in parallel.
• High security and availability: End-to-end traceable from data source to DApp.

Service Documentation

Price Oracle

On-chain price feeds for trading pairs. Read the latest price and check freshness via OraclePod.

Key Features:

• String-based price storage (decimal format)
• Timestamp-based freshness checks
• Per-market pod deployment

VRF Oracle

Verifiable random number generation. Request randomness by requestId and retrieve fulfilled random words.

Key Features:

• Request-response pattern
• Multiple random words per request
• Event-driven fulfillment notifications

Event Oracle

Off-chain event outcomes (currently sports fixtures) anchored on-chain. Query final results by requestId.

Key Features:

• Event metadata storage (description, sides, winner)
• String-based outcome representation
• Per-market pod deployment

zkID Oracle

Zero-knowledge KYC verification with policy-based routing. Verify user attributes without exposing personal data.

Key Features:

• Poseidon commitment storage
• Groth16 zkSNARK proof verification
• Policy versioning and isolation

Quick Start

1. Choose Your Service

Identify which oracle service you need:

• DeFi protocols → Price Oracle
• Gaming/NFTs → VRF Oracle
• Prediction markets → Event Oracle
• Compliance gates → zkID Oracle

2. Get the Pod Address

Each service publishes pod addresses for specific markets/policies. Contact the oracle team or check official announcements for the pod address relevant to your use case.

3. Integrate the Interface

Import the pod interface in your contract:

// Example: Price Oracle
interface IOraclePod {
    function getSymbolPrice() external view returns (string memory);
    function isDataFresh(uint256 maxAge) external view returns (bool);
}

4. Read Data

Call the pod's read functions in your business logic:

contract MyDApp {
    IOraclePod public oraclePod;
    
    constructor(address pod) {
        oraclePod = IOraclePod(pod);
    }
    
    function usePrice() external view {
        require(oraclePod.isDataFresh(10 minutes), "stale");
        string memory price = oraclePod.getSymbolPrice();
        // Use price in your logic
    }
}

5. Monitor Events

Subscribe to pod events for off-chain indexing:

event MarketPriceUpdated(string oldPrice, string price, uint256 timestamp);

Security Considerations

For All Services

• Aggregator-Only Updates: Only the registered aggregator can submit data to managers, preventing arbitrary injections
• BLS Signature Verification: All data is verified via aggregated BLS signatures before being written to pods
• Pod Whitelisting: Managers only accept updates for whitelisted pods
• Freshness Checks: Always validate data freshness where applicable (e.g., isDataFresh() for prices)

Service-Specific Notes

Price Oracle:

• Prices are stored as strings; parse carefully to avoid precision errors
• Always check isDataFresh() before using prices in critical operations

VRF Oracle:

• requestId must be unique per consumer; use deterministic encoding
• Always verify fulfilled status before consuming random words

Event Oracle:

• Winner strings are case-sensitive; normalize in your contract if needed
• No on-chain dispute mechanism; trust the oracle network's multi-operator consensus

zkID Oracle:

• Policy versions are enforced; ensure you use the latest version
• zk proof verification requires matching public inputs; follow the prover SDK instructions

Support & Resources

• Documentation: See individual service docs linked above
• Contract Interfaces: Available in oracle-contracts/src/interfaces/
• Examples: Reference implementations in service-specific documentation

License

See repository LICENSE file for details.