From research to production — a blockchain built for enterprise constraints
Larad voting consensus · container-native deployment · dynamic block sizing · REST-API smart contracts
Haidrun needed the guarantees of a blockchain without the properties that make public chains unusable inside a regulated business — public data, unpredictable cost, and throughput at the mercy of someone else’s network. Three of Magnus Mage’s founders led this one personally, from research through development.
Founder-led, research through development
Haidrun set out to build a private, permissioned blockchain for enterprises that had looked at public chains and found them unusable — not because the cryptography was wrong, but because the operating model was. A public chain puts your data where anyone can read it, prices your transactions against strangers’ demand, and gives you throughput you cannot commit to in an SLA. Haidrun’s answer was a platform where participation and visibility are controlled, deployment is container-native, and block sizing adapts to load rather than being fixed at genesis.
This engagement was led personally by three of Magnus Mage’s founders, and it ran the full arc from research through development — protocol and consensus research, the Larad consensus engine, the modular layered architecture, the cluster-chain model and the Layer 1 SDK, plus the container-native platform and the REST integration layer. It predates much of what Magnus Mage does at scale today, and it is where a good deal of the firm’s enterprise-blockchain thinking was formed.
Privacy and auditability, at the same time
The defining tension in enterprise blockchain is that the two things enterprises want most appear to cancel out. They need contents restricted — competitors, counterparties and the public must not read the ledger. They also need full accountability for external audit, which means a regulator or auditor has to be able to verify that the record was never altered. A public chain gives you the second by sacrificing the first. A private database gives you the first and none of the second.
The second constraint was operational. Enterprises commit to service levels, and a chain whose throughput and transaction cost move with someone else’s congestion cannot sit under an SLA. That rules out settling on a public network for anything latency- or cost-sensitive, regardless of how good the cryptography is. The shape of the problem was clear:
And the third was adoption. A blockchain that requires an enterprise to rewrite its existing systems to talk to it does not get deployed — it gets piloted and quietly shelved. Whatever was built had to reach the ledger from the software these organisations already run, without a rewrite. Those three constraints, together, defined the platform.
Delivery and design scope. Haidrun’s platform is not open source, so the architecture below is described at the level the company itself has published.
Research, architecture, and the platform underneath
The work ran from protocol research through to a deployable platform — consensus, the container-native runtime, contract execution and the integration surface enterprises actually touch. Here is how the architecture layers up.
Consensus & protocol engineering
We designed and implemented the consensus mechanism that keeps the network in agreement — block production, validator participation and finality — and the on-chain protocol rules that govern it. On Haidrun that engine is Larad, a voting-based consensus algorithm. In a permissioned network the validator set is known and accountable, which removes the need for the economic deterrents an open network depends on and allows agreement to be reached by vote among identified participants — faster, and without a token economy attached to it.
Node & network infrastructure
We built the node client others run to join the network: the P2P networking layer, transaction propagation, state storage, and the RPC and indexing services applications depend on. The platform is container-native, so a deployment can sit inside an organisation’s existing orchestration rather than demanding bespoke infrastructure. Block sizing is dynamic rather than fixed, so the chain adapts to actual load instead of forcing a throughput ceiling chosen before anyone knew the workload.
Contracts, token & economics
We implemented the token standard and core smart contracts, with secure upgrade paths and full test coverage, plus the incentive design that keeps validators and users aligned. Smart contracts are exposed through standard REST APIs, with integrated AI engines in the execution path. The REST surface is the deliberate choice: it means an existing enterprise application can call the ledger the same way it calls any other internal service.
Wallet, explorer & ecosystem
We delivered the user-facing surface that makes a chain usable: a wallet for holding and moving assets, a block explorer for transparency, and SDKs and APIs so third-party developers can build on the network. The integration layer connects to the systems already in place — enterprise applications, existing databases and other blockchains — so the ledger becomes another participant in the estate rather than a parallel one requiring its own migration project.
How the engagement ran
A disciplined path from first principles to a live network — the same shape we bring to every deep-tech build.
Discovery
Requirements, use cases and constraints — and the honest question of whether a custom chain was the right call at all.
Architecture
Consensus, node, contract and economic design, plus threat modelling, before a line of production code was written.
Build
Consensus, node, contracts and tooling built in short cycles with continuous testing and demoable increments.
Review & testnet
Internal review, automated static and dynamic analysis, and adversarial testing — then a full public testnet under real network conditions.
Launch
Coordinated mainnet deployment, validator onboarding, monitoring and runbooks for a confident go-live.
Support & scale
The platform went to market in May 2021 and the engagement is still running — Haidrun has been continuous with us since 2020.
The hard problems, and how we approached them
Restricted contents, full auditability
Enterprises need the ledger unreadable to outsiders and simultaneously verifiable by auditors. Solve one naively and you lose the other.
Permissioning at the protocol layer
Access control sits in the protocol rather than in an application in front of it, so who may participate and who may read are enforced by the chain itself — while the tamper-evident record underneath stays intact for external audit.
Throughput you can put in an SLA
On a public chain, throughput and transaction cost move with strangers’ demand. An enterprise that has committed to a service level cannot absorb that variance.
Known validators, adaptive blocks
A known, accountable validator set makes voting-based agreement viable, and dynamic block sizing lets capacity follow real load — so performance is a property of the deployment rather than of a public market.
Adoption inside an existing estate
A platform that requires rewriting the systems around it never leaves pilot. The blocker on enterprise blockchain is rarely the cryptography — it is the integration cost.
REST, not a rewrite
Exposing contracts over standard REST APIs meant existing applications and databases could reach the ledger without being rebuilt, and container-native deployment meant it landed in infrastructure teams already knew how to run.
What we built it with
Haidrun’s platform is not open source. The components above are those the company has described publicly; implementation detail is held under the engagement.
What we delivered
This page describes research and engineering delivery. Because the platform is not open source, we describe architecture and scope rather than internal metrics, and we make no claims about Haidrun’s commercial performance.
More deep-tech builds
CreataChain
Layer-1 · EVMTwo public mainnets — a BFT settlement chain and an EVM execution chain — with the consensus engine, SDK and explorers behind them.
Read case study →Libonomy
AI consensus L1A Layer-1 built around an AI-driven consensus engine — Aphelion, a four-pool node architecture and a WASM contract runtime.
Read case study →Planning something similar? Talk to our team.
Tell us what you’re building. We’ll come back within 2–3 business days with a scoping call — no sales runaround, straight to our team.