Origin Ledgers Launch App
PVN — technical overview

A network with one job: validate defined conditions and make the result provable later.

A privately operated validator network, separate from Ethereum’s public validators, that independently validates and reconciles lifecycle events across ORIGIN and LEDGERS without access to keys or signing authority.

The technical records of register units and the evidence remain recorded on public Ethereum. PVN verifies each event against defined technical and state requirements, reconciles its recorded state, and produces the corresponding validation evidence.

Validation run RUN-0001Illustrative
EventAllocation · Program A
Rule setv3.2
Registry refREG-A01-2024-0188
Quantity2,500 t
Program refPRG-A
Registry status Quantity within tolerance Program reference Duplicate check
ResultReconciled
Evidence ref EV-0001 · 7f3a…c21e
StateValidated Reconciled
Design rationale

An application records its state. A validation network records what was checked.

An allowance program creates positions that can lead to settlement. A participant settles when its recorded position requires it; eligible supply is allocated when the applicable conditions are met; a program period closes when its required states have been reconciled. Each of these outcomes depends on the integrity of the underlying record.

PVN creates an independent technical record of what was checked, which conditions were met, how the state changed and when the event occurred. The application manages program logic and execution; PVN provides a separate validation and evidence layer, allowing reviewers to verify the lifecycle independently of the system that initiated it.

Application record
Latest stateAllocated
What was checked—
Conditions—
State change—
Time—
Validation recordIllustrative
What was checked4 checks
ConditionsSatisfied
State changeValidated Reconciled
Time14 Sep 2026 09:12:07 UTC

Why the validator set is dedicated

Settlement is public: allowances and program-specific credit representations are recorded on Ethereum, where the evidence trail remains visible.

Validation is dedicated. Program rules, participant positions, identities and transaction data may be confidential, so validation runs through a purpose-built validator set rather than public consensus participants. This preserves program boundaries and protects commercially sensitive information.

Cross-program separation is built into the operating model.

How it’s built

A dedicated validator set, with distributed validation.

PVN is a defined, privately-operated validator set. These validators do not stake or participate in Ethereum’s public consensus — they exist solely to validate and reconcile Origin Ledgers program-specific lifecycle events, while the instruments themselves settle on the public Ethereum network. Validation duties within the set are supported through distributed validator technology (DVT), with validator key material managed across multiple shares and participating validator infrastructure. DVT separates validator key material and validator duties across participating components. The security and availability properties depend on the configured threshold, validator topology, operator separation, and recovery procedures.

Dedicated validator setIllustrativeValidates here
Validator
Validator
Validator
Validator
DVT key shares
Boundary
Public EthereumInstruments and evidence recorded here
eCRBXcCRBXEvidence

PVN's validators do not participate in Ethereum's public consensus.

What DVT gives the network Validator key material is distributed across shares rather than held as a single complete key on one machine. The configured threshold determines how those shares participate in validator operations. This can reduce dependence on any single machine or validator component and support continued operation when individual components become unavailable. It applies to PVN’s own validator set only, and has no bearing on Ethereum’s public consensus. It does not, by itself, establish independent governance or determine who controls the PVN validator set.
The important distinction Distributed validation is not the same as independent governance.
The strength of the network depends on who operates the validators, not only on how validator key material is distributed.
It also depends on how many validators participate, what threshold is required, and how failures are handled.
And on who can change the validator set, and under what governance process.
Check types

Two instrument classes, two separate rule sets.

Allowance sideeCRBX — allowance-side events
Eligibility against applicable program admission rules
Expected quantity and defined tolerance
Program and boundary references
Lifecycle-state consistency
Duplicate and replay detection
Reconciliation against the expected allowance position
Credit sidecCRBX — credit-side events
Supply validation checks the registry record and the seller's holding, and confirms the credit has not been sold or retired elsewhere.
Eligibility against defined screening criteria
Allocation to a named program
Registry retirement confirmation and beneficiary reference
Assignment to a single participant position
Settlement and retirement readiness
Separate by design. Validating an eCRBX event does not validate a cCRBX event, and vice versa. The rule sets are separate. The underlying registry records are separate. The lifecycle states are separate. No validation result on one instrument class confers eligibility, authorization, or standing on the other.
How checks behave

Same inputs, same rule set, same result.

Validation is deterministic A given event evaluated against the same inputs and versioned rule set produces the same result on every run. This makes the outcome reproducible and independently reviewable rather than dependent on an individual operator's interpretation.
Reconciliation compares expected against recorded An allowance position, settlement quantity, or retirement volume carries an expected state derived from the applicable program rules and a recorded state derived from the event data. Where the two do not match within the defined conditions and tolerances, the event does not advance to the next required state.
Divergence is preserved, not resolved A partially settled or otherwise divergent event remains recorded in its actual state. It is not treated as completed because a timeout expires, a retry succeeds partially, or one component confirms. The evidence of the divergence remains available even after the underlying issue is resolved.
Control boundary

PVN determines. It does not act.

PVN determines whether an event satisfies its defined technical conditions. It cannot act on that determination.

PVN cannot access participant private keys, signing secrets, custody credentials or registrar keys
PVN cannot move, release, or retire an asset
PVN cannot modify custody controls or register and key layer transaction policies
PVN cannot authorize treasury activity
PVN cannot alter governance quorum or participant-admission rules
PVN cannot change a program’s cap, schedule, or terms
Validated is a state, not an instruction.A successful validation records that defined technical conditions have been satisfied. It does not instruct another component to execute an asset movement. A separate authorization layer determines whether the requested action is permitted under the applicable rules. Origin Ledgers operates the program register. Participants hold no keys. Register operations are signed with Origin Ledgers’ registrar keys, only after authorization, policy checks and PVN validation.
The record

Every step produces something reviewable.

Each validated lifecycle event produces a record of the validation run, the applicable rule set, the inputs evaluated, the reconciliation result, the resulting state, and the state transition that followed. State transitions are recorded as lifecycle events rather than represented only by the latest state. This creates a chronological evidence trail that can be examined without relying solely on the current position.

Evidence trailRUN-0001 · 14 Sep 2026Illustrative
Pendingv3.2 · intake · Run opened 09:12:01 UTC
Validatedv3.2 · checks · All checks passed 09:12:04 UTC
Reconciledv3.2 · reconciliation · Expected = recorded 09:12:07 UTC
AuthorizedAuthorization layer · Action approved 09:14:30 UTC
CompletedCustody controls · Execution recorded 09:15:02 UTC
A program manager Can trace how a participant’s position was calculated and which validation and reconciliation events contributed to it.
A participant Can trace a settlement to the applicable credit, its registry retirement record, and the validation events associated with it.
A registry Can trace which program and beneficiary each retirement of its credits was made for.
An auditor or reviewer Can reconstruct the relevant lifecycle from recorded evidence rather than relying solely on the operator’s account of what occurred.
Operations

Nothing fails quietly.

Telemetry runs continuously across validation and reconciliation. Monitoring provides visibility into event status, system activity, and exceptions. It does not authorize transactions or advance an event by itself.

Events that fail validation or reconciliation are held, rejected or escalated. A retry succeeds only when the required conditions are met, and no event can timeout or bypass a control to reach completion. Escalation remains part of the lifecycle record until the required review, decision and resulting state are recorded.

Where PVN touches the platform

Four boundaries, each with a defined direction of responsibility.

LEDGERSAllowance events in · states out
ORIGINCredit events in · states out
PVNValidates · reconciles
RegistriesRead only
Registrar keysResults available · no keys
BoundaryWhat crosses it
LEDGERSAllowance lifecycle events enter PVN for validation. Validation states and reconciliation results return to the applicable program workflow.
ORIGINCredit allocation, retirement, and assignment events enter PVN for validation. Validation states and reconciliation results return to the applicable workflow.
RegistriesRegistry status and relevant evidence are read for validation. PVN does not write to or modify the registry of record.
Registrar keysValidation results can be made available to the authorization and transaction-control layer. PVN holds no participant private keys, signing secrets, custody credentials or registrar keys, and issues no execution instructions.
Bounded review

What a review can reach.

The disclosure boundary is published in full on Trust, Disclosure Boundaries: what’s available for review, what’s intentionally excluded, and why.

Request the review package
AvailableSanitized architecture, dummy-data lifecycle walkthroughs, validation and reconciliation records, boundary statements, and a role and permission matrix.
Not availableProduction source, credentials, key material, DVT shares, customer data, and proprietary logic.
Questions

What technical reviewers ask first.

PVN is a dedicated, privately-operated validator set used for distributed validation and ordered, tamper-evident lifecycle records. It is not a chain of its own and does not operate a native network asset: the register units it validates each have a technical record on the public Ethereum network as an ERC-20 token. PVN’s validators do not participate in Ethereum’s public consensus, and program operating data is not exposed publicly.

Boundary statement. PVN provides technical validation and lifecycle-readiness infrastructure. Origin Ledgers operates the program register. Participants hold no keys. Register operations are signed with Origin Ledgers’ registrar keys, only after authorization, policy checks and PVN validation. Origin Ledgers AG does not provide investment, tax, or accounting advice.