Merlin Protocol
  • Merlin Protocol
    • Intro
    • 0. Abstract - Features Implemented at the Choice of the DAO
    • 1. Decentralization and DeFi
      • 1.1 Features implementable at the choice of MerlinDAO
      • 1.2 Computer system
      • 1.3 Onchain Vs Offchain
      • 1.4 Risk Management
    • 2. The Merlin token, the MerlinDAO and future scenarios
      • 2.1 Merlin token (MRN)
      • 2.2 Merlin DAO
      • 2.3 Scenario of possible monetization of the MerlinProtocol
        • 2.3.1 Liquidity in the Liquidity Pool, Token Buyback and Burning
        • 2.3.2 The types of commissions that end up in the Liquidity Pools
      • 2.4 Staking
      • 2.5 Tokenomics
    • 3. Funds
      • 3.1 Top Cap
      • 3.2 Middle Cap
      • 3.3 Thematic Baskets
      • 3.4 Basket managed directly by MerlinDAO
      • 3.5 Index managed by AI
    • 4. How to use WebAPP to create and invest in TokenXFund decentralized funds
      • 4.1 Aladin fund creator user
        • 4.1.1 Use Case UCF1
      • 4.2 User investor of a fund
        • 4.2.1 Use Case UIF1
        • 4.2.2 Example: UIF1 use case
        • 4.2.3 UIF2 use case
        • 4.2.4 Example: UIF2 use case
    • 5. The creation and management of managed funds
      • 5.1 Active management
      • 5.2 Performance and benchmark
      • 5.3 Performance fees
      • 5.4 Ranking of Managed Funds
    • 6. Tokens to invest in
      • 6.1 The selection criteria for big and mid cap tokens
      • 6.2 Selection criteria for small and micro caps and ranking of tokens to put in portfolios
      • 6.3 Portfolio Composition Limits
    • 7. Oracles
      • 7.1 Decentralized Oracles
      • 7.2 Oracle design pattern
      • 7.3 ChainLink oracles —> (ChainLink Docs)
      • 7.4 Decentralized Data Model
      • 7.5 Data Security
      • 7.6 Uniswap v3 Pricing Oracles —> (Uniswap V3 whitepaper)
      • 7.7 Random Number Generator Oracles
    • 8. Swapping for fund rebalancing
      • 8.1 What is a Swap and why to Swap
      • 8.2 How to Swap
      • 8.3 When to Swap
      • 8.4 Javascript SDK for Uniswap v3
      • 8.5 DEX Expansion
Powered by GitBook
On this page
  1. Merlin Protocol
  2. 7. Oracles

7.2 Oracle design pattern

All oracles provide three key functions

  • Collect data from off-chain sources

  • Transfer data On-chain with certified messages

  • Store data in Smart Contract memory

Once the data has been placed in the storage systems of a Smart Contract, it can be accessed by other Smart Contracts via calls that invoke "retrieval" functions, and it can also be read via nodes in a blockchain infrastructure with appropriate clients enabled to directly access the memory of an oracle.

There are three main architectures to which an oracle pu; conform, and they are:

  • immediate-read

  • publish-subscribe

  • request-response

Immediate-read oracles are those that provide data necessary for an immediate decision. The query method of these oracles is just-in-time: the query is performed when the information is needed, and potentially never again. Once the data has been stored in a contract's storage, it can be used by other Smart Contracts.

An example of immediate-read oracle applied to the MerlinProtocol project could be the oracle that responds to the getLastPrice query, which is useful for finding updated information on the market price of traded pairs.

The second pattern considered is that of the publish-subscribe oracle, in which the oracle offers a data broadcast service in case of data modification. This is received by a series of on-chain Smart Contracts, or by special off-chain "daemon" controllers.

The pattern has an architecture similar to RSS Feed, WebSub and MQTT, with a flag alerting subscribers to the presence of new updates available.

"Subscribed" Smart Contracts must either request updated data from the oracles or remain listening for broadcast updates generated periodically by the oracles.

Polling is very inefficient in the web server world, but not overly so in the peer-to-peer context of blockchain platforms.

The third category is request-response oracles. This architectural approach has disadvantages in terms of the storage space required by the data on the Smart Contract, which can potentially become very high.

In general, in this architecture, users are expected to require only a small portion of the total space concurrently, and never the entire available storage.

The request-response architecture involves a set of on-chain Smart Contracts and off-chain infrastructure used for the entire process of requesting and related forwarding of the query to the appropriate oracles, retrieving and returning the response to the requestor's query.

From the requester to the oracle there are a number of intermediate actors interacting asynchronously, part of which presumably controlled by a data provider: after an initial interaction with a (potentially decentralized) application, the requester's query is forwarded to a function of an oracle's Smart Contract.

The launched function initializes the query with the appropriate arguments and includes additional relevant information, and then transmits it to the oracle itself.

Once the transaction has been validated, the oracle's response can be observed in the form of an oracle-generated EVM event that allows the oracle to retrieve information from oracle-generated data stored in an off-chain location.

The oracle may require a payment in Ethereum for this process, and certainly an expense will be required in terms of gas consumed by transactions on the main net.

Previous7.1 Decentralized OraclesNext7.3 ChainLink oracles —> (ChainLink Docs)

Last updated 2 years ago