Nondominium v0.2: hREA as the Economic Substrate

Type: Release Plan Created: 2026-08-21 Status: Draft, not yet a GitHub milestone Relates to: Integration Strategy, Strategic Roadmap, ValueFlows 1.0 Compliance, NDO Prima Materia

1. Thesis

v0.1.0 ships the peer mesh: Lobby, per-group Group DHTs, per-NDO Layer 0 cells. Its economic vocabulary is Nondominium's own, defined in zome_resource and zome_gouvernance.

v0.2 replaces that vocabulary with hREA's wherever ValueFlows already has the concept, and expresses everything else through hREA's module interface rather than through parallel entry types. The outcome we want is one economic substrate, not two that need reconciling.

This depends on work that does not exist yet: hREA has no module interface. Building it is the hREA-side prerequisite, planned as hREA v0.2 and proposed in the issue drafted alongside this document. Nondominium v0.2 cannot start until that lands.

2. Where the integration stands today

Verified against the working tree on 2026-08-21.

The bridge deliberately mirrors ReaAgent locally rather than taking a Cargo dependency on the hREA workspace. That choice is worth revisiting in v0.2: a shared types crate is the alternative, and the module interface may make it unnecessary.

3. Preconditions

v0.2 does not begin until all four hold.

1. v0.1.0 is released. Milestone v0.1.0 peer-mesh closed, .webhapp produced and smoke-tested (#121, #123).
2. hREA v0.2 ships a module interface. The design fork (compile-time composition versus runtime attachment) is resolved and implemented upstream. Proposed as an RFC issue on h-REA/hREA, positioned as the design question that follows #408.

2b. #408's slices land and the submodule pin moves. Claim, EconomicEvent.effortQuantity, the Holochain 0.6.1 bump and the integrity validation hardening all reach main-0.6 in reviewable pieces. As of this writing (2026-09-10) #408 is still open on feat/vf-proposal-purpose, explicitly staged as a branch to cut smaller PRs from rather than to merge whole. main-0.6 itself has not moved past fc3b5e78, the commit this repo's vendor/hrea submodule is already pinned to. What has changed is that the VF 1.0 surface this precondition is waiting on now exists and has been run: see the correction to precondition 3 below. 3. The Holochain 0.7 upgrade is unblocked in principle, not yet in practice. hREA happ-0.5.0-beta is about to land, built on feat/vf-proposal-purpose and on Holochain 0.7 (hdk 0.7.0 / hdi 0.8.0), with the zomes building clean, Sweettest 10/10 and the GraphQL acceptance battery 65/65 verified against a live 0.7 conductor with @holochain/client 0.21. That resolves the version-parity half of #134: hREA now runs on the same Holochain minor version Nondominium's chore/holochain-0.7 branch targets. It does not by itself resolve #134, because of the submodule mismatch below. 4. The two P0 ValueFlows gaps are closed or consciously deferred. See section 6.

4. Migration in two phases

Phase A: native ValueFlows concepts

Concepts where ValueFlows already has the class and hREA already has the entry type. These are straight substitutions: Nondominium stops defining the type and starts calling hREA.

Our action vocabulary is the sharpest test of the whole plan, and hREA PR #408 has already changed the answer. Nondominium defines 16 VfAction variants. Fourteen map onto hREA's canonical set once #408 lands, including TransferCustody, which becomes the builtin transfer-custody. The remaining two, InitialTransfer and AccessForUse, do not exist in ValueFlows.

On main-0.6 this did not matter: rea_action is an unvalidated String, so any verb could be written. #408 adds VF_BUILTIN_ACTIONS (21 ids) and vf_validate_action to the integrity zome, which returns Invalid for anything outside that set on EconomicEvent, Commitment, Intent and Claim. After #408, those two actions are rejected at DHT validation.

That is correct behaviour for a VF 1.0 compliant hREA, and it is precisely why the module interface has to exist before Phase A can complete. These two actions are the smallest end-to-end test case for the RFC, and they are named as such in it.

Phase B: concepts with no ValueFlows class

Expressed through the module interface once it exists. Each of these is a candidate module, and the order below is deliberate: smallest first, so the interface is tested before governance bends it.

Never migrates

PrivateParticipationClaim (the PPR system) stays as Nondominium private entries permanently. PPRs are user-sovereign, bilaterally signed, and stored on the owning agent's source chain. Putting them in a shared economic DNA would defeat their purpose. What can cross the boundary is attribution: a ReputationSummary derived locally and referenced from hREA, never the claims themselves.

The same holds for PrivatePersonData, PrivateDataCapabilityMetadata, RevokedGrantMarker, FilteredPrivateData, Device and AgentPersonRelationship. These are identity and privacy machinery with no economic face.

5. Sequencing

v0.1.0 ships
   │
   ├─ hREA v0.2: module interface designed, RFC'd, implemented, released
   │     └─ Nondominium contributes the first consumer and the acceptance tests
   │
   ├─ Holochain 0.7 upgrade on both sides (#134)
   │
   └─ Nondominium v0.2
         ├─ Phase A: native VF substitution (spec, resource, event, commitment)
         │     └─ Gate: dual-read parity tests green before any native type is removed
         ├─ Phase B1: `source` module (smallest real test of the interface)
         ├─ Phase B2: `nondominium-identity` module
         ├─ Phase B3: `governance` module
         └─ Phase B4: `federation` module

Phase A must be reversible. Following the dual-read pattern already described in integration-strategy.md section "Migration Strategy", every migrated read path returns from both stores and compares before the native type is deprecated.

6. Open questions and risks

The two P0 hREA gaps are addressed on #408 and now verified running, but not yet released. On the pinned main-0.6 submodule, vf:Claim has no entry type in dnas/hrea/zomes/integrity/hrea/src/lib.rs and effort_quantity exists on ReaCommitment, ReaIntent and ReaRecipeFlow but not on ReaEconomicEvent. PR #408 (feat/vf-proposal-purpose) adds both, along with SpatialThing, AgreementBundle, EconomicEvent.reciprocalRealizationOf and .settles, Commitment.reciprocalClauseOf, ResourceSpecification.substitutable and .mediumOfExchange, and Proposal.purpose with immutability enforced on update. It also replaces the permissive validation stubs with real DHT-wide checks (temporal consistency, quantity non-negativity, action validity, required-field presence) across every entry type the PR touches, per its own description. That PR is explicitly a staging branch, not to be merged as-is: smaller targeted PRs are to be cut from it. Genuinely still absent, on this branch and in hREA generally: BatchLotRecord (the PR removes the old ProductBatch and tracks BatchLotRecord as a named follow-up, not yet implemented) and ProposalList with listedIn. Nondominium's Claim and its work-event recording depend on these slices landing and on the submodule pin moving forward, which is a bigger step than it looks (see the fork and pin risk below).

The submodule points at a fork, and the fork's own 0.7 port is not on the release lineage. .gitmodules:1-4 pins vendor/hrea at git@github.com:Sensorica/hREA.git branch main-0.6, not at h-REA/hREA where PR #408 will eventually land as tagged releases. Verified by walking the actual commit graph: this repo's chore/holochain-0.7 branch pins the submodule at 8735ca07 (chore(deps): port hREA zomes to hdk 0.7 / hdi 0.8, Sensorica fork only). 8735ca07's direct parent is fc3b5e78, and fc3b5e78 is an ancestor of upstream h-REA/hREA's main-0.6, sprout and feat/vf-proposal-purpose branches, but 8735ca07 itself is not reachable from any upstream branch (git branch -a --contains 8735ca07 returns only origin/chore/holochain-0.7). That means whatever Sweettest count is currently green on Nondominium's 0.7 branch was measured against a submodule commit that predates hREA's entire VF 1.0 surface: no Claim, no SpatialThing, no AgreementBundle, none of the new validation. Moving the submodule pin to track feat/vf-proposal-purpose (or whatever tag happ-0.5.0-beta lands as) changes the hREA DNA hash and turns on validation those tests have never run against. Re-running the full test suite after the move, not just re-pinning and trusting the old green, is part of the work #134 still requires.

One consumer is a weak basis for a framework. If Nondominium is the only user of the module interface, we will build an interface shaped exactly like Nondominium. R&O and CFN are the plausible second and third consumers; whether they are actually available to review the design changes how much upfront generality is justified.

Capacity. Nondominium is built by two unpaid part-time contributors, and hREA maintenance runs alongside. v0.2 is the larger of the two efforts and it sits behind an upstream dependency we also have to build. The realistic risk is not slow delivery, it is starting Phase B before Phase A is stable.

A module interface may change the hREA DNA hash. If the resolution is compile-time composition, every distinct module set produces a distinct network. Nondominium would run its own hREA build rather than joining a shared hREA network. That is acceptable for our topology (we already clone per group and per NDO) but it must be a decision, not a discovery.

7. Success criteria

v0.2 is done when all of these are demonstrably true, each falsifiable by a test or an inspection.

1. No entry type in zome_resource or zome_gouvernance duplicates a concept hREA already implements.
2. Every economic read path in the UI resolves through hREA, verified by removing the native fallback and watching tests stay green.
3. The three Nondominium actions are registered through the module interface, not written as unvalidated strings.
4. At least one module (source) is proven portable: a second hApp can enable it without importing Nondominium.
5. PPR entries remain private entries on the owning agent's chain, verified by a test asserting a counterparty cannot read them.
6. The dual-read parity suite passes for every Phase A type before that type's native definition is deleted.

8. Not in scope for v0.2

• Unyt and Flowsta integrations. Both remain post-MVP and neither should shape the module interface.
• Layers 1 and 2 activation beyond what the modules above require.
• The collective agent ontology (AgentContext, AgentEntityType). It touches hREA's ReaAgent and deserves its own release.