Consensus-Backed Plugin Platform

Hanzo Cloud is one Go binary. Every subsystem — IAM, KMS, ingress, billing, MPC, observability, agents, and the rest — is compiled natively into it and served under a single /v1 surface that maps to hanzoai/openapi. Routing and ingress are themselves native subsystems, so the design point is that the one binary is the front door — not a stack of gateway and ingress tiers layered in front of it. This is already substantially shipped: the unified binary (HIP-0106) collapsed the former per-service fleet into this one process.

What the plugin platform adds is the next step, and it is not a re-layering: the one binary stays one binary. Each native subsystem becomes a placed plugin so that nodes specialize — the same binary runs on every node, but each node runs a dynamic subset of the plugins rather than all of them — with a small consensus control plane deciding where each plugin's write side lives. The goal is that a subsystem author writes almost none of the hard parts — placement, failover, replication, high availability — and inherits them from the platform.

The design rests on one principle: consensus orders decisions, not bytes.

The unit is a plugin

In the proposed model (HIP-0105, In-Process Extension Runtime Standard), a service registers itself with a single call:

// Proposed API (HIP-0105) — not yet available.
func init() {
    cloud.Register("kms", 500, mount)
}

A plugin is the unit the platform places and scales. The cloud binary loads a set of registered plugins; nodes specialize by running a dynamic subset of them rather than every node running everything. That makes the runtime one deployable artifact whose behavior on each node is data — the placement decision — rather than a per-service build.

Existing subsystems — KMS, IAM, ingress, billing, MPC, observability — are already native parts of the one binary today. What they are not yet is independently placed: right now every node that runs cloud runs all of them. The plugin model makes each subsystem a unit the control plane can place, so nodes specialize instead of every node running everything.

Consensus orders decisions, not bytes

The platform splits into two planes that are deliberately kept separate.

Control plane — a small, fixed quorum. Seven voter nodes run a post-quantum BFT consensus engine (the Quasar engine from Lux, with a post-quantum certificate profile), reaching agreement on a five-of-seven Byzantine quorum. Seven is the smallest voter set that tolerates two simultaneous faults ($N \ge 3f+1$, with a $2f+1 = 5$ quorum at $f = 2$). Its replicated log orders only tiny metadata:

• cluster membership,
• the placement map — which node holds the writer for each (plugin, shard), and its followers,
• writer leases with fencing epochs, so there is exactly one writer per shard per epoch.

Data plane — reuse what exists. The bytes do not go through consensus. The data plane reuses the existing streaming replication (HIP-0107) that already backs the platform's storage — the S3 / ZapDB log-ship. The only change is the write fence: instead of asking "do I hold a Kubernetes lease?", a writer asks "does the control plane grant this shard's lease at the current epoch?"

The consequence is the important part:

Scaling to N nodes

Dynamic scaling lives in the data plane, not the voter set. The two planes are sized by different rules, on purpose:

• 7 voters run the control plane, agreeing on a five-of-seven quorum. This set is small and fixed by design — BFT agreement cost grows with the number of voters (quadratic message complexity), so a fixed small quorum keeps decision latency constant no matter how large the fleet becomes. Seven is a fault-tolerance parameter (tolerates $f = 2$ at $N \ge 3f+1$), not a capacity ceiling; you don't add voters to handle more load.
• N data nodes host plugin shards, serve or proxy requests, and each follow a read-only copy of the placement map. They carry no consensus weight, so N grows without bound — this is where planet-scale happens.

So the fleet scales freely: you add data nodes, split plugins into per-tenant shards, and move writers — all dynamically, all in the data plane. The voter set stays fixed because it orders decisions, not bytes, and decisions are tiny. Changing the voter count (say, to tolerate more faults) is a deliberate, consensus-ordered reconfiguration, not an automatic response to load.

Within that topology:

• Pinned writers — each shard has one writer node, assigned by the placement map, so writes have a single owner and never conflict.
• Per-connection pinning — a client's connection is routed to the node that currently owns the shard it is talking to, so reads and writes land on the right replica.
• Per-tenant sharding — the write side can be split by tenant, down to a (plugin, org) shard, so a single busy organization gets its own writer. Fine per-tenant sharding is a later stage of the proposal; the earlier stages run one writer per plugin.

ZAP-native, easy plugin authoring

The payoff is the developer experience. Under HIP-0105 and HIP-0114, a plugin author implements one small interface and calls cloud.Register. In return the platform supplies placement, per-tenant scale, replication, per-connection pinning, and high availability — none of which the author writes.

// Proposed authoring model (HIP-0105 / HIP-0125) — illustrative, not yet available.
// The author writes the handler; the platform supplies placement + replication + HA.
func mount(deps cloud.Deps) http.Handler {
    db := deps.OpenShard("kms")     // the placement-assigned shard for this node
    return newHandler(db)           // ...just serve requests
}

func init() { cloud.Register("kms", 500, mount) }

The default wire is ZAP (Zero-Copy App Proto, HIP-0114) — the same high-performance, post-quantum transport documented in the ZAP section. Every plugin registered through cloud.Register speaks ZAP with no extra work, so cross-plugin and inter-node calls get zero-copy performance by default rather than as an opt-in.

Where this is specified

The plugin platform is defined across a set of Hanzo Improvement Proposals. Statuses are as of writing and may change — track them at hips.hanzo.ai and github.com/hanzoai/hips.

Next Steps