Adapter Creator

1. Adapter Creator

The Adapter Creator represents a foundational tool that defines the structure of off-chain inference requests, creating a standardized framework for AI agents, smart contracts, or other consumers to communicate effectively with off-chain data sources.

2. Parameter Specification

To create an adapter, you need to specify several essential parameters that define its functionality, capabilities, and communication requirements. These parameters ensure that the adapter is correctly configured to facilitate interactions between different systems, particularly between on-chain and off-chain environments. Here are the critical parameters:

• Name (String): Name of the adapter.

• Description(String): Provides a brief description of what the adapter does.

• Variables (String): Defines the adapter’s variables in a comma-separated string format for easy processing and validation.

• Category ID(Number): The ID of the category this adaptor belongs to.

• Output Type ID(Number): Specifies the ID of the output type that the adapter will produce. ( Currently, We support four different types of output: Bool, Bytes, Uint256, StringAndBool )

During the generation process, the system will automatically create a unique JobID in a format compatible with Solidity's bytes32 type. This JobID serves as a unique identifier and must be generated before the creation of the adaptor.

For example jobID: 0x1b364865ca3e6bb5ada098d0ea96f9e9369b5693cacede79d1352334c4213ac2

3. Example

Build a simple application designed to gather real-time token price data. From this foundation, you can expand the functionality by integrating AI agents to analyze the data, providing users with actionable insights.

For example, by leveraging AI-driven models, you can develop PriceIntel, an advanced system that evaluates current and historical token price trends to help predict future movements. Based on this analysis, the AI agent can assess whether the price of a specific token is likely to increase or decrease, offering actionable predictions for users in the context of:

• Trading: Deciding when to buy or sell tokens based on predictive trends.

• Portfolio Adjustments: Optimizing asset allocations based on token price forecasts.

• Strategic Investments: Identifying potential long-term investment opportunities.

Through this approach, users can enhance their trading strategies and make data-driven investment decisions using both real-time data from ADCS and AI-powered analysis.

Step-by-step guide on how to approach building the application

1. Adapter Definition:

You need to define an adapter that outlines the necessary parameters.

• Name (String) : getPrice.

• Description(String): Retrieve real-time price data for any token pair

• Variables (String): _from and _to: Price of a token from one currency to another. (e.g. BTC/USD _from:"BTC" , _to:"USD")..

• Category ID(Number): 1.

• Output Type ID(Number): 1

2. Setup your consumer contract

Depending on the type of outputData you have defined in the adaptor, your consumer contract must inherit from the appropriate ADCS fulfillment contract. Each fulfillment contract is tailored to handle a specific type of data response:

• ADCSConsumerFulfillUint256: For handling uint256 (unsigned integer) responses.

• ADCSConsumerFulfillBool: For handling bool (boolean) responses.

• ADCSConsumerFulfillBytes32: For handling bytes32 (32-byte hash) responses.

• ADCSConsumerFulfillBytes: For handling raw bytes responses.

// SPDX-License-Identifier: MIT
 pragma solidity ^0.8.20;
import "../ADCSConsumerFulfill.sol";
contract MockADCSConsumer is ADCSConsumerFulfillUint256{ }

Contract Variables:

This public state variable stores the last piece of data that was fulfilled by the oracles in response to a consumer request.

uint256 public lastUint256;

Constructor:

constructor(address _coordinator) ADCSConsumerBase(_coordinator) {}

The constructor takes the Coordinator contract's address (_coordinator) as input and passes it to the base contract. The Coordinator manages the interaction between oracles and consumers, facilitating the flow of data requests and responses.

Different Coordinator contract addresses are provided, each tailored to handle a specific output type, such as uint256, bool, or bytes. This allows consumers to interact with oracles in a way that matches the data type of the responses they expect.

Request Functions:

function requestUint256Data(
    uint32 _callbackGasLimit,
    bytes32 _jobId,
    string memory _from,
    string memory _to
) external returns (uint256 requestId) {
    bytes32 typeId = keccak256(abi.encodePacked("uint256"));
    ADCS.Request memory req = buildRequest(_jobId, typeId);
    req.add("from", _from);
    req.add("to", _to);
    requestId = COORDINATOR.requestData(_callbackGasLimit, req);
    emit DataRequestedUint256(requestId);
}

This function requests uint256 data from an oracle:

• _callbackGasLimit: The maximum amount of gas a user is willing to pay for completing the function.

• _jobId: The jobID that the consuming contract is registered to.

• _from and _to: Price of a token from one currency to another. (e.g. BTC/USD _from:"BTC" , _to:"USD").

• The function uses the buildRequest() function to create a request, adds the necessary parameters, and sends it to the Coordinator.

Fulfillment Functions:

function fulfillDataRequest(uint256, uint256 response) internal virtual override {
    lastUint256 = response;
}

This function is called by the Coordinator contract to fulfill the data requests once the oracles return the result.

3. Deploy your consumer contract