Validator infrastructure for institutions, funds and token projects
Beyond the retail pools on this site, we provision and operate dedicated validator nodes on your behalf: monitoring, key management, upgrade coordination and reporting, agreed per engagement rather than templated.
What’s included
The operational work of running a validator, not just the hardware underneath it.
Provisioning
Dedicated validator nodes for each network you delegate to, sized and configured for that network's own requirements, not a shared instance carved out of our retail infrastructure.
24/7 monitoring
Node health, peer connectivity, missed votes and block-signing are watched continuously, with alerting on anything that could put your delegation at risk before it becomes an incident.
Key management
Signing keys are handled under the custody arrangement agreed for your engagement, isolated from retail user funds and from any other client's infrastructure.
Coordinated protocol upgrades
Network upgrades, hard forks and parameter changes are tracked against each chain's own release schedule and applied with advance notice, not discovered when a node falls out of consensus.
Sentry architecture
Signing nodes sit behind sentry nodes that handle public peer connections, so the node holding your validator key is never directly reachable from the public network.
Reporting
Uptime, missed blocks, commission and any slashing events are reported for your validator specifically, on a cadence agreed in your engagement, not aggregated across our other pools.
Networks we are preparing
These are the networks we currently run validator infrastructure for. An institutional engagement gets its own dedicated nodes on the same networks, never the shared retail pool infrastructure itself. If the network you need isn’t listed, say so in the form below; scoping a new network is itself part of the first conversation.
How onboarding works
- 1
Confirm scope
We talk through which network or networks, roughly how much you're looking to delegate, your custody requirements and any compliance constraints. This decides the infrastructure and key arrangement. It isn't a generic template.
- 2
Agree terms
Commission, reporting cadence, key custody and what is and isn't covered are set out in writing before anything is provisioned.
- 3
In production
Nodes are provisioned, synced and tested against your validator address before it starts signing anything live.
What we’re responsible for
Read this before the form below. It’s the part that actually matters for deciding whether to delegate to us.
- Slashing exposure is real, and it isn't automatically ours
- If a validator we operate is slashed (for downtime or for double-signing), the penalty is deducted from the bonded stake itself, which is your delegation, not a balance we hold. We operate to avoid it, but indemnifying that loss is something we agree explicitly for a given engagement, not something implied by default.
- What an SLA would and wouldn't cover
- Where we agree a service-level commitment, it covers what we actually control: node uptime, monitoring response, and how quickly we act on an incident. It does not cover a network-level bug, a chain halt, a governance decision that changes slashing conditions, or the market value of the asset you've delegated. No validator operator can underwrite any of those.
- Key custody is agreed per engagement
- Who holds the signing key (us, you, or a threshold split between both) depends on your compliance requirements and on what the network's own tooling actually supports. We state plainly what each arrangement means for who can sign, and who is responsible if a key is mishandled, before you commit to one.
Tell us what you need
A few details are enough to start. We’ll reply by email once we’ve looked at what you’ve sent.