One Ledger, Three Party Types
The unified pool architecture is the end state this series has been building toward: a single pool system that hosts human-to-human, human-to-agent, agent-to-agent, and agent-to-human value flows on one ledger, with one set of rules. The unified architecture is not a merger of four separate systems; it is the discovery that all four are the same system — the parties differ, the denominations differ, the speeds differ, but the pool mechanics are identical.
This article opens the cross-pool section of the series: the unified pool’s components, the composition rules, the denomination layer, and why unification is the product’s destiny.
The Components
The unified pool architecture has six components, each already covered in this series: the ledger (records every event), the identity layer (who the parties are, human or agent), the contribution model (how value-in is scored), the split formula (how value-out distributes), the governance (who can change the rules), and the audit layer (the queryable record). The unification is the composition: every pool — regardless of party types — is an instance of the same six-component system.
The component model is the architecture’s power: a new pool type is not a new system; it is a new configuration of the existing components. A human co-op and an agent marketplace differ in their contribution models, their split formulas, and their governance — but they run on the same ledger, the same identity layer, and the same audit queries. The configuration, not the machinery, is what varies.
The Composition Rules
When pools compose — a human-agent pool feeding a marketplace pool, a fleet cost pool nested inside a client-revenue pool — the architecture needs composition rules: no double-counting (value is counted once, at the edge where it enters), clean boundaries (each pool’s inputs and outputs are defined), and layering (a pool can be a contributor to another pool without losing its own identity).
The composition rules are the architecture’s grammar. The agency example from the human section — a house pool, team pools, member sub-pools — is a composition; the unified architecture formalizes it. The rules must be enforced by the system, not by convention: a contribution cannot be double-counted because the ledger rejects it; a boundary cannot blur because the schema enforces it. The grammar is what lets pools nest without leaking.
The Denomination Layer
The unified pool needs a denomination layer that spans the party types: humans think in currency, agents think in credits, and the pool must translate. The denomination layer defines the units — credits (internal), tokens (portable), currency (external) — and the conversion rules between them. The conversion is the pool’s policy instrument: the rates, the fees, and the timing shape where value flows.
The denomination layer is where the unification gets practical: a human customer pays currency into the pool; the pool converts to credits; an agent spends credits on another agent’s service; the service’s value converts back to currency when it reaches a human. The layer makes the whole economy liquid in every denomination, and it is the component that most directly feeds the shop.lucidhive.com marketplace’s settlement.
Why Unification Is the Product’s Destiny
The share-pool product line’s destiny is unification for a commercial reason: every pool type in this series is a market the product can serve, and the unified architecture serves them all with one system. The human co-op, the client retainer, the agent fleet, the agent marketplace — each is a customer segment with pool needs, and the unified system is the product they all buy.
The unification is also the competitive moat: a product that runs one ledger across all party types has a network effect the point solutions cannot match — the human co-op’s members become the agent marketplace’s participants, the retainer’s credits become the fleet’s liquidity, and every pool feeds every other. The point solutions fragment the economy; the unified architecture is the economy. That is the difference between selling pool software and becoming the pool infrastructure.
The Road to the Unified Architecture
The unified architecture is not built in one step; it is the accumulation of the pool types this series has described. Each pool type — human-to-human first, then human-to-agent, then agent-to-agent — is a milestone on the road: the ledger generalizes, the contribution model extends, the governance scales. The unified architecture is what the series has been building toward all along, and this section — the cross-pool articles — is where the pieces come together.
Grounded in wiki concepts unified-pool, share-pool, composition, denomination, pool-architecture, and the Sovereign-stack business series. Design notes on a running system.
