CCV Starter Kit

The CCV Starter Kit deploys a Cross-Chain Verifier (CCV) into Kubernetes infrastructure you already run. It has two parts, each in its own repository with its own step-by-step documentation:

• The on-chain contracts kit deploys and governs your verifier contracts.
• The off-chain kit is a Helm chart that runs your verifier and aggregator as a cell: one verifier plus one aggregator, backed by Postgres. Both run as Docker images from the public Amazon ECR gallery.

Versions and releases

The chart and its images are versioned upstream, not in this guide, so these links always show the current releases:

Available on the marketplaces

The CCV Starter Kit is listed on AWS Marketplace and Google Cloud Marketplace. Professional operators deploy by following this guide and the starter kits.

AWS Marketplace

Google Cloud Marketplace

Who this guide is for

You run production Kubernetes and own your networking, TLS and ingress, secret management, and a production database. Cloud-specific dependencies are labeled by cloud (GCP, AWS, Azure, on-premise), and each links the vendor's own documentation. The Helm charts are cloud-agnostic, so the same concepts apply on any other cloud provider too. If you do not yet run this infrastructure, start with Prerequisites and set it up first.

This guide is the operator's install path. For what a CCV is and how it fits CCIP, see the CCV overview.

What you build

The verifier polls source chains and signs message hashes; the aggregator serves those attestations over gRPC; the CCIP indexer reads them, and the executor runs the message on the destination. For the full end-to-end CCIP v2 architecture, see the CCIP architecture overview.

What changes with your infrastructure

The verifier and aggregator run the same containers wherever you deploy them: any cloud (GCP, AWS, Azure, or another provider) or on-premise. Only three things differ, and you own all three: how you inject the configuration secret, how you expose the aggregator, and where Postgres comes from. On a managed cloud you use that cloud's services for each; on-premise you run them yourself. The kit is brownfield: it deploys into infrastructure you already run and provisions none of its own.

Production topology

A single cell is for learning. In production run a committee of cells across independent failure domains, ideally different clouds or regions, each cell fully independent (its own Postgres, secrets, and key custody, never shared). The smallest production committee is four cells with a threshold of three. Scale to a committee explains the sizing and how to grow beyond it.

Policy hook and key custody

The kit adds two operator capabilities on top of the core cell:

• A custom policy hook: an HTTPS endpoint you implement in any language to run your own compliance or risk checks before a node signs. It only has to honor the request/response contract (an OpenAPI spec); the verifier calls it for a PASS/FAIL on each message.
• KMS key custody: the signing key never leaves your cloud KMS. Strongly recommended on a managed cloud.

Start here

How-to guides

Operate and reference