The Internet of Value
Who can vouch for the work?
By Moses Sam Paul 2026-11-07
Who authored a record? Does it follow the rules? Who can attest to the work? Holochain and The Internet of Value, examined through one actual Foundation session.

Quick answer
Holochain supplies infrastructure for agent-owned records and shared application rules. The Internet of Value specifies responsibilities for activity capture, human context, community recognition and Wellbeing Identity. An application could use the former to implement parts of the latter, but that compatibility is a proposal here, not a delivered integration. Neither a valid signature nor a reproducible calculation establishes the quality, benefit or agreed price of work by itself. [1] [6] [11] [16]
We use my already-disclosed three-hour Foundation session. Its arithmetic can be reproduced; no Holochain deployment, agent key, operation, validation receipt or independent work attestation is supplied in the selected case. [9] [10]
What does Holochain stand for?
Holochain is a framework for peer-to-peer applications. Its official account emphasizes individual agency alongside shared rules: participants run applications, author their own records and help maintain shared data. It provides infrastructure on which an economic application can be built; this comparison does not treat the framework as a single currency or one prescribed valuation formula. [1] [5]
A source chain is the participant’s append-only journal. Records contain an action and, for some action types, an entry. Hash links and cryptographic signatures support authorship and tamper detection. A distributed hash table, or DHT, distributes shared data among peers who validate and hold it. A private source chain alone is not the whole network integrity story. [2] [3]
Applications define their data types and validation rules in integrity zomes. Other application functions live in coordinator zomes. Integrity code and modifiers determine the DNA hash identifying a network; coordinators can change without changing that hash. The infrastructure gives a community somewhere to encode its rules—it does not decide that my Foundation rate should be USD 750/hour. [5] [10]
Start with Holochain’s explanation →Explore source chains →Explore the DHT →
What does The Internet of Value do?
The Internet of Value connects bounded activity, private human context, applicable community validation and a consent-governed Wellbeing Identity. The four protocols distinguish those responsibilities; a recorded activity does not automatically establish a causal wellbeing benefit. [11] [12] [13] [14]
- Capture:
~ValueCaptureProtocolrecords time, attribution, evidence and lineage. [11] - Interpret:
~WellbecomingProtocolsupplies private human context and routes eligible Performance contributions toward community validation. [12] - Validate:
~SAOcommonssupplies the community institution layer when applicable, including recognition and valuation. [13] - Reflect:
~WellbeingIdentitycarries a living, selectively disclosed state—not merely a public score. [14]

Below, W, Vcom and VCperformance refer to one named founder implementation and historical event. They do not define a universal survey scale, a national index or a rule that every community must adopt. [15] [16]
The real Foundation contribution
On 31 July 2026, 09:30–12:30 IST, I recorded Foundation mathematics and Performance calculation infrastructure work, including community skill-approval dependencies. The event routes through Performance → OrgBuilding → Internet of Value Research Foundation, with native skill level SM3. Its duration is 180 minutes = 3 hours. This is the previously disclosed author-provided account, not a new intervention study. [9] [10]
The description mentions deployment/testing, but the selected proof field has no linked artifact. Reviews are founder self-review, not independent assessment. Neither work quality nor benefit to another person is established by an arithmetic reproduction. [9]
The reference rate is USD 750/hour, Moses-only, self-ratified policy 1.0.0. Self-ratification occurred at 12:34:42 IST and recording at 14:38:30, after the session ended at 12:30; reviews followed on 2 August. The selected evidence does not establish advance buyer agreement, and that gap does not prove no earlier agreement existed. The event is non_payable. [9] [10]
The public calculation artifact lets a reader inspect the disclosed inputs and reproduce the result. It does not contain an ONS life-satisfaction response, a beneficiary survey or a causal effect estimate for this session. [10]
The calculation we can actually reproduce
The selected version is founder-wellbeing-v0.1.1-fixed12. round12 means half-even rounding to 12 decimal places after each governed step. We independently reproduce this selected event’s arithmetic; additional decimal places do not establish measurement accuracy or empirical model validity. [10]
rate = 750 USD/hour
Wbefore = Wafter = 771.095689848427 WellbeingScore units
Vcom_event = round12(3 × 750)
= 2250.000000000000 USD
q = round12(Wbefore / 1000)
= 0.771095689848 (dimensionless)
VCperformance_event = round12(q × Vcom_event)
= 1734.965302158000 USD
ΔW = Wafter − Wbefore = 0 WellbeingScore units
Vcom is the duration-expanded policy valuation. VCperformance applies a pre-event wellbeing multiplier and retains this implementation’s USD reference unit. It is not a payment, a market price or a measure of someone’s worth. The recorded no_transition and zero W movement do not prove the session had no subjective effect. [10] [16]
The multiplier uses pre-event context, not the outcome of a Holochain validation. With a fixed positive Vcom, lower Wbefore lowers VCperformance while Vcom stays unchanged. This operation does not establish lower work quality or deserved pay. [10] [16]
Two kinds of validation, one real evidence gap
In Holochain, an operation is checked against system and application rules. That can include references, permissions and permitted state changes. In the Foundation case, “validation” also raises institutional questions: who is eligible to assess the contribution, which policy applies, and what evidence they considered. These can be connected by application design; they should not be silently equated. [6] [7] [13] [16]
Consider the missing proof link in my session. Software can require a field, authenticate its author and check a referenced attestation under specified rules. It cannot recover an absent work artifact or turn my self-review into an independent review merely by replicating the record. This is our interpretation of the documented mechanisms and the disclosed evidence boundary. [2] [7] [9]
| Question about this session | What the selected evidence establishes | What remains open |
|---|---|---|
| What was recorded? | A three-hour Foundation research/modeling account, with historical inputs. <a href="#i1">[9]</a> <a href="#i2">[10]</a> | A linked deployed-work artifact and independent assessment. |
| Who authored a Holochain operation? | No Holochain operation or agent key is supplied. <a href="#i1">[9]</a> <a href="#i2">[10]</a> | A real author-key binding, encoded action and signature verification. <a href="#h2">[2]</a> |
| Does that operation obey an application’s rules? | The selected case is not a Holochain validation run. <a href="#i1">[9]</a> <a href="#i2">[10]</a> | The DNA, operation, required dependencies and actual validation result. <a href="#h6">[6]</a> <a href="#h7">[7]</a> |
| Is the founder arithmetic reproducible? | Yes, for the disclosed inputs and fixed12 version below. <a href="#i2">[10]</a> | Input legitimacy, empirical model validity and work quality are separate questions. <a href="#i8">[16]</a> |
| Was an independent community decision made? | The disclosed reviews are founder self-review. <a href="#i1">[9]</a> | An eligible independent attestation, with its scope and evidence. |
| Does recognition create payment? | This event is non_payable. <a href="#i2">[10]</a> | An accepted obligation and settlement arrangement; no such outcome is inferred. <a href="#i8">[16]</a> |
Holochain’s math checks a different kind of object
The following is our schematic notation for documented hash-link and validation concepts. It is not Holochain’s byte encoding, a complete security model or executable adapter code. Let e be a chosen entry, aₙ an action and H a cryptographic hash operation over the correctly encoded object: [2] [4]
action_address = H(encode(aₙ))
For a non-genesis action:
previous_action_hash(aₙ) = H(encode(aₙ₋₁))
validation_result = Validate_DNA(operation, dependencies)
Result: Valid, Invalid or UnresolvedDependencies
Addresses identify data; they are not amounts of money or wellbeing. Holochain’s documentation distinguishes entry identity from action identity: the same entry content can be associated with different authoring actions. The callback’s result describes validation of an operation, not a measured quantity of contribution. [4] [7]
The source-chain links help detect changes to history; signatures authenticate authorship under a key. Their existence does not establish that a key belongs to a unique human or that a signed real-world claim is true. The DHT and application’s rules are additional parts of the design, not consequences of one hash calculation. This is the boundary we draw from the documented architecture. [2] [3] [5]
None of those Holochain addresses or results is calculated for my session here. There is no chosen encoding, action history, DNA or operation in the selected disclosure. We do not turn the public file’s existing source-code hashes into pretend Holochain entry hashes. [10] [4]
Why unresolved is not invalid—and arithmetic is not authority
The documented callback can return UnresolvedDependencies when required data cannot be fetched. That differs from a definitive Invalid result. We do not assign either status to this historical session: a missing field in our disclosure is not an observed network validation failure. [7] [9]
An application could require the exact arithmetic relation, expressed in our proposed check below. This would need a specified schema, policy references, rounding, access rules and tests before use. [6] [10] [16]
q = round12(Wbefore / 1000)
Vcom_expected = round12(hours × policy_rate)
VC_expected = round12(q × Vcom_expected)
arithmetic_matches =
(recorded_Vcom = Vcom_expected)
AND (recorded_VCperformance = VC_expected)
For the disclosed numbers, both equalities hold. That says the calculation matches the selected inputs. It does not certify that a reviewer was eligible, the rate was approved in advance, the work was delivered or a payment was due. Application rules could check suitably represented evidence and authority; writing those rules still requires substantive governance choices. [10] [9] [16] [6]
What an implementation would still have to decide
This is a proposed design exercise, not a field mapping shipped by either project. It identifies questions an implementation of this real case would have to answer. Sharing a framework does not automatically make different communities’ policies interchangeable. [5] [15] [16]
| Design responsibility | Candidate treatment | Missing evidence or decision |
|---|---|---|
| Contributor and journal | Bind an authorized contributor reference to an application agent and its authored records. <a href="#h2">[2]</a> | Actual key, identity-binding policy, recovery and delegation rules. |
| Event and lineage | Represent the event and later decisions as distinct related records. <a href="#h4">[4]</a> <a href="#i3">[11]</a> | Schema, identifiers, correction semantics and tested migration. |
| Rate authority | Reference the exact source policy and applicable time, separately from its numerical rate. <a href="#i8">[16]</a> | Governed eligibility and version checks; historical timing must remain visible. |
| Independent review | Represent the reviewer’s identity, authority, scope and evidence. <a href="#i5">[13]</a> | An actual independent review is absent in the selected disclosure. <a href="#i1">[9]</a> |
| Private context | Minimize what is disclosed and specify which evidence each checker can access. <a href="#h3">[3]</a> <a href="#i6">[14]</a> | A privacy/threat model and proof that the proposed rules are enforceable with those disclosures. |
| Replay and correction | Preserve versions, source decisions and the ability to recompute derived numbers. <a href="#i8">[16]</a> | A tested adapter; Holochain source-chain integrity is not itself an IoV replay implementation. <a href="#h2">[2]</a> |
Private entries in Holochain stay local, while their actions are shared within the DNA’s network. “Private” therefore does not mean that no metadata is observable. We would need to examine correlation risks and consent before putting wellbeing-related records or commitments into that network. That is a design requirement we propose, not a completed privacy assessment. [3] [4] [14]
Validation also needs deterministic, retrievable dependencies. If a rule needs evidence that peers cannot legitimately access, labelling an entry private does not solve the validation design. Possible designs would need explicit trust or disclosure choices and tests; we claim no ready solution here. [6] [14]
What about countersigning?
Holochain documents a mechanism for multiple parties to coordinate a shared entry, but the current developer page marks countersigning unstable and disabled by default in Holochain 0.4 and newer. It also separates prior human agreement from the automated process. We do not rely on this feature, call it universally production-ready or claim that our case was countersigned. Even an agreement between signers would require examining who they were authorized to attest for and what they actually witnessed. [8] [9]
My Wellbeing Identity is more than an agent key
View my actual public Wellbeing Identity →
That is the existing consent-controlled presentation. The historical W in this article comes from the July event, not today’s public display. A Holochain agent identifier is a cryptographic application identity; it does not automatically carry the governed state, issuer context and disclosure rules meant by Wellbeing Identity. An integration would have to define that relationship. [18] [10] [14] [19]
We present that page as public Identity context. No Holochain-signed Identity or author-key binding is supplied in this case. No hidden facets or new private records are exposed here. [9] [10] [18]
What we can learn from Holochain
Make the rules inspectable. Its separation of integrity and coordination prompts a concrete question for us: which rules establish validity, and which functions merely help a user create or inspect records? Policy versions, source authority, exact arithmetic and missing dependencies should be explicit. This is a design lesson, not a migration announcement. [5] [6] [16]
Distinguish authored history from witnessed work. My selected case demonstrates the gap: a precise three-hour account and exact calculation still lack a linked proof artifact and independent assessment. Adding cryptographic provenance would help answer different questions; it would not remove those omissions. [2] [9] [10]
Preserve uncertainty in the result. A missing dependency deserves a named state rather than a silently invented approval. Holochain’s documented validation outcomes are useful here. We can learn from the distinction without relabelling an IoV pending decision as the same state machine. [7] [16]
Design privacy with validation. Local private entries and shared actions create specific disclosure choices. The lesson is to test who can learn what and which rules they can enforce before connecting sensitive context to a shared record. [3] [4] [14]
Keep the recognition institution visible. Infrastructure can enforce represented rules. A community still has to decide what counts as evidence, who may recognize work, which rate applies and whether recognition creates any obligation. Our case’s Moses-only self-ratification and non-payable status remain visible rather than being erased by a technical diagram. [6] [9] [10] [13]
Questions readers may ask
Are Holochain and The Internet of Value competing economic systems?
They are not equivalent categories in this comparison. Holochain is infrastructure for applications with authored data and shared rules. The Internet of Value specifies the protocol responsibilities described above, with community-owned inputs and implementation-specific math. There can be overlap in an implementation, but we show no deployed integration. [1] [5] [15] [16]
Could Holochain run the same founder calculation?
An application could be designed to reproduce its exact arithmetic with declared inputs, policy and rounding. That is a feasibility proposal, not a tested port. Holochain does not make this particular W multiplier necessary, correct or universal; the formula remains owned by the named implementation and policies. [5] [10] [16]
Does a valid signature prove that my research was good?
No. It concerns authorship and integrity of signed data. Work quality requires appropriate evidence and judgment. The selected session has no linked artifact and uses founder self-review; neither a signature nor the calculation repairs that gap. [2] [9] [10]
Is starting with one person unique to The Internet of Value?
That is not established. Holochain also starts with an agent’s own journal. What a first record permits under a particular application, policy and network is the useful question. My three-hour session with later decisions is not proof of a first-day economic effect or a uniqueness claim. [2] [9]
Would writing this event on Holochain make its USD figure spendable?
No such inference follows. This selected event is non_payable. An application’s rules and actual arrangements would need to establish obligations and settlement; an address or a Valid callback result is not itself a payment. [7] [10] [16]
Sources, method and corrections
- Holochain: How it Works. Official account of individual agency, shared rules and application networks. Used for framework context, not economic-performance claims.
- Holochain developer documentation: The Source Chain. Authored journal, actions, append-only records, signatures and hash links; local history alone does not prevent owner rewriting.
- Holochain developer documentation: The DHT. Shared data, validation/storage responsibilities and private-entry versus shared-action distinction. No benchmark or universal security guarantee asserted.
- Holochain developer documentation: Working With Data. Entry/action identity, previous-action references, network scope and storage visibility. Our schematic uses no actual Holochain bytes or addresses.
- Holochain developer documentation: Application Structure. Integrity/coordinator responsibilities, DNA identity and agent/cell context. No adapter or identity equivalence asserted.
- Holochain developer documentation: Validation. Application validation, determinism and retrievable dependencies. Proposed arithmetic check is our design illustration, not code from this documentation.
- Holochain developer documentation: Validate callback. Operation input and Valid, Invalid, UnresolvedDependencies outcomes. No outcome is assigned to the Foundation session.
- Holochain developer documentation: Countersigning. Feature-status warning, prior agreement and coordination scope. Documentation consulted 7 November 2026; no countersigning dependency or current deployment claimed.
- Already-published Foundation contribution and source notes. Selected 31 July 2026 session, rate timing, founder review, absent proof link and 7 November export cutoff. Author-provided; underlying export private.
- Public selected-event calculation artifact. Exact historical inputs, fixed12 method, outputs and source-code hashes. Reproduction is not independent work, economic or empirical model validation.
- Value Capture: public protocol reference. Bounded activity, attribution, proof and lineage.
- Wellbecoming: public protocol reference. Private human context and conditional Performance routing.
- SAOcommons: public protocol reference. Community recognition, valuation and institutional responsibilities.
- Wellbeing Identity: public protocol reference. Living state, consent and disclosure responsibilities.
- Protocol registry. Version 0.7.0 when consulted 7 November 2026. Protocol authority; the Foundation website is explanatory.
- Published founder implementation limits. Public method and boundaries grounded in protocol documents. Limits on arithmetic, founder review and empirical claims; no universal law, payment or empirical validation implied.
- Human Protocol Flow. Existing approved explanatory illustration, reused unchanged. The specifications govern protocol truth.
- Moses Sam Paul Johnraj’s public Wellbeing Identity. Actual consent-controlled presentation, not a new agent key or a substitute for historical event inputs.
- Holochain developer documentation: Application Architecture. Agent/cell and application responsibilities; used for cryptographic application identity context, not a unique-human proof or Wellbeing Identity equivalence.
Sources consulted 7 November 2026. Holochain mechanisms are summarized from its documentation; this is not a security audit or benchmark. The event and founder arithmetic are previously disclosed. Mapping and validation-check ideas are proposals; no Holochain port, key binding, actual operation, signature, receipt, independent attestation, currency issuance or integration result is fabricated. Corrections are welcome through the link below.
Continue exploring
- Economic model comparisons
- The same session and time banking
- The same session and Sensorica
- The same session and SourceCred
- Before we price the work: Valueflows / REA
- When a number becomes a claim: mutual credit / CES
- Leave the return open: Sacred Economics
- What the ledger leaves out: Doughnut Economics
- A score is not a year: WELLBY / wellbeing indices
- Send a correction