[Feedback welcome] BlockSmith for Canton: self-service validator onboarding and lifecycle tooling
Hi Canton community,
I’m Diogo from 57Blocks. We recently submitted the BlockSmith for Canton Development Fund proposal, and we would appreciate feedback from validator operators, Daml developers, and other members of the ecosystem.
We are trying to understand whether the community sees value in this tool.
What is BlockSmith for Canton?
BlockSmith is a self-service CLI designed to help operators onboard and maintain Canton validators across DevNet, TestNet, and MainNet.
It covers validator onboarding, readiness verification, node bring-up, upgrades, rollback, backup and restore, disk reclamation, hardening, diagnostics, re-onboarding, and capacity assessment.
Before making a change, BlockSmith generates a plan for the operator to review. The operator must provide the reviewed plan hash before the CLI can apply it.
BlockSmith works with the official Splice validator_compose artifacts. It does not replace or fork them.
CLI first, assistant optional
The deterministic CLI is the main product. It does not require an AI model, API key, or assistant.
There is also an optional, read-only ask assistant. It can help operators understand the state of their validator and identify the appropriate commands, but it cannot apply plans or modify the node.
We recorded two demonstrations of the current prototype:
Current status
We already have a working prototype running against the 57Blocks DevNet validator.
The proposal would support publishing the project under Apache 2.0, completing the remaining functionality, improving the operator runbooks, and publishing reproducible evidence from DevNet, TestNet, and a MainNet-ready configuration.
The proposal is aligned with two Canton Development Fund RFPs:
RFP 7: Expanded Network Access and Validator Onboarding
RFP 23: Validator and Shared Infrastructure Security and Resilience
We would like your feedback
Would this type of self-service tooling be useful to you or your organization?
Which parts of validator onboarding or maintenance currently cause the most friction?
Would reviewing a plan before allowing the CLI to change the node make you more comfortable using it?
What evidence would you expect before using this type of tool on TestNet or MainNet?
Is the optional assistant useful, or would you mainly use the CLI?
Is there anything important missing from the proposed scope?
If you see value in the proposal, a public comment here or on the proposal PR would help us demonstrate community interest.
We are also looking for a Development Fund Champion. We understand that not everyone is in a position to take that role, but feedback and public support may help the proposal reach someone who can.
Thank you for taking the time to review it. Critical feedback is welcome too. We want to understand where BlockSmith would help and where it would not.