Enterprise
Permissioned ledger or public chain — how do you choose, once you know you need a shared ledger?
The wrong version of this comparison is ideological. The right version is an operating-cost and settlement-obligation question.
The answer
Choose permissioned when the participant set is known, finite, and each participant has an independent reason to run infrastructure — most enterprise consortia and regulated multi-party systems fit this. Choose public when the value of the system depends on being verifiable by a party who is not, and will never be, a formal participant — a public claim, a consumer-facing credential, or an asset meant to be liquid outside a closed group. This is chain selection, not a values choice, and it should be written down with the alternatives excluded and why.
What a permissioned choice actually buys
Known validators, a governance process for upgrades, and typically a faster, cheaper path to a stated finality window — at the cost of every participant having to trust the permissioning process itself, which is a governance design problem, not a technical one.
What a public choice actually buys
Verifiability by a party outside your control, at the cost of a finality window and a fee market you do not set, and an operating discipline — key ceremony, monitoring, upgrade tracking — that runs against infrastructure your organisation does not operate. This is the right trade only when outside verifiability is the point of the system.
The written output this decision should produce
A chain selection document naming the candidates actually considered, the finality assumption for each, the operating cost modelled, and a recorded reason for every option excluded — the same discipline this practice applies to every architecture engagement, because an unrecorded chain selection is the first thing a later reviewer questions.
Talk to the practice
Tell us what you are trying to build and what has to be true for it to work.
Contact