Validator Deployment Components
A validator deployment is more than just a single service—it's a coordinated set of components that work together to connect your organization to the Canton Network. Understanding these components helps operators debug issues, plan capacity, and configure networking correctly.
What's in a Validator Deployment?
When you deploy a validator using the Splice Helm chart, you're not just running one container. You're deploying a complete ecosystem with five main components, each serving a specific purpose in the network.
Each component is deployed as a Kubernetes pod (or set of pods) and can be scaled, monitored, and configured independently. Let's break down what each does.
Component Breakdown
1. Participant Node (Canton Node)
The participant is your organization's core connection to the Canton Network. It runs the Canton protocol—managing your ledger state, validating transactions, and synchronizing with sequencers.
| Property | Value |
|---|---|
| Container | splice-participant |
| Ports | 5061 (Ledger API), 5062 (Admin API) |
| Database | participant_canton |
| Stateful? | Yes — stores ledger data |
2. Validator App
The validator app is the orchestration layer that connects your participant to the Splice network infrastructure. It handles network onboarding, reward collection, and automation.
| Property | Value |
|---|---|
| Container | splice-validator |
| Port | 5003 (JSON API) |
| Database | validator_app |
| Key Feature | Wallet backend, automation triggers |
The validator app exposes a JSON API that powers the Wallet UI and provides the /api/validator endpoints used for balance queries, transfers, and reward collection.
3. Wallet UI
The Wallet UI is a web frontend that lets users interact with their Canton Coin (CC) holdings, transfer funds, and view transaction history.
| Property | Value |
|---|---|
| Container | wallet-web-ui |
| Port | 3000 |
| Connects to | Validator App (port 5003) |
| Auth Required | Yes — OIDC (Keycloak/Auth0) |
4. ANS UI (Canton Name Service)
The ANS UI (formerly CNS) provides a web interface for registering and managing human-readable names in the Canton Name Service—think ENS but for Canton.
| Property | Value |
|---|---|
| Container | cns-web-ui |
| Port | 3000 |
| Connects to | Validator App (port 5003) |
| Purpose | Name registration, transfers, lookups |
5. PostgreSQL Database
All stateful components connect to a shared PostgreSQL instance (or cluster). The database stores ledger state, app data, and sequencer/mediator state if you're running those locally.
| Database Name | Used By |
|---|---|
participant_canton | Participant node ledger data |
validator_app | Validator app state |
sequencer | Sequencer (if running SV) |
mediator | Mediator (if running SV) |
Helm Chart Mapping
The Splice project provides two main Helm charts for deployment. Here's how the components map to charts:
| Helm Chart | Components Deployed |
|---|---|
splice-validator | Validator App, Wallet UI, ANS UI |
splice-participant | Participant Node |
postgresql (Bitnami) | PostgreSQL database |
# Typical installation order
helm install postgres bitnami/postgresql -f postgres-values.yaml
helm install participant splice/splice-participant -f participant-values.yaml
helm install validator splice/splice-validator -f validator-values.yamlResource Recommendations
Here are typical resource requests for production workloads. Adjust based on your traffic and ledger size.
| Component | CPU Request | Memory Request | Notes |
|---|---|---|---|
| Participant | 1-2 cores | 4-8 GB | Most resource-intensive |
| Validator App | 0.5-1 core | 2-4 GB | Scales with users |
| Wallet UI | 100m | 256 MB | Static frontend |
| ANS UI | 100m | 256 MB | Static frontend |
| PostgreSQL | 2-4 cores | 8-16 GB | Use managed if possible |
Ingress Configuration
The UIs need to be exposed externally for users to access them. A typical ingress setup routes different subdomains to each service:
# Ingress routing example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: validator-ingress
spec:
rules:
- host: wallet.yourdomain.com
http:
paths:
- path: /
backend:
service:
name: wallet-web-ui
port:
number: 3000
- host: cns.yourdomain.com
http:
paths:
- path: /
backend:
service:
name: cns-web-ui
port:
number: 3000/api/validator internally to the validator app on port 5003. Configure your ingress annotations appropriately for path rewrites if needed.Key Takeaways
1. Five components work together: Participant, Validator App, Wallet UI, ANS UI, and PostgreSQL form a complete validator deployment.
2. Participant is stateful and critical: It holds your ledger data. Plan backups and high availability accordingly.
3. UIs talk to the Validator App: The web frontends proxy /api/ requests to the validator app on port 5003.
4. Use separate Helm charts: Deploy participant and validator separately for cleaner upgrades and rollbacks.