The mechanics of a permissioned chain split cleanly into who writes and how the writes commit. Both questions have direct legal consequences, and both look arbitrary until you trace them back to a regulatory obligation. Part 2 walks through validator admission and the consensus families that produce deterministic finality, with the legal payoff of each.
2.1 Validator selection
The writer set on a permissioned chain is selected through one of three patterns, and each pulls in a different liability model.
The first is operator-led, where a single legal entity, usually the consortium sponsor, decides who joins the validator set. This is how early Hyperledger Fabric deployments worked and how most of the JPMorgan internal builds started (Hyperledger Fabric). Cheap to set up, easy to govern, but the writer set inherits the credit risk of the operator. If the operator is sanctioned, the chain is sanctioned.
The second is consortium-led, where validator admission is voted on by the existing validator set under a defined quorum rule. Canton Network, R3 Corda networks, and the more mature Fabric consortia look like this (Canton Network, R3 Corda). The legal trick here is that the consortium agreement governs admission, expulsion, and liability, and the chain enforces the consortium agreement rather than substituting for it.
The third is licence-led, the model emerging in regulated tokenisation infrastructure. Validators are not admitted by a vote but by virtue of holding a specific regulatory licence, often a CSD authorisation or a payment institution licence. The set rotates as licences are granted or revoked. This is closer to how settlement systems already work, and it scales better across jurisdictions because the off-chain credential check is something regulators already do. The HKMA's Project Ensemble sandbox sits closest to this pattern, with the central bank operating the wholesale settlement layer and commercial banks credentialled into the asset and deposit layers above it (HKMA Project Ensemble).
Rotation matters because validator sets that never change accumulate technical debt and political capture. A well-designed consortium has a published cadence for reviewing the writer set, ideally annually, with clear performance and conduct criteria.
2.2 Consensus and finality
Permissioned chains overwhelmingly use deterministic Byzantine fault tolerant (BFT) consensus rather than the probabilistic finality you see on public proof-of-work or proof-of-stake chains. The reason is not engineering taste. It is legal.
In a public-chain world, finality is statistical. Your transaction is "very likely" final after some number of confirmations, and you choose how much risk you tolerate. That works fine for a memecoin trade. It does not work for the legal settlement of a bond coupon, where the question "did settlement occur" must have a yes-or-no answer at a specific timestamp, with no chance of rollback. Regulators, custodians, and auditors all need to point to a single moment after which the trade is done. A chain that can reorg, even in theory, fails this requirement. Hyun Song Shin's June 2024 BIS speech is the cleanest articulation of why deterministic settlement matters at the wholesale layer, framing it as a precondition for the unified ledger architecture rather than an optional optimisation.
Deterministic BFT consensus, in the family of practical Byzantine fault tolerance (PBFT), Tendermint, HotStuff, and the various derivatives running under Canton, Fabric, and Corda, gives you exactly this. Once a block is committed, it is final. There is no probabilistic settlement, no waiting for confirmations, no concept of a fork. The trade-off is that you need a known validator set and you can tolerate fewer faulty nodes, which is fine because you knew who the validators were anyway. Throughput per validator is higher than on a public chain at the same security budget, which is also useful, but the dispositive feature is finality, not throughput.
The capital implication is the line every CFO eventually asks about. A bank running on a chain with deterministic finality can book a settled position immediately. A bank waiting for probabilistic finality has to hold capital against the unsettled exposure for the duration of the wait. Over a year of bond settlement volume, the difference between a one-block deterministic commit and a six-block probabilistic wait is real money on the risk-weighted assets line. This is the operational reason institutional tokenisation has converged on deterministic BFT, not a stylistic preference.
There is a related point about liveness that gets less attention. Deterministic BFT protocols halt rather than fork when the validator set loses quorum. From a public-chain perspective, halting feels like a failure. From a settlement-system perspective, halting is the correct behaviour: it surfaces the problem to operators and regulators rather than pretending to make progress on an unresolvable disagreement. Settlement systems already have outage procedures. The chain inherits them.
What this buys the regulator
The combined effect of credentialed validators and deterministic finality is that a regulator can name, at any moment, the set of legal entities responsible for the state of the ledger and the timestamp at which any transaction became unwindable only by court order. That is the regulatory deliverable. It is not what a public chain provides, and it is not what the early Web3 framing of "decentralisation" was optimised for. It is, however, what every institutional tokenisation programme needs to demonstrate before the first real bond settles on chain.
The next part picks up privacy: why permissioned chains cannot copy the public-chain default of universal transparency, and how the four major stacks, Fabric, Canton, Quorum, and Corda, each solve confidentiality in architecturally distinct ways.