Consensus designed as an AI system, engineered from the ground up
Aphelion consensus engine · four specialised node pools · WASM contract runtime · Go, Rust, C
Libonomy set out to make consensus itself AI-driven, and to interoperate on-chain with proof-of-work, proof-of-stake, delegated proof-of-stake and BFT networks rather than bridging to each one separately. We engineered the protocol layer and the system around it.
An AI engine inside the consensus path
Libonomy’s premise was that consensus should not be a fixed rule set but an adaptive one — a network that observes its own conditions and allocates work accordingly. That produced Aphelion: a consensus engine in which nodes are sorted into four specialised pools rather than one undifferentiated validator set. A power pool verifies transactions, an exploit-finding pool watches for adversarial behaviour, an audit pool enforces the rules, and a maintenance pool keeps the system healthy. The second half of the premise was interoperability at the protocol level rather than the bridge level: one hub speaking to proof-of-work, proof-of-stake, delegated proof-of-stake and BFT networks directly.
Magnus Mage was responsible for the protocol engineering: the Aphelion consensus implementation and its staking logic, full and light node clients, the libp2p-based peer-to-peer layer, the WASM smart-contract runtime built on Wasmer, the CUSP SDK and CLI, cryptographic primitives including ed25519 and secp256k1 signing, Ledger hardware-wallet support, a Bitcoin transaction relayer for sidechains, and the block explorer. We worked as an embedded engineering team across architecture and build.
Making an adaptive system behave deterministically
Putting intelligence inside a consensus path runs straight into the property consensus depends on. Every node must reach byte-identical agreement on the same input, every time — and inference is, by default, the opposite of that. Anything adaptive sitting on the critical path has to be constrained so tightly that its output is reproducible across every machine on the network, or it cannot be in the critical path at all. That constraint, not the modelling, is the engineering problem.
The second constraint was interoperability at the protocol layer. Bridging to one chain is a known problem; speaking to four different consensus families — proof-of-work, proof-of-stake, delegated proof-of-stake and BFT — means handling four different finality models, four different reorganisation risks, and four different definitions of when a transaction is safe to act on. The shape of the problem was clear:
Beyond the protocol, the surrounding system still had to exist: node clients others could run, a peer-to-peer layer that held up under churn, a contract runtime, key management safe enough for hardware wallets, and an explorer. A novel consensus design with none of that around it is a paper, not a network. That end-to-end scope was the real challenge.
Delivery scope, not network activity. Every item above is a component we designed and built.
One team, the whole protocol
We engineered Libonomy as a single system — from the consensus engine and node clients up through the contract runtime and the tooling teams need to use any of it. 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 Libonomy that engine is Aphelion, written in Go. Rather than one undifferentiated validator set, nodes are sorted into four specialised pools — power, exploit-finding, audit and maintenance — each with a distinct responsibility, with the staking module governing entry and rewards.
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. We built both a full node and a light node in Go, over a libp2p-based peer-to-peer layer with a network simulator for testing behaviour under churn. Storage sits on LevelDB, with SIMD-accelerated SHA-256 and hardened ed25519 and secp256k1 packages underneath.
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 execute in a WebAssembly runtime built on Wasmer, in Rust — chosen over an EVM-compatible path so contract authors are not restricted to Solidity. The staking module handles bonding, rewards and pool membership.
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. We shipped a wallet suite across desktop, web and mobile, a one-click contract wizard, a mining console, a dApp browser, LiboDEX and Libo Swap, plus the CUSP SDK and daemon in Go, Ledger hardware-wallet support written in C, a Bitcoin transaction relayer for sidechains and the block explorer.
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
Handover of a protocol the client’s own team can operate and extend — documented node clients, an SDK others can build against, and published source rather than a black box.
The hard problems, and how we approached them
Determinism vs. adaptivity
Anything adaptive in the consensus path must still produce byte-identical results on every node, or the network forks. The tension is structural, not a tuning problem.
Adaptive logic, deterministic output
We kept the adaptive component off the critical agreement path and constrained its outputs to a bounded, reproducible set, so node assignment could respond to network conditions while the agreement itself stayed deterministic and verifiable.
Four consensus families, one hub
Interoperating with proof-of-work, proof-of-stake, delegated proof-of-stake and BFT networks means four finality models and four different answers to when a transaction is actually safe to act on. Treating them identically is how bridges get drained.
Finality modelled per chain
We modelled confirmation and reorganisation risk separately for each consensus family rather than assuming a single confirmation depth, and built the relayer to hold a per-chain view of when a transaction is safe to act on.
Operability from day one
A novel consensus design is only adoptable if the surrounding pieces exist. Without node clients others can run, a contract runtime, key management safe enough for hardware wallets and an explorer, the protocol stays a paper.
Tooling, monitoring & docs
We delivered full and light node clients, the WASM contract runtime, the CUSP SDK and CLI, Ledger hardware-wallet support, a JavaScript signing library and the explorer — so the protocol was usable, inspectable and buildable-on rather than theoretical.
What we built it with
The stack as delivered, confirmed against the project’s published source.
What we delivered
This page describes engineering delivery. We make no claims here about the network’s adoption, market or current operation — only about what was designed and built, which is verifiable in the project’s published source.
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 →Haidrun
Enterprise blockchainA private, permissioned enterprise blockchain — chain-level guarantees without exposing operations on a public network.
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.