Coincento managed permissioned blockchain
Introduction
Running enterprise blockchain is a complex task. Beyond deploying the blockchain, organisations need to manage nodes and infrastructure, control network access and cryptographic keys, monitor performance and security and keep the network available and dependable 24/7.
Building and maintaining all of this in-house requires specialised technical expertise and dedicated operational resources. But it can also be outsourced to a specialist third party while retaining the same level of control.
Exactpro’s new division – Coincento – gives regulated financial organisations the infrastructure and operational support to run a permissioned blockchain without handing ownership of the network to a technology vendor.
Coincento is a permissioned Hyperledger Besu network deployed inside your own tenancy and operated for you 24/7.
Coincento architecture
What you get
The network
Upstream Besu, QBFT deterministic finality, topology sized to your fault domains.
Permissioning and keys
Governed allow-lists. Non-exportable keys in your own HSM.
Integration surface
Governed RPC gateway, event streaming, explorer, reconciliation extracts.
24/7 operations
Continuous operational coverage to monitor network health, respond to incidents and coordinate recovery, backed by defined SLAs and escalation procedures.
A private blockchain for regulated institutions
Coincento is a natural fit for regulated financial organisations building or operating permissioned institutional digital-asset, payment or settlement networks that want a network running inside their own cloud tenancy.
-
Uniform shape, few knobs: every client deployment looks alike – same node roles, same consensus, same plugin, same monitoring.
-
Many small segments, not one big pool: a chain deployment is a handful of nodes per network segment.
-
Audit is a first-priority requirement: who deployed what, where and when must be tracked.
Deployment diagram
Your infrastructure, fully transparent and under your control
Client owns everything from day one
Nothing runs on the operator's side; the owner can revoke operator access without stopping block production.
No Kubernetes
Kubernetes adds overhead that cannot be justified for 5–10 pinned nodes. Containers are deployed to VMs by the Coincento GitOps pipeline.
Containers on prebuilt images
Every service ships as a prebuilt, version-pinned image. Deployments are deterministic and declarative: nothing is manually configured on a live machine, so there is no configuration drift.
Configuration lives in Git
Infrastructure, chain parameters and access rules are all versioned files. A deployment is a commit, an approval and a pipeline run – that forms the audit trail.
Validation before deployment
Every change is checked against a schema and a set of forbidden settings on push.
Load balancer + Envoy
Lower cost
A standard load balancer plus small Envoy instances cost less than an application gateway and API management.
More control
Envoy gives us additional benefits: routing on the JSON-RPC payload, chain-aware health checks, per-client rate limits and bounded timeouts.
Security at the edge
OAuth2 authentication and authorisation are enforced on the Envoy gateway.
Clear division of roles
The load balancer only forwards traffic and probes Envoy; Envoy handles everything at the application level.
Stateless and replaceable
Envoy configuration comes from the GitOps pipeline and the TLS certificate from the Key Vault.
No operability vs simplicity tradeoff
Centralised logging
VM and container logs are streamed to a single place: the owner's Log Analytics workspace.
More control
Prometheus + Grafana, with dashboards and alert rules kept in git. Nodes are discovered automatically, so adding one needs no monitoring change.
Security at the edge
Validator signing keys live in a Managed HSM and never leave it; other nodes fetch their identity keys from the Key Vault at startup.
Key ceremony as a framework
Why a framework
A SaaS vendor owns every resource, one ceremony script serves every client. In our model the client owns the Azure subscription and the HSM. So the ceremony has to be fitted to the client rather than the client to the ceremony.
The client performs, we witness
The client's security staff run the ceremony with their own credentials. We tailor the framework into a client-specific script, prepare the participants, and act as witness. Every artefact stays with the client.
What we adapt
Jurisdiction and regulator: evidence requirements, custody for evidence.
HSM type: cloud (our default) or on-premises hardware.
Roles: custodian, security officer, witnesses, etc.
Credentials: smart cards, YubiKey, no passwords.