​
processor

The processor is the on-chain aspect of the IC-ADC. It is responsible for receiving data from an off-chain orchestrator node, verifying provided TLS proofs, and processing this data for destination Canisters within the Internet Computer.

​
Inter-Canister Call to Verity Verifier

In the processor/ic/src/sources/mod.rs file, the function request_proof_verification makes an inter-canister call to the ic/managed/verifier. This call is crucial for obtaining verified or decrypted proofs from the managed verifier canister. 
/// Request verification from the managed verifier response
pub async fn request_proof_verification(
    stringified_proofs: &Vec<String>,
    notary_pubkey: &String,
) -> Vec<ProofResponse> {
    let verifier_canister = state::get_verifier_canister().unwrap();

    // make a request to the managed verifier canister
    // to get a response which would contain the verified/decrypted proofs sent
    let (response,): (Vec<ProofResponse>,) = ic_cdk::call(
        verifier_canister,
        "verify_proof_async",
        (stringified_proofs, notary_pubkey),
    )
    .await
    .unwrap();

    response
}
The function uses the ic_cdk::call method to communicate with the verifier canister, passing the stringified proofs and the notary public key as arguments. This interaction is a key part of the Verity DP framework, enabling the Internet Computer to verify proofs asynchronously. In a parent function call get_token_price, we simply parses the response proofs to obtain the values.
There is no subsequent proof after the request_proof_verification call. This is because all of this computation is occurring on-chain, within the IC.
// Provided a token and a notary public key for the notary used to generate the proofs attached to the tokens
// verify/decrypt the proofs and come to a concensus on the token price
pub async fn get_token_price(token: &Token, notary_pubkey: &String) -> anyhow::Result<f64> {
    // get the proofs in a stringified form
    let proof_types = token.proofs.as_ref().unwrap();
    let stringified_proofs: Vec<String> = proof_types
        .iter()
        .map(|pt: &ProofTypes| pt.to_string())
        .collect();

    // request proof response from verification canister
    let verification_response_proofs =
        request_proof_verification(&stringified_proofs, notary_pubkey).await;

    // parse the proof response based on the corresponding proof type
    // to get the price in the response of the http response body of the verified request
    // use the proof type to parse the json as either a pyth or redstone proof
    let asset_price = get_asset_price_from_proofs(proof_types, &verification_response_proofs);

    asset_price
}

​
orchestrator

​
Verity Client Usage

The verity-client module is used in the orchestrator/src/helpers/verity.rs file to create a VerityClient for interfacing with a Verity Prover. 
use verity_client::client::{VerityClient, VerityClientConfig};

use crate::config::Config;

pub const DEFAULT_PROVER_URL: &str = "http://127.0.0.1:8080";

pub fn get_verity_client() -> VerityClient {
    let config = Config::env();

    let verity_config = VerityClientConfig {
        prover_url: config.prover_url,
    };

    VerityClient::new(verity_config)
}
In a parent function, the verity_client is used similarly to Rust’s reqwest library: 
impl PricingDataSource for Pyth {
    fn new() -> Self {
        Self {}
    }

    async fn get_url(ticker: String) -> Result<String> {
        let ticker_id = Self::get_ticker_id(ticker).await?;
        Ok(format!(
            "https://hermes.pyth.network/api/latest_price_feeds?ids[]={}",
            ticker_id
        ))
    }

    async fn get_proof(ticker: String) -> Result<ProofTypes> {
        // construct the request URL
        let request_url = Self::get_url(ticker).await?;
        let verity_client = get_verity_client();

        // get the proof using the verity client
        let response = verity_client.get(&request_url).send().await?;

        // check for a succesfull and valid response
        let http_response_string = response.subject.text().await?;
        Self::validate_response(http_response_string).await?;

        return Ok(ProofTypes::Pyth(response.proof));
    }

​
Conclusion

These references show where the Verity DP modules are integrated within the processor and orchestrator folders. The inter-canister call to the Verity Verifier and the use of the Verity Client are essential components of the Verity DP integration, ensuring secure and efficient data processing and verification.