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

# Usher Labs' Managed Verity Services

> This topic covers operating the Verity Network Nodes via the CLI, and additional tools for verifying TLS proofs.

## Verity Notary

Usher Labs manages Verity Notaries as a fundamental requirement for operating the Verity Network.
Provers must connect to a verified Notary to generate TLS proofs.
Notaries, can however, be operated third-party Node Operators in a fully decentralised manner. *This feature is not yet available.*
Usher Labs has conducted thorough research and benchmarks to evaluate that ensuring Prover and Notary nodes are in close proximity is a requirement for reliable proof generation.

## Verity Prover

Self-hosting the Verity Prover is advised to ensure full security over your data, and data acquired from your data sources.
Self-hosting does require additional overhead in operating and scaling the Prover, especially in a production environment that demands massive concurrency.

To address this, Usher Labs offers a fully managed Verity Prover infrastructure.
This includes autoscaling, monitoring, and alerting to ensure uptime and performance of the Prover for your zkTLS use case.

For specific circumstances, we may deploy a Prover at a different domain specific to your enterprise. Please [contact Usher Labs](https://go.usher.so/discord) for more information.

### Getting Started

This guide outlines how to interact with the managed Verity Prover from a terminal. For convenience, the **Verity Client** has been developed to streamline and abstract many of these steps.

#### **Verity Client Source Code**

[https://github.com/usherlabs/verity-dp/tree/main/rs/verity-client](https://github.com/usherlabs/verity-dp/tree/main/rs/verity-client)

#### Verity Client Integration Example

1. Instantiate the Client —  [https://github.com/usherlabs/ic-adc/blob/8f28678abff9d8c098d878b83ebcc8615d442f35/orchestrator/src/helpers/verity.rs#L7](https://github.com/usherlabs/ic-adc/blob/8f28678abff9d8c098d878b83ebcc8615d442f35/orchestrator/src/helpers/verity.rs#L7)

2. Execute a Request Using the Client — \*\*\*\*[https://github.com/usherlabs/ic-adc/blob/8f28678abff9d8c098d878b83ebcc8615d442f35/orchestrator/src/handlers/price/sources/pyth.rs#L58](https://github.com/usherlabs/ic-adc/blob/8f28678abff9d8c098d878b83ebcc8615d442f35/orchestrator/src/handlers/price/sources/pyth.rs#L58)

#### **Step 1: Generate a UUID**

A UUID serves as a unique identifier for the verifiable request. It enables correlation between asynchronously generated proofs and the originating request.

To generate a `request_id`, use the following command:

```bash theme={null}
uuidgen
```

**Output:**

```bash theme={null}
5432b484-0e4c-4fc1-94e1-25e49a64b57
```

#### **Step 2: Subscribe to Async Proofs**

To receive proofs delivered via Server-Sent Events (SSE), use the `curl` tool. Open a terminal and listen for SSE at the `/proof/[request_id]` endpoint:

```bash theme={null}
curl -N https://prover.verity.usher.so/proof/5432b484-0e4c-4fc1-94e1-25e49a64b57f
```

#### **Step 3: Execute Request via Verity Prover**

The Verity Prover functions as a proxy.

It facilitates the desired HTTP request while generating a TLS attestation to cryptographically prove the correctness and authenticity of the data source.

Under the hood, the process is assisted by the network and follows a protocol to guarantee integrity.

In a second terminal window, execute the request to the Verity Prover, including the `request_id` as the value for the `T-REQUEST-ID` header.

```bash theme={null}
curl https://prover.verity.usher.so/proxy -X GET \
-H "T-PROXY-URL: https://jsonplaceholder.typicode.com/posts/98" \
-H "T-REQUEST-ID: 5432b484-0e4c-4fc1-94e1-25e49a64b57f"
```

Verity is designed to support high-concurrency proof generation for TLS attestations, accommodating a range of APIs, from social data to crypto asset data.

**Sample HTTP Request Body to X API:**

```json theme={null}
{
  "data": [
    {
      "edit_history_tweet_ids": [
        "1848795612164305086"
      ],
      "public_metrics": {
        "retweet_count": 2204,
        "reply_count": 660,
        "like_count": 31415,
        "quote_count": 192,
        "bookmark_count": 2273,
        "impression_count": 2152378
      },
      "id": "1848795612164305086",
      "text": "Tucker Carlson says Tim Walz is \"very obviously gay. I look at him and I’m like ‘Well, you’re gay.’” \uD83D\uDC80\n\nhttps://t.co/s6CWzXZvpa"
    }
  ]
}
```

#### **Step 4: Rollup**

Verity operates as a [*zkRollup for TLS attestations*](/tech/introduction), consolidating numerous attestations into a single verifiable proof.

The [**Verity Data Processor (VDP)**](/build/vdp) Framework simplifies this process by providing libraries and tools to process multiple TLS attestations into a verifiable output via a zkVM. This ensures scalability and efficiency.

Verifiability is underpinned by decentralised compute, leveraging both public and private compute environments to partially verify proofs before consolidation.

For more information, visit:

[https://github.com/usherlabs/verity-dp/](https://github.com/usherlabs/verity-dp/)