"The majority of the tips received this year involved crypto – an area that continues to have pervasive fraud and other illegality," Romero said in a statement published on the

CFTC Awards $16M to U.S. Whistleblowers; Most Tips Were Crypto-Related

Existing stablecoins aren't fully compliant with relevant regulatory requirements, a report by the Committee on Payment and Market Infrastructures said.

Drawbacks of Stablecoin Cross-Border Use Outweigh Benefits: Global Payments Watchdog

The government said it hopes the move, potentially affecting the likes of Binance and Coinbase, will bring greater regulatory clarity.

Spain Brings Forward MiCA Crypto Rules by Six Months After EU Pressure

Sam Bankman-Fried's attorneys are trying again to have the jury overseeing his trial consider the role of English law in governing FTX's terms of service, in the hopes it may lead to a "not guilty" verdict on some of the fraud charges the exchange founder faces.

Sam Bankman-Fried's Defense Team Makes Last-Ditch Bid to Get 'English Law' Detail in Jury Instructions

Animoca will build Web3 service capabilities with global commercial application alongside NEOM to support its aspirations as a futuristic tech hub.

Animoca Brands Courts $50M Investment From Saudi Arabia's NEOM

Bitcoin has doubled this year. The bullish trend may continue unabated as key indicator shows no signs of overheating, according to IntoTheBlock.

Bitcoin Shows no Signs of Overheating, Despite Doubling This Year

Bitcoin's advance this week coupled with gains across all digital asset sectors, highlighting the breadth of the crypto rally.

Bitcoin's 14% Weekly Gain Signals 'End of an Era' as Big Tech Dumps, Analyst Says

Austin, TexasThe biggest and most established global hub for everything crypto, blockchain and Web3.Register Now Cryptocurrency exchange Gemini has sued Genesis Global, its former business partner for its Gemini Earn product,

Gemini Sues Bankrupt Lender Genesis, Its Former Partner, Over $1.6B Worth of GBTC

The Fed is widely expected to hold rates steady next week but traders will be watching for signals about future policy moves.

Bitcoin Catches Market Cap of Elon Musk's Tesla Amid ETF-Fueled Rally, but Traders Cautious Ahead of Fed Meeting

Bankrupt crypto exchange FTX moved another batch of crypto assets worth millions including Chainlink's LINK and Polygon's MATIC Thursday afternoon, blockchain data revealed. Some $2.6 million in LINK and $1.3 million in adventure gold AGLD were deposited ...

FTX Moves Millions Worth of LINK, MATIC, AGLD to Coinbase as Sam Bankman-Fried Testifies

API3

api3

Using Gelato, Witnet, API3 And Chainlink Vrf to Schedule Randomness

Oracles provide a secure and reliable way for smart contracts to access real-time market data, which is essential for various DeFi applications. API3 has developed an oracle node that is operated by the API Provider, removing the intermediary node layer, or middleman. This change in oracle architecture creates a scalable and transparent solution that enables first-party oracles to be aggregated according to user requirements. DeFi protocols looking to utilize first-party oracles do so by integrating dAPIs to their smart contracts. With developers in mind, dAPIs have been designed with a simple integration process that abstracts away the technical implementation of accessing data feeds. The API3 Market provides the ability to manage these data feeds while giving users access to a range of first-party data feeds. In the future, additional data feed services, such as capturing (OEV) will be accessible once a dAPI has been integrated. Oracle Extracted Value This tutorial will demonstrate how easy it is for developers to switch from Chainlink data feeds to API3’s first-party oracles. Choosing the Contract To demonstrate how easy it is to port over from Chainlink to API3, we are going to port over the DeFi options contract from this C . hainlink tutorial We don’t need to go over the entire contract because we will only be modifying a small section of the contract to port it over, but in summary, the contract enables users to create, buy, exercise, and cancel options within the contract using Ethereum (ETH) and Chainlink (LINK) tokens. It makes use of Chainlink’s aggregator interface for obtaining price feeds while exercising options. For more of an in-depth explanation, you can check out the . full guide Now let’s look at the code we want to modify: pragma solidity ^0.8.17;

import "//github.com/smartcontractkit/chainlink/blob/develop/evm-contracts/src/v0.6/interfaces/LinkTokenInterface.sol";
import "//github.com/smartcontractkit/chainlink/blob/master/evm-contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";

contract chainlinkOptions {
    //Pricefeed interfaces
    AggregatorV3Interface internal ethFeed;
    AggregatorV3Interface internal linkFeed;
    //Interface for LINK token functions
    LinkTokenInterface internal LINK;
    uint ethPrice;
    uint linkPrice;
    //Precomputing hash of strings
    bytes32 ethHash = keccak256(abi.encodePacked("ETH"));
    bytes32 linkHash = keccak256(abi.encodePacked("LINK"));
    address payable contractAddr;
    
    //Options stored in arrays of structs
    struct option {
        uint strike; //Price in USD (18 decimal places) option allows buyer to purchase tokens at
        uint premium; //Fee in contract token that option writer charges
        uint expiry; //Unix timestamp of expiration time
        uint amount; //Amount of tokens the option contract is for
        bool exercised; //Has option been exercised
        bool canceled; //Has option been canceled
        uint id; //Unique ID of option, also array index
        uint latestCost; //Helper to show last updated cost to exercise
        address payable writer; //Issuer of option
        address payable buyer; //Buyer of option
    }
    option[] public ethOpts;
    option[] public linkOpts;

    //Kovan feeds: //docs.chain.link/docs/reference-contracts
    constructor() public {
        //ETH/USD Kovan feed
        ethFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
        //LINK/USD Kovan feed
        linkFeed = AggregatorV3Interface(0x396c5E36DD0a0F5a5D33dae44368D4193f69a1F0);
        //LINK token address on Kovan
        LINK = LinkTokenInterface(0xa36085F69e2889c224210F603D836748e7dC0088);
        contractAddr = payable(address(this));
    }

    //Returns the latest ETH price
    function getEthPrice() public view returns (uint) {
        (
            uint80 roundID, 
            int price,
            uint startedAt,
            uint timeStamp,
            uint80 answeredInRound
        ) = ethFeed.latestRoundData();
        // If the round is not complete yet, timestamp is 0
        require(timeStamp > 0, "Round not complete");
        //Price should never be negative thus cast int to unit is ok
        //Price is 8 decimal places and will require 1e10 correction later to 18 places
        return uint(price);
    }
    
    //Returns the latest LINK price
    function getLinkPrice() public view returns (uint) {
        (
            uint80 roundID, 
            int price,
            uint startedAt,
            uint timeStamp,
            uint80 answeredInRound
        ) = linkFeed.latestRoundData();
        // If the round is not complete yet, timestamp is 0
        require(timeStamp > 0, "Round not complete");
        //Price should never be negative thus cast int to unit is ok
        //Price is 8 decimal places and will require 1e10 correction later to 18 places
        return uint(price);
    }
    
    //Updates prices to latest
    function updatePrices() internal {
        ethPrice = getEthPrice();
        linkPrice = getLinkPrice();
    }
    
    -----------------------
    -----------------------
    
    
} The contract initializes the AggregatorV3Interfaces via the constructor for both the Eth and Link datafeeds; these can later be used to fetch the price. The two functions and use the AggregatorV3Interface to fetch the price and return it. The struct defines how options are stored when they are created, along with the and array to store the created options. getEthPrice() getLinkPrice() options ethOpts linkOpts Porting it Over Porting over the contract to use API3’s dAPIs in this options contract can be done in 3 easy steps: Fetching the proxy address of the “ETH/USD” and “LINK/USD” dAPIs from the API3 Market Import the proxy interface from API3 repo and set the proxy addresses in the constructor Replace the and the logic with a function call to the proxy interface getEthPrice() getLinkPrice() .read() And that's it. You do not need to hold any special type of token to be able to read from the oracle, it is completely free to read. Over 100+ dAPIs are currently available on the api3 market and work on a self-funded basis i.e you can top up the gas wallets to start reading from the oracle. If the dAPI is already funded you just need to copy the proxy address as seen below: Here’s the same DeFi options contract updated to use API3 dAPIs pragma solidity ^0.8.17;

import "@api3/contracts/v0.8/interfaces/IProxy.sol";

contract Api3Options {
    //Pricefeed proxies
    address public ethProxy;
    address public linkProxy;
    uint ethPrice;
    uint linkPrice;
    //Precomputing hash of strings
    bytes32 ethHash = keccak256(abi.encodePacked("ETH"));
    bytes32 linkHash = keccak256(abi.encodePacked("LINK"));
    address payable contractAddr;
    
    //Options stored in arrays of structs
    struct option {
        uint strike; //Price in USD (18 decimal places) option allows buyer to purchase tokens at
        uint premium; //Fee in contract token that option writer charges
        uint expiry; //Unix timestamp of expiration time
        uint amount; //Amount of tokens the option contract is for
        bool exercised; //Has option been exercised
        bool canceled; //Has option been canceled
        uint id; //Unique ID of option, also array index
        uint latestCost; //Helper to show last updated cost to exercise
        address payable writer; //Issuer of option
        address payable buyer; //Buyer of option
    }
    option[] public ethOpts;
    option[] public linkOpts;

    //Kovan feeds: //docs.chain.link/docs/reference-contracts
    constructor(address _ethProxy, address _linkProxy) public {
        //ETH/USD Proxy on Goerli
        ethProxy = _ethProxy
        //LINK/USD Proxy on Goerli
        linkProxy = _linkProxy
        contractAddr = payable(address(this));
    }

    //Returns the latest ETH price
    function getEthPrice() public view returns (uint) {
        (int224 value,uint32 timestamp) = IProxy(ethProxy).read();
        // if the data feed is being updated with a one day-heartbeat
        // interval, you may want to check for that.
        require(
            timestamp + 1 days > block.timestamp,
            "Timestamp older than one day"
        );
        //Price should never be negative thus cast int to unit is ok
        //Price is 18 decimal places
        return uint(uint224(value));
    }
    
    //Returns the latest LINK price
    function getLinkPrice() public view returns (uint) {
        (int224 value,uint32 timestamp) = IProxy(linkProxy).read();
        // if the data feed is being updated with a one day-heartbeat
        // interval, you may want to check for that.
        require(
            timestamp + 1 days > block.timestamp,
            "Timestamp older than one day"
        );
        //Price should never be negative thus cast int to unit is ok
        //Price is 18 decimal places
        return uint(uint224(value));
    }
    
    //Updates prices to latest
    function updatePrices() internal {
        ethPrice = getEthPrice();
        linkPrice = getLinkPrice();
    }
    
    -----------------------
    -----------------------
    
    
} As you can see, we only needed to call on the interface to start reading from the datafeed. We ended up with lesser lines of code and a much simpler reading interface. You can try running the contract yourself on . (Note: The remix version only allows you to open and close options in ETH for simplicity). .read() IProxy(ethProxy) REMIX Why use dAPIs ? dAPIs have been designed to abstract away the technical implementation of data feeds. Once a dAPI has been imported to oracle contracts, the API3 DAO can redirect the dAPI mapping upon user requests. This means that data feeds can be upgraded from self-funded to managed dAPIs, or directed to read alternate reference data with zero technical implementation. Any update to data feeds, or a lack thereof, can create opportunities for OEV, such as arbitrage and liquidations. During each of these interactions value is leaking from the dApp users to both searchers and validators. Once a dAPI has been integrated, DeFi protocols will be able to capture Oracle Extractable Value without any further technical implementation. Additionally, switching from Chainlink to API3 data feeds means no major alterations to smart contracts. This mitigates the need for audits while keeping battle-tested code intact.

How to Migrate to dAPIs - A Developers Guide on Switching Your Oracle 

API3 is simplifying how Web3 builders access real-world data by solving the . Their first-party oracle enables data providers to be an API gateway for blockchains, eliminating the need for third-party middlemen. For developers, access to secure, transparent, and decentralized data feeds through Airnode-enabled APIs will be available on Fantom alongside API3’s oracle tooling. API connectivity problem Overview The demand for developer tooling and infrastructure services has exponentially increased alongside the increasing number of engineers building decentralized applications (dApps). Ultimately, tools such as oracles provide the ability to realize the potential of decentralized protocols by building meaningful on-chain applications. The ability to utilize real-world data provided by traditional API Providers in a smart contract has been a problem only recently solved by the introduction of API3’s . However, solving the API connectivity problem is only half the battle. Airnode What is a dAPI? By simplifying how real-world data is accessed by smart contracts, API3 has designed a simple interface for developers to access and manage data feeds: dAPIs. A dApp is an application that is implemented as a smart contract that runs on a decentralized blockchain. By the same token, a dAPI is an API-like service that is delivered to smart contracts. In simpler terms, just as applications use APIs, dApps will use dAPIs. - Core Technical Lead API3 DAO Burak Benligiray Through a dAPI the consumption of data feeds becomes simple. The dAPI interface provides access to continuously updated streams of off-chain data, such as the latest cryptocurrency, stock, and commodity prices. Understanding the dAPI Interface A key part of the API3 toolkit is dAPIs. These managed API services are specifically engineered for smart contracts to mimic traditional Web APIs. dAPIs possess a range of distinct attributes: dAPIs have a standardized, user-friendly interface that intends to abstract away the technical implementation. A dApp uses the dAPI interface to access data feed services. These services exist in a fully permissionless or authorized format. dAPIs exist entirely on-chain as smart contracts and use first-party oracles served in a variety of data feed services such as self-funded or managed dAPIs (more on this later). Through a dAPI smart contract, developers can access additional services such as Service Coverage or Oracle Extractable Value. dAPI Services: Self-Funded & Managed Data Feeds A dAPI enables smart contracts to access continuously updated streams of data. However, these streams of data can be accessed in a range of different data feed services to suit the requirements of an application. Through a dAPI, developers will be able to request two types of data feed services: Self-funded dAPIs provide developers with the tools to use single-source data feed services with minimal associated costs and no upfront commitment, served in a fully permissionless fashion through the API3 Market. Once gas funds have been provided in the oracle sponsor wallet a dAPI will begin automatically post data on-chain when price deviation thresholds are met. Managed dAPIs are sourced from multiple first-party oracles and aggregated using a median function. Compared to self-funded dAPIs, managed dAPIs require user authorization through the API3 Market. Accessing dAPIs means builders can utilize secure and accurate data in their DeFi protocols and dApps, with managed data feeds providing additional benefits to security and decentralization as well as the API3 DAO overseeing oracle management. The oracles serving dAPIs will be operated by reputable data providers, with source transparency being realized through the first-party oracle architecture. Accessing a dAPI is Simple: API3 Market For users to access dAPIs, they can head to the API3 Market and explore all the dAPIs available on a range of EVM-compatible chains as well as their testnets. To use the novel self-funded dAPI mechanism the user will be required to fund the sponsor wallet of the respective data feed with gas to activate it. The amount of gas supplied will determine how long your dAPI will be available for use. If the dAPI runs out of gas, it can be funded again to keep it available for use. After funding the dAPI, the final step for the user will be to deploy a proxy contract to access the dAPI. Now the developer can easily set the proxy contract address in his contract and start reading from the dAPIs. dAPI proxies allow dAPIs to be used like libraries. The smart contract just needs to import the interface for calling the proxy contract. To read a different dAPI, the contract does not need to change the code itself, rather it only needs to use a different proxy address when calling the function on the proxy contract. read() Summary dAPIs will provide the DeFi ecosystem with access to first-party oracle services across dozens of EVM chains. By leveraging API3's decentralized infrastructure, developers can build increasingly complex and useful dApps that are resistant to downtime, censorship, and data tampering. By facilitating the economy between Web3 developers and API Providers, API3 is expanding the capability of the blockchain to solve real-world problems, while protecting the core principle of decentralization.

Using Decentralized APIs to Build Meaningful DApps

Oracle extractable value (OEV) refers to oracles making use of their position to capture value that would otherwise have gone to third parties. As a simple example, say we have an ETH/USD price data feed with the value of 1000 and the deviation threshold of 1% (meaning that the value after the next update will be 990 or 1010.) A user has a position that can be liquidated when the data feed value is at least 1005, and ETH/USD price is increasing. In the traditional case, the oracles will wait until the underlying APIs return 1010 to update the data feed value to 1010. Then, it’s a race between third parties to liquidate the user and net the reward. With OEV, the data feed gets updated as soon as the underlying APIs return 1005 and the user gets liquidated in the same transaction to claim the reward. Oracles can either extract the OEV themselves, or auction off the right to extract the OEV, which results in an equivalent financial outcome for them. OEV is a concept that is as old as oracles themselves, but important developments have taken place since it was being entertained as a theoretical inevitability. The traditional way of getting a piece of the pie used to be getting into gas wars with other third parties. Over the last year, Flashbots proved that taking this process off-chain is possible in practice, . It’s even that this may be one of the reasons why Ethereum gas fees don’t spike as hard during market volatility. This demonstrates that as long as there is a trustlessly-available mechanism to fall back on, adding more efficient value extraction mechanisms is feasible, and can benefit all stakeholders. MEV extracting more than $650M to date argued Before moving on, let us note that intentionally degrading the advertised oracle service specs (by or ) is an oracle attack and not a method of value , which implicitly needs to be sustainable. At API3, we don’t only advertise specs, but also provide trustless security guarantees through the retrospective, insurance-like service coverage arbitrated by a decentralized third party, which means users of our data feeds are protected from all kinds of oracle attacks. Furthermore, the added OEV functionality does not make our data feeds any less secure or insurable, as we retain the traditional, decentralized first-party data feed — a trust-minimized architecture — to automatically fall back on. delaying updates flat-out misreporting extraction Why is there an OEV in the first place? When people think of oracles, they usually think of data feeds, i.e., live data points on a chain, always ready to be used. Unfortunately, the only thing certain about a live data feed is that it is outdated (compared to the underlying APIs), if only by milliseconds. This issue allows arbitrage, frontrunning and various other kinds of value extraction, all paid for by the dApps that use them. The only immediate solution here is to update the data feeds as frequently as possible, yet the cost of doing so still has to be passed on to someone, and this also makes it difficult to justify providing a large number of data feeds due to the associated gas costs, which impedes innovation. Now imagine an oracle service that does not store the data that will be used by third parties to change the state, but instead changes the state directly. If we go back to our liquidation example, the oracles would not need to periodically update any data feeds, and simply liquidate positions as needed. The dApp wouldn’t need to reward the oracles for this, as this is what one pays for when they’re buying an oracle service. (As a note, this doesn’t eliminate second-order OEV, e.g., due to cascading liquidations.) Although our Airnode request–response and publish–subscribe protocols are designed to allow these kinds of novel oracle services to be built, we’re aware that data feeds are not going anywhere soon, and our primarily cater to DeFi projects that require traditional data feeds for this exact reason. This section is just to clarify that OEV is an unwanted side-effect of legacy-DeFi and fundamental limitations of blockchains in general. dAPIs What to do with OEV? OEV is DeFi projects bleeding money due to being architected around a suboptimal oracle solution (which, to be fair, is the only one that is readily available.) Therefore, capturing OEV does not generate more value than picking up the wallet that someone has dropped. Then, it is obvious what needs to be done with the OEV proceeds. API3 will extract the OEV, and return it to the dApps. OEV is more than oracles having primary rights to MEV. Let us consider the liquidation example again. The traditional approach also ends up liquidating the position, but only if ETH/USD price ends up reaching 1010. But what if the ETH/USD price goes up to 1009, and then goes back down without reaching 1010? Then, the traditional data feed would not have updated, and the position would not have been liquidated even though it should have. This is a common occurrence with deviation threshold-based data feeds, and causes significant losses to the dApps that use them. OEV-based updates benefit the dApp financially even without the dApp receiving the proceeds. Traditionally, the quality of a data feed is measured by its deviation threshold, where smaller values are better because they result in fewer events such as the example above. OEV-based updates make this metric obsolete by updating precisely when needed, achieving zero deviation threshold in practice. Note that OEV-based and deviation threshold-based updates work well together to deliver the best of both worlds because in the context of data feeds, all updates are good updates. How does it work? API3 runs an API that announces data feed updates that can be bid on (imagine 100+ data feeds each on 10+ chains, including Ethereum, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Fantom, Gnosis Chain, Moonbeam, Moonriver, Milkomeda, Metis, RSK and more). Searchers (bots that are programmed to automatically extract MEV) periodically check on these to see if there is an update that can be used to extract any value. When there is such an update, searchers bid an amount in the native currency of the chain. The winner of the auction is presented with a meta-transaction that is cryptographically-signed by each API provider that powers the specific dAPI, . Then, the winner of the auction can push the meta-transaction to the chain to update the dAPI, and trigger any additional events in the same transaction, which will guarantee them all the rewards. (Since the update will be signed to be executed by a specific searcher, it will be compatible with any block production and validation scheme — for example, it doesn’t require a private mempool.) The auction proceeds accumulate in a dApp-specific contract, withdrawable by the respective account. which can only be used by the winner of the auction, if they send the bid amount that won the auction along with the meta-transaction More competitive auctions will result in more efficient value extraction, which will be achieved by making them publicly accessible to all searchers. A staking-based security mechanism will be used for newly onboarded participants to disincentivize denial attacks, which will dynamically shift to a reputation-based system to ensure capital efficiency. This auction layer is particularly suitable for monetization by first-party oracles (i.e., API providers), as it’s essentially a Web service provided to searchers. The system will also be publicly accessible to all dApps — in that any dApp that uses any data feed on any chain will be able to open their usage to OEV extraction in a practically permissionless way by following the instructions, and withdraw the proceeds by interacting with a trustless contract. Conclusion Traditional oracle solutions update data feeds blindly, which is wasteful and provides poor granularity. OEV extraction updates data feeds exactly when needed, which results in cheap and maximally accurate data feeds. Furthermore, the OEV update transactions can be offloaded to third-parties, making it financially feasible to operate a large variety of data feeds. dApps typically offer some MEV to facilitate the automatic triggering of events — for example, liquidating positions should be rewarded for third parties to liquidate positions. This amount is difficult to minimize without jeopardizing the service, which causes dApps to overpay. In addition, there are cases where dApps leak MEV without any benefit to themselves. Extracting OEV maximally through a publicly competitive auction and returning the proceeds to dApps resolves these issues, and provides dApps with a novel and very significant source of revenue. Check out the API3 OEV if you want to learn more. litepaper

What is Oracle Extractable Value (OEV)?

Random number generation (RNG) has always been one of the biggest problems when working with smart contracts. A deterministic virtual machine is incapable of generating ‘true’ randomness. Due to this, RNG needs to be provided as an oracle service. To fulfill the need for randomness in smart contracts, decentralized pseudorandom RNG has been a common way. One of the most used methods is Chainlink’s VRF or verifiable random function, which provides cryptographically provable random numbers on-chain. It generates a random number off-chain with cryptographic proof that’s used to verify the result. However, this configuration suffers from the same issues as any other third-party oracle network. Setting up an oracle node that can provide PRNG exposes potential attack vectors like , but also lacks source transparency and decentralization. For example, one needs to trust the governing entity to select the network participants, which means decentralized PRNG is only as secure and decentralized as the governing entity. Sybil attacks Quantum Random Number Generation QRNG generates randomness via quantum phenomena. It uses a ‘true’ source of entropy using unique properties of quantum physics to generate true randomness. There are different methods of implementing QRNG with varying levels of practicality, yet the common point is that the resulting numbers will be truly random because the outcome of a quantum event is theoretically uncertain with well-defined characteristics. Therefore, QRNG is the gold standard for random number generation. Australian National University’s QRNG Airnode As we already discussed, providing RNG through a third-party oracle network opens space for attack vectors. But first-party oracles ( ) that are directly operated by the Providers optimally counter the Sybil attack risk. Airnodes QRNG API is a public utility offered through the Australian National University (ANU). It is powered by an Airnode hosted by ANU Quantum Random Numbers, meaning that it is a first-party service. ’s Quantum Optics Division is one of the worlds leading research institutions in the field. The division also operates a REST API, , to serve QRNG in Web2. API3 QRNG Australian National University Quantum Random Numbers API Read more about how ANU Generates random numbers in real time by measuring the quantum fluctuations of the vacuum It is served as a public good and is free of charge (apart from the gas costs), and it provides ‘true’ quantum randomness via an easy-to-use solution when requiring RNG on-chain. How Airnode and API3 QRNG works To begin, we need to deploy and sponsor the with a matching sponsor wallet. The will be the primary contract that retrieves the random number. QrngRequester QrngRequester The submits a request for a random number to . Airnode gathers the request from the protocol contract, retrieves the random number off-chain, and sends it back to . Once received, it performs a callback to the requester with the random number. QrngRequester AirnodeRrpV0 AirnodeRrpV0 AirnodeRrpV0 You can read more about how API3 QRNG uses the request-response protocol . here Coding QrngRequester.sol Getting started Make sure you have the following installed: Node.js yarn/NPM Also, make sure you’ve already cloned and installed the . If you haven’t, clone the Airnode Monorepo with this command: Airnode Monorepo $ git clone //github.com/api3dao/airnode.git . To install the dependencies, do the following: $ yarn run bootstrap To build all the packages, use this command: $ yarn run build Compiling the Contract To compile the QrngRequester contract, we are going to use . It’s an online IDE that allows the developing, deploying, and administering of smart contracts for EVM-compatible blockchains. Remix IDE //SPDX-License-Identifier: MIT
pragma solidity 0.8.9;
import "@api3/airnode-protocol/contracts/rrp/requesters/RrpRequesterV0.sol";

contract RemixQrngExample is RrpRequesterV0 {
    event RequestedUint256(bytes32 indexed requestId);
    event ReceivedUint256(bytes32 indexed requestId, uint256 response);

    address public airnode;
    bytes32 public endpointIdUint256;
    address public sponsorWallet;
    mapping(bytes32 => bool) public waitingFulfillment;

    // These are for Remix demonstration purposes, their use is not practical.
    struct LatestRequest { 
      bytes32 requestId;
      uint256 randomNumber;
    }
    LatestRequest public latestRequest;

    constructor(address _airnodeRrp) RrpRequesterV0(_airnodeRrp) {}

    // Normally, this function should be protected, as in:
    // require(msg.sender == owner, "Sender not owner");
    function setRequestParameters(
        address _airnode,
        bytes32 _endpointIdUint256,
        address _sponsorWallet
    ) external {
        airnode = _airnode;
        endpointIdUint256 = _endpointIdUint256;
        sponsorWallet = _sponsorWallet;
    }

    function makeRequestUint256() external {
        bytes32 requestId = airnodeRrp.makeFullRequest(
            airnode,
            endpointIdUint256,
            address(this),
            sponsorWallet,
            address(this),
            this.fulfillUint256.selector,
            ""
        );
        waitingFulfillment[requestId] = true;
        latestRequest.requestId = requestId;
        latestRequest.randomNumber = 0;
        emit RequestedUint256(requestId);
    }

    function fulfillUint256(bytes32 requestId, bytes calldata data)
        external
        onlyAirnodeRrp
    {
        require(
            waitingFulfillment[requestId],
            "Request ID not known"
        );
        waitingFulfillment[requestId] = false;
        uint256 qrngUint256 = abi.decode(data, (uint256));
        // Do what you want with `qrngUint256` here...
        latestRequest.randomNumber = qrngUint256;
        emit ReceivedUint256(requestId, qrngUint256);
    }
} The will have three main functions: , , and . QrngRequester setRequestParameters() makeRequestUint256() fulfillUint256() The takes in , , and sets these parameters. setRequestParameters() airnode endpointIdUint256 sponsorWallet The function calls the function of the protocol contract which adds the request to its storage and returns a . makeRequestUint256() airnodeRrp.makeFullRequest() AirnodeRrpV0.sol requestId The targeted off-chain ANU gathers the request and performs a callback to the requester with the random number. Airnode Request Parameters The function expects the following parameters to make a valid request. makeRequestUint256() (address) and specify the endpoint. Get these from . airnode endpointIdUint256 here specifies which wallet will be used to fulfill the request. sponsorWallet Response Parameters The callback to the contains two parameters: QrngRequester : First acquired when making the request and passed here as a reference to identify the request for which the response is intended. requestId : In case of a successful response, this is the requested data that has been encoded and contains a in addition to other response data. Decode it using the function from the object to get your random number. data timestamp decode() abi Head to Remix IDE, make a contract, and paste it in the code. QrngRequester Now, hit compile on the right side of the dashboard and compile the smart contract. Deploying the Contract We are going to deploy our to Goerli. Make sure you have enough testnet ETH in your wallet to deploy the contract and fund the later. You can get some testnet Goerli . QrngRequester sponsorWallet here Head to deploy, run Transactions, and select the “Injected Provider — MetaMask” option under Environment. Connect your MetaMask. Make sure you’re on Goerli. The is the main . The RRP contracts have already been deployed on-chain. You can check for your specific chain . _rrpAddress airnodeRrpAddress here Once the is populated, click on “Deploy.” Confirm the transaction on your MetaMask and wait for it to deploy the Requester contract. _rrpAddress Calling the Contract When your gets deployed, head to Deploy, run transactions, and click on the dropdown for your Requester under Deployed Contracts. QrngRequester Now select the dropdown to set all the parameters. setRequestParameters Add the following to the corresponding fields for the function. : The airnode address of the desired QRNG service provider. See its value from the . _airnode ANU Airnode : The Airnode endpoint ID will return a single random number. See its value from the . _endpointIdUint256 ANU Airnode : A wallet derived from the requester contract address, the Airnode address, and the Airnode xpub. The wallet is used to pay gas costs to acquire a random number. A sponsor wallet must be derived using the command from the Admin CLI. Use the value of the sponsor wallet address that the command outputs. _sponsorWallet derive-sponsor-wallet-address After you’ve set up the Airnode CLI, installed and built all the dependencies and packages, run the following command to derive your : _sponsorWallet Linux npx @api3/airnode-admin derive-sponsor-wallet-address \
  --airnode-xpub xpub6CUGRUo... \
  --airnode-address 0xe1...dF05s \
  --sponsor-address 0xF4...dDyu9 Windows npx @api3/airnode-admin derive-sponsor-wallet-address ^
  --airnode-xpub xpub6CUGRUo... ^
  --airnode-address 0xe1...dF05s ^
  --sponsor-address 0xF4...dDyu9 ANU’s and can be found . airnode-address airnode-xpub here Fund the with some test ETH. Click on transact button and confirm the transaction to set the parameters. sponsorWallet To make the request, click on the button to call the function and make a full request. makeRequestUint256 Now you can head over to and check your for any new transactions. //goerli.etherscan.io/ sponsorWallet You might need to wait for a while as the Airnode calls the function in that will in turn call back the requester contract at using function to deliver (the random number). fulfill() AirnodeRrpV0.sol fulfillAddress fulfillFunctionId data Here, we can see the latest transaction. Fulfill Now go back to Remix and click on button to check the response. latestRequest If the callback has been successfully completed, the will be present. The value of will be . randomNumber waitingFulfillment false If you want to learn more about it, check out the . QRNG Example Project Read more about . API3 QRNG Also published here.

How you can use Quantum random numbers as a public good, on 13 smart contract protocols

Smart Contract Tutorial for Beginners — Part 2

By Camron Haider - API3 Core Team Twitter: @CamBrazy3 In this tutorial, we’ll be walking through building and deploying a decentralized lottery smart contract in Solidity using . Hardhat In this example use case, anyone can choose a number 1–10,000 and buy a ticket to enter into a weekly lottery. The ticket revenue is collected into a pot in the contract. After 7 days, the contract will allow anyone to trigger the drawing. The contract will then call the for a truly random number generated by quantum mechanics. The pot will be split amongst all users that chose this winning number. If there are no winners, the pot will be rolled over to the next week. Once deployed, the lottery will continue to run and operate itself automatically without any controlling parties! API3 QRNG By the end of this tutorial you should be able to: Deploy a decentralized lottery smart contract to the that uses . Goerli testnet Quantum Randomness Who is this tutorial for? Developers with a basic understanding of the Solidity and Javascript languages that would like to expand their knowledge of building with smart contracts using . oracles In Part 1, we create a centralized lottery smart contract. In Part 2, we decentralize our lottery by integrating the . API3 QRNG Setup Create a folder and open it up in your preferred IDE. We prefer with the . Visual Studio Code Hardhat extension 1. Initialize a Node.js project Create a folder for your project and open it in VSCode. In a terminal, initialize a project by running the following command: npm init -y 2. Install Hardhat is a npm library with a built-in local Ethereum node that allows you to develop smart contracts. Because it will only be used for development purposes, we can install it as a development dependency: Hardhat npm install -D hardhat 3. Initialize the Hardhat project We’ll use the Hardhat CLI to create a boilerplate Web3 project: npx hardhat Follow the prompts to and choose the default options for the rest. Create a JavaScript project When the CLI is done creating the project, you should see a few new files and directories inside of your project. Boilerplate contracts are located in the folder. Tests for that contract are located in the folder. We’ll be deleting these files in the next steps so now would be a good time to look through them. contracts tests Run the test command to see the boilerplate contract in action. npx hardhat test When we run , Hardhat spins up a local node and tests against it before shutting down. This makes it fast and free to execute our contracts. npx hardhat test Writing the Smart Contract Writing the Smart Contract The complete contract code can be found in the Part1 branch 1. In the folder, delete the file and create a file named contracts Lock.sol Lottery.sol 2. Set the solidity version, and start with an empty contract pragma solidity ^0.8.9;
contract Lottery {} 3. Add global variables to the contract contract Lottery {
    uint256 public pot = 0; // total amount of ether in the pot
    uint256 public ticketPrice = 0.0001 ether; // price of a ticket
    uint256 public week = 1; // current week counter
    uint256 public endTime; // unix datetime lottery is closable
    uint256 public constant MAX_NUMBER = 10000; // max guess
} 4. Underneath the global variables, add our error handling error EndTimeReached(uint256 lotteryEndTime); Underneath the errors, add the for tickets and winning numbers mappings The mapping stores the list of addresses that guessed a specified number during a specified week. The mapping stores each weeks winning number. tickets winningNumber mapping(uint256 => mapping(uint256 => address[])) public tickets;
mapping(uint256 => uint256) public winningNumber; Mappings can be accessed throughout our code by using for example. winningNumber[weekNumber] 6. Underneath the mappings, add the constructor function When deploying the contract, we’ll need to pass in a unix timestamp of when the lottery will end. We store the value in our global variable from step 3. _endTime endTime constructor(uint256 _endTime) {
endTime = _endTime;
} 7. Underneath the constructor function, add a function to buy a ticket Users can call this function with a number 1–10,000 and a value of 0.001 ether to buy a lottery ticket. function enter(uint256 _number) external payable {
    require(_number <= MAX_NUMBER, "Number must be 1-MAX_NUMBER");
    if (block.timestamp >= endTime) revert EndTimeReached(endTime);
    require(msg.value == ticketPrice, "Price is 0.0001 ether");
    tickets[week][_number].push(msg.sender);
    pot += ticketPrice; 
} We make the function so that it can only be called from an external user. We also make it because users will have to send funds to purchase the ticket. external payable On line 2 we add a statement to prevent users passing in a guess higher than the maximum allowed. Line 3 we throw an error in the case that the current time has passed the . Line 4 we ensure the ticket price was sent in the transaction. [require](//docs.soliditylang.org/en/v0.4.24/control-structures.html#error-handling-assert-require-revert-and-exceptions) endTime On line 5 we add the user’s address ( ) to our mapping from step 5, then add the revenue from the ticket sales to the . msg.sender tickets pot 8. Create a function to mock picking the winners Before we decentralize our lottery, let’s mock the random number generation so that we can test the contract’s functionality. We’ll be decentralizing this function in of this tutorial by using the . Part 2 API3 QRNG function closeWeek(uint256 _randomNumber) external {
    require(block.timestamp > endTime, "Lottery has not ended"); 
    winningNumber[week] = _randomNumber;
    address[] memory winners = tickets[week][_randomNumber];
    week++;
    endTime += 7 days;
    if (winners.length > 0) {
        uint256 earnings = pot / winners.length; 
        pot = 0; 
        for (uint256 i = 0; i < winners.length; i++) {
            payable(winners[i]).call{value: earnings}("");
        }
    }
} Since we’re just mocking randomness in this step, we’ll make our function take a argument and make it external. In line 3 we store the “random number” in our mapping. In line 4 we get all of the addresses that chose the winning number and store them in instead of since we won’t be changing any of the data, just referencing it. Next, we increment the counter and . _randomNumber winningNumber memory storage week endTime Then, unless there are no winners this week, divide the pot amongst the winners. Line 9 we set the pot back to 0 ether before we pay out winners on line 11. 9. Create read-only function This function will return the list of addresses that chose the given number for the given week. This will make our lives easier during the testing steps. function getEntriesForNumber(uint256 _number, uint256 _week) 
public view returns (address[] memory) {
    return tickets[_week][_number];
} We mark the function as so that it can be used externally and internally if necessary. We also mark it as because no data should be changed when calling this function. public view 10. Create function receive The will be called if funds are sent to the contract. In this case, we need to add these funds to the pot. receive function receive() external payable {
pot += msg.value;
} Testing the contract If our contract is used in production, users’ real funds will be at stake. That makes thorough testing extremely important in smart contract development. If you haven’t worked with before, I recommend you learn the basics. We’ll mainly be interacting with our contract through testing and scripts. unit tests 1. In the test folder, delete the file and create a file called Lottery.js Lock.js 2. Import npm libraries const { expect } = require("chai");
const { ethers } = require("hardhat"); We’ll be using the library inside of Hardhat which includes some extra capabilities. ethers 3. Add tests We’ll start with a simple deployment test to be sure that the contract is deploying correctly. describe("Lottery", function () {
  let lotteryContract, accounts, nextWeek;
  it("Deploys", async function () {
      const Lottery = await ethers.getContractFactory("Lottery");
      accounts = await ethers.getSigners();
      nextWeek = Math.floor(Date.now() / 1000) + 604800;
      lotteryContract = await Lottery.deploy(nextWeek);
      expect(await lotteryContract.deployed()).to.be.ok;
  });
}); On line 2, we create empty global variables to store a few values that we’ll be using in multiple tests. In our test, we’ll get our Lottery contract factory that we’ll use to deploy new instances of our contract. We get all of our signers, or wallets that are connected to Hardhat, and store them globally as . We also store globally because we’ll use it later. Deploys accounts nextWeek On line 7 we deploy the contract using from our contract factory. Our constructor takes in 1 argument, , which we’ll pass into . .deploy() endTime .deploy() We use to validate the boolean returned from is truthy. expect().to.be.okay .deployed() We can use to run the test. npx hardhat test Let’s add a few more tests but feel free to add any/all of the relevant tests from the . completed test file describe("Lottery", function () {
    let lotteryContract, accounts, nextWeek;
  
    it("Deploys", async function () {
        const Lottery = await ethers.getContractFactory("Lottery");
        accounts = await ethers.getSigners();
        nextWeek = Math.floor(Date.now() / 1000) + 604800;
        lotteryContract = await Lottery.deploy(nextWeek);
        expect(await lotteryContract.deployed()).to.be.ok;
    });
  
    it("Users enter between 1-3", async function () {
        for (let account of accounts) {
            let randomNumber = Math.floor(Math.random() * 3);
            await lotteryContract
                .connect(account)
                .enter(randomNumber, { value: ethers.utils.parseEther("0.0001") });
            const entries = await lotteryContract.getEntriesForNumber(randomNumber, 1);
            expect(entries).to.include(account.address);
        }
    });
  
    it("Choose winners", async function () {
      const winningNumber = 2;
      // Move hre 1 week in the future
      let endTime = await lotteryContract.endTime();
      await ethers.provider.send("evm_mine", [Number(endTime)]);
      
      const winners = await lotteryContract.getEntriesForNumber(winningNumber, 1);
      let balanceBefore = await ethers.provider.getBalance(winners[0]);
      await lotteryContract.closeWeek(winningNumber);
      const balanceAfter = await ethers.provider.getBalance(winners[0]);
      expect(balanceAfter.gt(balanceBefore)).to.be.true;
    });
}); Run to try it out. npx hardhat test Conclusion All of the completed code for Part 1 can be found in the of the repo. Part 1 Branch In Part 1 of this tutorial we learned how to build and test a lottery smart contract using Hardhat. The problem is, our function is not secure, as it is public and can be called by anyone accessing the smart contract after the week's lottery ends. In its current state, anyone could enter the lottery and then pass their number into the function to steal the pot. Because a decentralized online gambling application is only as feasible as the degree to which it is fair, secure, and unexploitable, it requires a source of random number generation that is unbiased and tamper-proof. closeWeek closeWeek In Part 2, we’ll be decentralizing our lottery contract and addressing the security concerns using the . Any participant will still be able to call the function, but will not be able to provide a winning number. Instead, our contract will call the API3 QRNG to generate a truly random number that will be used to determine the winner(s). Once deployed, the lottery will continue to run and operate itself automatically without any controlling parties! API3 QRNG closeWeek Also Published Here

Smart Contract Tutorial for Beginners — Lottery dAPP [Part 1]

by Vansh Wassan, Integrations Engineer & Developer Relations @ API3 Twitter: @WassanVansh Github: vanshwassan Part I: Deploy an Airnode to a REST API As we all know that it is not possible by a Smart Contract to directly access external APIs outside of a blockchain. Interacting with off-chain data while working with Smart Contracts is a real problem for a lot of dApps. The Ethereum blockchain was designed to be entirely deterministic while the Internet was not. Calling an API directly sounds easy but on a blockchain, it would require all the nodes to call the same endpoint at the same time and expect to get the same data in order to come to a consensus. Plus, the core concept of a blockchain is its security, that is derived from a decentralized network of independent validators that purposefully limit their connection to the outside world. However, with , you can have first-party oracles that are directly operated by the API Providers, called that provides data to any on-chain dApp*.* As a result, you can easily make any REST API accessible to a Smart Contract. API3 Airnodes Say Hello to ChainAPI is a platform that enables you to integrate and deploy the open-source Airnode with its step-by-step integration and deployment tools. ChainAPI To get started, go to and log in by connecting your MetaMask. ChainAPI ChainAPI You will be prompted to confirm and sign the transaction through your MetaMask extension. Make sure you’re using a new MetaMask Wallet with a fresh mnemonic. Your mnemonic will later be used to deploy the Airnode. You need to keep it extremely safe as this will serve as the “private key” of your deployed Airnode. Each time you return to ChainAPI you will connect again, using MetaMask, to identify yourself by signing a message for the same account. Complete the signup process and name your workspace. Workspaces provides you with a way to invite other users to help or collaborate with integrations and deployments. This makes it easy to manage your Airnode’s as a team or to outsource the process while still maintaining control over your integrations and deployments. To change the name of your in the future, click on name on the top-left of the dashboard Within ChainAPI you will be able to create and manage your integrations or Airnode deployments by navigating to the “Integrations” or “Deploy” dashboards on the left hand navigation panel. Integrating your Airnode For this tutorial, I am going to use endpoints to retrieve stock data. dxFeed’s public REST API To get started select the “Integrate API” option in the top right hand of the dashboard. Enter the details about the API that you are integrating. You need to enter the base URL of your API along with all the endpoints that you want to integrate. As it’s a public API, it doesn’t have any security schemes. You can now start by adding all your endpoints. Here, the dxFeed REST API has one endpoint with some query parameters. You can add all the parameters that your API requires. GET /events.json Now you need to add all the parameters and define where they go (query/header/path/cookie). Here, all the parameters are query params and are required to be defined by the user. I’ve made the param as I want it to return the response in . format fixed json define what part of the response is to be picked and encoded before fulfillment. It can be defined by the requester but we can also hardcode it in the Airnode configuration. Reserved parameters After adding all the required endpoints, you can now press finish and get ready to deploy your Airnode. Deploying your Airnode To deploy the Airnode, go to the deploy section on the menu. Name your deployment and select the integration that you want to use with it. Select your Cloud Provider where you want your Airnode to be deployed. Now select the Chains for your deployment. You can also select multiple networks and providers if you want it on multiple Chains. Here, we are going to have our Airnode on the Polygon Mumbai Testnet. Review your configuration for one final time. If everything seems correct, click on next. Download all the Airnode configuration files and extract them. This is how your Airnode config directory should look like: contains and . config config.json secrets.env The file is used during the deployment/redeployment of an Airnode to configure its behavior and to provide mappings of API operations. config.json The file holds values for config.json that must be kept secret. secrets.env The output directory will have the that will be generated after you successfully deploy the Airnode. receipt.json The file holds AWS credentials for deployments targeted to AWS. aws.env As we are using AWS as our cloud provider, we need to add our AWS IAM Access Keys with Administrator Access policy. You can refer to this if you are not sure how to obtain them. video The contains all the steps to deploy the airnode provided in a markdown format. README.md Open aws.env and add your and that you just created. AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY Open and add your wallet mnemonic. Make sure you keep it extremely safe as this will serve as the “private key” of your deployed Airnode. From the mnemonic phrase, Airnode is able to assign wallet addresses to both the Airnode instance and its users. config/secrets.env You also need to add your Blockchain Provider URL. Here, we are going to use Alchemy for a free Polygon Mumbai Testnet Provider URL. You can use any blockchain provider that supports your network You can also set-up your * *credentials. It’s an optional service that allows authenticated users to make HTTP requests to your deployed Airnode instance for testing. ChainAPI has already generated these keys for you but you can change them if you want. HttpGateway One final step before deploying your Airnode is to set in the file. Authorizers config.json When an Airnode receives a request, it can use on-chain authorizer contracts to verify if a response is warranted. This allows the Airnode to implement a wide variety of policies and to authorize requester contract access to its underlying API. For the scope of this tutorial, we can set the authorizer array empty in so that any requester contract can access the Airnode config.json Now you are ready to deploy your Airnode. Make sure you have Docker installed on your system. Copy and paste the commands below to your terminal at the root directory of your deployment package. Windows docker run -it --rm ^
      --env-file aws.env ^
      -v "%cd%/config:/app/config" ^
      -v "%cd%/output:/app/output" ^
      api3/airnode-deployer:0.7.3 deploy OSX docker run -it --rm \
      --env-file aws.env \
      -e USER_ID=$(id -u) -e GROUP_ID=$(id -g) \
      -v "$(pwd)/config:/app/config" \
      -v "$(pwd)/output:/app/output" \
      api3/airnode-deployer:0.7.3 deploy Linux docker run -it --rm \
      --env-file aws.env \
      -e USER_ID=$(id -u) -e GROUP_ID=$(id -g) \
      -v "$(pwd)/config:/app/config" \
      -v "$(pwd)/output:/app/output" \
      api3/airnode-deployer:0.7.3 deploy Your Airnode is now deployed. You can check its status on the deployment section. Check out the Github Repo for this guide . here Part II: How to code a Requester contract to call and read the data from the Airnode. In Part I, we successfully integrated and deployed an Airnode through ChainAPI. Now we will code a simple Requester Contract to call and read data from our Airnode. Before starting, make sure you set up the on your system. Follow through the Readme to install and build all the dependencies and packages to be able to access the Airnode CLI. Airnode Monorepo Clone the Airnode Monorepo. $ git clone //github.com/api3dao/airnode.git . To install the dependencies, $ yarn run bootstrap To build all the packages, $ yarn run build An Airnode is a first-party oracle that pushes off-chain API data to your on-chain contract. It makes a request to the on-chain ( ) that adds the request to the event logs. The off-chain Airnode then accesses the event logs, gets the API data and performs a callback to the requester. RRP protocol contract AirnodeRrpV0.sol <//docs.api3.org/airnode/v0.8/grp-developers/ ](//docs.api3.org/airnode/v0.8/grp-developers/) A * *is a contract that triggers an Airnode request. To do so, the requester needs to be sponsored and make the request using a matching sponsor wallet. Requester The Requester then calls the protocol contract, which emits a blockchain event with the request parameters. Airnode listens to the events emitted by the contract. During the next run cycle, Airnode gets the request parameters from the emitted event. AirnodeRrpV0 An Airnode is a first-party oracle that pushes off-chain API data to your on-chain contract. It makes a request to the on-chain ( ) that adds the RRP protocol contract AirnodeRrpV0.sol Coding Requester.sol The Requester Contract will have two main functions, and . makeRequest() fulfill() The function will call the function of the protocol contract which adds the request to its storage. The targeted off-chain gathers the request from AirnodeRrpV0.sol’s storage and responds using the function of AirnodeRrpV0.sol. makeRequest() makeFullRequest() AirnodeRrpV0.sol Airnode fulFill() Request Parameters The function expects the following parameters to make a valid request. makeRequest() (address) and specify the endpoint. airnode endpointId and (addresses) specify which wallet will be used to fulfill the request. sponsor sponsorWallet specify the API and (see for how these are encoded) We will encode the parameters off-chain using library. parameters Reserved Parameters Airnode ABI specifications @airnode-abi Response Parameters The callback to the contains two parameters: Requester : First acquired when making the request and passed here as a reference to identify the request for which the response is intended. requestId : In case of a successful response, this is the requested data which has been encoded and contains a in addition to other response data. Decode it using the function from the object. data timestamp decode() abi Compiling the Contract To deploy the Requester Contract, we are going to use . It’s an online IDE that allows developing, deploying and administering smart contracts for EVM Compatible Blockchains. Remix IDE Make a contract and paste in the code. Requester.sol Now hit compile on the right side of the dashboard and compile the Smart Contract. Now we are all set to deploy our Requester. Deploying the Requester As we are going to deploy the contract on Polygon Mumbai Testnet, make sure you have enough MATIC in your wallet to deploy the Requester and then fund the later. You can get some from the . sponsorWallet Mumbai Faucet Head to Deploy and run Transactions and select Injected Provider — MetaMask option under Environment. Connect your MetaMask. Make sure you’re on Mumbai Testnet. The is the main The RRP Contracts have already been deployed on-chain. You can check for your specific chain . _rrpAddress airnodeRrpAddress. here Fill in the and click on Deploy. Confirm the transaction on your MetaMask and wait for it to deploy the Requester Contract. _rrpAddress Make sure you’re on the Polygon Mumbai Testnet Calling the Requester As soon as your Contract gets deployed, head on to Deploy & run transactions and click on the dropdown for your Requester under Deployed Contracts. Now select the dropdown to see all the parameters you need to pass in order to make a full request to the Airnode. makeRequest Here, you need to pass in your (Airnode address), , (The Requester itself), and in order to call the function. airnode endpointID sponsor sponsorWallet parameters makerequest() We can find the in the under the output directory that we got when we deployed our Airnode. airnode receipt.json The can be found under the file. endpointID config.json We need to derive the through the Airnode CLI command that will make the actual call. We also need to fund it with some MATIC to cover the gas cost. sponsorWallet After you’ve set up the Airnode CLI and installed and built all the dependencies and packages, run the following command to derive your : sponsorWallet Linux: npx @api3/airnode-admin derive-sponsor-wallet-address \
  --airnode-xpub xpub6CUGRUo... \
  --airnode-address 0xe1...dF05s \
  --sponsor-address 0xF4...dDyu9 Windows: npx @api3/airnode-admin derive-sponsor-wallet-address ^
  --airnode-xpub xpub6CUGRUo... ^
  --airnode-address 0xe1...dF05s ^
  --sponsor-address 0xF4...dDyu9 Your and (The extended public key) can be found in the same The will be the address of the Requester contract itself (the one that you just deployed). airnode-address airnode-xpub Airnode’s receipt.json. sponsor-address Run the command to obtain your . sponsorWallet Fund the with some test MATIC. sponsorWallet The parameters are required to be encoded in before you send it. We are going to use the library for encoding the parameters off-chain and then sending it to the Requester. bytes32 @airnode-abi You can head over and clone and set it up. this tutorial’s repository Run the following command to get your encoded : parameters node .\src\encodeParams.js Now you have all the parameters that you require to run the function. Populate all the fields and click on Transact. makeRequest Note: The sponsor here will be the address of the Requester Contract that you just deployed. Click on transact, confirm the transaction on MetaMask and wait for the transaction to complete. Now you can head over to and check your for any new transactions. //mumbai.polygonscan.com sponsorWallet You might need to wait for a while as the Airnode calls the fulfill() function in AirnodeRrpV0.sol that will in turn call back the requester contract at fulfillAddress using function fulfillFunctionId to deliver data . Here, we can see our latest transaction. Fulfill Now go back on Remix and check for under logs for the latest transaction. requestId You can also find your under logs in the Polygon Mumbai Block Explorer. requestId Copy your and paste it on under the method to decode the response. Click on call and it will show you your API response. requestId fulfilledData Here, we requested Tesla’s Stock price. Now you successfully deployed an Airnode and made a Requester Contract to get data from it. You can also refer to for all the code that I’ve used for this tutorial. this Repo Any questions? Check out and drop your queries in the dev-support channel! API3’s Discord Server

How to request data from a REST API to a Solidity Smart Contract 

Cómo solicitar datos de una API REST a un contrato inteligente de Solidity

In 2021, a lot of buzz about first-party oracles was heard in the world of smart contracts and decentralized applications. The accompanying first-party vs third-party oracle debate is fascinating for some and utterly confusing for others. Blockchain oracles get their data from Web APIs. A first-party oracle, where the API provider itself (the data source) is the oracle, publishes data directly to the blockchain. A third-party oracle is one where a third-party entity (other than the API provider) is the oracle. The third-party oracle calls the API to get data and then publishes it to the blockchain. Why Third-Party Oracles? Intuitively, the benefits of first-party oracles are obvious. If the API provider publishes data directly on-chain then the data doesn’t have to pass through an untrusted middleman. The API provider is the only entity that must be trusted before the data is etched in the immutable blockchain. Currently, however, the oracle space is dominated by third-party oracles. Let’s take a step back and ask my favorite question — “Why?” About a year ago Burak posed the question “ ” along with an intimidating list of obstacles that explain why we haven’t seen them yet. See that article for details but in summary, API providers haven’t chosen to run their own oracle software because: Where are the first-party oracles? Existing oracle node software: is unstable to operate can’t self-recover has vague configuration recommendations requires auxiliary software Traditional API providers don’t want to: be paid in cryptocurrency have costs in cryptocurrency stake cryptocurrency For these reasons, API providers have, until now, opted not to run their own first-party oracles. But there is a huge demand for off-chain data on Web3, particularly in decentralized finance (DeFi). As a result, there has been a very lucrative opportunity for third parties to run oracle nodes and serve as middlemen between the API providers and the blockchains. In short, third-party oracles currently dominate because it has been too difficult and risky for API providers to run first-party oracles. The Game Has Changed Day to day movement can feel excruciatingly slow, but it’s amazing what can be accomplished in a year! API3 spent the last year building Airnode, oracle software that addresses and eliminates all of the reasons API providers haven’t wanted to run their own first-party oracle in the first place. This development changes the game entirely. With Airnode, API providers no longer have good reasons to choose not to run their own oracle software. We can finally realize the obvious benefits of first-party oracles, cutting out the third-party middlemen, increasing efficiency, and reducing risk. But this development presents a new problem to overcome. Let’s think through these questionable assertions. We’ve been conditioned by middlemen with a profit motive to believe that third-party oracles are decentralized and that decentralized is always better. Decentralization and Transparency A core tenet of Web3 is decentralization. In order to avoid an attack on or manipulation by an individual, smart contracts rely on decentralization and consensus for security. Ethereum, for example, is a platform for trustless computing. You can’t trust the individual nodes but you can trust the decentralized network. Another core tenet of Web3 is transparency. In order to have secure, trustless computing through decentralization and consensus the nodes must be transparent. Transparency is why we are able to “Don’t trust. Verify.” on Web3. Transparency can be seen from the source code level — Web3 is overwhelmingly open source — all the way up to organizational governance and the proliferation of DAOs. Both decentralization and transparency help enable the trustless and permissionless computing environment of Web3. However, it’s important to understand when to apply each concept. Transparency allows us to independently review and verify something from an individual. On its own, transparency doesn’t guarantee truth. An individual can lie and “transparently” provide false or misleading information to support the lie. Decentralization is a way to reduce the risk of an individual lying. It’s less probable that 3 out of 4 individuals will collude and lie than it is that one individual will lie. It’s tempting, then, to conclude that everything should always aim to be more decentralized. In fact, that is often the point of view taken in crypto. But to always assume that is naive and foolish. In reality, decentralization is an engineering trade off. It can have benefits, but it also has costs. Deciding when it’s appropriate to decentralize something requires a cost benefit analysis. Do the benefits justify the costs? Why First-Party Oracles? It might seem like third-party oracles are preferable because we’re told they’re decentralized. But a further investigation shows this assumption is misguided. While third-party oracles have solved the problem of connecting APIs to blockchains, they’ve introduced a new problem. In addition to trusting the API provider, we also have to trust the third party oracle in the middle. The typical way this new trust problem has been addressed is to follow the lead of the blockchains themselves and decentralize oracle nodes. As stated before, the benefit of decentralization is that it reduces the risk of an individual lying. But the thing that’s decentralized when we’re talking about third-party oracle networks is the third-party oracle nodes, not necessarily the API providers. In fact, it’s quite normal for third-party oracle nodes to acquire their data from the same APIs. In some cases third-party oracle networks even “decentralize” data from only a single source and then “aggregate” it back together. We can’t trust third-party oracle nodes and so we decentralize them to reduce the risk they introduced in the first place. And the reasons for needing them have been eliminated. We don’t need them anymore. In these situations the only problem being solved by decentralization is the one created by third-party oracles. The risk of an attack on or by third-party oracle nodes exists, even if it’s reduced using decentralization. With first-party oracles the middlemen nodes are eliminated entirely so there is no third-party trust problem to solve. The added risk from third-parties is zero because there are none. In both cases the risk from the API provider is the same so with third-party oracles the overall risk is increased, even when those oracles are “decentralized”. To further muddy the third-party oracle water, they are often not transparent about their data sources. This opacity violates a core tenet of Web3. First-party oracles, on the other hand, are inherently transparent. When the data source is the oracle, there is never any question about where the data comes from. The reputation of the API provider is brought on-chain with the data. If there are multiple, truly independent sources of data then there can be value in decentralizing the data sources themselves. But when the API provider has a strong reputation, which many do, then the value added by decentralizing data sources can be low. It may even be harmful to decentralize and aggregate a very reputable data source with a less reputable source because it dilutes the quality of the data from the more reputable source. Of course, with opaque third-party oracles you would never know. You have no choice but to trust them. Here we compare first-party oracles vs third-party oracles when the API provider has a strong reputation. When the API provider has a strong reputation a “decentralized” network of third-party oracles sacrifices both transparency and efficiency in order to gain a dubious decentralization benefit that in many cases is actually harmful. In the end it’s no contest. First-party oracles outperform third-party oracles in almost every way you can compare. The reasons for having third-party oracles in the first place have been eliminated by API3 and Airnode. The next generation of blockchain oracles are first-party. As introduced in Burak’s recent article “ ”, API3 is building scalable, efficient, transparent data feeds based on first-party oracles. Please keep your hands and feet inside the car at all times, this is going to be a fun ride. The first-party oracles are coming. Beacons: Building blocks for Web3 data connectivity Also published here

The Rising Importance of First-Party Oracles

We do two things at API3: Build the tooling that will make Web APIs available to smart contracts in the form of first-party oracles. This is not limited to integration, but also productization and monetization. Foster an API-first oracle ecosystem to break through the chicken-and-egg problem that is common in emerging technologies. The goal is to turn services that real-world businesses provide into building blocks on the blockchain, which developers will be able to compose into complex use-cases in a trustless way. These projects will be able to create value by the virtue of embodying real-world services, and will be a quantum leap over the speculatory Rube Goldberg machines that DeFi composability is limited to today. The implications of this far exceed the traditional DeFi use-cases, yet an elegant solution should be expected to apply for a variety of problems, and this is the case for first-party oracles. If one wants to set up a live asset price feed on-chain, doing this through first-party oracles is the ideal solution due to many reasons listed in . In this post, we will build up on this and discuss the of it. our whitepaper how What is wrong with “decentralized” oracles? The weakness in the traditional decentralized oracle model is that the assumption that powering a service through multiple nodes or APIs makes it decentralized. However, there are two additional requirements that all decentralized blockchain projects must satisfy: Lack of centralized governance Transparency, to be able to validate the decentralization requirements Transparency, to be able to validate the decentralization requirements Take the with the CoinMarketCap API for example. What can you make of this screenshot? recent issue On the surface, it looks like only 01node was affected by the issue. Were they only using the CMC API, or were they using other APIs that have misreported? What about the other nodes, how many others were using the CMC API (and/or others that have misreported), and how close were they to misreporting themselves? The answers to these questions don’t matter, the point is that they can’t be answered trustlessly. Normally, one should assume a lack of decentralization if they can’t verify it. However, this is not always the case: This begets the question: Why would anyone assume that Chainlink has never operated a “decentralized” data-feed using only 2 APIs? If this has ever happened under the veil of source obfuscation, is this not a graver issue than Band doing it openly? Our solution: First-party oracles, Beacons, dAPIs, insurance First-party oracles imply an inherently one-to-one mapping between data sources and oracles. Then, discussing transparency is redundant, as the oracle is the data source and the data source is the oracle. This is very useful in dealing with issues such as the recent CMC misreport, because one can be ensured that other first-party oracles are guaranteed to not be affected by the incident. Moreover, this allows the consumers to choose their oracles based on data source performance. Compared to this, you can’t tell to what degree third-party oracles will be affected by such an error or if they will take precautions in the future because their data sources can’t be investigated transparently. Individual first-party oracles will fare better in the case of data source problems, while third-party solutions obscure weaknesses until a catastrophic failure. What we want to discuss in this post is how data feeds should be designed to complement the first-partyness of the constituent oracles. To this end, we introduce a new concept called a , which is an atomic data feed that is powered by a singular first-party oracle. Beacon Michael Thompson, The Lighting of the Beacons, 2017. A Beacon is a point of data that is kept alive on-chain by the respective first-party oracle. Anyone is able to request a Beacon to be updated, given that they have funded their sponsor wallet that will be charged for the gas cost of the update. These updates can either be triggered by requests made through the request–response protocol, or will happen automatically based on the respective condition specified through the publish–subscribe protocol. In other words, Beacons will be built on the Airnode protocols, and carry over the data source transparency from the oracle-level to the data feed-level. The traditional way a data feed is built is that the data consumer is confined to what the centrally governed oracle project thinks is a good idea, and they don’t even know what they are agreeing to due to third-party oracles not being transparent with their data sources. In other words, the lack of composability is as important of a problem as the lack of transparency, as it disables the data consumer from rejecting data coming from a particular provider. Beacons will be the building blocks of dAPIs, meaning that a particular dAPI will be built as an arbitrary combination of Beacons. The Beacon-based dAPI architecture creates a paradigm shift in that it not only allows the user to see where exactly the data comes from, it also gives them granular control over the selection if they wish. Although Beacons are excellent components to build dAPIs out of, they are also ideal for standalone use when: The Beacon is reliable enough for the use-case and decentralization creates an unjustifiable overhead The Beacon is exceptionally reliable to the point that any decentralization would degrade the result Therefore, we foresee that API3 services will include both individual Beacons and dAPIs that are built out of these Beacons. But what if a client uses a Beacon in standalone fashion and the data provider keeping the Beacon experiences a failure? Beacons and their vast combinations in the form of dAPIs all appear as equivalent live data points on-chain, with differing levels of reliability. Then, singular Beacons — or from another point of view, dAPIs built out of individual Beacons — can share the same security guarantees that are meant for dAPIs: Insurance, made possible by API3 staking. The same incentives would apply, in that the DAO would only insure Beacons for standalone use if they are assessed to be adequately reliable, and black swan events would be covered by insurance premiums collected during normal operation. The recent CMC issue has validated our concerns about third-party oracles lacking data source transparency and how this makes it impossible to assess their level of reliability or decentralization. We found this to be an apt opportunity to introduce Beacons, as they are both data source-transparent and give the dAPI consumer not only information, but also control over where they get their data from. An important benefit of standalone Beacons secured through insurance will be breaking down the currently monolithic state of DeFi. When an oracle project is operated by a traditional centralized organization, this limits the number of chains and data feeds that they can serve, which forces their consumers to flock to the same chains to use the same data feeds or starve. Beacons will enable many previously infeasible use-cases and allow DeFi to grow wide, and not only tall. Finally, we find Beacons to be a very important step towards democratization of data feed composition and governance. This is closely related to our fractal scaling vision, in that we expect dAPI curation out of Beacons to be one of the important verticals that API3 ecosystem projects will pursue. For that to be possible, it is of utmost importance for dAPI composition to be easy and permissionless, which is one of the aims of the Beacon-based architecture. In this post, we have briefly introduced Beacons and how they fit in with our existing first-party oracle approach, dAPIs and insurance. We’re sure you have questions and ideas, so feel free to join and discuss them with the community. our Discord Previously published here

Stories, News & Mentions about API3

Api3’s Stories on HackerNoon

Api3's News & Mentions