Why a project stalls at the blockchain selection stage
The team gets stuck between two scenarios: a public network with an open set of validators and a closed perimeter under company control. The first promises transparency and external audit of operations, the second — predictability and strict limitation of data access.
The decision is postponed, the pilot is launched on the public network, and after a couple of weeks it turns out that part of the registry contains information that cannot be taken outside the perimeter.
Then architecture rework goes in circles: the access model, signer roles, and key storage scheme change, followed by contracts being rewritten and integration with the accounting system reassembled.
The registry state has to be migrated, and agreed-upon checks reassembled for the new scheme. By the third iteration, the protracted pilot stops proving anything: the team discusses not the business logic but how to avoid rewriting again what already works.
The root of the problem is that decisions are made piecemeal, without network selection criteria.
Choosing a blockchain for a project is not comparing a list of platforms but answering specific questions: who validates and signs records, where personal data physically resides, who pays for transactions and how, how long the rollback of an erroneous record lives, what happens when the node provider changes.
Until these points are agreed upon, the risks of a wrong scheme manifest later and cost more — already at the implementation stage, when rework affects working processes. Below we break down how this is addressed.
What a justified blockchain choice gives a project
Choosing a blockchain is an engineering decision with a cost of error: an unsuitable network manifests not on a test bench but at peak load, when rewriting accounting contracts is already too late.
The survey captures the system profile: how many operations arrive at peak, what finality the business logic needs, which data may be taken into the public registry and which remain in the closed perimeter.
The output is not advice to take a “fashionable network” but requirements against which the platform is selected and verified.
The effect of the survey is saved time to market. Before the first line of code, it is clear where the accounting model will hit limitations, how the fee for computation and state storage is structured, and how many nodes are needed for the declared level of fault tolerance.
Contested points are resolved on the diagram, not after launch, when changing the network means data migration and reworking integrations.
Growth in the number of participants no longer means rewriting the core. The network is selected with headroom in throughput and a clear scaling path — by adding nodes, channels, or a second layer — so contracts and external integrations remain the same.
The headroom is confirmed by load scenarios. For public verifiability, a mature open network is taken, for example Ethereum; for the closed perimeter, a private or consortium one.
A separate outcome is an eliminated class of failures: a single network access node, a single signing key, no backup route when a counterparty is unavailable. This is removed by the scheme — duplicate access nodes, multisignature, contract versioning, and a practiced rollback.
Total cost of ownership decreases structurally: infrastructure expenses grow with the number of participants, not with the number of manual operations and registry reconciliations.
Comparison of options: public network, closed perimeter, hybrid
Choosing a blockchain is not “which engine is more popular” but an answer to three questions: who sees the data, who confirms transactions, and who is responsible for access.
From this follow the cost of writing, finality speed, and the ability to verify history independently of the vendor.
Technical alternatives
| Option | When it fits | Limitations |
|---|---|---|
| Public network | External verifiability: history is open, anyone can verify a transaction | Data is irreversibly public, writing depends on network load and fees, rollback is impossible |
| Consortium network | Several organizations share a registry but do not trust each other unilaterally | The validator set and voting rules must be agreed; a participant's exit breaks the quorum |
| Closed perimeter | Data does not leave the perimeter: accounting, document flow, settlements between divisions | Privacy rests on trust in the operator, not on cryptography; nodes and updates are on us |
| Hybrid scheme | Traces and attestations are public, amounts and personal data are closed | Two perimeters must be synchronized; the bridge between them becomes a point of failure |
| Ready-made industry solution | A typical task and tight deadlines: a working perimeter is needed | The vendor defines the logic and access model; modifications are limited by its interfaces |
We count not “fashionability” but compatibility: how the option interfaces with current systems, what happens to accumulated state when the perimeter is changed, and how labor-intensive exiting the solution is.
We record the limitations of the options in writing before the start — changing the access model later means migration and a repeated audit of contracts.
Work stages: from requirements elicitation to handing over the schemes
The order of stages here is not a formality: each next step relies on an artifact from the previous one. Until requirements are fixed, the data scheme is doomed to rework, and configured nodes have nothing to verify them against. Below is the sequence followed by blockchain selection consulting.
-
Requirements audit. We analyze what the project writes to the network, what it reads from it, and who initiates operations. We fix the load profile — peak frequency, allowable confirmation delay, history storage depth.
The output is a list of requirements by which networks are comparable to each other, rather than “like or dislike.”
-
Data and role scheme. We lay out entities by levels: what lives in the network, what in external storage, what is computed on the service side. We define roles — who issues assets, who confirms operations, who has administrative rights, and how they are transferred.
-
Network selection. We compare consensus models, write predictability, maturity of development tools, and maintenance cost. Separately, we look at how ready the network is for a private perimeter or hybrid scheme.
-
Node setup. We bring up full, archive, or light nodes — according to the need for history and query response speed. We configure replication, availability monitoring, and a backup perimeter.
-
Load and failure testing. We run scenarios at peak operation volume and deliberately break components: node unavailability, version mismatch, transaction rollback. We look at where states diverge and how fast recovery is.
-
Documentation handover. We hand over flow and role schemes, the contract registry, instructions for deployment, updates, and recovery from backups. The customer's team can operate the perimeter without us.
If during the audit it turns out that the task can be solved without blockchain — we say so directly at the second stage.
Documentation set: network schemes, access policies, regulations
Choosing a platform without documentation leaves the project dependent on specific people rather than processes.
We hand the set over to the customer's repository together with the source code: it is enough for a new team or contractor to enter the project without retellings and restore the logic of decisions from facts, not from participants' memory.
- Network scheme — node topology: who validates operations, who works read-only, where trust boundaries run, and what happens when a node drops out.
- Role model — actors: contract owner, operator, auditor, service account — and what each is allowed and forbidden to do.
- Access policies — permission separation at the level of contracts and individual methods, confirmation thresholds for critical operations, key lifetime and rotation procedure.
- Operations regulations — contract update procedure, who initiates a change, how the result is verified, how a node is added and removed.
- Team instructions — deployment of a local bench, test runs, release, scenarios for typical support requests.
- Architecture decision log — why this network and this consensus model were chosen, which options were rejected and by what criteria.
- Rollback plan — state save points, procedure for returning to the previous contract version, and conditions under which rollback is triggered.
Case: eliminated data desynchronization between participants
An industrial manufacturer and a network of nine suppliers conducted procurement in four systems: the customer's accounting system, two databases of key counterparties, and a shared approvals file.
Each side considered its own state correct, and discrepancies were discovered at acceptance, when it was already too late to change anything.
Where desynchronization arose
An order line could be changed at the customer after the supplier had confirmed it on their side, and there was no way to determine which version was current.
Reconciliation was done manually once a month: two engineers and a procurement specialist compared exports line by line, it took up to two working days, and disputed lines were closed by calls and letters.
What was changed
First, options were compared by privacy, operation cost, and counterparties' readiness to run nodes; then a single order registry was assembled in a closed network based on Ethereum.
Each side has its own node, a change is recorded by signature, and the line state exists in a single instance. Rights were separated by role: the supplier confirms shipment, the customer — acceptance, one line cannot be closed twice.
What happened
Reconciliation came down to exporting a report — instead of two days, about fifteen minutes; the share of discrepancies by line fell from 9% to less than 1%.
Repeated approvals of one order decreased fourfold, and the change history is restored from signatures without correspondence. The scheme was transferred to a second perimeter: new participants connect as nodes, without rebuilding accounting processes.
How does a consortium network differ from a closed perimeter?
A consortium network is a shared registry maintained by several independent organizations, and participant management here is collective.
A new organization is admitted by agreement with the others; write rights are granted by roles at the node level, not by a single administrator's decision.
In a closed perimeter, there is one owner: they themselves add and remove participants, decide who sees what, and do not coordinate access with anyone.
Changing network rules is the main difference.
In a consortium, new logic (field composition, writing scheme, confirmation threshold) takes effect only after the majority of participants bring it up: as long as at least one node remains on the old version, the network is forced to maintain compatibility with it.
In a closed perimeter, the owner releases the version and rolls it out on their own schedule — there is no coordination, but there is also no external verification of their decisions.
Trust boundaries are arranged differently as well. In a consortium, no participant can rewrite history or conduct a significant operation alone — a signature threshold is needed, so trust is distributed among organizations, but the risk of their collusion appears.
In a closed perimeter, trust is entirely in the operator: they see everything, and their actions cannot be challenged from within.
For the data model, this means the following.
In a consortium, shared reference data and write rights are divided among participants, and sensitive fields are moved into private channels accessible only to the counterparties of the transaction; the scheme is changed rarely and backward-compatibly, because each participant updates at its own pace.
In a closed perimeter, the scheme belongs to one owner and changes faster, but each change cuts off those who remain on the previous version.
Doubts about integration, access, and scaling
Accounting systems remain the source of truth for reference data, balances, and counterparties, so the blockchain connects to them as a receiver of confirmed events, not as a replacement.
Exchange goes through an intermediate layer: it checks idempotency by the record's business key, so a repeated export run does not create duplicates, and discrepancy is visible by checksums.
How to differentiate participant rights?
Rights are set at two levels: network roles determine who invites nodes and confirms blocks, and action rules — who signs specific operations and reads the closed data perimeter.
In corporate networks on Hyperledger Fabric, this is laid out by channels, so a counterparty sees only its own transactions, not the shared registry.
What happens when operation volume grows?
Throughput does not grow “head-on”: some checks move to the client side, and reports are calculated using indexes outside the registry rather than by iterating through history.
Confirming nodes maintain consensus, reading nodes serve requests — with planned growth, a node is added and load is redistributed without stopping the network.
What happens if an individual node fails?
More confirming nodes are provisioned than the minimum needed for a quorum, and they are distributed across different sites. The loss of one slows writing but does not stop it; a node returned to service catches up on history from the registry.
Can data be migrated to another network?
Yes, if the record structure and access rules are described in advance. We fix the format of events and exports, so history can be migrated or exported to the accounting system — without parsing closed snapshots.
Let's discuss the task and come back with an estimate and work plan
To discuss the task substantively, a few inputs are enough for us: what exactly goes into the distributed registry, who holds the keys and signs operations, what requirements exist for confirmation speed and operation cost during peak hours, whether there are external requirements for data audit, and who on your side makes the final decision.
These points determine a short list of networks — without them, comparison turns into an enumeration of names.
In response, we send a package that can be used to make a decision:
- Project estimate: scope by perimeter — registry, smart contracts, integrations with accounting systems, assumptions and risks that change this estimate.
- Composition of stages with boundaries: what we implement in the network, what we deliberately leave outside it.
- Work plan and start order: what we start with, what runs in parallel, where the checkpoints are.
- Verification scheme: a trial network perimeter, running target scenarios, testing operation rollback and registry state recovery.
- Selection criteria: throughput, operation cost, access models, maturity of deployment and observability tools.
- Operating model: contract updates, key rotation, node access.
- Open questions: decisions needed from you before the start.
The decision is made in three steps: we check the inputs, agree on criteria and stage composition, and fix the selected network — after that, the start order does not change without revising the estimate.