PTVS Standard Change Management Policy

Ensuring the deterministic, transparent, and technically rigorous evolution of the Prop Trust Verified Standard (PTVS) from v1.0 to future iterations.

The Principle of Standard Stability

A global standard cannot be subject to the unilateral whims of a single commercial entity. To maintain institutional trust, regulatory compliance, and backward compatibility for tokenized assets, the PropTrust Association enforces a strict, democratic, and auditable Change Management Policy.

All modifications to the PTVS methodology, cryptographic primitives, or smart contract interfaces must pass through the following five-phase lifecycle, overseen by the independent Steering Committee.

The 5-Phase Evolution Lifecycle

From initial proposal to final ratification, every change follows this mandatory institutional path.

Phase 01 Request for Change (RFC)

Any PTCE expert, institutional member, or research body (e.g., Forensics Oracle Initiative) may submit a formal RFC. The proposal must include the technical justification, impact on existing assets, and proposed cryptographic or methodological adjustments.

Submission & Initial Triage

Phase 02 Technical & Legal Impact Assessment

The Technical Board evaluates the RFC for cryptographic soundness and smart contract compatibility. Simultaneously, Legal Counsel assesses alignment with eIDAS 2.0, MiCA, and ERC-3643 regulatory frameworks.

15-30 Days Review Period

Phase 03 Public Consultation Period

The validated RFC is published on the Forensics Oracle Initiative repository for a mandatory 30-day open comment period. All Association members, licensees, and the public may submit feedback or objections.

30 Days Mandatory Open Window

Phase 04 Steering Committee Ratification

Following public consultation, the Steering Committee votes on the final draft. Approval requires a two-thirds (2/3) supermajority. The Founding Chair retains veto power exclusively over changes that compromise core forensic integrity principles.

2/3 Supermajority Required

Phase 05 Publication & Backward Compatibility

The new standard version is published with a new DOI. A mandatory 6-month transition period is enforced, during which both the old and new versions remain valid to ensure backward compatibility for existing tokenized assets.

6-Month Grace Period

Semantic Versioning Strategy

Major (v1.0 → v2.0): Fundamental shifts in methodology, cryptographic primitives, or breaking changes to the ONCHAINID claim structure. Requires full re-certification of PTCE experts.
Minor (v1.0 → v1.1): Addition of new asset class modules (e.g., Maritime, Energy), non-breaking API updates, or enhancements to the scoring matrix.
Patch (v1.0.1): Typographical corrections, non-breaking smart contract gas optimizations, or clarification of existing forensic guidelines.

Emergency Amendment Protocol

In the event of a critical smart contract vulnerability, a fundamental flaw in the forensic methodology, or a severe regulatory mandate, the standard bypasses the 30-day consultation.

Trigger: Identified by Technical Board or Legal Counsel.
Action: Immediate emergency vote by the Steering Committee (requires unanimous consent).
Execution: The compromised hash is instantly added to the PTVS Revocation Registry, and a patched version is deployed within 72 hours.

Submit a Request for Change (RFC)

Are you a PTCE expert, institutional member, or researcher? Propose an evolution to the PTVS standard and help shape the future of physical asset verification.

Submit RFC Proposal