Layers

Node Architecture

Documented architecture

Node roles, their relationships and the boundaries between them, as described on paper. No node software has been released, no nodes are deployed, and no node count, operator list or geographic distribution is reported anywhere on this platform.

Not live

The node network 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: Internal topology draft, not yet supplied for verification
Document version: Not yet assigned
Last reviewed: 19 September 2026

Architecture model

The diagram below is rendered from the documented model. It shows responsibility boundaries, not a deployment.

  submitters ──▶ [ admission ]      identity & eligibility proofs required
                      │
                      ▼
              [ validating nodes ] ──▶ rule execution, acceptance, ordering
                      │                       ▲
      epoch snapshot  │                       │ authorized rule versions
                      ▼                       │
              [ archive nodes ] ◀──── [ governance authority ]
                      │
        read queries  ▼
              [ read nodes ] ──▶ explorer / API surfaces (planned)
                      │
              [ observers ] ──▶ monitoring only, no acceptance role

Documented responsibility model. No element corresponds to running infrastructure.

Roles and responsibilities

Node roles, their responsibilities and the authority each does not hold
Role	Responsibility	Explicitly not authorised to
Validating node	Accepts entries, applies the authorized rule version, extends the shared history.	Change rules, grant eligibility, or reverse an accepted entry.
Archive node	Retains full history and evidence references for audit and reconstruction.	Participate in acceptance or alter retained history.
Read node	Serves queries over accepted state to interfaces and explorers.	Submit, accept or annotate entries.
Observer	Follows the network for monitoring and measurement.	Influence acceptance in any way.

Which of these roles survives into an implementation is not settled. The separation exists so responsibility can be reasoned about before anything is built.

Validator and governance relationship

Governance authorizes, nodes execute

Documented architecture

A validating node applies a rule version that governance has authorized. Running the software does not confer the authority to decide what the rules are.

Rule changes are referenced, not implicit

Documented architecture

Each accepted entry should reference the rule version under which it was accepted, so a later reader can tell which regime applied.

Operator set is a governance question

Planned

Who may run a validating node, under what accountability and with what removal path, is an unresolved governance decision, not a technical default.

No validator economics described

Planned

Rewards, staking, slashing or fee models are not specified. No figure of any kind is stated here.

Topology concepts

Acceptance core — a bounded set of validating nodes under named accountability.
Retention ring — archive nodes distributed so the loss of one custodian does not lose history.
Read edge — read nodes serving interfaces, replaceable without affecting acceptance.
Observation — independent observers able to check what the core reports.

Connectivity model, peer discovery, message formats and transport are to be specified. Nothing is claimed about latency, throughput or geography.

Trust and authority boundaries

Trust boundaries between node roles and external parties
Boundary	What crosses it	Assumption that must hold
Submitter → admission	Entry request plus identity and eligibility proofs.	Proof verification is independent of the submitter.
Governance → validating node	Authorized rule versions and role grants.	Authority records are verifiable and current.
Validating → archive	Accepted entries and epoch snapshots.	Archive cannot rewrite what it retains.
Archive → read → interface	Query responses over accepted state.	Read surfaces are replaceable and never the source of truth.

Node lifecycle

01
Eligibility
An operator is identified and authorized under a governance decision before any software is issued.
02
Configuration
The node is configured with its role, the authorized rule version and its retention obligations.
03
Join
The node establishes its identity to peers and synchronises history to a known snapshot.
04
Operation
The node performs only its role's duties and records what it accepted and under which rules.
05
Evidence
Operational evidence — snapshots, acceptance records, retention attestations — is produced for review.
06
Exit
A node leaves with its history handed over or already replicated, under an authorized decision.

Every stage above is a written intention. No stage has been implemented.

Resilience and failure considerations

Custodian loss

Documented architecture

History must survive the loss of any single archive custodian, which is why retention is described as replicated rather than centralised.

Divergence

Planned

What happens when validating nodes disagree — detection, halt, reconciliation — is an open specification item, tied to the undecided consensus mechanism.

Interface outage

Documented architecture

Read surfaces and explorers are replaceable. Their unavailability must not affect acceptance or the integrity of history.

Operator compromise

Planned

Containment, revocation of a compromised operator and reconstruction from evidence are described as requirements, with no procedure written yet.

Deployment roadmap context

A staged deployment sequence has been referred to in project material — an initial site, a second site, and a wider set of nodes afterwards. The specific locations, sequence and timing are recorded here as unverified, and no site, agreement, host or date is named until a source is supplied.

Not determined

Node software: Not written or released
Consensus mechanism: Not decided
Operator model: Not decided
Peer protocol: To be specified
Hardware requirements: Not established
Deployed nodes: None

VPLedger proof and execution model Security architecture

Evidence register

Each statement on this page is tracked against a source. A claim without a verified source is never presented as fact.

Claims on this page and the verification state of their sources
Claim	Source type	Verification	Note
Node role definitions and topology concepts	Internal topology draft	Source claimed, not yet verified	Draft to be supplied for verification.
Staged deployment sequence and site names	Project material	Source claimed, not yet verified	Referred to in discussion; no site, host, agreement or date is published here.
Node counts, operators, regions or uptime	Network telemetry	No source on file	No network exists; no metrics are shown.

Architecture model

Roles and responsibilities

Validator and governance relationship

Governance authorizes, nodes execute

Rule changes are referenced, not implicit

Operator set is a governance question

No validator economics described

Topology concepts

Trust and authority boundaries

Node lifecycle

Eligibility

Configuration

Join

Operation

Evidence

Exit

Resilience and failure considerations

Custodian loss

Divergence

Interface outage

Operator compromise

Deployment roadmap context

Not determined

Evidence register