DEV Community: Aurelio Tamarit Blay

PFOI vs PTVS: Understanding the New Infrastructure Category Solving RWA's Physical Oracle Problem

Aurelio Tamarit Blay — Wed, 26 Aug 2026 15:44:33 +0000

PFOI vs PTVS: Understanding the New Infrastructure Category Solving RWA's Physical Oracle Problem
published: true
description: "Physical Forensic Oracle Infrastructure (PFOI) is a new market category. Prop Trust Verified Standard (PTVS v1.0) is its first implementation. Here's the difference and why it matters for RWA tokenization."
tags: [blockchain, rwa, web3, standards, tokenization]
cover_image: https://images.unsplash.com/photo-1451187580459-43490279c0fa?auto=format&fit=crop&w=1200&q=80

canonical_url: https://dev.to/aurema_group_ee4f7593374a/pfoi-vs-ptvs-understanding-the-new-infrastructure-category-solving-rwas-physical-oracle-problem

In the rapidly evolving world of Real-World Asset (RWA) tokenization, we keep hearing about "standards." But there's a critical distinction that most projects miss:

The difference between creating a market category and creating a technical standard.

Today, I want to clarify two concepts that are reshaping how institutional investors think about physical asset verification:

PFOI (Physical Forensic Oracle Infrastructure) — The Category
PTVS (Prop Trust Verified Standard) — The Standard

If you're building, investing in, or regulating RWA platforms, understanding this distinction is essential.

🏗️ The Analogy: Internet vs TCP/IP

To understand PFOI vs PTVS, think about the early days of the internet:

Category: "Internet" (the concept of interconnected networks)
Standard: "TCP/IP" (the specific protocol that made it work)

You couldn't have the internet without TCP/IP. But TCP/IP is just one implementation of the broader category of "interconnected networking."

Same logic applies to RWA verification:

Category: PFOI (Physical Forensic Oracle Infrastructure) — The infrastructure layer that connects physical reality to blockchain
Standard: PTVS v1.0 (Prop Trust Verified Standard) — The first open standard implementing PFOI

📚 What is PFOI? (The Category)

Physical Forensic Oracle Infrastructure (PFOI) is a new market category we formally defined in August 2026.

Formal Definition:

A multi-billion dollar infrastructure category bridging sworn judicial forensic practice and blockchain-based cryptographic verification, establishing the foundational trust layer for the global Real-World Asset (RWA) tokenization economy.

What PFOI Encompasses:

All infrastructure that enables deterministic physical verification of off-chain assets
Methodologies for connecting judicial experts to smart contracts
Networks of certified forensic auditors (PTCEs)
Cryptographic anchoring systems (SHA-256 + blockchain)
Regulatory compliance frameworks (MiCA Art. 36, eIDAS 2.0)

Why PFOI Exists:

The Physical Oracle Gap — blockchain can verify token ownership and price feeds, but it's blind to physical reality.

When a tokenized building develops structural cracks, when a vessel is arrested under maritime lien, or when agricultural land is contaminated, the smart contract has no idea.

PFOI is the infrastructure that fixes this blind spot.

What is PTVS? (The Standard)

Prop Trust Verified Standard (PTVS v1.0) is the first and defining technical standard within the PFOI category.

Published in August 2026 with:

DOI: 10.5281/zenodo.21719175 (CERN/Zenodo)
Academic validation: SSRN (Abstract ID 7245361), HAL Open Science (hal-05713062v1)
Regulatory submissions: ESMA, EBA, EIOPA, ECB/SSM, INATBA

The Four Pillars of PTVS v1.0:

Pillar 1: Qualified Forensic Audits (eIDAS 2.0)

On-site inspections by certified Judicial Experts (PTCEs)
Non-Destructive Testing (NDT) protocols
Legal accountability (civil & penal responsibility)

Pillar 2: Cryptographic Lineage (SHA-256)

Canonical JSON serialization
Deterministic hashing
RFC 3161 qualified timestamps
PDF/A long-term preservation

Pillar 3: On-Chain Circuit Breakers

PTVSClaimInjector.sol smart contract
ERC-3643 / ONCHAINID compatibility
Automated transfer restrictions based on PTVS Score
Emergency revocation mechanism

Pillar 4: Decentralized Expert Network

PTCE (Prop Trust Certified Expert) certification program
Global network of sworn judicial experts
Continuous professional development
Professional liability insurance

PTVS Score (0-100):

Every audited asset receives a deterministic score:

91-100: AAA (Institutional Grade)
81-90: AA (Investment Grade)
71-80: A (Acceptable with monitoring)
<70: Circuit Breaker Activated (Transfers halted)

🔍 Key Differences: Category vs Standard

Aspect	PFOI (Category)	PTVS (Standard)
Nature	Market concept / Infrastructure layer	Technical specification / Implementation
Analogy	"Internet"	"TCP/IP"
Scope	Broad (all physical verification infrastructure)	Specific (4-pillar deterministic architecture)
Ownership	Category concept (like "DeFi" or "NFT")	Open standard (like ERC-20 or ERC-3643)
Governance	Market adoption defines it	Forensics Oracle Initiative maintains it
Competition	Other categories could emerge	Other standards could implement PFOI

💡 Why This Distinction Matters

For Platform Builders (Tokeny, Brickken, RealT):

You're not just "integrating PTVS." You're adopting PFOI infrastructure to solve a systemic risk. PTVS is the how, PFOI is the why.

For Institutional Investors (Family Offices, Banks):

When evaluating RWA platforms, ask: "Do you have PFOI infrastructure in place?" If they say no, they have a Physical Oracle Gap — and MiCA Art. 36 compliance is impossible.

For Regulators (ESMA, CNMV, ECB):

PFOI is the infrastructure category you need to reference in Regulatory Technical Standards (RTS). PTVS is the open standard you can cite as a reference implementation.

For Developers:

You can build PFOI-compatible systems using PTVS v1.0 as your reference. The PTVSClaimInjector.sol contract is open-source (MIT License) and ERC-3643 compatible.

Real-World Validation: Proyecto Navarrés

The PFOI category and PTVS standard aren't theoretical. They've been empirically validated:

Case Study: Proyecto Navarrés (Valencia, Spain)

Asset: 108,000 m² industrial real estate
Inspection: Full forensic pathology + NDT by Judicial Expert (Exp. 0161)
PTVS Score: 91/100 (AAA Grade)
On-Chain: Canonical hash injected via PTVSClaimInjector.sol
Result: First Physical Proof of Reserve (PPoR) for a tokenized Spanish asset

This proves that PFOI infrastructure works at scale and PTVS methodology is executable.

The Economic Flywheel

Here's why PFOI/PTVS will become inevitable:

MiCA Art. 36 Enforcement (2027) requires continuous proof of reserve assets
Institutional Investors demand physical verification before deploying capital
RWA Platforms without PFOI infrastructure become non-compliant and uninvestable
PTVS Adoption becomes the path of least resistance (open-source, pre-validated, regulator-submitted)

The flywheel:

🛠️ Try It Yourself (5 Minutes)

We've built a public sandbox where you can test the complete PTVS flow:

🔗 proptrustverified.com/sandbox

No signup. No backend. No cost. Just:

Upload a mock forensic report
Generate a canonical SHA-256 hash
See how it maps to ONCHAINID claims
Understand the circuit breaker logic

References & Further Reading

Technical Documentation:

PTVS v1.0 Reference Architecture: DOI 10.5281/zenodo.21719175
GitHub Repository: github.com/aurema-group/prop-trust-verified-standard
Smart Contract: PTVSClaimInjector.sol (MIT License)

Regulatory Submissions:

ESMA: FOI/ESMA/2026-001 (Under Review)
EBA: FOI/EBA/2026-002 (Under Review)
EIOPA: FOI/EIOPA/2026-003 (✅ Confirmed)
ECB/SSM: FOI/ECB-SSM/2026-004 (✅ Registered via ADITO)

Academic Validation:

SSRN/Elsevier: Abstract ID 7245361
HAL Open Science/CNRS: hal-05713062v1
U.S. Copyright Office: Registered

🎯 The Bottom Line

PFOI is the category. PTVS is the standard.

You can't scale RWA tokenization to €1T+ without PFOI infrastructure. And the fastest way to implement PFOI today is PTVS v1.0.

The question isn't whether your platform needs physical verification. The question is whether you'll:

Build your own PFOI infrastructure (18-24 months, €5-10M)
Partner with Big Four (expensive, slow, not blockchain-native)
Adopt PTVS v1.0 (immediate, compliant, battle-tested, open-source)

The smart money is already choosing #3.

Veritas in Re · Certitudo in Code

About the Author:

Aurelio Tamarit Blay is a Certified Judicial Expert (Exp. No. 0161, Spain) with 33+ years of forensic practice in real estate, construction, and maritime assets. He is the Creator of the PFOI Category and Lead Architect of PTVS v1.0.

ORCID: 0009-0007-5824-3602

LinkedIn: linkedin.com/in/aurelio-tamarit-blay

Questions about PFOI/PTVS integration? Drop them in the comments. I monitor this thread daily.

Integrating Physical Verification into Your RWA Platform: A Step-by-Step Guide with PTVS v1.0

Aurelio Tamarit Blay — Wed, 26 Aug 2026 15:28:52 +0000

"Integrating Physical Verification into Your RWA Platform: A Step-by-Step Guide with PTVS v1.0"
published: true
description: "A developer's guide to adding on-chain physical verification (PPoR) to tokenized real-world assets using the open-source PTVSClaimInjector.sol and ERC-3643."
tags: [blockchain, web3, solidity, rwa, smartcontracts]
cover_image: https://images.unsplash.com/photo-1555949963-aa79dcee981c?auto=format&fit=crop&w=1200&q=80

canonical_url: https://dev.to/aurema_group_ee4f7593374a/integrating-physical-verification-into-your-rwa-platform-a-step-by-step-guide-with-ptvs-v10-25pd

If you are building a Real-World Asset (RWA) tokenization platform, you have likely hit a critical wall: The Physical Oracle Gap.

Your platform can verify investor KYC/AML via ERC-3643. Your price oracle can feed the market value of the asset. But neither can verify if the underlying building has developed structural cracks, if the vessel is under maritime lien, or if the agricultural land has been contaminated.

When MiCA Article 36 enforcement begins, regulators will ask: "How do you continuously prove the physical integrity of the reserve assets?"

Price oracles are not enough. You need Physical Proof of Reserve (PPoR).

In this tutorial, I will show you how to integrate the Prop Trust Verified Standard (PTVS v1.0) into your existing RWA stack using our open-source PTVSClaimInjector.sol smart contract.

🏗️ The Architecture: How PTVS Fits Your Stack

PTVS v1.0 is designed to be blockchain-agnostic and fully compatible with permissioned identity standards like ERC-3643 (T-REX) and ONCHAINID.

The flow is simple:

A certified Judicial Expert (PTCE) conducts a forensic audit off-chain.
The findings are structured into a Canonical JSON and hashed (SHA-256).
The hash and metadata are injected on-chain via PTVSClaimInjector.sol.
Your RWA smart contract reads this claim to enable/disable minting, transfers, or dividend distributions based on the asset's physical health.

🛠️ Step 1: The Smart Contract (`PTVSClaimInjector.sol`)

The core of the integration is the Claim Injector. This contract acts as a decentralized registry of physical verification claims, linked to the asset's ONCHAINID identity.

Here is the simplified interface of the contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/Ownable.sol";
import "@onchain-id/solidity/contracts/interface/IIdentity.sol";

contract PTVSClaimInjector is Ownable {
    // Event emitted when a physical verification claim is added or updated
    event ClaimInjected(
        address indexed assetIdentity,
        bytes32 indexed claimTopic,
        string reportUri,
        uint256 ptvsScore,
        uint256 timestamp
    );

    // Event emitted when a claim is revoked (e.g., asset fails inspection)
    event ClaimRevoked(
        address indexed assetIdentity,
        bytes32 indexed claimTopic
    );

    // The PTVS Claim Topic (e.g., keccak256("PTVS_PHYSICAL_VERIFICATION_V1"))
    bytes32 public constant PTVS_CLAIM_TOPIC = 0x7f8c...; // Simplified for brevity

    IIdentity public identityRegistry;

    constructor(address _identityRegistry) {
        identityRegistry = IIdentity(_identityRegistry);
    }

    /// @notice Injects a new physical verification claim into the asset's identity
    /// @param assetIdentity The ONCHAINID of the tokenized asset
    /// @param reportUri IPFS/HTTPS URI of the full forensic report (PDF/A)
    /// @param reportHash SHA-256 hash of the canonical JSON report
    /// @param ptvsScore The deterministic PTVS Score (0-100)
    function injectClaim(
        address assetIdentity,
        string calldata reportUri,
        bytes32 reportHash,
        uint256 ptvsScore
    ) external onlyOwner {
        require(ptvsScore <= 100, "PTVS Score must be <= 100");

        // Encode the claim data: URI + Hash + Score
        bytes memory claimData = abi.encode(reportUri, reportHash, ptvsScore);

        // Inject into ONCHAINID
        identityRegistry.addClaim(assetIdentity, PTVS_CLAIM_TOPIC, claimData, msg.sender);

        emit ClaimInjected(assetIdentity, PTVS_CLAIM_TOPIC, reportUri, ptvsScore, block.timestamp);
    }

    /// @notice Circuit breaker: Revokes a claim if physical degradation is detected
    function revokeClaim(address assetIdentity) external onlyOwner {
        identityRegistry.removeClaim(assetIdentity, PTVS_CLAIM_TOPIC);
        emit ClaimRevoked(assetIdentity, PTVS_CLAIM_TOPIC);
    }
}

📝 Step 2: Structuring the Off-Chain Canonical JSON

Before calling the smart contract, the forensic data must be standardized. PTVS v1.0 mandates a specific JSON schema to ensure deterministic hashing.

{
  "ptvs_version": "1.0",
  "asset_id": "SPV-NAV-2026-001",
  "asset_type": "industrial_real_estate",
  "inspection_date": "2026-08-15T10:00:00Z",
  "ptce_expert_id": "PTCE-2026-0001",
  "ptvs_score": 91,
  "pillars": {
    "structural_integrity": "PASS",
    "legal_encumbrances": "CLEAR",
    "environmental_compliance": "PASS",
    "documentation": "COMPLETE"
  },
  "report_uri": "ipfs://QmXyZ.../navarres_report.pdf"
}

Developer Note: To generate the reportHash, you must stringify this JSON without extra whitespace (canonicalization) and compute the SHA-256 hash. This ensures that any tampering with the off-chain PDF will result in a hash mismatch.

⛓️ Step 3: On-Chain Injection (Frontend / Backend Script)

Once the hash is generated, your backend (or the PTCE's dashboard) will call the injectClaim function. Here is how you do it using ethers.js:

const { ethers } = require("ethers");

// 1. Connect to provider and signer (e.g., the authorized PTCE wallet)
const provider = new ethers.providers.JsonRpcProvider("https://polygon-amoy.g.alchemy.com/v2/YOUR_API_KEY");
const signer = new ethers.Wallet("YOUR_PRIVATE_KEY", provider);

// 2. Contract ABI and Address (Deployed on Polygon Amoy for testing)
const contractAddress = "0xYourDeployedPTVSInjectorAddress";
const abi = [ /* Paste the ABI of PTVSClaimInjector here */ ];
const injector = new ethers.Contract(contractAddress, abi, signer);

// 3. Prepare the data
const assetIdentity = "0xAssetOnchainIDAddress";
const reportUri = "ipfs://QmXyZ.../navarres_report.pdf";
const reportHash = ethers.utils.id(JSON.stringify(canonicalJson)); // SHA-256 hash
const ptvsScore = 91;

// 4. Execute the transaction
async function injectVerification() {
    console.log("Injecting PTVS Claim...");
    const tx = await injector.injectClaim(assetIdentity, reportUri, reportHash, ptvsScore);
    console.log("Transaction sent:", tx.hash);

    const receipt = await tx.wait();
    console.log("Claim successfully injected on-chain!");
}

injectVerification();

🔍 Step 4: Reading the Claim (The "Circuit Breaker" Logic)

Now that the claim is on-chain, your RWA platform's compliance contract can read it before allowing a transfer or a dividend payout.

function canTransfer(address from, address to, uint256 amount) public view override returns (bool) {
    // 1. Check standard ERC-3643 compliance (KYC/AML)
    if (!super.canTransfer(from, to, amount)) return false;

    // 2. Check Physical Verification Status
    bytes memory claimData = identityRegistry.getClaim(assetIdentity, PTVS_CLAIM_TOPIC);
    require(claimData.length > 0, "Transfer blocked: No active PTVS physical verification");

    // Decode the score
    (, , uint256 score) = abi.decode(claimData, (string, bytes32, uint256));

    // Circuit breaker: Block transfers if the physical score drops below 70
    require(score >= 70, "Transfer blocked: Asset physical score below minimum threshold");

    return true;
}

🌍 Real-World Validation: Proyecto Navarrés

This is not theoretical. The PTVS v1.0 methodology was empirically validated on Proyecto Navarrés, a 108,000 m² industrial real estate development in Valencia, Spain.

Inspection: Full forensic pathology and NDT (Non-Destructive Testing) by a sworn judicial expert.
Result: PTVS Score of 91/100.
On-Chain: The canonical hash and Verifiable Claim were successfully injected, creating an immutable link between the physical reality and the digital token.

🚀 What's Next for Your Platform?

The €1 trillion RWA market will be won by platforms that can prove both digital compliance and physical integrity.

Don't wait for regulatory mandates to force your hand. Get ahead of MiCA enforcement by integrating physical verification today.

🔗 Resources for Developers:

🧪 Try the Interactive Sandbox (5 mins, no backend): proptrustverified.com/sandbox
📂 Full GitHub Repository (Solidity + JSON Schemas): github.com/aurema-group/prop-trust-verified-standard
📄 PTVS v1.0 Reference Architecture (CERN/Zenodo DOI): 10.5281/zenodo.21719175

Building in RWA? Drop a comment below if you have questions about integrating PTVSClaimInjector.sol with your specific ERC-3643 setup. I monitor this thread daily.

Veritas in Re · Certitudo in Code

Aurelio Tamarit Blay | Lead Researcher, Forensics Oracle Initiative | Creator of PTVS v1.0


---

### 🎯 INSTRUCCIONES DE PUBLICACIÓN EN DEV.TO

1. **Ve a:** [https://dev.to/new](https://dev.to/new)
2. **Copia y pega** todo el texto Markdown de arriba (desde `---` hasta el final).
3. **Portada (Cover Image):** Dev.to te pedirá una imagen. Usa este enlace de Unsplash (ya está en el frontmatter, pero puedes subirlo manualmente si prefieres):  
   `https://images.unsplash.com/photo-1555949963-aa79dcee981c?auto=format&fit=crop&w=1200&q=80` (Muestra código + arquitectura, perfecto para el tema).
4. **Tags:** Asegúrate de que estén exactamente así: `blockchain`, `web3`, `solidity`, `rwa`, `smartcontracts`. (Dev.to permite hasta 4-5 tags, estos son los de mayor tráfico para tu nicho).
5. **Series:** Si tienes una serie creada en Dev.to, añádela a "Physical Oracle Gap Series". Si no, déjalo en blanco.
6. **Canonical URL:** Ya está configurada en el frontmatter con la URL que me has pasado, lo que protege tu SEO.
7. **Publicar:** Haz clic en **"Publish"**.

---

### 🔄 SECUENCIA DE DISTRIBUCIÓN POST-PUBLICACIÓN (Inmediata)

Una vez publicado, copia este texto y pégalo en **LinkedIn** (como comentario en tu propio post de Medium o como un post nuevo):

text
👨‍💻 For the builders: I just published a complete, step-by-step technical guide on Dev.to for integrating physical verification into RWA platforms.

It includes:
✅ Full Solidity code for PTVSClaimInjector.sol
✅ Canonical JSON schema + SHA-256 hashing logic
✅ ERC-3643 / ONCHAINID compatibility examples
✅ Circuit breaker logic for token transfers

If you are building in RWA, this is the missing layer between your smart contract and physical reality.

🔗 Read & fork the code: https://dev.to/aurema_group_ee4f7593374a/integrating-physical-verification-into-your-rwa-platform-a-step-by-step-guide-with-ptvs-v10-25pd

🧪 Try the 5-minute sandbox first: proptrustverified.com/sandbox

Questions? Drop them in the Dev.to comments. I'm monitoring the thread.

Web3 #Solidity #RWA #SmartContracts #Blockchain #MiCA #Developer

INTEGRATING PHYSICAL VERIFICATION INTO YOUR RWA PLATFORM: A STEP-BY-STEP GUIDE WITH PTVS v1.0

Aurelio Tamarit Blay — Sun, 16 Aug 2026 17:18:54 +0000

INTEGRATING PHYSICAL VERIFICATION INTO YOUR RWA PLATFORM: A STEP-BY-STEP GUIDE WITH PTVS v1.0

How to add on-chain physical verification to tokenized real-world assets using PTVSClaimInjector.sol

If you're building an RWA tokenization platform, you've probably hit this wall:

Your smart contract knows who owns the token, but it doesn't know if the asset behind the token still exists.

MiCA Art. 36 requires continuous proof of reserve assets. Price oracles give you market value, but they can't verify physical integrity. You need physical verification — and it needs to be on-chain, deterministic, and legally admissible.

In this tutorial, I'll show you how to integrate the Prop Trust Verified Standard (PTVS v1.0) into your existing RWA platform using the open-source PTVSClaimInjector.sol smart contract.

What you'll build:

Deploy PTVSClaimInjector on a testnet
Generate a forensic inspection report (canonical JSON)
Compute SHA-256 hash
Inject a Verifiable Claim on-chain
Query the claim from your dApp
Integrate with ERC-3643/T-REX for compliance

Time required: approximately 1 hour
Prerequisites: Basic Solidity, familiarity with Hardhat or Foundry, MetaMask wallet

Let's build.

STEP 1: UNDERSTAND THE ARCHITECTURE

Before writing code, let's understand the data flow:

Key concept: The forensicHash is the cryptographic link between the physical evidence (PDF/A report) and the on-chain claim. Any modification to the report changes the hash, making tampering detectable.

STEP 2: DEPLOY PTVSCLAIMINJECTOR

2.1 Get the Contract

PTVSClaimInjector is open-source (MIT License). Clone the repository:

git clone https://github.com/aurema-group/ptvs-sdk-python.git
cd ptvs-sdk-python

Or install via npm (for JavaScript/TypeScript projects):

npm install @aurema-group/ptvs-sdk

2.2 Contract Source Code

Here's the complete PTVSClaimInjector.sol contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/Ownable.sol";

contract PTVSClaimInjector is Ownable {

    enum ClaimStatus { VERIFIED, CONDITIONAL, EXPIRED, REVOKED }

    struct VerifiableClaim {
        bytes32 assetId;
        uint8 ptvsScore;
        bytes32 forensicHash;
        uint256 inspectionTimestamp;
        address ptceAddress;
        ClaimStatus status;
    }

    mapping(bytes32 => VerifiableClaim) public claims;
    mapping(address => bool) public authorizedPTCEs;

    event ClaimInjected(
        bytes32 indexed assetId,
        uint8 ptvsScore,
        bytes32 forensicHash,
        address indexed ptceAddress,
        uint256 timestamp
    );

    event ClaimRenewed(
        bytes32 indexed assetId,
        uint8 newScore,
        bytes32 newHash,
        uint256 timestamp
    );

    event ClaimRevoked(
        bytes32 indexed assetId,
        string reason,
        uint256 timestamp
    );

    event CircuitBreakerTriggered(
        bytes32 indexed assetId,
        uint8 score,
        string action,
        uint256 timestamp
    );

    modifier onlyAuthorizedPTCE() {
        require(authorizedPTCEs[msg.sender], "Not authorized PTCE");
        _;
    }

    constructor() Ownable(msg.sender) {}

    function authorizePTCE(address ptce) external onlyOwner {
        authorizedPTCEs[ptce] = true;
    }

    function revokePTCE(address ptce) external onlyOwner {
        authorizedPTCEs[ptce] = false;
    }

    function injectClaim(
        bytes32 assetId,
        uint8 ptvsScore,
        bytes32 forensicHash,
        uint256 inspectionTimestamp,
        bytes memory ptceSignature
    ) external onlyAuthorizedPTCE {

        ClaimStatus status;
        if (ptvsScore >= 70) {
            status = ClaimStatus.VERIFIED;
        } else if (ptvsScore >= 50) {
            status = ClaimStatus.CONDITIONAL;
        } else {
            status = ClaimStatus.REVOKED;
        }

        claims[assetId] = VerifiableClaim({
            assetId: assetId,
            ptvsScore: ptvsScore,
            forensicHash: forensicHash,
            inspectionTimestamp: inspectionTimestamp,
            ptceAddress: msg.sender,
            status: status
        });

        emit ClaimInjected(
            assetId,
            ptvsScore,
            forensicHash,
            msg.sender,
            block.timestamp
        );

        // Trigger circuit breaker if needed
        if (status == ClaimStatus.REVOKED) {
            emit CircuitBreakerTriggered(
                assetId,
                ptvsScore,
                "Trading paused",
                block.timestamp
            );
        }
    }

    function renewClaim(
        bytes32 assetId,
        uint8 newScore,
        bytes32 newHash,
        uint256 newTimestamp,
        bytes memory ptceSignature
    ) external onlyAuthorizedPTCE {
        require(claims[assetId].assetId != bytes32(0), "Claim does not exist");

        ClaimStatus newStatus;
        if (newScore >= 70) {
            newStatus = ClaimStatus.VERIFIED;
        } else if (newScore >= 50) {
            newStatus = ClaimStatus.CONDITIONAL;
        } else {
            newStatus = ClaimStatus.REVOKED;
        }

        claims[assetId] = VerifiableClaim({
            assetId: assetId,
            ptvsScore: newScore,
            forensicHash: newHash,
            inspectionTimestamp: newTimestamp,
            ptceAddress: msg.sender,
            status: newStatus
        });

        emit ClaimRenewed(assetId, newScore, newHash, block.timestamp);
    }

    function revokeClaim(
        bytes32 assetId,
        string calldata reason
    ) external onlyOwner {
        require(claims[assetId].assetId != bytes32(0), "Claim does not exist");

        claims[assetId].status = ClaimStatus.REVOKED;

        emit ClaimRevoked(assetId, reason, block.timestamp);
        emit CircuitBreakerTriggered(
            assetId,
            claims[assetId].ptvsScore,
            reason,
            block.timestamp
        );
    }

    function getClaim(bytes32 assetId) 
        external 
        view 
        returns (VerifiableClaim memory) 
    {
        return claims[assetId];
    }

    function isClaimValid(bytes32 assetId) external view returns (bool) {
        VerifiableClaim memory claim = claims[assetId];
        return claim.status == ClaimStatus.VERIFIED;
    }
}

2.3 Deploy to Testnet

Using Hardhat:

npx hardhat run scripts/deploy.js --network sepolia

Or using Foundry:

forge create src/PTVSClaimInjector.sol:PTVSClaimInjector --rpc-url $SEPOLIA_RPC_URL --private-key $PRIVATE_KEY

Save the deployed contract address — you'll need it for the next steps.

STEP 3: GENERATE CANONICAL JSON AND COMPUTE HASH

3.1 Create Inspection Data

First, create the inspection findings:

Python example:

import json
from Crypto.Hash import SHA256

inspection_data = {
    "assetId": "0x1a2b3c4d5e6f7890abcdef1234567890abcdef1234567890abcdef12345678",
    "assetName": "Edificio residencial · Calle Mayor 42, Valencia",
    "assetType": "real_estate",
    "inspectionDate": "2026-08-15T10:30:00Z",
    "jurisdiction": "ES-VC",
    "ptceId": "PTCE-0161",
    "ptvsScore": 85,
    "structural": {
        "score": 85,
        "cracks": 0,
        "corrosion": 1,
        "degradation": 0
    },
    "legal": {
        "score": 92,
        "encumbrances": 0,
        "titleClear": True
    },
    "environmental": {
        "score": 78,
        "contamination": 0,
        "hazards": 0
    },
    "documentation": {
        "score": 95
    },
    "insurance": {
        "score": 88,
        "active": True
    },
    "notes": "Minor corrosion detected on balcony railings. Recommend treatment within 6 months."
}

3.2 Canonicalize JSON

Canonical JSON ensures deterministic serialization (sorted keys, no whitespace):

# Canonicalize: sort keys alphabetically, remove whitespace
canonical_json = json.dumps(
    inspection_data, 
    sort_keys=True, 
    separators=(',', ':'),
    ensure_ascii=False
)

print("Canonical JSON:")
print(canonical_json)

Output example:

{"assetId":"0x1a2b3c4d5e6f7890abcdef1234567890abcdef1234567890abcdef12345678","assetName":"Edificio residencial · Calle Mayor 42, Valencia","assetType":"real_estate",...}

3.3 Compute SHA-256 Hash

# Compute SHA-256 hash
hash_obj = SHA256.new(canonical_json.encode('utf-8'))
forensic_hash = '0x' + hash_obj.hexdigest()

print(f"Forensic Hash: {forensic_hash}")
# Output: 0xa3f2b8c9d4e5f6789012345678901234567890abcdef1234567890abcdef12345678

This hash is what you'll inject on-chain. It's the cryptographic link between your physical evidence and the on-chain claim.

STEP 4: INJECT CLAIM ON-CHAIN

4.1 Python Integration (Web3.py)

from web3 import Web3

# Connect to testnet
w3 = Web3(Web3.HTTPProvider('https://sepolia.infura.io/v3/YOUR_PROJECT_ID'))

# Contract ABI (simplified)
abi = [
    {
        "inputs": [
            {"name": "assetId", "type": "bytes32"},
            {"name": "ptvsScore", "type": "uint8"},
            {"name": "forensicHash", "type": "bytes32"},
            {"name": "inspectionTimestamp", "type": "uint256"},
            {"name": "ptceSignature", "type": "bytes"}
        ],
        "name": "injectClaim",
        "outputs": [],
        "stateMutability": "nonpayable",
        "type": "function"
    },
    {
        "inputs": [{"name": "assetId", "type": "bytes32"}],
        "name": "getClaim",
        "outputs": [
            {
                "components": [
                    {"name": "assetId", "type": "bytes32"},
                    {"name": "ptvsScore", "type": "uint8"},
                    {"name": "forensicHash", "type": "bytes32"},
                    {"name": "inspectionTimestamp", "type": "uint256"},
                    {"name": "ptceAddress", "type": "address"},
                    {"name": "status", "type": "uint8"}
                ],
                "name": "",
                "type": "tuple"
            }
        ],
        "stateMutability": "view",
        "type": "function"
    }
]

# Load contract
contract_address = '0xYOUR_DEPLOYED_CONTRACT_ADDRESS'
contract = w3.eth.contract(address=contract_address, abi=abi)

# PTCE account (must be authorized)
ptce_account = w3.eth.account.from_key('YOUR_PTCE_PRIVATE_KEY')

# Prepare transaction
asset_id = bytes.fromhex(inspection_data['assetId'][2:])  # Remove '0x'
ptvs_score = inspection_data['ptvsScore']
forensic_hash = bytes.fromhex(forensic_hash[2:])  # Remove '0x'
inspection_timestamp = int(datetime.now().timestamp())
ptce_signature = b''  # In production, this would be the QES signature

# Build transaction
nonce = w3.eth.get_transaction_count(ptce_account.address)
tx = contract.functions.injectClaim(
    asset_id,
    ptvs_score,
    forensic_hash,
    inspection_timestamp,
    ptce_signature
).build_transaction({
    'from': ptce_account.address,
    'nonce': nonce,
    'gas': 200000,
    'gasPrice': w3.eth.gas_price
})

# Sign and send
signed_tx = ptce_account.sign_transaction(tx)
tx_hash = w3.eth.send_raw_transaction(signed_tx.raw_transaction)

print(f"Transaction sent: {tx_hash.hex()}")

# Wait for confirmation
receipt = w3.eth.wait_for_transaction_receipt(tx_hash)
print(f"Transaction confirmed in block {receipt.blockNumber}")

4.2 JavaScript Integration (Web3.js)

const Web3 = require('web3');
const crypto = require('crypto');

// Connect to testnet
const web3 = new Web3('https://sepolia.infura.io/v3/YOUR_PROJECT_ID');

// Contract instance
const contractAddress = '0xYOUR_DEPLOYED_CONTRACT_ADDRESS';
const contract = new web3.eth.Contract(ABI, contractAddress);

// PTCE account
const ptceAccount = web3.eth.accounts.privateKeyToAccount('YOUR_PTCE_PRIVATE_KEY');
web3.eth.accounts.wallet.add(ptceAccount);

// Inspection data
const inspectionData = {
  assetId: '0x1a2b3c4d5e6f7890abcdef1234567890abcdef1234567890abcdef12345678',
  ptvsScore: 85,
  // ... rest of inspection data
};

// Compute forensic hash (same as Python example)
const canonicalJson = JSON.stringify(inspectionData, Object.keys(inspectionData).sort());
const forensicHash = '0x' + crypto.createHash('sha256').update(canonicalJson).digest('hex');

// Inject claim
async function injectClaim() {
  const tx = await contract.methods.injectClaim(
    inspectionData.assetId,
    inspectionData.ptvsScore,
    forensicHash,
    Math.floor(Date.now() / 1000),
    '0x'  // ptceSignature
  ).send({
    from: ptceAccount.address,
    gas: 200000
  });

  console.log('Transaction hash:', tx.transactionHash);
  return tx;
}

injectClaim().catch(console.error);

STEP 5: QUERY AND VERIFY CLAIMS

5.1 Read Claim from Contract

# Query claim
claim = contract.functions.getClaim(asset_id).call()

print(f"Asset ID: 0x{claim[0].hex()}")
print(f"PTVS Score: {claim[1]}")
print(f"Forensic Hash: 0x{claim[2].hex()}")
print(f"Inspection Timestamp: {claim[3]}")
print(f"PTCE Address: {claim[4]}")
print(f"Status: {['VERIFIED', 'CONDITIONAL', 'EXPIRED', 'REVOKED'][claim[5]]}")

5.2 Verify Claim Independently

Any third party can verify the claim by recomputing the hash:

def verify_claim(claim, original_json):
    """Verify that on-chain claim matches original inspection report."""

    # Recompute hash from original JSON
    recomputed_hash = '0x' + SHA256.new(original_json.encode('utf-8')).hexdigest()

    # Compare with on-chain hash
    on_chain_hash = '0x' + claim[2].hex()

    if recomputed_hash == on_chain_hash:
        print("Verification successful: hashes match")
        return True
    else:
        print("Verification failed: hashes do not match")
        print(f"  Expected: {on_chain_hash}")
        print(f"  Got:      {recomputed_hash}")
        return False

# Verify the claim
verify_claim(claim, canonical_json)

STEP 6: INTEGRATE WITH ERC-3643/T-REX

If you're using ERC-3643/T-REX for identity and compliance, here's how to integrate PTVS:

6.1 Architecture

ERC-3643/T-REX
├─ Identity Registry (ONCHAINID)
├─ Compliance Module
└─ Token Contract
                ↕
PTVSClaimInjector (PTVS v1.0)
├─ Physical verification claims
├─ PTVS Score enforcement
└─ Circuit breaker actions

6.2 Compliance Integration Example

// In your token contract
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "./PTVSClaimInjector.sol";

contract RWA_Token is ERC20 {
    PTVSClaimInjector public ptvsInjector;
    bytes32 public assetId;

    constructor(
        address _ptvsInjector,
        bytes32 _assetId
    ) ERC20("Real World Asset Token", "RWAT") {
        ptvsInjector = PTVSClaimInjector(_ptvsInjector);
        assetId = _assetId;
    }

    function transfer(address to, uint256 amount) public override returns (bool) {
        // Check PTVS claim before allowing transfer
        require(
            ptvsInjector.isClaimValid(assetId),
            "Transfer blocked: asset verification expired or revoked"
        );

        return super.transfer(to, amount);
    }
}

This ensures that tokens cannot be transferred if the physical asset verification has expired or been revoked.

STEP 7: BUILD A FRONTEND VERIFICATION WIDGET

7.1 HTML + JavaScript Widget

<!DOCTYPE html>
<html>
<head>
    <title>PTVS Verification Widget</title>
    <script src="https://cdn.jsdelivr.net/npm/web3@latest/dist/web3.min.js"></script>
</head>
<body>
    <h1>Asset Verification</h1>
    <input type="text" id="assetId" placeholder="Enter Asset ID (0x...)">
    <button onclick="verifyAsset()">Verify</button>

    <div id="result"></div>

    <script>
        const web3 = new Web3('https://sepolia.infura.io/v3/YOUR_PROJECT_ID');
        const contractAddress = '0xYOUR_DEPLOYED_CONTRACT_ADDRESS';
        const contractABI = [/* ABI here */];
        const contract = new web3.eth.Contract(contractABI, contractAddress);

        async function verifyAsset() {
            const assetId = document.getElementById('assetId').value;
            const claim = await contract.methods.getClaim(assetId).call();

            const statusMap = ['VERIFIED', 'CONDITIONAL', 'EXPIRED', 'REVOKED'];
            const status = statusMap[claim.status];

            let html = `
                <h2>Verification Result</h2>
                <p><strong>Asset ID:</strong> ${claim.assetId}</p>
                <p><strong>PTVS Score:</strong> ${claim.ptvsScore}/100</p>
                <p><strong>Status:</strong> ${status}</p>
                <p><strong>Inspection Date:</strong> ${new Date(claim.inspectionTimestamp * 1000).toLocaleString()}</p>
                <p><strong>PTCE Address:</strong> ${claim.ptceAddress}</p>
            `;

            if (status === 'VERIFIED') {
                html += '<p style="color: green;">Asset is verified and eligible for trading</p>';
            } else if (status === 'CONDITIONAL') {
                html += '<p style="color: orange;">Asset is conditional - increased risk</p>';
            } else {
                html += '<p style="color: red;">Asset verification revoked - trading paused</p>';
            }

            document.getElementById('result').innerHTML = html;
        }
    </script>
</body>
</html>

STEP 8: TEST THE FULL FLOW

8.1 Try the Sandbox First

Before deploying to production, test the complete flow in our public sandbox:

https://proptrustverified.com/sandbox/

The sandbox lets you:

Define a mock asset
Run a forensic inspection
Compute SHA-256 hash
Simulate on-chain claim injection
Verify the claim

No backend required. All computations happen in your browser.

8.2 Production Checklist

Before going to mainnet:

Security audit of your integration code
Deploy PTVSClaimInjector to mainnet (or L2 like Arbitrum/Polygon for lower gas)
Authorize your PTCE addresses
Test circuit breaker logic with mock degraded assets
Integrate with your existing compliance workflow
Add monitoring for claim expiration (90-day re-audit cycle)
Document the verification process for your users

REAL-WORLD EXAMPLE: PROYECTO NAVARRÉS

To see this in action with a real asset, check out Proyecto Navarrés:

Asset: 108,000 m² urbanizable land in Valencia, Spain
PTVS Score: 91/100 (VERIFIED)
Status: Live on-chain with Verifiable Claim
Case study: https://forensics-oracle.org/case-studies/navarres/

This demonstrates that PTVS v1.0 is not theoretical — it's been executed against real assets.

RESOURCES

Reference Architecture: https://doi.org/10.5281/zenodo.21719175
GitHub: https://github.com/aurema-group/ptvs-sdk-python
Sandbox: https://proptrustverified.com/sandbox/
Compatibility Program: https://forensics-oracle.org/compatibility/

QUESTIONS?

If you run into issues integrating PTVS, drop a comment below or reach out:

Technical support: enterprise@proptrustverified.com
Discord: https://discord.gg/forensics-oracle
GitHub Issues: https://github.com/aurema-group/ptvs-sdk-python/issues

Happy building!

Aurelio Tamarit Blay is the Lead Researcher of the Forensics Oracle Initiative and creator of the Prop Trust Verified Standard (PTVS v1.0). He is a sworn judicial expert (Exp. No. 0161, Spain) with 33 years of forensic practice. ORCID: 0009-0007-5824-3602.

Tags: blockchain smartcontracts rwa solidity

DEV Community: Aurelio Tamarit Blay

PFOI vs PTVS: Understanding the New Infrastructure Category Solving RWA's Physical Oracle Problem

canonical_url: https://dev.to/aurema_group_ee4f7593374a/pfoi-vs-ptvs-understanding-the-new-infrastructure-category-solving-rwas-physical-oracle-problem

🏗️ The Analogy: Internet vs TCP/IP

📚 What is PFOI? (The Category)

Formal Definition:

What PFOI Encompasses:

Why PFOI Exists:

What is PTVS? (The Standard)

The Four Pillars of PTVS v1.0:

PTVS Score (0-100):

🔍 Key Differences: Category vs Standard

💡 Why This Distinction Matters

For Platform Builders (Tokeny, Brickken, RealT):

For Institutional Investors (Family Offices, Banks):

For Regulators (ESMA, CNMV, ECB):

For Developers:

Real-World Validation: Proyecto Navarrés

The Economic Flywheel

🛠️ Try It Yourself (5 Minutes)

References & Further Reading

🎯 The Bottom Line

Integrating Physical Verification into Your RWA Platform: A Step-by-Step Guide with PTVS v1.0

canonical_url: https://dev.to/aurema_group_ee4f7593374a/integrating-physical-verification-into-your-rwa-platform-a-step-by-step-guide-with-ptvs-v10-25pd

🏗️ The Architecture: How PTVS Fits Your Stack

🛠️ Step 1: The Smart Contract (PTVSClaimInjector.sol)

📝 Step 2: Structuring the Off-Chain Canonical JSON

⛓️ Step 3: On-Chain Injection (Frontend / Backend Script)

🔍 Step 4: Reading the Claim (The "Circuit Breaker" Logic)

🌍 Real-World Validation: Proyecto Navarrés

🚀 What's Next for Your Platform?

🔗 Resources for Developers:

Web3 #Solidity #RWA #SmartContracts #Blockchain #MiCA #Developer

INTEGRATING PHYSICAL VERIFICATION INTO YOUR RWA PLATFORM: A STEP-BY-STEP GUIDE WITH PTVS v1.0

🛠️ Step 1: The Smart Contract (`PTVSClaimInjector.sol`)