# Introduction The fully on-chain oracles for secure and reliable decentralized data feeding and automation across multiple chains. Welcome to Orally, the forefront of decentralized solutions and oracle services within the blockchain ecosystem. As the digital world continuously evolves, the need for interconnected, secure, and versatile applications becomes paramount. Orally bridges this gap, offering a suite of tools that integrate the trustless nature of blockchain with the ever-expanding needs of decentralized applications (dApps). Our platform is built on the innovative Internet Computer Protocol (ICP), designed to provide seamless interaction between traditional internet services and decentralized blockchain functionality. Through our sophisticated suite of services — Sybil, Pythia, Apollo, Hephaestus, and Hermes — we empower developers, enterprises, and end-users to create a fully integrated, multi-chain, and versatile decentralized experience. Below, find an overview of our revolutionary tools, each named after iconic figures from mythology, resonating with their unique capabilities and roles within the Orally ecosystem: 1. **Sybil**: Inspired by the multiple sources of prophecy in ancient lore, Sybil provides a multitude of embedded price data feeds for various assets, operating through decentralized data fetching and offering custom feed creation based on the specific needs of dApps with an efficient verifiable approach. 2. **Pythia**: Named after the revered oracle of Delphi, Pythia is an automation module that allows for subscription-based data delivery by time or volatility, pulling from Sybil's data feeds or generating random numbers for an added layer of functionality. 3. **Apollo**: Reflecting the prophetic prowess of the god Apollo, this module facilitates request-based data delivery, where EVM contracts can request specific data, processed and delivered by our system with precision and efficiency. 4. **Hephaestus**: Symbolizing the transformative craft of the god of blacksmiths, Hephaestus allows for intricate data preprocessing, accepting user-defined algorithms to mold raw data into refined, dApp-specific requirements. 5. **Hermes**: Embodying the swift communication attributed to the messenger god, Hermes enables seamless messaging between chains, optimizing costs and enhancing connectivity across the blockchain spectrum. In the following sections, we dive deep into each module, offering comprehensive technical guides, use cases, integration methods, and best practices to harness the full potential of Orally's offerings. Whether you're a developer looking to integrate decentralized features into your project, an enterprise aiming for blockchain expansion, or a curious enthusiast navigating the realms of decentralized services, our documentation is your starting point. Join us in pioneering the future of decentralized connectivity, where security, versatility, and innovation converge, powered by Orally. Welcome to the next generation of blockchain integration. # Why Orally? In the rapidly evolving realms of blockchain and traditional digital spaces, a dire need exists for secure, reliable, and efficient bridges that seamlessly interlink these systems. As decentralized applications (dApps) continue to advance, they're increasingly in need of real-world data inputs, enhanced user experiences, and advanced interoperability. This is the juncture where Orally doesn’t just step in; it pioneers. But why choose Orally? Here’s an exploration into the foundational reasons. ### Unparalleled Interoperability **Cross-Chain Communication:** In an ecosystem teeming with diverse blockchains, the ability to communicate and initiate transactions across these varied chains isn’t just a convenience; it’s a critical requirement. Orally’s Hermes module, drawing its name from the messenger of the gods known for traversing worlds, equips dApps with the remarkable capability to transmit messages and data effortlessly across distinct blockchains. This innovative function shatters the barriers that have traditionally segregated blockchains, heralding a transformative era of cross-chain cooperation and enriched functionality. ### Trustworthy Data, Decentralized **Verifiable Real-World Data:** The credibility and accuracy of data are the linchpins around which the utility of any decentralized application revolves. Sybil, named after the prophetic figure renowned for her multiple voices, establishes a fortified framework for accumulating, authenticating, and leveraging real-world data within the blockchain arena. From cryptocurrency price feeds to eclectic data types like weather forecasts or social media trends, Orally guarantees that your applications operate based on data that is not only prompt and precise but also secure and dependable. ### User-Centric Design **Seamless Authentication:** The chasm that separates traditional digital user experiences and blockchain technology often manifests as a daunting hurdle for mainstream users. Orally's DAuth module elegantly bridges this divide, presenting a user-friendly authentication process via prevalent social media logins while upholding the stringent privacy and security protocols intrinsic to blockchain technology. This fusion significantly elevates user experience and accessibility, propelling mainstream user adoption of decentralized platforms. ### Precision-Driven Customizability **Data Tailoring:** A generic solution is seldom the right fit in the nuanced landscape of data utilization. Recognizing this, Orally’s Hephaestus module bestows upon dApps the tools necessary to refine, tailor, and customize data — mirroring the divine craftsmanship of its namesake. This capability ensures your applications are not merely recipients of accurate data but are empowered by information that is contextually relevant, specifically curated, and strategically valuable. ### Proactivity & Efficiency **Automated Operations:** The realm of the future is reserved for those who architect it in the present. Orally’s Pythia and Apollo modules function as proactive conduits within the ecosystem, automating data delivery based on specific, predefined conditions, and enabling on-demand, request-based data retrieval, respectively. This level of foresight ensures that your dApps are optimally responsive, exceptionally resource-efficient, and strategically prescient, thereby enhancing operational efficacy and cost optimization. ### Commitment to Decentralization and Economical Efficiency **Utilizing Established Consensus:** Instead of reinventing the wheel and establishing a new network of validators, thereby being only "semi-decentralized," Orally leverages the existing, robust consensus mechanism provided by the Internet Computer Protocol (ICP). This strategic choice not only underscores our commitment to full decentralization but also significantly enhances economic efficiency, leading to lower costs — savings that we pass directly to our users. ### Problem-Oriented Solutions for dApps **Empowering dApp Development:** Orally is not just a platform but a solution-oriented partner for dApp developers. We understand the unique challenges faced by decentralized applications, especially concerning data needs for on-chain business logic. Our platform negates the necessity for dApps to construct their own centralized services, offering instead a reliable, economical, and autonomous alternative. By focusing on resolving actual, practical problems, we make data handling easy, flexible, and affordable, allowing developers to focus on what they do best: creating groundbreaking dApps. ### Security as a Standard **Decentralized and Secure Foundations:** In the contemporary digital epoch, where security is as critical as innovative breakthroughs, Orally steadfastly upholds the principles of decentralization to deliver solutions that are groundbreaking yet securely fortified. Through methodologies like ECDSA signatures for data authentication and the consistent, real-time heartbeat system from the ICP execution layer, Orally embeds trust and reliability at every interactional juncture. ### Why Orally? Because Your Vision Merits Exceptionalism Orally isn’t solely a product; it’s a manifestation of a seamless, interconnected, and efficient decentralized future. It’s a commitment to equipping dApp developers and users with tools and services that don’t just fulfill expectations but transcend them. With its intuitive interfaces, state-of-the-art technological framework, and visionary modules, Orally distinguishes itself as the guiding light for those navigating the exhilarating yet challenging waters of blockchain innovation. Opting for Orally means choosing more than a service. You are selecting a partner wholly dedicated to amplifying your vision, elevating your aspirations, and safeguarding your journey through the digital landscape. You're embracing a future where your dApp isn’t an insular entity but an integral component of a broader, interconnected, and synergistic ecosystem. Welcome to a realm of boundless possibilities. Welcome to Orally. # Orally Price Feed Integration Guide ### Overview The Orally Price Feed system provides real-time price data from 9 centralized exchanges, secured through ICP canister's trusted execution environment and verified on-chain through ECDSA signatures. This guide explains the integration process and operation flow. ### Initial Setup 1. Generate API Key * Visit * Follow the API key generation process * Store the key securely for subsequent requests ### Integration Process #### Regular Price Monitoring Your liquidation bot should monitor prices using the following flow: 1. Regular Price Checks * Endpoint: `get_xrc_data` or `get_xrc_data_batch` * Cost: $0.001 per request * Include: * API key * Cache TTL (default 600 seconds) * Target token pair ID * Response: Current price feed without proof #### Price Update Verification When price changes require on-chain updates: 1. Request Signed Data * Endpoint: `get_xrc_data_with_proof` * Cost: $0.04 per request * Returns: Price data with ECDSA signature from ICP canister 2. On-Chain Verification * Submit signed data to Partisia chain * Smart contract verifies: * ECDSA signature authenticity * Signer authorization * Data integrity * After verification, data is decoded and available for use ### Technical Details #### Proof Generation 1. ICP canister aggregates price data from exchanges 2. Data is encoded into a standardized format 3. Canister generates ECDSA signature using its DKG key 4. Returns packed data: {price\_data, metadata, signature} #### Verification Process 1. Smart contract unpacks the provided data 2. Verifies ECDSA signature against authorized signer list 3. Decodes price data for use in smart contract operations ### Cost Structure * Regular price checks: $0.001 per request * Recommended for continuous monitoring * Use cache\_ttl to optimize costs * Signed data requests: $0.04 per request * Only needed when updating on-chain values * Includes proof generation and ICP canister operations ### Best Practices #### Optimize Batch Requests 1. Use `get_xrc_data_batch` instead of multiple single requests: * Group related price feed queries into a single batch request * Example: Query all tokens in a lending pool in one call * Reduces total API calls and associated costs * Improves overall response time #### Cache TTL Optimization 1. Regular Price Monitoring: * Use longer cache\_ttl (e.g., 600-1800 seconds) for stable pairs * Shorter cache\_ttl (60-300 seconds) for volatile pairs 2. Proof Generation: * Use the same cache\_ttl as for monitoring requests when requesting proofs * Ensures fresh data for on-chain updates * Balance between data freshness and cost efficiency **Regular monitoring flow** ``` Copyget_xrc_data_batch (longer cache_ttl) → detect significant price change → get_xrc_data_with_proof (shorter cache_ttl) → submit to chain ``` # Sybil: data feeds Pull based oracle guide

Sybil Architecture

This step-by-step guide will help you understand how to effectively utilize data feeds from the Sybil module. This module is a data fetcher that can be integrated as a pull-based oracle. Additionally, it can be used in conjunction with the Pythia automation module for push-based implementations. ### Step 1: API Key Setup 1. **Visit the Sybil API Key Portal:** Navigate to [Sybil API Key Management](https://staging.app.orally.network/sybil/api-keys). 2. **Top Up Wallet and Generate API Key:** Follow the portal instructions to top up your wallet and generate an API key for enhanced access. Optionally, you can whitelist your app domain to streamline the process. 3. **Dynamic Link Calculation:** Utilize the dynamic link calculation feature for custom data requests. ### Step 2: Fetch Data from Sybil * **Construct Your Data Request:** Define the endpoint to fetch the latest data with proof. Example request format: 
https://tysiw-qaaaa-aaaak-qcikq-cai.icp0.io/get_xrc_data_with_proof?id=BTC/ETH&bytes=true&cache_ttl=1800&api_key={api_key}
* **Parameters Documentation:** Detailed documentation for each method parameter (`get_xrc_data_with_proof`, `get_dxr_data_with_proof, read_logs_with_proof`, `read_contract_with_proof`). {% tabs %} {% tab title="get\_xrc\_data\_with\_proof" %} Dynamically fetch requested price feed from exchanges (can calculate routing feeds, like BTC/ICP or WIF/ETH) | | | | --------------------------------- | ----------------------------------------------------------------------------------------------- | | id | Price feed id (BTC/USD, BTC/ETH, ...) | | api\_key (optional) | Your API key | | bytes (`true / false` - optional) | Respond in bytes to pass it easily on-chain and verify. Default is `false` | | cache\_ttl (optional) | Cache response for exactly this data feed request to optimize usage. Default is `600 (10 mins)` | | {% endtab %} | | {% tab title="get\_dxr\_data" %} Dynamically fetch price feed from specified DEX liquidity pool. `get_dxr_data` / `get_dxr_data_with_proof` | | | | --------------------------------- | ------------------------------------------------------------------------------------------------- | | api\_key (optional) | Your API key | | bytes (`true / false` - optional) | Respond in bytes to pass it easily on-chain and verify. Default is `false` | | cache\_ttl (optional) | Cache response for exactly this data feed request to optimize usage. Default is `600 (10 mins)` | | chain\_id | The chain from where reading the contract should happen | | block\_numbers | Array of block numbers from which heights data should be aggregated | | pool\_address | Address of DEX pool | | dex\_type | Type of DEX (e.g. `UniswapV2`), which determines the ABI to use for interacting with the pool | | reverse\_pair (optional) | Boolean indicating whether to reverse the pair for price calculation (e.g., DAI/MKR vs. MKR/DAI). | | {% endtab %} | | {% tab title="read\_contract\_with\_proof" %} Dynamically read the contract from the specified chain, block, and address and provide proof that it could be used on other chains. | | | | --------------------------------- | ----------------------------------------------------------------------------------------------- | | id | Price feed id (BTC/USD, BTC/ETH, ...) | | api\_key (optional) | Your API key | | bytes (`true / false` - optional) | Respond in bytes to pass it easily on-chain and verify. Default is `false` | | cache\_ttl (optional) | Cache response for exactly this data feed request to optimize usage. Default is `600 (10 mins)` | | chain\_id | The chain from where reading the contract should happen | | block\_number (optional) | Block number from when it is going to read. By Default reads from the last block. | | contract\_address | Address of reading contract | | function\_signature | Function ABI (as `function balanceOf(address account) external view returns (uint256)`) | | method | Method name to call (as `balanceOf`) | | params | Parameters to pass in call function (as `(0x654DFF41D51c230FA400205A633101C5C1f1969C)`) | | {% endtab %} | | {% tab title="read\_logs\_with\_proof" %} Dynamically read the logs from the specified chain and block range and provide proof that could be used on other chains. | | | | --------------------------------- | ------------------------------------------------------------------------------------------------- | | id | Price feed id (BTC/USD, BTC/ETH, ...) | | api\_key (optional) | Your API key | | bytes (`true / false` - optional) | Respond in bytes to pass it easily on-chain and verify. Default is `false` | | cache\_ttl (optional) | Cache response for exactly this data feed request to optimize usage. Default is `600 (10 mins)` | | chain\_id | The chain from where reading the logs should happen | | block\_from | Block number from when it is going to read | | block\_to | Block number to it is going to read | | addresses | Addresses which emitted logs (`0xa533f744b179f2431f5395978e391107dc76e103`) | | topics0 | Indexed logs topic (`topics0=0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef`) | | {% endtab %} | | | {% endtabs %} | | ### Step 3: Implement Data Fetching in Frontend Use TypeScript and the Wagmi library to integrate Sybil data into your dApp: ```typescript import { useWriteContract } from 'wagmi'; const API_KEY = {MY_API_KEY}; const { writeContract } = useWriteContract(); // Case 1: Verify price feed data const interactWithYourDappWithFeed = async () => { const dataBytes = fetch(`https://tysiw-qaaaa-aaaak-qcikq-cai.icp0.io/get_xrc_data_with_proof?id=BTC/ETH&bytes=true&cache_ttl=1800&api_key=${API_KEY}`); writeContract({ address: {your contract address}, abi: {abi of your contract}, functionName: 'interact', args: [dataBytes], chainId: {chainId}, }); } ``` ### Step 4: Verify Data in Smart Contracts Utilize the [Orally Solidity SDK](https://www.npmjs.com/package/@orally-network/solidity-sdk) to implement verification in your dApp's smart contracts: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import "@orally-network/solidity-sdk/IOrallyVerifierOracle.sol"; import "@orally-network/solidity-sdk/OrallyStructs.sol"; contract YourDappContract { IOrallyVerifierOracle oracle; constructor(address orallyVerifierOracleAddress) { oracle = IOrallyVerifierOracle(orallyVerifierOracleAddress); } // price data from // https://tysiw-qaaaa-aaaak-qcikq-cai.icp0.io/get_xrc_data_with_proof?id=DOGE/SHIB&bytes=true&api_key={YOUR_API_KEY} function interact( bytes memory priceFeedData ) public view returns (OrallyStructs.PriceFeed memory) { // Verify the price feed data and get the price, decimals, and timestamp. OrallyStructs.PriceFeed priceFeed = oracle.verifyPriceFeed(priceFeedData); // priceFeed.price is the price of DOGE/SHIB // priceFeed.decimals is the number of decimals in the price // priceFeed.timestamp is the timestamp when price feed was aggregated return priceFeed; } // -- or -- // with cache // https://tysiw-qaaaa-aaaak-qcikq-cai.icp0.io/get_xrc_data_with_proof?id=DOGE/SHIB&bytes=true&API_KEY={YOUR_API_KEY} function interact( bytes memory priceFeedData ) public returns (OrallyStructs.PriceFeed memory) { // Verify the price feed data and get the price, decimals, and timestamp. oracle.updatePriceFeed(priceFeedData); // Get the price feed data from the cache. OrallyStructs.PriceFeed priceFeed = oracle.getPriceFeed("DOGE/SHIB"); // priceFeed.price is the price of DOGE/SHIB // priceFeed.decimals is the number of decimals in the price // priceFeed.timestamp is the timestamp when price feed was aggregated return priceFeed; } // -- or -- // without API key // https://tysiw-qaaaa-aaaak-qcikq-cai.icp0.io/get_xrc_data_with_proof?id=DOGE/SHIB&bytes=true function interact( bytes memory priceFeedData ) public payable returns (OrallyStructs.PriceFeed memory) { // Get the update fee for the price feed data. uint256 fee = oracle.getUpdateFee(priceFeedData); // Verify the price feed data and get the price, decimals, and timestamp. OrallyStructs.PriceFeed priceFeed = oracle.verifyPriceFeedWithFee{ value: fee }(priceFeedData); // if this price feed will be needed for later usage you can use `updatePriceFeedWithFee` instead (+90k to gas) and access as `oracle.getPriceFeed("DOGE/SHIB")` // priceFeed.price is the price of DOGE/SHIB // priceFeed.decimals is the number of decimals in the price // priceFeed.timestamp is the timestamp when price feed was aggregated return priceFeed; } // -- or verifying chain data example -- // chain data from // https://tysiw-qaaaa-aaaak-qcikq-cai.icp0.io/read_contract_with_proof?chain_id=42161&function_signature="function balanceOf(address account) external view returns (uint256)"&contract_addr=0xA533f744B179F2431f5395978e391107DC76e103&method=balanceOf¶ms=(0x654DFF41D51c230FA400205A633101C5C1f1969C)&bytes=true function getSideChainUserTokenBalance( bytes calldata chainData ) public view returns (uint256) { // Verify the chain data and get the balance of the user. (bytes memory dataBytes, bytes memory metaBytes) = oracle.verifyReadContractData(chainData); // `verifyReadContractDataWithFee` for paying fee in the same transaction instead of API key (uint256 balance) = abi.decode(dataBytes, (uint256)); (OrallyStructs.ReadContractMetadata memory meta) = abi.decode(metaBytes, (OrallyStructs.ReadContractMetadata)); // balance is the balance of the user of the requested token // meta.chainId is the chain id of the side chain // meta.contractAddr is the address of the contract on the side chain // meta.method is the method that was called on the contract // meta.params is the parameters that were passed to the method return balance; } } ``` This Solidity snippet demonstrates how your dApp's contract can interact with the `OrallyVerifierOracle` contract to verify the data received from Sybil. ### Conclusion This guide outlines the steps to effectively integrate and utilize the Sybil data feeds in your decentralized applications. By following these steps, you can enhance the functionality and reliability of your dApps with secure and verified data from multiple external sources. ### OrallyVerifierOracle addresses {% tabs %} {% tab title="Mainnets" %} | Chain | Contract Address | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ethereum | [`0xB28f077244021BD84C878798b712e1D9B0FBC7Da`](https://etherscan.io/address/0xB28f077244021BD84C878798b712e1D9B0FBC7Da) | | Linea | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | Aurora | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | Base | [`0x6cB284120D5e4ca3Eb95b40273D99c5E15aD05Fd`](https://basescan.org/address/0x6cB284120D5e4ca3Eb95b40273D99c5E15aD05Fd#readProxyContract) | | Polygon | [`0x76d67e374391DF6363B72dA8530035Ee5f27a3Da`](https://polygonscan.com/address/0x76d67e374391DF6363B72dA8530035Ee5f27a3Da#readProxyContract) | | Arbitrum | [`0x6b0853c181559c83eCC0C400395F0124310E6952`](https://arbiscan.io/address/0x6b0853c181559c83eCC0C400395F0124310E6952) | | Stellar (Soroban) | [CC2IHRVOKCO42PPXP5TAZWE5WJGWON7SJTOEPHSQT4H7ZN4EQH724VCF](https://stellar.expert/explorer/public/contract/CC2IHRVOKCO42PPXP5TAZWE5WJGWON7SJTOEPHSQT4H7ZN4EQH724VCF?filter=interface) | | zkSync | 0xeC853A8dab05306e61E58fcc155bB98207eD078B | | Manta Pacific Network | 0x7b348835A12aaE1fDA26E2Ce8CB9746fcf865b18 | | {% endtab %} | | {% tab title="Testnets" %} | Chain | Chain Id | Contract Address | | ----------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------- | | Sepolia | 11155111 | [`0x3df7c674a27E25e41dEbDe3Fc463912FB95124CD`](https://sepolia.etherscan.io/address/0x3df7c674a27E25e41dEbDe3Fc463912FB95124CD) | | Zircuit | 48899 | [`0x6fcc686fD4159Cf94d34bfcbc792552168D93626`](https://explorer.zircuit.com/address/0x6fcc686fD4159Cf94d34bfcbc792552168D93626) | | Linea | 59140 | 0xDFB6d80A003907c3021c714F8C60f284Ee259f58 | | Q Testnet | 35443 | 0xc4691e0A3d69681a8c9b6CbC62B14584D93841b6 | | Ultron Testnet | 1230 | 0x51c84C7430FEE3FC07B903400F70167644b0AfDE | | BSC Testnet | 97 | 0xec4b9D8B068233F89B03f0B806C98D1b550780f6 | | Optimism Goerli Testnet | 420 | 0xCFf00E5f685cCE94Dfc6d1a18200c764f9BCca1f | | Arbitrum Goerli Testnet | 421613 | 0xCFf00E5f685cCE94Dfc6d1a18200c764f9BCca1f | | Gnosis Chiado Testnet | 10200 | 0xCFf00E5f685cCE94Dfc6d1a18200c764f9BCca1f | | Aurora Testnet | 1313161555 | 0x447e7fd904325e5aD65c05EE84E3d6775789b9Da | | Avalanche Fuji Testnet | 43113 | 0x447e7fd904325e5aD65c05EE84E3d6775789b9Da | | Bitfinity Testnet | 355113 | 0xb0Ca868a53A55E678F35D2a78ebE27b574567385 | | Taiko (Alpha-3 Testnet) | 167005 | 0xCFf00E5f685cCE94Dfc6d1a18200c764f9BCca1f | | {% endtab %} | | | | {% endtabs %} | | | ### Creating a Custom Pair Orally's Sybil provides existing price feeds and allows you to create your custom price feed pair. The process is straightforward and user-friendly: 1. **Navigate to the Front-End App:** Visit the Orally front-end app at [Sybil dApp](https://kclew-uiaaa-aaaal-qbuiq-cai.ic0.app/sybil). 2. **Initiate the Custom Pair Creation Flow:** Locate and click the button on the main page to initiate the Custom pair creation flow. This will open a modal where you will input details about your custom pair. 3. **Input Pair Details:** Provide the necessary details for your custom pair in the modal. These will include the symbol name, the frequency of updates, and the endpoints from which to fetch the price feed for your token. Ensure that these details are accurate, as they will directly influence the behaviour and accuracy of your custom pair's price feed. 4. **Authenticate with SIWE:** After inputting the necessary details, authenticate yourself using SIWE (Signing with Ethereum). This step is necessary for security and accountability reasons. 5. **Top Up Balance:** After authentication, top up the balance with the specified token. This balance is necessary to cover the execution costs associated with your custom pair's price feed. 6. **Run Your Custom Pair:** After completing all the previous steps, you can run your custom pair. Congratulations—you now have your own token price feed! Following these steps, you can create a custom price feed pair for any token you choose. Orally's Sybil's power truly shines in its versatility and adaptability, making it a highly valuable tool for all developers in the blockchain space. # Apollo: request feeds from EVM Step-by-step integration real-world data to your EVM SC

Apollo architecture

**Apollo** is an intricate module developed to bridge the gap between EVM (Ethereum Virtual Machine) contracts and the data-rich environment of the Orally platform, particularly its [Sybil](https://docs.orally.network/orally-products/sybil) component. Beyond mere data provisioning, Apollo is also configured to provide a level of [randomness](https://docs.orally.network/utilised-icp-features/random-tape) through a cryptographic measure, utilizing the unpredictable BLS signatures inherent to the Internet Computer (ICP) execution layer. **Integration Steps:** 1. To start using the Apollo module, your smart contract needs to inherit from [`ApolloReceiver`](https://github.com/orally-network/evm-oracle/blob/main/src/apollo/ApolloReceiver.sol). This setup allows your contract to receive data from the Apollo network: ```solidity // Import the ApolloReceiver contract import {ApolloReceiver} from "../apollo/ApolloReceiver.sol"; // Your contract inherits from ApolloReceiver contract YourContract is ApolloReceiver { // Constructor initializes the ApolloReceiver with registry and coordinator addresses constructor(address _executorsRegistry, address _apolloCoordinator) ApolloReceiver(_executorsRegistry, _apolloCoordinator) {} } ``` 2. To request data, such as a price feed, use the `requestDataFeed` (or `requestRandomFeed` for randomness) function from the [`ApolloCoordinator`](https://github.com/orally-network/evm-oracle/blob/main/src/apollo/ApolloCoordinator.sol) ([interface](https://github.com/orally-network/evm-oracle/blob/main/src/interfaces/IApolloCoordinator.sol)). This function emits an event that the Apollo network listens for to provide the requested data. {% tabs %} {% tab title="Random Feed" %} ```solidity // Example function to request a price feed // `apolloCoordinator` is passing as public var from ApolloReceiver contract function requestRandomFeed() public { // Requesting the randomness with a specified callback gas limit and number of random words apolloCoordinator.requestRandomFeed(300000, 1); } ``` {% endtab %} {% tab title="Data Feed" %} ```solidity // Example function to request a price feed // `apolloCoordinator` is passing as public var from ApolloReceiver contract function requestPriceFeed() public { // Requesting the ICP/USD price feed with a specified callback gas limit apolloCoordinator.requestDataFeed("ICP/USD", 300000); } ``` {% endtab %} {% endtabs %} 3. Override the `fulfillData` function to define how your contract should handle the incoming data. This function is called when the Apollo network delivers the data to your contract. {% tabs %} {% tab title="Random Feed" %} ```solidity contract YourContract is ApolloReceiver { // ... // Overriding the fulfillData function to handle incoming data function fulfillData(bytes memory data) internal override { (, uint256[] memory randomWords) = abi.decode(data, (uint256, uint256[])); // transform the result to a number between 1 and 20 inclusively uint256 randomNumber = (randomWords[0] % entries.length) + 1; pickWinner(randomNumber); } } ``` {% endtab %} {% tab title="Data Feed" %} ```solidity contract YourContract is ApolloReceiver { // Data storage variables uint256 public requestId; string public dataFeedId; uint256 public rate; uint256 public decimals; uint256 public timestamp; // Overriding the fulfillData function to handle incoming data function fulfillData(bytes memory data) internal override { ( uint256 _requestId, string memory _dataFeedId, uint256 _rate, uint256 _decimals, uint256 _timestamp ) = abi.decode(data, ( uint256, string, uint256, uint256, uint256 )); requestId = _requestId; dataFeedId = _dataFeedId; rate = _rate; decimals = _decimals; timestamp = _timestamp; } } ``` {% endtab %} {% endtabs %} That's it! You successfully requested data and received it in the callback. Here are contract addresses for [IApolloCoordinator](https://github.com/orally-network/evm-oracle/blob/main/src/interfaces/IApolloCoordinator.sol) and [IOrallyExecutorRegistry](https://github.com/orally-network/evm-oracle/blob/main/src/interfaces/IOrallyExecutorsRegistry.sol). {% tabs %} {% tab title="Sepolia" %}
Contract
ApolloCoordinator0xDC88B1919AF3AD86AAcE0FB19F125cb3Db3543e2
OrallyExecutorsRegistry0x4531112808f8C0068768cC3fAE0939e0c05719D1
{% endtab %} {% tab title="Zircuit" %}
Contract
ApolloCoordinator0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B
OrallyExecutorsRegistry0x76d67e374391DF6363B72dA8530035Ee5f27a3Da
{% endtab %} {% tab title="Taiko Katla" %}
Contract
ApolloCoordinator0x1FEa4E134c8BcDF6E1323C1Bf2Aa0899049CC754
OrallyExecutorsRegistry0x81f8573B46895f65C7658Aa3A0eB90578F7F2dC9
{% endtab %} {% endtabs %} Here are Apollo consumer examples: * [RaffleExample](https://github.com/orally-network/evm-oracle/blob/main/src/examples/RaffleExample.sol) (randomness) * [ApolloConsumerExample](https://github.com/orally-network/evm-oracle/blob/main/src/examples/ApolloConsumerExample.sol) (price feed) # Pythia: automation Pythia is a flexible automation oracle capable of executing transactions at scheduled intervals, providing randomness, or delivering price feeds from Sybil. This guide will walk you through the process of creating a subscription using both the front-end application and Solidity. ### **Frontend Subscribe** {% tabs %} {% tab title="Frontend" %} For frontend subscription, follow these steps: 1. Visit the Pythia application page at [Pythia DApp](https://kclew-uiaaa-aaaal-qbuiq-cai.ic0.app/pythia). 2. Set up your own subscription by choosing the chain where your contract resides, specifying your contract address, and defining the method to be executed. 3. Define the automation frequency, and if desired, add payload to execution transactions as randomness or price feed from Sybil. 4. Authenticate with Self Identity Wallet Extension (SIWE), top up your execution wallet, and submit your subscription. {% endtab %} {% tab title="Solidity Call Subscribe \[under construction]" %} You can also create a subscription through Solidity using the [`OrallyPythiaSubscriptionsRegistry`](https://github.com/orally-network/evm-oracle/blob/main/contracts/OrallyPythiaSubscriptionsRegistry.sol) contract. Here's the contract's interface: ```solidity interface IOrallyPythiaSubscriptionsRegistry { function subscribe( address target, string calldata method, uint256 frequency, bool is_random, string calldata pair_id ) external; function unsubscribe(uint256 subscription_id) external; } ``` {% endtab %} {% endtabs %} ### Subscription Usage Examples Here are a few examples demonstrating how to use the Pythia subscription in different scenarios: {% tabs %} {% tab title="Basic Execution" %} 1. Basic Execution: An example where the Pythia oracle executes a simple update to a value. ```solidity import {OrallyPythiaConsumer} from "../consumers/OrallyPythiaConsumer.sol"; contract PythiaExecutionExample is OrallyPythiaConsumer { uint256 public value; constructor( address _pythiaRegistry ) OrallyPythiaConsumer(_pythiaRegistry) {} function updateValue(uint256 _value) external onlyExecutor { value = _value; } } ``` {% endtab %} {% tab title="Raffle" %} 2\. Raffle: In this scenario, Pythia is used to randomly pick a raffle winner. ```solidity import {OrallyPythiaConsumer} from "../consumers/OrallyPythiaConsumer.sol"; contract RaffleExample is OrallyPythiaConsumer { uint256 maxNumberOfTickets; uint256 ticketPrice; address[] entries; constructor( address _pythiaRegistry, uint256 _maxNumberOfTickets, uint256 _ticketPrice ) OrallyPythiaConsumer(_pythiaRegistry) { maxNumberOfTickets = _maxNumberOfTickets; ticketPrice = _ticketPrice; } function enterRaffle() external payable { require( entries.length < maxNumberOfTickets, "RaffleExample: Raffle is full" ); require( msg.value == ticketPrice, "RaffleExample: Ticket price is not correct" ); entries.push(msg.sender); } function pickWinner(uint256 _randomNumber) external onlyExecutor { require( entries.length == maxNumberOfTickets, "RaffleExample: Raffle is not full" ); uint256 winnerIndex = _randomNumber % entries.length; payable(entries[winnerIndex]).call{value: address(this).balance}(""); } } ``` {% endtab %} {% tab title="Price Feed" %} 3\. Price Feed: This example demonstrates how Pythia can be used to regularly update a price feed using data from Sybil. ```solidity import {OrallyPythiaConsumer} from "../consumers/OrallyPythiaConsumer.sol"; interface IFxPriceFeedExample { function pair() external view returns (string memory); function baseTokenAddr() external view returns (address); function decimalPlaces() external view returns (uint256); } contract FxPriceFeedExample is OrallyPythiaConsumer, IFxPriceFeedExample { uint256 public rate; uint256 public lastUpdate; string public pair; address public baseTokenAddr; uint256 public decimalPlaces; constructor( address _pythiaRegistry, string memory _pair, address _baseTokenAddr, uint256 _decimalPlaces ) OrallyPythiaConsumer(_pythiaRegistry) { pair = _pair; baseTokenAddr = _baseTokenAddr; decimalPlaces = _decimalPlaces; } function updateRate( string memory _pairId, uint256 _rate, uint256 _decimals, uint256 _timestamp ) external onlyExecutor { rate = (_rate * (10 ** decimalPlaces)) / (10 ** _decimals); // normalise rate lastUpdate = _timestamp; } function updateTime() external view returns (uint256) { return lastUpdate; } function exchangeRate() external view returns (uint256) { return rate; } } ``` {% endtab %} {% endtabs %} These examples should help you get started with using Pythia. With its robust features, Pythia offers great flexibility in automating transactions and retrieving real-time data, making it a vital tool for any decentralized application. # Useful addresses & Links Contract addresses on covered chains **Mainnet:** App: Sybil proof signer address: 0x60825063CB0f4EF508854Ad4913f3a6de86B3807 PMA (Pythia Main Address - permissionless execution wallet): 0x05c3f2a3ae0b7f3775044eefed8a864c47125f19 {% tabs %} {% tab title="Ethereum" %}
OrallyVerifierOracle0x7b348835A12aaE1fDA26E2Ce8CB9746fcf865b18
OrallyPythiaExecutorsRegistry0x3c038E3777dc5a9B3a25F2969a9571e2983d16a8
OrallyMulticall0x5B9a19f59e875cB7C75Ec139b090f3fB5425c973
{% endtab %} {% tab title="zkSync" %}
OrallyVerifierOracle0xeC853A8dab05306e61E58fcc155bB98207eD078B
OrallyPythiaExecutorsRegistry0xb325C933406F39308d1476191F36e37960373Ec3
OrallyMulticall0x08A3C205b1d44E6a01A2e9DFFEC4C85E26D9098c
PriceFeed_BTC_USD0xF03A56a5Ee800cc91c4C0D46ef0b5b4967f82055
PriceFeed_ETH_USD0x1447C4a336dC2767EF685Db67F54a00dd35B9364
PriceFeed_USDT_USD0x3fA254Ce4cE582a64406E036CbB407De63d72890
PriceFeed_USDC_USD0xcc45ab7Fcf089d6567CEA1B28013cE4c0F577Cf7
PriceFeed_BNB_USD0xF0a6452de1d5D9db24b2a492f336F4247C5f53C7
{% endtab %} {% tab title="Aurora" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | OrallyPythiaExecutorsRegistry | 0x3c038E3777dc5a9B3a25F2969a9571e2983d16a8 | | OrallyMulticall | 0x88e33D0d7f9d130c85687FC73655457204E29467 | | PriceFeed\_BTC\_USD | 0x5E9293bEe776AF37f0bE4453b8Fe0eF03E295BDE | | {% endtab %} | | {% tab title="Q" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | OrallyPythiaExecutorsRegistry | 0x3c038E3777dc5a9B3a25F2969a9571e2983d16a8 | | OrallyMulticall | 0x88e33D0d7f9d130c85687FC73655457204E29467 | | PriceFeed\_BTC\_USD | 0xBe4427367e18B55af78eC1ACd864A775E9260953 | | PriceFeed\_DAI\_USD | 0x90AA67aC6E80C4e8509CC7FA2fd21f28C56576ad | | PriceFeed\_ETH\_USD | 0xd7C3359c00D80343069667572765251a8F24BCe6 | | PriceFeed\_USDC\_USD | 0x4851c140720c1225F04c07d2753067f9Ee6c6654 | | RoundedRandomness (example) | 0xB8cA2D8A5e8250293140694531D9722bB216c34c | | {% endtab %} | | {% tab title="Linea" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | OrallyPythiaExecutorsRegistry | 0x3c038E3777dc5a9B3a25F2969a9571e2983d16a8 | | OrallyMulticall | 0x88e33D0d7f9d130c85687FC73655457204E29467 | | {% endtab %} | | {% tab title="Manta Pacific L2 Rollup" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x7b348835A12aaE1fDA26E2Ce8CB9746fcf865b18 | | OrallyPythiaExecutorsRegistry | 0x3c038E3777dc5a9B3a25F2969a9571e2983d16a8 | | OrallyMulticall | 0x5B9a19f59e875cB7C75Ec139b090f3fB5425c973 | | PriceFeed\_BTC\_USD | 0xB3961794eEEed388574bd6500EBAeBd252E8D67F | | {% endtab %} | | {% tab title="Arbitrum" %} | | | | -------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x096eb773BE73CEDed425029Dc43EC0890DB72507 | | {% endtab %} | | | {% endtabs %} | | **Testnet**: App: Sybil proof signer address: 0xBFD54D868BE89184f19f597489A9FA9385AA708e PMA (Pythia Main Address - permissionless execution wallet): 0x16bb8cb8dcd224c97a36726eea6724f6f1169004 {% tabs %} {% tab title="Zircuit" %} Zircuit | | | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | OrallyVerifierOracle | [`0x7b348835A12aaE1fDA26E2Ce8CB9746fcf865b18`](https://explorer.zircuit.com/address/0x7b348835A12aaE1fDA26E2Ce8CB9746fcf865b18?activeTab=3) | | OrallyPythiaExecutorsRegistry | [`0x76d67e374391DF6363B72dA8530035Ee5f27a3Da`](https://explorer.zircuit.com/address/0x76d67e374391DF6363B72dA8530035Ee5f27a3Da?activeTab=3) | | OrallyMulticall | [`0x5B9a19f59e875cB7C75Ec139b090f3fB5425c973`](https://explorer.zircuit.com/address/0x5B9a19f59e875cB7C75Ec139b090f3fB5425c973?activeTab=3) | | ApolloCoordinator | [`0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B`](https://explorer.zircuit.com/address/0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B?activeTab=3) | | PriceFeed\_BTC\_USD | [`0xc090Ba528C6d3409C5E15391E8B2C1d88A6DF057`](https://explorer.zircuit.com/address/0xc090Ba528C6d3409C5E15391E8B2C1d88A6DF057?activeTab=3) | | PriceFeed\_ETH\_USD | [`0x5aA08940a2fAaf42421628B3852c0201D02a9AFb`](https://explorer.zircuit.com/address/0x5aA08940a2fAaf42421628B3852c0201D02a9AFb?activeTab=3) | | {% endtab %} | | {% tab title="zkSync testnet" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x36C350518335236f4766B85A372a69B939459C6e | | OrallyPythiaExecutorsRegistry | 0x426A36f24f02223b6876A42A9ea8478A9218BC30 | | OrallyMulticall | 0x00bD11f178894cEE788E3FEA0ed909E8C4F9f9AD | | PriceFeed\_BTC\_USD | 0xE701F39DDc230770F41A29b467dFeAd09E6Bb4fd | | PriceFeed\_ETH\_USD | 0x715f7A3b43757B0202f5a725955c88be87dc8Ed8 | | PriceFeed\_USDT\_USD | 0x37D5aD671B147b861cEadD2CB970177c8cbBFFef | | PriceFeed\_USDC\_USD | 0x43437610829dff7CCe82458b13479f998De68F0C | | PriceFeed\_BNB\_USD | 0x3Daf2341fAF7041dda5B4b26963346461d02aadF | | {% endtab %} | | {% tab title="Arthera Testnet" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | OrallyPythiaExecutorsRegistry | 0x51324081c6483E6170379289a0A3CCC161835b39 | | OrallyMulticall | 0x73e14D35f17B4F6cEbD2fF799D56ce59A1Ea34e9 | | PriceFeed\_BTC\_USD | 0x49353d54cC6d23079c6748A2A2160D39a5B3358E | | PriceFeed\_ETH\_USD | 0x203a9D19FbF21301501d40432279c3aAa6aC1eC6 | | PriceFeed\_USDT\_USD | 0xBD8df979082Dee9a0D70248CD56904A37Fa57af6 | | PriceFeed\_USDC\_USD | 0xA7b014dB6927e4FF62eF7c612189F5a50C8CD82F | | PriceFeed\_BNB\_USD | 0x806fD9C1e7786B00806E0cb71fEda797aF7db1bB | | {% endtab %} | | {% tab title="Manta Pacific Testnet" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x7b348835A12aaE1fDA26E2Ce8CB9746fcf865b18 | | OrallyPythiaExecutorsRegistry | 0xa27a3A7702Bc1010be95f73A2c64873d21D6D027 | | OrallyMulticall | 0x76d67e374391DF6363B72dA8530035Ee5f27a3Da | | PriceFeed\_BTC\_USD | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | PriceFeed\_ETH\_USD | 0xF10D4AF1C426Ef1F5CF047abE4774b813BD2Fb7f | | PriceFeed\_USDT\_USD | 0x51324081c6483E6170379289a0A3CCC161835b39 | | PriceFeed\_USDC\_USD | 0xB3961794eEEed388574bd6500EBAeBd252E8D67F | | PriceFeed\_BNB\_USD | 0xB28f077244021BD84C878798b712e1D9B0FBC7Da | | {% endtab %} | | {% tab title="Taiko L2 Testnet" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | OrallyPythiaExecutorsRegistry | 0x3c038E3777dc5a9B3a25F2969a9571e2983d16a8 | | OrallyMulticall | 0x88e33D0d7f9d130c85687FC73655457204E29467 | | PriceFeed\_BTC\_USD | 0xc26A888Be67279f8E8A150F4F1bc33Ce2372663A | | PriceFeed\_ETH\_USD | 0xd6a81c44bBE2e2878b6211C41Aa4144c2Da70559 | | PriceFeed\_USDT\_USD | 0x5E9293bEe776AF37f0bE4453b8Fe0eF03E295BDE | | PriceFeed\_USDC\_USD | 0x510391Dbb92a1dCBfFA6Ea4b2c836DED0B4752aA | | PriceFeed\_BNB\_USD | 0x5e46a2d3414D5E2Dd666fc84C33838e2B0E2bECb | | {% endtab %} | | {% tab title="Taiko L3 Testnet" %} | | | | ----------------------------- | ------------------------------------------ | | OrallyVerifierOracle | 0x45f61bAD7e29a6FB9ec307daD7B895e63Db1940B | | OrallyPythiaExecutorsRegistry | 0x3c038E3777dc5a9B3a25F2969a9571e2983d16a8 | | OrallyMulticall | 0x88e33D0d7f9d130c85687FC73655457204E29467 | | PriceFeed\_BTC\_USD | 0xB8cA2D8A5e8250293140694531D9722bB216c34c | | PriceFeed\_ETH\_USD | 0xd7C3359c00D80343069667572765251a8F24BCe6 | | PriceFeed\_USDT\_USD | 0x07e958b4a52acC2FA5eD9473A44FAE24FD8FC34a | | PriceFeed\_USDC\_USD | 0x89f44ED88023d7b8E31980fa69Ed504b1da62E81 | | PriceFeed\_BNB\_USD | 0xE2675B77E7470a7b7C7d7A6A084464Fc7027ABC8 | | {% endtab %} | | | {% endtabs %} | | # Video Overview Got 2 minutes? Check out a video overview of our products: {% embed url="" %} Video overview for Sybil and Pythia {% endembed %} # How Orally Works

How Sybil Works

How Pythia works

A booklet with all products architecture: In a world where decentralized applications (dApps) are revolutionizing digital interactions, Orally stands as a beacon, illuminating the path with its innovative suite of solutions designed to bridge the gap between blockchains and the real world. But how does Orally achieve this remarkable feat? Let's delve into the mechanics of Orally's operations. ### Architectural Overview At its core, Orally is a sophisticated network of interconnected modules, each designed to serve specific needs within the blockchain ecosystem while working in harmony to provide a seamless, integrated experience. These modules — Sybil, Pythia, Apollo, Hephaestus, and Hermes — offer diverse functionalities, from fetching real-world data to facilitating cross-chain communication. Orally's infrastructure is deeply entrenched in decentralization, leveraging the Internet Computer Protocol's (ICP) consensus mechanism instead of relying on a proprietary network of validators. This approach ensures absolute decentralization, superior security, and optimized transactional efficiency. ### Data Fetching and Verification: Sybil and Apollo **Sybil** stands at the forefront of data aggregation and delivery. Named after the legendary oracle known for her prescience and multitude of voices, Sybil collects data from various external sources, ensuring the information's accuracy and timeliness through a decentralized consensus reached by various nodes on the ICP chain. **Apollo**, the request-based data delivery system, works in tandem with Sybil. When a contract on an EVM-compatible chain requires specific data, it sends a request to Apollo. Post request, Apollo fetches the necessary data through Sybil or generates randomness using unpredictable BLS signatures, preparing the data for transit. Both Sybil and Apollo use ECDSA signatures for data authentication, ensuring that the data's integrity and origin are verifiable, bolstering the overall trust in the data provided. ### Cross-Chain Communication: Hermes **Hermes** epitomizes Orally's commitment to creating a unified blockchain ecosystem. It empowers dApps with the ability to transmit messages and data across different blockchains. Whether it's a contract on Ethereum wishing to initiate a transaction on another chain or a dApp requiring information from a separate blockchain, Hermes facilitates this communication seamlessly, living up to the reputation of its mythological namesake, the messenger of the gods. ### User Authentication: DAuth **DAuth** simplifies the authentication process for dApp users. It allows users to log in using familiar social media credentials, enhancing user experience without compromising security. Once a user logs in through a social platform, DAuth verifies the access token's validity, signs a proof of the authenticated data, and sends this proof back to the user's frontend. This proof can then be attached to any transaction, enabling the dApp to confirm the user's identity through DAuth's EVM verifier contract. ### Custom Data Solutions: Hephaestus **Hephaestus** is where customization takes the center stage. It allows dApps to tailor data feeds or craft unique data solutions, befitting specific needs. From dynamic NFTs that change based on real-world data to governance structures that adapt based on specific triggers, Hephaestus provides the tools necessary for innovation. ### Subscription-Based Automation: Pythia **Pythia** is the embodiment of automation and precision. It allows the scheduling of transactions or the triggering of smart contract functions based on time or data parameters. With Pythia, dApps can automate processes, optimize resource allocation, and respond promptly to market conditions or pre-defined triggers. ### Security Measures Security in Orally is not an afterthought; it's an integral component of its design. The platform utilizes advanced security measures such as ECDSA signatures for data authentication and a continuous heartbeat system from the ICP for real-time performance monitoring and anomaly detection. ### In Summary Orally works by integrating various specialized modules into a cohesive unit, offering a spectrum of services essential for the thriving dApp ecosystem. It maintains a steadfast commitment to decentralization, security, and user-centric design. By providing a bridge between the blockchain and the real world, Orally is not just a platform; it's the architect of a future where the potential of dApps can be fully realized. Join us in redefining the boundaries of what's possible. Welcome to Orally. # Security and Reliability Orally is deeply committed to ensuring a secure, reliable, and resilient infrastructure for decentralized applications (dApps) and their users. Understanding that the digital landscape is fraught with various security threats, Orally has instituted several layers of security protocols and measures, ensuring not just data integrity but also the consistent availability and reliability of its services. This page delves into the intricate security and reliability strategies employed by Orally. ### Decentralization: The First Layer of Security Decentralization isn't just a buzzword for Orally; it's the foundational security principle. By utilizing the Internet Computer Protocol's (ICP) consensus mechanism, Orally avoids the pitfalls of centralization and eliminates single points of failure. This fully decentralized approach not only enhances security but also significantly improves data authenticity and system reliability. ### Data Authentication with ECDSA Signatures Ensuring the authenticity of data fetched from the real world is paramount. Orally uses Elliptic Curve Digital Signature Algorithm (ECDSA) signatures to validate the integrity and origin of data. This cryptographic technique guarantees that the data has not been altered in transit, providing dApps and their users with confidence in the information they rely on for decision-making and operations. ### Continuous Heartbeat System To monitor system health and performance in real-time, Orally employs a continuous heartbeat system from ICP. This mechanism regularly checks the pulse of the network, detecting anomalies, and ensuring system components are functioning optimally. In the event of a component failure or a security breach, the heartbeat system facilitates a swift response, thereby minimizing impact and potential downtimes. ### Rigorous Access Control The DAuth module implements rigorous access control mechanisms. It ensures that user authentication data received from social platforms is stringently validated. DAuth creates a secure environment where user credentials are verified without being exposed, even to the dApp they're interacting with, thereby minimizing the risks associated with phishing and fraudulent activities. ### Advanced Encryption Standards Orally utilizes advanced encryption protocols to protect sensitive data and user information. By employing industry-leading encryption standards, it ensures that user data, transaction details, and other sensitive information are safeguarded from unauthorized access and cyber threats. ### Multi-Layered Security Protocols In addition to these measures, Orally employs multi-layered security protocols across its network. These include regular security audits, continuous monitoring for suspicious activities, automatic security patch deployments, and strict compliance with industry best practices and standards. ### Reliability Through Redundancy Orally’s infrastructure is designed with multiple redundancies to prevent service disruptions. Data is replicated and stored across different nodes, ensuring its availability even if some points in the network experience failures. This design not only guarantees data durability but also enhances the overall system reliability. ### Proactive Incident Response A dedicated security team continually monitors the network for potential threats. In case of any security incidents, Orally has a proactive incident response protocol designed to swiftly isolate and mitigate the threat, followed by a comprehensive investigation to prevent future occurrences. ### In Summary Security and reliability are not mere afterthoughts; they are ingrained in every facet of Orally’s architecture. Through a combination of cutting-edge technology, stringent protocols, and innovative practices, Orally provides a secure, reliable, and resilient environment. This unyielding commitment ensures that users can confidently interact with decentralized applications, assured in the knowledge that their data and transactions are protected in a fortress of digital security. Join us in experiencing a new standard of security and reliability in the world of decentralized applications, only with Orally. # Glossary Products & naming explanation 1. **Sybil**: * **Technical Description**: Sybil is a sophisticated oracle module capable of decentralized data fetching from numerous embedded price data feeds for both crypto and traditional financial assets. It aggregates results, caches them based on data feed settings, and signs the data feed messages with a DKG permissionless wallet, ensuring the integrity and verifiability of the data across various blockchain platforms. Additionally, Sybil offers an HTTP gateway for end-user applications and supports the creation of custom data feeds tailored to specific dApp needs. * **Name Origin**: The term "Sybil" originates from ancient Greek and Roman mythology, where the Sybils were oracles or prophetesses known for their divination and wisdom. The Sybil product acts as a digital oracle, providing insights and data, much like the Sybils of antiquity provided prophecies. 2. **Pythia**: * **Technical Description**: Pythia stands as an automated data delivery module that allows subscriptions based on time or volatility conditions, fetching data from Sybil for delivery to various blockchain platforms. It includes features like random number generation and supports pure automation, minimizing payload. Pythia operates on a pay-per-use model, charging for each transaction plus a small fee in the native coin of the destination chain. * **Name Origin**: "Pythia" is derived from the title given to the Oracle of Delphi in ancient Greece, known for her role as the mouthpiece of the deity Apollo and her cryptic predictions. The Pythia module, similarly, delivers valuable data (modern-day "prophecies") to decentralized applications across various blockchains. 3. **Apollo**: * **Technical Description**: Apollo serves as a request-based data delivery module, allowing EVM contracts to request specific data. The Apollo contract on ICP analyzes these requests, fetches the required data through Sybil (or generates randomness), and delivers it to the requesting contract using the `fulfillData` method. It operates on a subscription-based model, charging per request. * **Name Origin**: "Apollo" is named after the Greek god of prophecy, healing, the sun, and more, and he's famously associated with the Oracle of Delphi. The Apollo module, acting upon request much like the god would in myths, delivers data and responds to calls, embodying the spirit of divine insight and guidance. 4. **Hephaestus**: * **Technical Description**: Hephaestus is an innovative preprocessor for data feeding, accepting Rust code functions as algorithms for data preprocessing post-fetch (from Sybil) and prior to delivery. It automates the deployment of this code to smart contracts, making them instantly available for use by Apollo or Pythia. * **Name Origin**: Named after the Greek god of blacksmiths, crafting, and fire, "Hephaestus" reflects the module's ability to craft and mold data feeds — similar to how the god forged powerful and intricate artifacts for the gods of Olympus. 5. **Hermes:** * **Technical Description**: Hermes facilitates seamless cross-chain messaging, optimizing gas costs on more expensive chains, and can be used for delivering events/data. It acts as a bridge, ensuring efficient communication between various blockchain platforms. * **Name Origin**: "Hermes," the Greek god of messengers, commerce, and travelers, is a fitting namesake for this module, signifying its role in fast and reliable transmission of messages and data across different "realms" — in this case, blockchains. Each product, deeply entrenched in technology, carries a name steeped in mythological significance, emphasizing its unique role in the modern-day digital pantheon of decentralized applications. # Page # The Oracle Problem In the world of blockchain and decentralized applications (dApps), the "oracle problem" has emerged as a significant hurdle. Despite the promise of blockchains providing immutable, transparent, and tamper-proof data storage, they face a fundamental limitation: their inability to access or verify real-world external data. This gap between on-chain and off-chain data is often referred to as the "oracle problem," and it's one that Orally is determined to solve. This document provides an overview of this challenge and outlines how Orally addresses it. ### What is the Oracle Problem? At its core, the oracle problem is about trust and data integrity: 1. **Blockchains are Isolated**: By design, blockchains cannot access external data on their own. Their deterministic nature means that every node in the network must be able to come to the same conclusion independently, based on the data available on-chain. This isolation ensures data integrity within the blockchain but limits its ability to interact with external information. 2. **Reliability of Data Sources**: Even if a blockchain could access external data, there's the question of trustworthiness. How can one ensure that the data being fed into the blockchain is accurate and hasn't been tampered with? 3. **Single Points of Failure**: Traditional centralized oracles that feed data into blockchains introduce vulnerabilities. If such an oracle is compromised, it could feed incorrect data into the blockchain, leading to erroneous operations or financial losses. 4. **Consensus Challenges**: How can we ensure that multiple data sources agree on the data's accuracy, especially when the data sources themselves might have conflicts or discrepancies? ### Why is it a Significant Issue? The limitations posed by the oracle problem have profound implications for dApps and smart contracts. For these decentralized platforms to realize their full potential, they must be able to: * **Trigger Actions Based on Real-world Events**: A smart contract that pays out insurance in the event of a natural disaster, for instance, needs reliable information about the occurrence and severity of the event. * **Integrate with Existing Systems**: For blockchain technology to achieve widespread adoption, it must be able to communicate and interoperate with existing non-blockchain systems seamlessly. * **Ensure Financial Accuracy**: Many DeFi applications rely on accurate price feeds for assets, commodities, and currencies. Incorrect data can result in significant financial distortions. ### Orally’s Solution to the Oracle Problem Orally provides a comprehensive solution to the oracle problem through its suite of tools: 1. **Decentralized Data Fetching**: Orally's Sybil and Pythia modules fetch data from various sources and aggregate it, ensuring that no single data source can compromise the integrity of the information. 2. **Validation & Consensus**: Multiple nodes on the ICP chain ensure consensus on fetched data, eliminating single points of failure and ensuring reliability. 3. **Immutable Proofs**: Data is signed with cryptographic proofs, verifying its origin and ensuring it hasn't been altered during transmission. 4. **Flexible Integration**: Orally’s tools like Apollo and Hephaestus allow for both request-based data fetching and preprocessing, giving dApps unparalleled flexibility in how they access and use real-world data. 5. **Transparency & Auditability**: All operations are transparent, and every data point can be audited, fostering trust in the system. ### Conclusion The oracle problem is one of the most pressing challenges in blockchain technology today. By bridging the gap between the on-chain and off-chain worlds, Orally offers a reliable, decentralized, and transparent solution. Our suite of tools ensures that dApps can trust the external data they rely on, unleashing a new realm of possibilities for blockchain applications. # Frozen Oracle Problem ### Understanding the Frozen Oracle Problem The Frozen Oracle Problem occurs when an oracle's data feed becomes stagnant or frozen, meaning it no longer updates or provides the latest information from the external world. This stasis can happen for various reasons, including technical issues with the data source, a failure in the oracle's updating mechanisms, or even malicious attacks targeting the oracle's infrastructure. The implications of a frozen oracle are significant: 1. **Inaccurate Data**: Smart contracts relying on the outdated information continue to trigger actions as if the data were accurate, leading to incorrect operations, financial inaccuracies, or unjust outcomes. 2. **Loss of Trust**: Dependence on inaccurate data can erode user confidence in a dApp or the broader blockchain platform, as users cannot trust the outcomes. 3. **Exploitation**: Malicious actors might exploit known frozen oracle states, manipulating dApps to their advantage. ### How Orally Addresses This Problem Orally has implemented several strategies within its infrastructure to prevent the Frozen Oracle Problem and ensure continuous, reliable data delivery: 1. **Multiple Data Sources (Sybil)**: By fetching data from numerous sources, Orally's Sybil module mitigates the risk associated with relying on a single point of failure. If one feed becomes stagnant, Sybil will still aggregate data from other active sources, ensuring that the overall feed remains up-to-date and accurate. 2. **Decentralized Data Fetching**: The requests for data are made from various nodes on the ICP chain, not just a single node. This consensus mechanism ensures that even if one node fails to update, the others will compensate, maintaining the data's freshness and reliability. 3. **Automated Monitoring (Pythia and Apollo)**: These modules provide automated data delivery based on set conditions, such as time or value changes. They continuously monitor data feeds for updates, and their automated nature means they can quickly react if a data source becomes frozen, triggering alerts or switching to alternative sources as needed. 4. **Immutable Data Records**: All fetched data is recorded on the blockchain with timestamps, allowing for easy auditability. If users or developers suspect a data feed might be frozen, they can verify the data's timeliness themselves. 5. **Heartbeat System**: Orally implements a heartbeat system, where oracles periodically validate their operational status and data accuracy. If an oracle fails to "check-in" during its designated period, the system will investigate the delay, potentially flagging the feed as unreliable until it's confirmed as accurate. ### Use Cases: Proactive Solutions in Action * **Dynamic NFTs**: For NFTs whose properties change based on real-world data, a frozen oracle could render them static. Orally's safeguards ensure these NFTs continue to update and remain dynamic. * **DeFi Platforms**: In the DeFi space, accurate asset prices are crucial. Orally's infrastructure ensures that these platforms receive timely and accurate market data, preserving fair trades and robust financial services. * **Supply Chain Management**: For dApps tracking real-world goods, current data on location, condition, or delivery status is essential. Orally's system guarantees this data's continual refresh, keeping the supply chain transparent and accurate. ### Conclusion The Frozen Oracle Problem poses a real threat to the integrity and functionality of smart contracts and dApps. Orally's multi-pronged approach — leveraging decentralized data fetching, multiple data sources, automated monitoring, immutable records, and a heartbeat system — provides a robust solution to this issue, ensuring the continuous flow of accurate, up-to-date information for on-chain applications. # Use Cases #### **1. DeFi Lending Protocols** **Need:** Lending protocols require timely, accurate, and tamper-proof data to manage loans, interest rates, and liquidations. The decentralized lending protocol business model absolutely relies on the efficient and accurate delivery of real-time price data. **Use Case:** * Orally seamlessly integrates with a DeFi lending protocol to fetch real-time asset prices, ensuring that loans are issued and updated at current market values. * In the event of significant price drops, Orally’s real-time responsiveness can deliver timely data, allowing the protocol to initiate liquidation processes for under-collateralized loans. * The permissionless and decentralized nature of Orally helps DeFi lending protocols prevent potential losses, ensures platform stability, and builds trust among users who are growing tired of centralized third-parties involved in decentralized systems. #### **2. GameFi Platforms** **Need:** GameFi platforms need unpredictable randomness to make games fair and to distribute in-game rewards. By the nature of their architecture, blockchains are deterministic, meaning they progress in a very logical way — and build on preceding events. But digital games, especially world-building kinds of games, require randomness to truly work well. Orally can integrate with gaming platforms to provide decentralized randomness for the future of gaming. **Use Case:** * A GameFi platform can utilize Orally to generate and deliver the unpredictable randomness that is essential for making good games great. * True randomness in games is vital for determining unpredictable game outcomes, like battle results, loot drops, or procedural world generation. * One of the greatest aspects of using a decentralized oracle is that it helps users feel like the game is truly random and fair. And that each time they play, the outcome will continually change. #### **3. Dynamic NFT Projects** **Motivation:** Some NFT projects are designed to change based on real-world conditions or events. For example, what is a piece of artwork changed based on the weather, or what if a sports collectible changed based on the outcome of the latest game or match? **Use Case:** * An NFT project could integrate Orally to fetch real-world data like weather or the results of events, like a box score or how a playoff series ended up. * One of the greatest attributes of digital art and collectibles is that they can be programmed to react or update based on real-world events. But in order to be truly and meaningfully dynamic, these NFTs need a reliable and consistent data oracle, which is where Orally’s ability to capture and relay real-world data comes into play. * Building truly dynamic art and collectibles will open up an entirely new kind of experience for the next generation of NFTs, and Orally is positioned to play a big role. #### **4. Insurance Smart Contracts** **Need:** Insurance dApps can only work if they are based on accurate data. More importantly, to be fair, the data needs to come from an impartial third party. Orally functions as a permissionless and decentralized source of data so that all parties involved can feel like claims and issues are handled fairly. **Use Case:** * A crop insurance dApp can use Orally to fetch weather data, which allows for automated decision-making. * If a certain region faces unexpected rainfall or drought, the smart contract can automatically release funds to insured farmers in that region, minimizing the need for a massive claims-related back office. * The reliance on data streams and an automated claims process ensures timely payouts, building trust among users and reducing manual claim verification and payment processes. #### **5. Prediction Markets** **Need:** Prediction markets are based on the outcomes of real-world events and need trustworthy data to settle bets. **Use Case:** * A prediction market platform can utilize Orally to fetch outcomes of sports events, real-time scores, player statistics, political elections, or even economic indicators. * How and when Orally fetches data and feeds it to the prediction markets can be tuned and automated depending on the underlying dApp settings, making the process as simple or dynamic as the end user needs require. * By using a permissionless and completely decentralized oracle, like Orally, all parties involved with the prediction market will feel like the results are fair and properly reported. #### **6. Cross-chain DApps** **Need:** One massive growth area with the blockchain space is the ability to move data and assets across chains and across decentralized apps with minimal friction or cost. Additionally, the security risks associated with moving data across chains can be minimized or better controlled using a completely decentralized oracle. **Use Case:** * A dApp operating on multiple chains can utilize Orally to fetch and relay data consistently across blockchains and ecosystems quickly and cost-effectively, which creates new opportunities for new decentralized businesses, services, and products. * Orally's ability to maintain support for numerous EVM-compatible networks ensures that the underlying dApp can remain chain-agnostic, expanding its reach and user base. #### **7. Real-World Assets (Tokenized Assets)** **Need:** Tokenizing real-world assets like real estate, stocks, or commodities requires accurate and timely data about changes in valuation. **Use Case:** * A platform tokenizing real estate properties can utilize Orally to fetch current market conditions, ensuring that the tokens represent a fair value of the asset. * When trading real-world asset tokens, Orally can provide continually updated price feeds, ensuring buyers and sellers transact based on the latest market values. This real-time data helps with overall asset liquidity. #### **8. Smart Contracts for Intellectual Property** **Motivation:** Intellectual properties, like music, art, or patents, can be managed via smart contracts for royalties, licensing, and rights management. **Use Case:** * A musician can use a smart contract to manage royalties for their songs. Orally can fetch streaming/playback data from platforms, ensuring that the artist receives fair compensation based on real-time play counts. * This kind of outside-the-loop data service can help artists have more trust and confidence in streaming and payment numbers and make reporting metrics more fair and trustworthy. * Similarly, for patent licensing, Orally can verify if a licensee exceeds the permitted usage and automatically trigger additional licensing fees or notifications. The same logic and service can also be applied to other kinds of art, content, or software that is subject to licensing agreements. #### **9. Decentralized Exchanges Functions** **Need:** A decentralized exchange (DEX) needs real-time asset price data to maintain trading pairs, liquidity provisions, and slippage management. **Use Case:** * Orally can supply a DEX with consistent and continually updated price feeds for various trading pairs, enabling users to make informed trading decisions. * Accurate price feeds from Orally can assist liquidity providers in gauging pool performances and potential impermanent losses. #### **10. Automated Portfolio Management** **Need:** DeFi users need tools to manage and rebalance their portfolios based on market conditions and asset performance. **Use Case:** * A DeFi portfolio manager can utilize Orally to automatically fetch asset prices, market data, and other relevant metrics. * Based on this data, a smart contract can be created to rebalance a user's portfolio, ensuring optimal asset distribution and risk management. #### **11. Oracle for Governance Votes** **Need:** Decentralized projects often conduct governance votes, where accurate data is required to validate quorums, voter stakes, or outcome impacts. **Use Case:** * A decentralized autonomous organization might want to hold a vote based on its token's current market value. Orally can provide this data, ensuring that decisions are made with full awareness of the token's current market standing. * Orally can also verify quorums by checking against real-time token distribution data, ensuring votes are valid and fair. #### **12. Event Ticketing and Verification** **Need:** Event organizers can use smart contracts for ticket issuance, verification, and secondary market sales to prevent fraud. **Use Case:** * An event ticketing platform could employ Orally to verify the authenticity of a ticket being sold in the secondary market. Orally can data from the original ticketing system, ensuring the ticket hasn't been duplicated or falsified. * Dynamic pricing for events, based on demand and seat location, can be updated in real time using Orally’s data provision. #### **13. Supply Chain & Authenticity Verification** **Need:** Businesses need to verify the authenticity and origin of products, especially in sectors like luxury goods, organic produce, or pharmaceuticals. **Use Case:** * A brand can use Orally to fetch data from manufacturing units, verifying each product's authenticity during resale or warranty claims. * Orally can also assist in tracking organic produce, ensuring consumers receive data on the source, treatment, timeline, and transportation of their food. #### And More: Orally's ability to provide real-time, efficient, and transparent data has wide-reaching implications across various sectors. Whether enhancing trust, ensuring fair trading, facilitating automation, or empowering projects across the DeFi spectrum, Orally's adaptability and unique proposition of efficient, transparent, and cost-effective data delivery make it an indispensable tool for numerous decentralized applications. # Sybil Decentralized Data Aggregation & Efficient Delivery

Sybil architecture

**Technical Overview:** **Sybil** operates as a vital module within the Orally infrastructure, offering decentralized data aggregation, validation, and delivery across a broad spectrum of data types. While it has built-in mechanisms for aggregating price feeds from a plethora of sources, its customizable feed functionality ensures it's not limited to just asset prices. From weather forecasts, sport match outcomes, and social network data to AI interpretations, Sybil can cater to an expansive array of dApp data requirements. **Deep Dive:** 1. **Data Feeds & Aggregation**: * By default, Sybil provides a myriad of embedded price data feeds spanning crypto and stock assets. * Beyond these default feeds, Sybil permits dApps to specify their data sources, be it for obtaining social media insights, sport scores, or AI-generated content, thus tailoring the service to distinct necessities. 2. **Decentralized Data Fetching**: * Sybil's process for fetching data is entirely decentralized, ensuring no single point of data retrieval and consequently reducing vulnerabilities. * Every data request made to Sybil is propagated through various nodes on the ICP chain. This propagation facilitates a consensus mechanism, ensuring the aggregated data is both comprehensive and reliable. 3. **Data Caching & Signature**: * Once data is aggregated, Sybil caches it based on the specific data feed's settings, optimizing data retrieval times. * Every chunk of data is subsequently signed through a DKG (Distributed Key Generation) permissionless wallet. This signature acts as a validation stamp, certifying the data's authenticity for users or dApps across any destination chain. 4. **HTTP Gateway Integration**: * An integral part of Sybil is its HTTP gateway, primed to serve end-users or dApps with the requested data and the accompanying proof of its legitimacy. * This mechanism simplifies data access, bypassing the need for direct blockchain interaction. 5. **Custom Data Feed Creation**: * Sybil extends its services beyond pre-defined data feeds, empowering users to dictate their sources, thus serving bespoke data requirements. 6. **Payment Mechanism**: * Fetching custom data feeds incurs charges under a subscription model, payable using a stablecoin on a common chain. **Use Cases:** 1. **Real-Time Price Information for DeFi**: * DeFi platforms can extract tremendous value from Sybil, utilizing its timely and accurate asset price data for various functions like trading and staking. 2. **Dynamic NFT Projects**: * Projects that produce dynamic NFTs can rely on Sybil for data to drive animations within the NFTs, ensuring each token remains unique and data-driven. 3. **Tokenizing Real-World Assets (RWAs)**: * In scenarios like tokenizing commodities, Sybil’s data aggregation capabilities can offer real-time insights, ensuring the tokenized representation remains accurate. 4. **Governance Votes & GameFi**: * Platforms that oversee decentralized voting can employ Sybil for aggregating voting data, ensuring transparency. Similarly, GameFi platforms can tap into Sybil for various game-related data. **Additional Attributes:** 1. **Reliability through Decentralization**: * Sybil's inherent decentralized nature guarantees not just up-to-date data but also safeguards against single-point manipulations. 2. **Security**: * Sybil's commitment to data integrity is evident with its DKG permissionless wallet signatures, reinforcing data credibility. 3. **Customization & Flexibility**: * The platform's provision to set up custom data feeds amplifies its utility, catering to an extensive array of data needs. **Summary:** Sybil transcends traditional data aggregation boundaries in the decentralized realm, amalgamating data from diverse domains and bolstering its reliability quotient. Its architecture is synonymous with customization, accuracy, and trustworthiness, making Sybil an invaluable resource for any decentralized application or platform hungry for diverse, real-time, and validated data. # Pythia Automated Cross-Chain Data Delivery

Pythia architecture

**Technical Overview:** **Pythia** stands as a robust module within the Orally architecture, designed explicitly for automating cross-chain data delivery. Pythia isn't just a subscription-based mechanism; it's an innovation that brings conditional data delivery to dApps. Whether a dApp requires regular time-based updates or dynamic feeds based on asset volatility, Pythia streamlines it all. Embedded with Sybil data feeds or complemented with randomness, it's an embodiment of flexibility and automation. **Deep Dive:** 1. **Subscription-Based Automation**: * At the core of Pythia is its subscription model, where users can define parameters and automate data deliveries. * Based on the user's subscription, Pythia can be programmed to send data either on time intervals or conditional triggers such as asset price volatility. 2. **Cross-Chain Compatibility**: * Pythia's design inherently supports EVM-compatible chains, ensuring dApps across multiple ecosystems can benefit from its features. * The cross-chain functionality ensures that data can be fetched from different sources (via Sybil) and delivered to a contract on various chains, seamlessly. 3. **Integration with Sybil**: * Pythia is deeply integrated with Sybil, Orally's decentralized data aggregation module. * Users can opt for any of the numerous Sybil feeds to be their data source, encompassing everything from crypto prices to sport scores or weather updates. 4. **Embedding Randomness**: * Beyond Sybil data feeds, Pythia offers the feature to incorporate randomness into the data delivery. * This randomness is sourced through unpredictable BLS signatures on the ICP execution layer, ensuring the generated numbers remain tamper-proof. 5. **Pure Automation Mechanism**: * Pythia's automation is devoid of any redundant tasks. It performs a pure, unadulterated form of automation, without unnecessary overhead. * Once parameters are set, Pythia needs no manual interventions, delivering data precisely as required. 6. **Payment Structure**: * Adhering to its subscription model, every transaction incurs charges for gas and a minor fee. The latter is denominated in the native coin of the destination chain, ensuring transparency and predictability in costs. **Use Cases:** 1. **Time-Driven dApp Updates**: * dApps that require regular data updates, like daily weather updates or hourly stock price notifications, can rely on Pythia's time-based automation. 2. **Dynamic DeFi Platforms**: * DeFi platforms can harness Pythia to trigger specific actions based on asset price volatility, such as auto-liquidation or portfolio rebalancing. 3. **Randomized Gaming**: * GameFi projects can embed Pythia's randomness into their platforms to generate unpredictable outcomes, enhancing the gaming experience. 4. **Event-Driven Protocols**: * For protocols that need to respond to specific external events, Pythia can automate actions based on the event data aggregated by Sybil. **Additional Attributes:** 1. **Flexibility**: * Pythia's ability to integrate with Sybil feeds or infuse randomness showcases its versatile nature, ready to serve a plethora of dApp requirements. 2. **Security**: * The integration of BLS signatures for randomness and DKG permissionless wallet from Sybil for data ensures the utmost security, ensuring data remains untampered. 3. **Cross-Chain Efficiency**: * Pythia's cross-chain compatibility bridges the gap between chains, ensuring data fluidity and expanding dApp horizons. **Summary:** In the vast landscape of decentralized technologies, Pythia emerges as an emblem of automation and cross-chain data fluidity. Through its seamless integration with Sybil and the option to incorporate randomness, Pythia brings unparalleled flexibility to dApps, ensuring they remain updated, responsive, and dynamic. It's not just a tool; it's the future of automated, conditional data delivery in the blockchain realm. # Apollo Request-Based Data Delivery Across EVM networks

Apollo architecture

**Technical Overview:** **Apollo** is an intricate module developed to bridge the gap between EVM (Ethereum Virtual Machine) contracts and the data-rich environment of the Orally platform, particularly its [Sybil](https://docs.orally.network/orally-products/sybil) component. Beyond mere data provisioning, Apollo is also configured to provide a level of [randomness](https://docs.orally.network/utilised-icp-features/random-tape) through a cryptographic measure, utilizing the unpredictable BLS signatures inherent to the Internet Computer (ICP) execution layer. **Deep Dive:** 1. **EVM Contract Communication**: * An EVM-based contract, when requiring data or randomness, communicates its requirement to the Apollo EVM contract. * This request, in essence, is a call to Apollo's EVM contract specifying the data required or the randomness generation needed. 2. **Apollo’s ICP Contract Interaction**: * Apollo's ICP contract actively monitors its counterpart on the EVM for any new events or data requests. * Upon detecting a request, the ICP contract undertakes a series of operations to address this requirement. 3. **Data Procurement Through Sybil**: * If the request pertains to data, Apollo's ICP contract communicates with the Sybil module to fetch the necessary data. * Sybil, as already known, aggregates and verifies the data from multiple sources to ensure its reliability and accuracy. 4. **Randomness Generation**: * If the request pertains to randomness, Apollo's ICP contract leverages the BLS (Boneh-Lynn-Shacham) signatures inherent in the ICP execution layer. * This randomness generation is unpredictable, secure, and reliable, making it suitable for various applications. 5. **Transaction Preparation & Signature**: * Post data fetching or randomness generation, Apollo's ICP contract prepares a transaction containing the necessary data. * This transaction is designed to call a predefined callback function named `fulfillData([types])` on the requester's contract. The `types` parameter varies depending on the nature and structure of the data. * Before dispatching, the transaction is signed to ensure its authenticity and integrity. 6. **Transaction Dispatch to Requester**: * The signed transaction, containing the requested data or randomness, is sent to the originating contract on its native blockchain. * Upon receipt, the requester's contract processes the `fulfillData([types])` function, assimilating the data into its operations or logic as needed. **Payment Mechanism:** * **Subscription-Based**: * Rather than a one-off payment, Apollo adopts a subscription model where the requesting contract (identified by its address) is charged. * Subscriptions allow for repeated and seamless data requests without the need for individual transaction payments. **Use Cases:** 1. **Dynamic Data Requirements in DeFi**: * Decentralized finance (DeFi) platforms often need real-time or periodic data updates to make lending, staking, or swapping decisions. Apollo can provide this data on-demand. 2. **Gaming & Lotteries**: * Many gaming dApps or decentralized lotteries require randomness to decide outcomes. Apollo's randomness generation is apt for such applications. 3. **Decentralized Identity Verification**: * For dApps requiring identity or user-related data verifications, Apollo's connection to Sybil can facilitate real-time verification data. **Additional Attributes:** 1. **Multi-Chain Support**: * Although Apollo inherently communicates with EVM contracts, its architecture and underlying principles enable potential expansion to support other blockchain infrastructures. 2. **Security**: * The dual involvement of EVM and ICP contracts ensures robustness. The BLS signature mechanism further enhances security, especially in randomness generation. **Summary:** Apollo stands as a testament to the power of bridging diverse blockchain technologies – EVM and ICP in this case. By offering on-demand data delivery and randomness generation, it embodies the spirit of decentralization and enhances the capabilities of smart contracts across blockchains. Its secure, reliable, and subscription-based approach makes it a vital asset in the modern decentralized application ecosystem. # Cassandra (DAuth) Decentralized Authentication with Web2 Integration

Cassandra architecture

**Technical Overview:** **Cassandra** emerges as a pioneering module in the Orally ecosystem, bridging the Web2 and Web3 worlds. It's a comprehensive solution to the long-standing challenge of user-friendly authentication in decentralized applications. Instead of relying on intricate crypto-wallet setups, Cassandra leverages familiar social network logins, turning them into secure entry points for dApps. From a simple "Login with Social Network" click to a verified and decentralized proof of identity, Cassandra revolutionizes dApp user experiences. **Deep Dive:** 1. **Web2 Integration for Web3 Applications**: * Cassandra integrates seamlessly with popular social networks. * The familiar "Login with \[Social Network]" button activates Cassandra's mechanism. 2. **Token-based Verification**: * Once a user logs in via their preferred social network, the platform generates an `access_token`. * This token, representing the user's session, is securely transmitted to Cassandra's smart contract module. 3. **Data Validation and Proof Generation**: * Cassandra employs advanced validation techniques to ensure the `access_token` corresponds to the correct `user_id`. * Upon validation, Cassandra crafts a data signature encompassing `{ userId: string, accessToken: string, platform: string, timestamp: u64 }`. * This signature stands as irrefutable proof of the user's identity and session validity. 4. **Data Integration with dApps**: * The signed data proof is transmitted to the user's frontend. * The frontend then appends this proof to any transaction directed at the dApp's contracts. * This ensures that the dApp contract can verify the user's identity with absolute certainty, using the Cassandra EVM verifier contract. 5. **Decentralized Verification Mechanism**: * Cassandra's EVM verifier contract is the backbone of its security mechanism. * It verifies the provided data's authenticity, ensuring that it was indeed signed by the Cassandra module and that the user's identity matches the declared one. **Use Cases:** 1. **Crypto Wallets with Web2 Login**: * Wallet providers can integrate Cassandra to offer their users a familiar login method, eliminating the intimidation factor of traditional crypto-authentication methods. 2. **User-Friendly DeFi Platforms**: * DeFi platforms can greatly enhance their user experience by incorporating Cassandra. Instead of juggling cryptographic keys, users can simply log in using their preferred social network. 3. **dApp Personalization**: * dApps can leverage Cassandra to offer personalized experiences. By fetching basic profile data (with user consent), dApps can curate content, offers, or features tailored to individual users. 4. **Enhanced Security for Gaming Platforms**: * GameFi and other dApp gaming platforms can use Cassandra to ensure user accounts and in-game assets remain secure behind familiar login mechanisms. 5. **Content Platforms and Creator Verification**: * Platforms that host user-generated content can employ Cassandra to ensure content creators are genuine. This can be pivotal in combating impersonation and ensuring the integrity of content. **Additional Attributes:** 1. **User-Centricity**: * Cassandra is designed with users in mind, bringing the familiar web2 login experience into the decentralized world, promoting adoption and enhancing UX. 2. **Robust Security**: * Cassandra's token validation and data signature mechanism ensure that only genuine users access dApp services, mitigating risks of impersonation or malicious activities. 3. **Interoperability**: * By bridging popular social networks and decentralized platforms, Cassandra becomes a versatile tool for various blockchain projects, irrespective of their domain. **Summary:** DAuth represents a harmonious blend of familiarity and innovation. By integrating Web2's comfortable authentication processes with Web3's security and decentralization, DAuth ushers in a new era of user experience in the blockchain domain. It's not merely an authentication tool; it's a statement that decentralized platforms can be as user-friendly as their centralized counterparts. With DAuth, the future of dApps looks not only decentralized but also delightfully accessible. # Deplhos Decentralized Data Preprocessing for dApps

Delphos architecture

**Technical Overview:** **Hephaestus** is an innovative module within the Orally ecosystem, designed to serve as a data preprocessor for decentralized applications (dApps). It empowers developers by allowing them to input custom Rust code functions, which are then used to tailor and transform data after its retrieval but before its delivery to the target dApp. This facilitates the creation of versatile and dynamic dApp experiences, tailored precisely to specific requirements. **Deep Dive:** 1. **Customizable Data Algorithms**: * Developers can submit Rust code functions tailored to specific data processing needs. * These algorithms can range from simple data transformations to intricate computations and aggregations. 2. **Automated Smart Contract Deployment**: * Once a preprocessing algorithm is defined, Hephaestus takes charge of the heavy lifting. * It automatically compiles, deploys, and integrates the provided Rust function into a separate, dedicated smart contract. 3. **Seamless Integration with Sybil**: * Hephaestus operates in close synergy with the Sybil module. * After data retrieval from Sybil, Hephaestus's preprocessor kicks in, ensuring the data is modified, aggregated, or transformed as per the defined custom function before being dispatched to the dApp. 4. **Dedicated Environment for Testing and Iteration**: * Developers can utilize Hephaestus as a sandbox to test, iterate, and refine their data preprocessing algorithms. * This ensures that the final deployed function is optimized for the dApp's needs. 5. **Security and Isolation**: * Each custom function operates within its dedicated smart contract, ensuring data processing isolation. * This modular approach prevents cross-contamination and enhances the security of data transformations. **Use Cases:** 1. **Dynamic NFTs**: * Hephaestus can process data to drive the attributes or visual characteristics of NFTs. For instance, an NFT's appearance could be adjusted based on external data such as weather or stock prices. 2. **Decentralized Finance (DeFi) Platforms**: * DeFi applications can use Hephaestus to derive complex financial metrics, indicators, or aggregations from raw data, ensuring users have access to the latest, tailored financial insights. 3. **Gaming and Simulation**: * GameFi platforms can leverage Hephaestus to transform external data into game mechanics, such as altering in-game resources based on real-world commodity prices. 4. **Data-Driven Governance**: * DAOs and decentralized governance platforms can utilize Hephaestus to preprocess proposal data, member inputs, or external metrics before making collective decisions. 5. **Dynamic Content Platforms**: * dApps that deliver content based on external triggers or data can use Hephaestus to curate and adapt this content, ensuring users receive personalized, up-to-date information. **Additional Attributes:** 1. **Developer Empowerment**: * Hephaestus stands as a testament to Orally's commitment to developer empowerment, offering them the tools they need to craft tailored dApp experiences. 2. **Flexibility**: * With the capability to define custom Rust functions, Hephaestus ensures that dApps aren't constrained by rigid data structures or predefined processing patterns. 3. **Enhanced dApp Dynamics**: * Hephaestus's preprocessing capabilities enable dApps to become more reactive, responsive, and aligned with real-world data dynamics, enhancing user engagement and relevance. **Summary:** Hephaestus is more than just a data preprocessor; it's a testament to the limitless potential of decentralized applications when granted the right tools. By providing developers with the capability to custom tailor their data processing routines, Hephaestus ensures that the future of dApps will be as dynamic, relevant, and engaging as the world around them. In the ever-evolving landscape of decentralized tech, Hephaestus sets a new standard for adaptability and precision. # Hermes Cross-Chain Communication Simplified

Hermes architecture

**Technical Overview:** **Hermes** is a crucial component within the Orally ecosystem, streamlining cross-chain communication for decentralized applications (dApps). This module enables seamless message transfer between various blockchains, optimizing gas costs on high-fee chains and facilitating the conveyance of events or data between interconnected platforms. **Deep Dive:** 1. **Cross-Chain Communication**: * Enables dApps on one chain to send and receive messages to and from dApps on another chain. * Designed to overcome the traditional siloed nature of blockchains, allowing for interoperable functionality. 2. **Gas Cost Optimization**: * Especially beneficial for dApps operating on chains with high transaction fees. * By leveraging the Hermes module, dApps can optimize and potentially reduce the gas fees associated with data transfer and operations. 3. **Event and Data Delivery**: * Facilitates the seamless transfer of both event triggers and associated data. * dApps can utilize this feature to activate specific functions or operations based on events occurring on a different chain. 4. **Security-Centric Design**: * Ensures that messages are securely transmitted with end-to-end encryption, guaranteeing data integrity and confidentiality. * Implements cryptographic verification to ascertain the legitimacy of messages, preventing malicious activities or data breaches. 5. **Versatile Compatibility**: * Engineered to support a wide array of blockchains, from major players to emerging chains. * Ensures that dApps on newer or less prevalent chains can still communicate with those on established networks. **Use Cases:** 1. **DeFi Liquidity Pools & Bridges**: * Enables liquidity providers to move assets between chains or inform other chains about liquidity conditions, optimizing yield strategies. 2. **Cross-Chain NFT Marketplaces**: * Artists and collectors can verify the authenticity, origin, or ownership of NFTs across different blockchains, ensuring provenance and value. 3. **DAOs & Governance**: * Members from different chains can partake in collective decision-making processes or verify cross-chain proposal data before voting. 4. **Inter-Chain Gaming**: * Gamers can transfer in-game assets, scores, or achievements between games hosted on different blockchains. 5. **Decentralized Exchanges (DEX)**: * Facilitates seamless trading by updating order books, price information, or liquidity conditions from other chains. **Additional Attributes:** 1. **Real-Time Communication**: * Designed to minimize latency, ensuring that cross-chain messages are transmitted and processed promptly. 2. **Scalability**: * As the blockchain ecosystem expands, the Hermes module is well-equipped to incorporate more chains, ensuring future compatibility. 3. **Developer-Friendly Interface**: * Developers are provided with a suite of tools and a streamlined API, facilitating easy integration of the Hermes module into their dApps. **Summary:** In the burgeoning age of interconnected blockchain networks, the Hermes module emerges as a beacon of seamless communication, bridging the gaps that traditionally separated individual chains. By offering optimized, secure, and versatile cross-chain communication capabilities, Hermes positions itself as an indispensable tool in the toolkit of the modern dApp developer. In the ever-converging blockchain world, Hermes is the glue that binds disparate chains into a unified, coherent ecosystem.
# ECDSA threshold Signatures Orally Network incorporates Elliptic Curve Digital Signature Algorithm (ECDSA) Threshold Signatures from the Internet Computer Protocol (ICP) to bolster its security and ensure interoperability with other blockchain ecosystems. ### Chain-Key Signatures and Interoperability The Internet Computer Protocol (ICP) is renowned for its chain-key technology, which offers a robust digital signature scheme. This scheme extends to chain-key signatures that allow transactions aimed at other blockchains to be computed fully on-chain. The unique aspect of chain-key signatures is that they facilitate seamless integration with other blockchains in an entirely trustless manner. This method is the most decentralized way of integrating blockchains as it doesn't require any additional parties to manage signature keys or their shares. Orally Network, utilizing the benefits of chain-key signatures, facilitates a smooth and reliable interaction with other popular blockchains such as Bitcoin and Ethereum. This level of interoperability is a testament to Orally's commitment to creating a universal and interconnected decentralized network. ### ECDSA Threshold Signatures ECDSA signatures are a staple in the blockchain industry, renowned for their security and efficiency. By implementing ECDSA threshold signatures, Orally Network enables canister smart contracts to have an ECDSA public key and sign in accordance with it. The corresponding secret key is threshold-shared among the nodes of the subnet hosting the canister smart contract. This feature lays the foundation for direct integration between the Orally Network and popular blockchains such as Bitcoin and Ethereum. The implementation of ECDSA threshold signatures presents numerous technical challenges, most notably the requirement for robust security and efficiency in an asynchronous network environment. While many protocols have been proposed for threshold ECDSA, none have met the stringent requirements of the ICP, which demands reliability even with network latency and a considerable number of faulty nodes. ### Distributed Key Generation (DKG) To address these challenges, Orally Network, drawing on the advancements of DFINITY, has implemented a novel threshold ECDSA signing protocol that leverages Distributed Key Generation (DKG). This new protocol works efficiently over an asynchronous network and ensures the production of signatures even if up to a third of the nodes in a subnet crash or corrupt. The Distributed Key Generation (DKG) protocol is integral to this system, as it securely generates and distributes the shares of the secret signing key across the network. It offers robust performance, ensuring network functionality even with a significant number of faulty nodes. ### Conclusion The adoption of ECDSA Threshold Signatures and the use of DKG in the Orally Network is a testament to our dedication to security, scalability, and interoperability. By harnessing the potential of ICP's advancements, Orally Network stands as a versatile platform ready to usher in a new era of decentralized applications and services. # HTTP Outcalls Orally Network integrates the HTTPS outcalls feature of the Internet Computer Protocol (ICP) to establish direct connectivity with the Web 2.0 world, opening up a wide range of applications. This ability allows canister smart contracts within Orally Network to interact with APIs and services on the internet, fetch real-time data from various sources, and even communicate with other blockchains. ### The Power of HTTPS Outcalls The majority of the world's API-accessible data today resides on Web 2.0 services, outside the secure confines of the blockchain. Smart contract software often relies on this off-chain data to implement functional use cases. By enabling HTTPS outcalls, Orally Network is unlocking the full potential of smart contracts and paving the way towards blockchain singularity, where most computations run on the blockchain itself. ### Overcoming the Oracle Problem Traditional blockchains face a limitation known as the "oracle problem" where smart contracts can receive messages, but cannot send them to the outside world. Fetching off-chain data typically requires smart contracts to interact with centralized oracle services, which can be expensive, potentially insecure, and depend on intermediaries. With the introduction of HTTPS outcalls in the Orally Network, this dependency on oracles is eliminated. Canister smart contracts can make HTTPS outcalls to specified URLs to directly obtain off-chain data or interact with off-chain systems, including Web 2.0 services and enterprise IT infrastructure. ### How HTTPS Outcalls Work in Orally Network HTTPS outcalls allow canister smart contracts hosted on the Orally Network to request a URL. Every node in the subnet hosting the smart contract separately requests the URL. Each node then passes the result they obtained to a special function implemented by the requesting canister smart contract using a query call. The aim here is to preprocess the result to make it consistent with the results other nodes have obtained. If the preprocessed results obtained by query calls to the canister smart contract are sufficiently consistent across all the nodes, the result is agreed upon by consensus and provided back to the smart contract that requested the URL. ### Architecture and Consensus Mechanism The HTTPS outcalls feature is implemented as an extension of the IC protocol stack, showcasing its flexible architecture. The process involves multiple layers of the IC stack, including the execution, consensus, and networking layers. The HTTPS outcall request lifecycle involves: 1. A canister makes an HTTPS outcall request which is stored in the replicated state of the corresponding subnet. 2. The request is forwarded through the HTTP pool manager in the consensus layer to the networking layer, which interacts with the HTTP adapter. 3. Each HTTP adapter on each node issues the requested HTTPS request to the remote server and returns a response. 4. The HTTP adapter invokes an optional transform function on the calling canister, ensuring all responses are exactly the same for consensus. 5. The Consensus layer distributes shares of the response to all peers, allowing the block maker to see that enough peers received the same response. 6. The response is included in a block and made available to the execution layer, invoking a callback to return the response to the canister asynchronously. In the event of discrepancies in the responses, a transformation function can be invoked to normalize the data and ensure consensus can be achieved. This function is provided by the canister developer. ### Conclusion By incorporating HTTPS outcalls, the Orally Network enhances the ability of smart contracts to interact directly with the Web 2.0 world. This feature not only eliminates the need for centralized oracles but also adds a new dimension of functionality to the smart contracts, pushing the boundaries of what can be achieved within a blockchain network. # ICP timers (heartbeat system) ### Overview The Orally Network utilizes the [Internet Computer Protocol's execution layer](https://internetcomputer.org/how-it-works/execution-layer/), specifically the heartbeat and timer functionality, to manage canister smart contracts and schedule tasks. This allows the network to execute work in rounds, with each round triggered by consensus on a block of messages. The implementation of heartbeat or timer methods allows canisters to schedule tasks at regular intervals. This is achieved by placing messages in a canister-specific task queue. During each round, the scheduler chooses between executing a task or a message in a round-robin fashion when the canister is scheduled for execution. ### ICP Timer Mechanism The timer mechanism in the Orally Network is made possible through the use of the ICP's canister execution model. Each canister can initiate timer events, and these events are scheduled and executed in rounds as determined by the consensus layer. Within a round, messages for timer events are placed into input queues for the respective canisters, with a certain instruction limit for execution in each round. This instruction limit, in combination with the scheduler's determination, dictates how many timer events can be executed in each round. The ability to schedule tasks at regular intervals through heartbeat or timer methods allows the network to effectively manage workloads and ensure fair distribution among canisters. These scheduled tasks can cover a range of operations within the network, including updating state, interacting with other canisters, or any other work that the canister is programmed to perform. ### Timer On-Chain The use of timers on-chain provides a reliable, deterministic mechanism for scheduling tasks within the network. It enables the ability to have specific tasks or operations performed at regular intervals, which is crucial for maintaining synchronization and coordination within the Orally Network. In addition, on-chain timers contribute to the robustness and reliability of the network. As these timers are part of the replicated state within the network, they are resistant to single points of failure and are not affected by the downtime of individual nodes. These timer functionalities are key to the efficient operation of canisters within the Orally Network. By enabling tasks to be performed at regular intervals, they ensure that canisters can operate independently while also cooperating effectively with other canisters. Overall, the use of ICP timers in the Orally Network allows for efficient scheduling and execution of tasks. This, in turn, contributes to the overall efficiency and reliability of the network. # Random tape Random number generation is a vital process for various applications. Generating random numbers naively during execution would disrupt the deterministic nature of the network because every node would calculate different random values. To mitigate this, the Orally Network employs the Internet Computer's decentralized pseudorandom number generator, known as the "random tape". ### Random Tape The random tape is a unique feature of the Internet Computer and, provides a secure and highly efficient source of random numbers. It is established using chain-key cryptography. At the beginning of each round, the subnet creates a fresh threshold Boneh-Lynn-Shacham (BLS) signature. This signature is inherently unpredictable and uniformly distributed. Hence, it is ideal for seeding a cryptographic pseudorandom generator. ### Utilization of Random Numbers Once generated, these pseudorandom numbers are accessible to canister smart contracts within the Orally Network. The numbers generated are deterministic, replicable, and uniformly distributed, providing a source of randomness that is both secure and compatible with the deterministic nature of the network. Through the use of the random tape, the Orally Network can provide secure randomness for various applications. Whether it's for cryptographic operations, decentralized gaming applications, or randomized algorithms within smart contracts, the random tape delivers a much-needed source of reliable, decentralized, and secure randomness. This efficient randomness generation is just one of the unique features of the Orally Network, emphasizing its commitment to security, efficiency, and deterministic behavior in decentralized applications. # Exchange rate canister Powered by HTTPS outcalls, the Exchange Rate Canister (XRC) on the Internet Computer, is a crucial feature living entirely on-chain. The XRC fetches data from Web 2.0 servers and interacts with major cryptocurrency exchanges to retrieve real-time or historical pricing information via their public APIs. It also periodically queries public APIs of foreign exchange data providers around the world to get forex rates. This feature makes it possible to integrate the XRC into Decentralized Exchanges (DEXs) to compare exchange rates against market rates and determine the value of assets held under management in a canister smart contract, for instance, with respect to a fiat currency. ### HTTPS Outcalls: Breaking Barriers Canister smart contracts on the Internet Computer can make direct calls to any Web 2.0 data source via HTTPS outcalls. These outcalls fetch data from regular web servers in a deterministic and decentralized manner, thereby eradicating the need for additional trust assumptions. By enabling this functionality, HTTPS outcalls have transformed smart contracts into a more potent tool, capable of utilizing a wealth of data from the traditional Web 2.0 world. However, it's essential to understand that HTTPS outcalls provide access to Web 2.0 resources but do not in themselves provide oracle functionality. Despite this, they are an invaluable building block for developing oracles that operate entirely on-chain. ### The Exchange Rate Canister At the heart of this revolution is the Exchange Rate Canister (XRC). Developed by DFINITY, the XRC is an on-chain pricing oracle that fetches and provides exchange rates for any pair of base and quote assets. These assets can either be a cryptocurrency or a fiat currency. The XRC also enables the retrieval of both current rates and rates from the past. This canister smart contract interacts with the major cryptocurrency exchanges through public APIs to get current or historical pricing information. Additionally, it periodically queries public APIs of foreign exchange data providers around the world to get forex rates. When the XRC receives a request via the get\_exchange\_rate endpoint, it triggers the necessary HTTPS outcalls to gather rates. It then filters out outliers and returns the median of the remaining rates to the caller, along with pertinent metadata about the request. ### Robust and Secure Operation Developing such an oracle is not a trivial task. It requires a series of optimizations and enhancements to ensure the desired level of performance and security. Some notable optimizations include using a least-recently-used cache to store recent query results, thereby reducing HTTPS outcall repetitions. There is also a rate-limiting system to protect the subnet against a flood of requests. Moreover, the XRC charges a fair price for its service in cycles, depending on the actual number of HTTPS outcalls that it makes to serve a request. This pricing not only makes the system more efficient but also provides a certain level of protection against denial-of-service attacks. ### Practical Use Cases There are numerous potential applications for a pricing oracle like the XRC. It's a desirable feature for DEXs, enabling them to compare the exchange rates against the market rate. Canisters holding certain funds can also leverage the XRC to determine the value of the assets under management. Most notably, the XRC plays a significant role in the Internet Computer's Network Nervous System (NNS). The cycle-minting canister (CMC) requires an accurate ICP/XDR conversion rate to convert ICP into cycles, and it retrieves this rate from the XRC, making exchange rate proposals obsolete. ### The Future of Oracle Capabilities The Exchange Rate Canister is a pivotal first step towards the next generation of canister smart contracts with oracle capabilities. It exemplifies how a smart contract can harness the power of HTTPS outcalls to offer an oracle service that runs entirely on-chain. This innovative approach could be extended to various types of Web 2.0 data, paving the way for more on-chain oracles that provide rates for different asset classes such as stocks or ETFs. Indeed, the advent of the Exchange Rate Canister signals a thrilling future for the Internet Computer ecosystem, where canister smart contracts reach unprecedented levels of reliability, accuracy, and trustworthiness. # FAQ | Canister ID | | | --------------------------- | ------- | | wth3l-tiaaa-aaaap-aa5uq-cai | prod 1 | | xywyw-qiaaa-aaaad-aaema-cai | prod 2 | | tysiw-qaaaa-aaaak-qcikq-cai | staging |
How I can top up balance? * Go to * Choose your canister * Select allowed token in "Top Up" modal * Make deposit On the same page you can your current balance on current canister: ![](/files/mDu0GWJ371qANZkzlh6W)
How I can generate API key? * Go to * Press the button "Generate API key" * Copy & Use it OR construct your request in example module
How to get TWAP price from DEX pool? To request data, use method **get\_dxr\_data\_batch.** To request data with proof, use method **get\_dxr\_data\_batch\_with\_proof.** Query Fields: * chain\_id - on which chain your DEX pool is located * pool\_addresses\[] - array of targeted pool addresses * dex\_type - the type of DEX (e.g. `UniswapV2`) * bytes (boolean) - to receive bytes response for easy to pass and use on-chain * api\_key - your API key * cache\_ttl - cache time interval in seconds (responsible for universal cache, if you want to optimize time and cost between different user or services) Example: ```javascript const SYBIL_CANISTER = 'wth3l-tiaaa-aaaap-aa5uq-cai'; // or xywyw-qiaaa-aaaad-aaema-cai // or tysiw-qaaaa-aaaak-qcikq-cai (staging) const parameters = { chain_id: 1, pool_addresses: ['0x811cfb75567a252bea23474e2ccd1286927bfe0a'], dex_type: 'UniswapV2', bytes: true, cache_ttl: 30, api_key: '11e7b24ec171a41d73309f8c0c665667', } const query = queryString.stringify(parameters, {arrayFormat: 'bracket'}); const fetchBatchData = () => { fetch(`https://${SYBIL_CANISTER}.raw.icp0.io/get_dxr_data_batch?${query}`) .then(response => response.json()) .then(data => console.log(data)); }; const fetchDataWithProof = () => { fetch(`https://${SYBIL_CANISTER}.raw.icp0.io/get_dxr_data_batch_with_proof?${query}`) .then(response => response.json()) .then(data => console.log(data)); }; ```
How much it costs? For requesting dex data with proof (if 1 ICP = 8T cycles && 1 ICP = $12): * Price = ±27B cycles = ±0,003375 ICP = ±$0,04 * Time = 6 sec (fetching data) + 5 sec (generating proof) = 11 sec For requesting data without proof (if 1 ICP = 8T cycles && 1 ICP = $12): * Price = ±687M cycles = ±0,000085875 ICP = ±$0,001 * Time = 6 sec