Layers · Review draft
Proposed Canon & Protocol Invariants v0.1
A proposed normative scope for ByteShares protocol behaviour, prepared for owner review. Draft / Awaiting owner acceptance — Proposed / Non-operational. Nothing here describes a running system, ratified standard or conformance result.
- Source / verification
- Proposed draft prepared 8 Oct 2026 from historical roots and 2026 provenance controls; owner adoption pending; no implementation or conformance evidence
- Document version
- Canon draft v0.1 (not a software, specification or network version)
- Last reviewed
- 8 October 2026
Status and authorization
On 8 October 2026 Ronny Boesing authorized preparation of this draft after an archive search found relevant historical roots but no single current 2026 source defining the complete normative invariant set, binding state-transition inputs, authority constraints and conformance criteria. Ronny has not adopted these contents as final canon. The source is the owner-authorized archive draft “ByteShares – Proposed Canon & Protocol Invariants v0.1 – 2026-10-08”, a normative-design candidate held privately and not linked from this site.
This page is a documentation draft — not a standards ratification, software release, security assessment, operational specification or legal opinion.
Evidence basis and historical boundary
Historical roots (dated, historical status):
- Actual Eng WhitePaper ver. 2.1 (July 2019) — verification/KYC, VPG governance framing, hierarchical dynamic account permissions, voting/user-protection and transaction-model concepts.
- VPLedger Memorandum (2019/2020) — protective-democracy / VPG governance principles.
- VPLedger summary 12102021 — legal/accountable infrastructure, delegated KYC and hierarchical account management.
- VPLedger features at time of mainnet 2022 — hierarchical permissions, threshold/multisig, recurring/scheduled payments, limits and audit-history features.
- Technical WP for MVP ver. 1.0 (Sep 2019) — referenced via the 2026 provenance dossier for hierarchical permissions, multi-party authority and VPG chronology.
2026 evidence controls: IP Provenance Dossier, Concept Evolution Register, Chain-of-Title Matrix and Clean Title Record.
These sources provide design lineage and documented provenance. They are not proof of current legal ownership, a complete chain of title or operational implementation.
Responsibility separation
Identity (eIDspot) establishes the subject; governance scopes authority and rule context; VPLedger records evidence-bearing outcomes; nodes execute adopted rules; interfaces are replaceable access surfaces. No layer may assume another layer's responsibility.
Proposed invariants INV-001–INV-035
Thirty-five proposed invariants from the archive draft, grouped for review. Every entry is Proposed / Awaiting owner acceptance; none is implemented, tested or adopted.
Authority and responsibility (INV-001–005)
| ID | Proposed invariant |
|---|---|
| INV-001 | Identity is not authority. |
| INV-002 | Authority is explicit and scoped. |
| INV-003 | Delegation cannot amplify authority. |
| INV-004 | Interfaces do not create protocol truth. |
| INV-005 | Governance and execution remain distinct. |
State-transition decisions (INV-006–012)
| ID | Proposed invariant |
|---|---|
| INV-006 | No accepted transition without complete required inputs. |
| INV-007 | Rule version is binding. |
| INV-008 | Prior state is binding. |
| INV-009 | Preconditions are explicit. |
| INV-010 | Replay protection is required. |
| INV-011 | Deterministic concurrency handling is required. |
| INV-012 | Refusals are first-class evidence. |
History and correction (INV-013–015)
| ID | Proposed invariant |
|---|---|
| INV-013 | No silent mutation. |
| INV-014 | Corrections are additive. |
| INV-015 | Historical verification uses historical context. |
Evidence, anchoring and data sovereignty (INV-016–019)
| ID | Proposed invariant |
|---|---|
| INV-016 | Evidence and commitments are distinct. |
| INV-017 | Minimize sensitive disclosure. |
| INV-018 | Durable evidence requires explicit custody. |
| INV-019 | Snapshot semantics need a separate specification. |
Governance, exceptions and versioning (INV-020–024)
| ID | Proposed invariant |
|---|---|
| INV-020 | Governance changes are versioned and prospective. |
| INV-021 | Exceptions require explicit authority. |
| INV-022 | Reversal is not deletion. |
| INV-023 | Exceptions/disputes need a separate owner-approved procedure. |
| INV-024 | Cooperative governance and technical protocol governance are not automatically identical. |
Node and execution (INV-025–028)
| ID | Proposed invariant |
|---|---|
| INV-025 | Nodes execute accepted rules; they do not privately redefine them. |
| INV-026 | Node role does not imply unlimited authority. |
| INV-027 | Divergence handling is defined before operation. |
| INV-028 | Deployment evidence is not architecture prose. |
Security and fail-closed (INV-029–032)
| ID | Proposed invariant |
|---|---|
| INV-029 | Missing authority fails closed. |
| INV-030 | Administrative power is bounded and reviewable. |
| INV-031 | Security claims require an assessed implementation. |
| INV-032 | Security disclosure requires an accountable route. |
Versioning and interpretability (INV-033–035)
| ID | Proposed invariant |
|---|---|
| INV-033 | Documentation version is not software/specification version. |
| INV-034 | A breaking semantic change creates a new version. |
| INV-035 | Historical proofs remain interpretable. |
Identity, authority and delegation
- Identity is not authority: a verified subject has no permission unless a mandate grants it.
- Authority is explicit and scoped by action, resource/domain, time and conditions.
- No authority amplification: a delegate can never receive more scope than the delegator held.
- Expired or revoked authority is treated as absent at decision time.
Interface truth and governance vs execution
- Replaceable interfaces cannot create protocol truth or grant authority.
- Governance defines and changes rules; execution applies adopted rules and cannot redefine them.
- Cooperative governance (ByteShares.dk membership decisions) and technical-protocol governance are separate domains; one does not silently bind the other.
Binding state-transition input contract (conceptual)
Proposed / Non-operational — conceptual inputs; no field names, types or wire format.
| Input | Role in the decision |
|---|---|
| Subject | Who or what the transition concerns or is initiated by. |
| Identity / credential evidence | Presented proof of the subject; never authority by itself. |
| Authority / mandate | Explicit, scoped permission to perform the intent for the resource. |
| Intent / action | The requested operation, stated explicitly. |
| Resource / domain | What the action affects and under which governance domain. |
| Prior state | The exact state reference the decision is evaluated against. |
| Rule / version | The binding rule set and its version applied to the decision. |
| Input / evidence commitments | Commitments to the evidence relied on, not the evidence itself. |
| Context | Additional declared conditions required by the rule. |
| Replay / idempotency reference | Reference preventing duplicate or replayed application. |
| Time / validity context | Validity windows, expiry and revocation state at decision time. |
Fail-closed and decision rules
- Fail closed: a missing, unverifiable or expired required input produces refusal, never a default acceptance.
- Every decision binds the rule version and the prior state it was evaluated against.
- Preconditions are explicit; replay protection is mandatory.
- Concurrency is resolved deterministically: equal inputs under the same rule version and prior state yield the same outcome.
Decision / outcome contract (conceptual)
Each decision yields an evidence-bearing outcome — accepted or refused — referencing the inputs, rule version, prior state and reason. Refusals are recorded as evidence, not discarded. Proposed / Non-operational.
| Outcome | Meaning |
|---|---|
| Accepted | All required inputs present and valid; transition applied against the bound prior state and rule version, with evidence. |
| Refused | A required input is missing, invalid, expired, revoked, out of scope or replayed; refusal recorded as evidence with its reason. |
| Corrected / reversed | An additive compensating outcome linked to the original; the original remains in history. |
No silent mutation and historical verification
- Recorded outcomes are never silently changed.
- Corrections and reversals are additive compensating events linked to what they correct.
- Historical outcomes are verified under the rule version and time context in force when they were decided.
Evidence, commitments and custody
- A commitment proves that specific data was referenced — not that it is true, that title exists, that authority is current or that the data remains available.
- Data minimization: only what a rule requires is committed or disclosed.
- Evidence custody is explicit: who holds underlying evidence must be stated.
- Snapshot semantics remain a separate specification (see gap register).
Versioned governance and exceptions
- Governance changes are versioned and prospective; they do not rewrite past decisions.
- Exceptions require explicit, identified authority and produce evidence like any other decision.
- The exception/dispute procedure itself is not defined by this canon.
Node and security invariants
- Node execution cannot privately redefine rules; nodes must be semantically equivalent under the same rule version.
- Node/operator authority is bounded to execution roles.
- Security and administrative power is bounded, attributable and reviewable; failures fail closed.
Documentation vs specification, software and network versions
Documentation version (0.9 RC1) ≠ canon draft v0.1 ≠ specification, software or network version — none of the latter are assigned. Breaking semantic changes create new versions, and historic proofs remain interpretable under their original version.
Proposed conformance minimum C-01–C-14
Proposed criteria only. No test suite, vectors or conformance results exist.
| ID | Criterion | Status |
|---|---|---|
| C-01 | Identity/authority separation | Proposed — not tested |
| C-02 | Delegation scope enforcement | Proposed — not tested |
| C-03 | Expiry/revocation handling | Proposed — not tested |
| C-04 | Rule-version binding | Proposed — not tested |
| C-05 | Prior-state binding | Proposed — not tested |
| C-06 | Deterministic decisions | Proposed — not tested |
| C-07 | Replay safety | Proposed — not tested |
| C-08 | Refusal evidence | Proposed — not tested |
| C-09 | Append-only correction | Proposed — not tested |
| C-10 | Historical verification | Proposed — not tested |
| C-11 | Data minimization | Proposed — not tested |
| C-12 | Snapshot verification once specified | Proposed — not tested |
| C-13 | Node semantic equivalence | Proposed — not tested |
| C-14 | Explicit version migration | Proposed — not tested |
Relation to Sig-56, F.I.P. and eIDspot
The canon states invariants those specifications must respect; it does not supply them. Sig-56 signature rules, F.I.P. agent identity/permitted-memory rules and eIDspot credential/revocation rules remain separate, unresolved normative specifications.
Historical VPLedger lineage
Hierarchical permissions, multi-party/threshold authority, delegated verification, VPG governance and audit history inform this draft as concept lineage. Historical token, performance, product or launch claims are not imported and are not current statements.
VPLedger evidence layerVPLedger 2019 foundation and 2026 lineage — historical source trace: the owner reports direct inspection of the original whitepaper and PDF memorandum. The comparison retains the memorandum date discrepancy, copyright/title limits and distinction between historical network voting and cooperative constitutional voting. It does not adopt, overwrite or revise this canon, or verify current implementation.
Claim / source trace
Each theme is grounded in the archive draft plus existing ByteShares.org documentation. Historical roots provide design lineage and provenance, not proof of current legal ownership or operational implementation.
| Claim | Source | Related page |
|---|---|---|
| 35 proposed invariants and C-01–C-14 | Archive draft “Proposed Canon & Protocol Invariants v0.1”, 8 Oct 2026 | /protocol-canon |
| Responsibility separation, identity vs authority | Archive draft + existing principle boundaries | /protocol-architecture |
| Mandate scope, expiry and revocation | Archive draft + identity mandate chain | /identity-eidspot |
| Append-only correction, commitments, custody | Archive draft + proof and custody model | /vpledger |
| Prospective governance, exception authority | Archive draft + governance flow | /governance-layer |
| Node execution and bounded operator authority | Archive draft + node roles | /node-architecture |
| Fail-closed, bounded admin power, disclosure route | Archive draft + threat trace | /security |
| Proposed request/outcome shapes | Archive draft + developer conceptual shapes | /developers |
| Historical lineage | 2019–2022 historical roots via 2026 provenance controls (lineage, not title) | /github |
Remaining gap register
This canon does not resolve these independent gaps; each stays open.
| Gap | Page | Evidence required |
|---|---|---|
| Merkle snapshot construction | /vpledger | Snapshot specification and verifier vectors |
| Exceptions, reversals & disputes procedure | /governance-layer | Owner-approved procedure |
| Node deployment roadmap | /node-architecture | Dated topology/deployment plan and site scope |
| Security disclosure process | /security | Owner decision on recipient, scope and handling |
| IP / licensing / title | /github | Component-linked assignments and licence review |
| Sig-56 normative specification | /standards | Source specification and test vectors |
| F.I.P. normative specification | /standards | Source specification and conformance criteria |
| eIDspot credential/revocation specification | /identity-eidspot | Issuer, format, revocation and custody rules |
| Operational consensus/finality and implementation evidence | /network-status | Implementation and operational evidence before any network claim |
Owner review checklist
- Decision required
- Adopt, amend or reject Proposed Canon & Protocol Invariants v0.1.
- Not part of this decision
- Publication, source acceptance, GitHub approval or operational launch.
- Are the responsibility separations and identity/authority rules correct and complete?
- Is the eleven-input state-transition contract the intended binding set?
- Are fail-closed, replay and deterministic-concurrency rules acceptable as stated?
- Are INV-001–INV-035 complete, correctly grouped and correctly worded?
- Is C-01–C-14 the intended conformance minimum?
- Is the cooperative vs technical-protocol governance separation correct?
- Are any historical concepts wrongly included or omitted?