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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.