> ## Documentation Index
> Fetch the complete documentation index at: https://docs.verity.usher.so/llms.txt
> Use this file to discover all available pages before exploring further.

# IC-ADC Implementation

> This documentation provides an overview of how the Verity DP framework is integrated within the `processor` and `orchestrator` folders of the project. It highlights the usage of Verity modules and the inter-canister communication with the Verity Verifier.

## `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.

```rust theme={null}
/// 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`](https://github.com/usherlabs/ic-adc/blob/3075e393e416029c13ff350f97f75934101d3e72/processor/ic/src/utils.rs#L18), we simply parses the response proofs to obtain the values.

<Note>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.</Note>

```rust theme={null}
// 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`](https://github.com/usherlabs/ic-adc/blob/eda06461349e85f8c16456af165654e7d167cfa2/orchestrator/src/helpers/verity.rs#L7) file to create a `VerityClient` for interfacing with a Verity Prover.

```rust theme={null}
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](https://github.com/usherlabs/ic-adc/blob/7dd247aacaf358708ebb1ec7cb463ece48f410af/orchestrator/src/handlers/price/sources/pyth.rs#L42-L68), the `verity_client` is used similarly to Rust's [`reqwest`](https://docs.rs/reqwest/latest/reqwest/) library:

```rust theme={null}
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.