Deterministic rule execution
Documented architectureThe same declared inputs, authorized rule version and prior state are intended to produce the same outcome. Hidden application logic is outside the canonical model.
Layers
VPLedger
Documented architecture
VPLedger is the working name for the value and participation ledger described in the architecture. This page records the model as written. There is no ledger instance, no genesis state, no balances and no transactions.
Not live
VPLedger is not operating. Nothing on this page reports real activity, and no operational figures are shown, because no verified operational data source exists yet.
- Source / verification
- Owner-asserted canon; provenance audit ongoing
- Document version
- Ledger specification: not yet assigned
- Last reviewed
- 19 September 2026
Model as documented
The ledger is described as an append-only record of entries. An entry references the participant it concerns, the kind of contribution or transfer it represents, and the moment it was accepted. Entries are described as never edited: a correction is itself a new entry that refers back to the one it corrects.
Two kinds of record are distinguished in the drafts: value entries, which track transferable amounts, and participation entries, which track contribution that is recognised but not transferable. The separation is deliberate, so that recognition of work cannot be traded as if it were value.
Proof + Execution Layer
Verifiable histories
Documented architectureEach accepted transition should retain its inputs, authority, rule reference, timestamp and link to prior state so the result can be reconstructed.
Controlled participation
Documented architectureEligibility and authority proofs gate who may submit, approve or receive a particular state transition.
High-integrity accounting
Documented architectureAccounting state is append-only, reconciliable and attributable; correction occurs through a linked compensating entry rather than silent mutation.
These are documented invariants. No execution engine, proof verifier or production accounting system is running.
Proof objects
Contract lifecycle
Documented architectureCreation → escrow → settlement. Each stage records the governing terms, authority, state change and evidence reference.
Governance decision
Documented architectureProposal → vote → authorization. The proof binds eligibility, threshold evaluation and authorized outcome.
Compliance & eligibility
Documented architectureA scoped proof states that a condition was satisfied under a named rule without requiring unrelated source data to be exposed.
Institutional audit extract
Documented architectureA bounded, reproducible extract links selected entries, rule versions and evidence references to an anchored snapshot for independent review.
Merkle snapshots
Documented architecture
A Merkle snapshot is the documented proof primitive for committing a defined record set at an epoch boundary. Its root can be anchored with the timestamp and rule context; an inclusion path then verifies a selected record without disclosing the full set.
Snapshot format, hashing profile, epoch policy and verifier are not yet implemented or fixed.
Anchors and durable evidence
| Kept on-chain | Kept off-chain | Reason |
|---|---|---|
| Rule references and versions | Full rule text and rationale | The commitment must be small; the material must stay readable. |
| Hashes and timestamps | The documents and records they commit to | A hash proves the artefact without disclosing it. |
| Accounting state transitions | Supporting commercial and identity evidence | Accounting must be reconstructable without exposing source data. |
| Evidence references | The evidence itself, under custody | Custody and retention stay explicit and revocable. |
Content-addressed storage is the documented direction for durable evidence, with a Filecoin rail recorded only as planned positioning. No storage rail is contracted or in use, and hash construction, reference format and retention obligations are to be specified.
Lifecycle examples
Each example shows where a proof object would be produced. None can be executed today.
A
Contract: creation → escrow → settlement
Terms and authority are bound at creation, the escrow condition is recorded, and settlement produces a proof referencing both earlier stages.
B
Governance authorization
Proposal, eligibility and threshold evaluation resolve into an authority record that execution can reference.
C
Compliance or eligibility proof
A scoped proof states that a named condition held, without disclosing the underlying documents.
D
Institutional audit extract
A bounded set of entries, rule versions and evidence references is tied to an anchored snapshot for independent review.
Unresolved
- Consensus mechanism
- Not decided
- Entry schema
- Draft, not fixed
- Finality rules
- Not specified
- Instance
- None exists
Evidence register
Each statement on this page is tracked against a source. A claim without a verified source is never presented as fact.
| Claim | Source type | Verification | Note |
|---|---|---|---|
| Append-only entry model with value/participation split | Master Business Plan v2.1 / aligned canon | Source claimed, not yet verified | Owner-asserted; the cited document has not been supplied, and the source provenance audit remains open. |
| Proof objects and deterministic execution model | Owner-provided aligned technical canon | Source claimed, not yet verified | Documented model only; schemas, hashing and snapshot formats are to be specified, not invented. |
| Any balance, supply or transaction figure | Ledger state | No source on file | No ledger exists; no figures are shown anywhere on this platform. |