Prop Trust Verified Standard (PTVS) v1.0

Abstract

The Prop Trust Verified Standard (PTVS) v1.0 presents a deterministic, four-pillar architecture for the physical verification of tokenized Real-World Assets (RWAs) within the European regulatory framework.

PTVS resolves the “Physical Oracle Gap” — the structural inability of Distributed Ledger Technology (DLT) systems to attest to the physical existence, structural integrity, and legal encumbrances of off-chain assets backing tokenized securities.

The standard integrates four complementary layers: (1) on-site forensic inspections conducted by sworn judicial experts under eIDAS 2.0 Qualified Electronic Signatures (QES), (2) off-chain SHA-256 canonical hashing for cryptographic lineage, (3) on-chain Verifiable Claims injected via the PTVSClaimInjector smart contract with automated circuit breakers, and (4) a decentralized network of Prop Trust Certified Experts (PTCEs) ensuring geographic and jurisdictional coverage.

PTVS v1.0 has been formally submitted to the four European Supervisory Authorities (ESMA, EBA, EIOPA) and the European Central Bank (ECB/SSM), permanently registered at CERN/Zenodo, HAL/CNRS, OSF, and the U.S. Copyright Office, and is governed by the PTVS Technical Board — an open, multi-stakeholder governance body inspired by W3C and ISO models.

This Reference Architecture document establishes the definitive technical specification, capability matrix, and implementation guidelines for PTVS v1.0, serving as the authoritative reference for institutional adoption, regulatory review, and future standard evolution.

Keywords: Physical Oracle, RWA Tokenization, MiCA, eIDAS 2.0, ERC-3643, T-REX, Verifiable Claims, Circuit Breakers, Forensic Engineering, PFOI, PTVS

Executive Summary

2.1 The Problem

The European tokenization market has achieved regulatory clarity under Regulation (EU) 2023/1114 (MiCA), yet the physical-digital bridge remains architecturally under-specified. While MiCA establishes comprehensive requirements for reserve verification (Art. 36), custody obligations (Art. 45), and investor protection, it contains a structural blind spot: no mechanism exists to deterministically verify the physical state of Real-World Assets backing tokenized securities.

This gap — which we define as the Physical Oracle Problem — creates systemic risk:

• Toxic RWAs: Assets with hidden structural pathologies, legal encumbrances, or environmental damage are tokenized without verification
• Information asymmetry: On-chain compliance is perfect, but physical reality is opaque
• Institutional risk: Banks, insurers, and pension funds cannot meet Solvency II, IORP II, or Basel III requirements without physical verification
• Regulatory exposure: MiCA Art. 36 reserve requirements cannot be demonstrated without physical attestation

2.2 The Solution

PTVS v1.0 resolves the Physical Oracle Problem through a four-pillar deterministic architecture:

2.3 Key Differentiators

PTVS v1.0 is not a price oracle (like Chainlink), not a proof-of-reserve mechanism (like traditional PoR), and not a traditional audit methodology (like Big Four engagements). It is the first standard specifically designed for the physical verification of tokenized RWAs, combining:

2.4 Institutional Validation

PTVS v1.0 has been validated through:

• 4 regulatory submissions (ESMA, EBA, EIOPA confirmed, ECB/SSM via ADITO)
• 1 industry submission (INATBA RWA Working Group)
• 4 permanent scientific registries (CERN/Zenodo, HAL/CNRS, OSF, U.S. Copyright)
• Open-source implementation (PTVSClaimInjector.sol, MIT License)
• Technical Board governance (17 seats, W3C-inspired)

Introduction: The Physical Oracle Problem

3.1 Definition

The Physical Oracle Problem is the structural inability of Distributed Ledger Technology (DLT) systems to attest to the physical existence, structural integrity, and legal encumbrances of off-chain assets backing tokenized securities, Asset-Referenced Tokens (ARTs), and Eurosystem collateral.

3.2 Regulatory Context

European regulation mandates physical verification but does not specify mechanisms:

MiCA Regulation (EU 2023/1114)

• Art. 36: Issuers of ARTs must maintain reserves “sufficient to cover claims” at all times
• Art. 45: Crypto-asset service providers must segregate and safeguard reserve assets
• Unresolved question: How does the issuer prove the physical asset still exists and retains value?

Solvency II Directive (2009/138/EC)

• Art. 84: Insurers must value investments with “appropriate methods” ensuring reliability
• Unresolved question: How is physical degradation (e.g., structural pathology) reflected on-chain?

Eurosystem Collateral Framework (Guideline EU 2015/510)

• Eligible collateral must meet “high credit standards” verified periodically
• Unresolved question: What oracle attests to physical condition of real estate collateral?

eIDAS 2.0 Regulation (EU 2024/1183)

• Qualified electronic signatures have equivalent legal effect to handwritten ones
• Unresolved question: How is a qualified judicial attestation injected into DLT systems?

3.3 Failure Modes Without Physical Verification

Absent deterministic physical verification, the following failure modes emerge:

1. Structural degradation: A tokenized building develops aluminosis or reinforced concrete carbonation. The token continues trading at pre-degradation value.
2. Hidden encumbrances: A tokenized vessel is arrested in port under maritime lien. The token’s smart contract shows no change in status.
3. Environmental damage: Tokenized agricultural land suffers soil contamination. The on-chain representation remains unchanged.
4. Insurance lapse: Physical asset loses insurance coverage. Token holders are unaware of increased risk exposure.
5. Custodial failure: Physical asset is damaged in custody. No mechanism alerts token holders.

3.4 Why Existing Oracles Cannot Solve This

• Price oracles (Chainlink, Pyth, Band Protocol) provide market data feeds but cannot verify physical state.
• Identity oracles (ONCHAINID, T-REX) provide compliance verification but cannot attest to physical integrity.
• IoT sensors provide continuous data but lack judicial admissibility. A sensor can report “humidity 82%” but cannot produce a legally binding forensic attestation.
• Traditional audits (Big Four, local firms) produce PDF reports but lack cryptographic anchoring and automated enforcement.

PTVS v1.0 bridges all these gaps by combining judicial authority, cryptographic integrity, smart contract automation, and decentralized execution.

PTVS Architecture Overview

4.1 Four-Pillar Design

PTVS v1.0 is organized into four complementary pillars, each addressing a distinct layer of the Physical Oracle Problem:

4.2 Data Flow

The complete verification flow follows this sequence:

1. Physical Asset → PTCE Expert (on-site inspection)
2. → PDF/A Report (ISO 19005)
3. → QES Signature (eIDAS 2.0) → RFC 3161 Timestamp
4. → Canonical JSON (deterministic serialization)
5. → SHA-256 Hash (cryptographic lineage)
6. → PTVSClaimInjector.sol (smart contract) → Verifiable Claim (on-chain)
7. → ERC-3643/T-REX (identity layer) → Circuit Breaker Actions (automated enforcement)

4.3 Design Principles

PTVS v1.0 is governed by five design principles:

1. Determinism: Every verification produces the same result given the same inputs
2. Judicial admissibility: All evidence meets eIDAS 2.0 standards for legal proceedings
3. Cryptographic integrity: SHA-256 hashing ensures tamper-evident lineage
4. Automated enforcement: Smart contracts trigger protective actions without human intervention
5. Decentralized execution: No single entity controls the verification process

Pillar I: eIDAS 2.0 Qualified Forensic Audits

5.1 Inspection Methodology

PTVS v1.0 inspections follow a standardized methodology:

Phase 1: Pre-Inspection Preparation

• Review asset documentation (title deeds, permits, certificates)
• Identify inspection scope (structural, legal, environmental)
• Prepare inspection checklist based on asset type
• Verify PTCE credentials and jurisdictional eligibility

Phase 2: On-Site Inspection

• Physical examination of asset condition
• Structural pathology detection (cracks, corrosion, degradation)
• Legal title verification (registry status, encumbrances)
• Environmental assessment (contamination, hazards)
• Photographic and sensor documentation

Phase 3: Report Generation

• Structured findings in canonical format
• PTVS Score calculation (0-100)
• Risk assessment and recommendations
• PDF/A rendering (ISO 19005 compliance)

5.2 PDF/A Compliance

All inspection reports are rendered in PDF/A format per ISO 19005:

• PDF/A-1a: Basic compliance (required)
• PDF/A-2a: Enhanced compression (recommended)
• PDF/A-3a: Embedded file support (optional for sensor data)

Key requirements: all fonts embedded, no JavaScript or executable content, metadata includes creation date, author, and standard version, color profile specified (ICC).

5.3 Qualified Electronic Signature (QES)

Reports are signed using eIDAS 2.0 Qualified Electronic Signatures:

• Legal basis: Regulation (EU) 2024/1183 (eIDAS 2.0)
• Effect: Equivalent legal effect to handwritten signatures in all EU Member States
• Requirements: Qualified certificate issued by a Qualified Trust Service Provider (QTSP), Qualified signature creation device (QSCD), Identity verification of signer
• PTCE requirement: All PTCEs must hold valid QES certificates

5.4 RFC 3161 Timestamping

Signed reports are timestamped per RFC 3161:

• Purpose: Prove existence of document at a specific point in time
• Mechanism: Timestamp Authority (TSA) issues signed timestamp token
• Compliance: Qualified timestamps per eIDAS 2.0 Art. 41
• Storage: Timestamp token embedded in PDF/A metadata

Pillar II: SHA-256 Cryptographic Lineage

6.1 Canonical JSON Serialization

Inspection findings are serialized into canonical JSON format:

Canonicalization rules:

1. Keys sorted lexicographically (alphabetical)
2. No whitespace between tokens
3. UTF-8 encoding (no BOM)
4. Numbers represented without trailing zeros
5. Strings use minimal escaping
6. No duplicate keys

Example canonical JSON:

6.2 SHA-256 Hash Generation

The canonical JSON is hashed using SHA-256:

• Algorithm: SHA-256 (FIPS 180-4)
• Input: Canonical JSON bytes (UTF-8)
• Output: 256-bit (32-byte) hash, represented as 64-character hexadecimal string
• Example: a3f2b8c9d4e5f6789012345678901234567890abcdef1234567890abcdef12345678

6.3 Off-Chain Anchoring

SHA-256 hashes are anchored in multiple permanent registries:

6.4 Tamper Detection

Any modification to the original report changes the SHA-256 hash:

• Original JSON → SHA-256 → a3f2b8c9...
• Modified JSON → SHA-256 → f7e6d5c4... (different hash)

This ensures tamper-evident lineage: any party can independently verify that the on-chain claim corresponds to the original inspection report.

Pillar III: Smart Contract Circuit Breakers

7.1 PTVSClaimInjector Overview

The PTVSClaimInjector smart contract is the core on-chain component of PTVS v1.0. It receives Verifiable Claims from off-chain inspections and enforces automated protective actions based on PTVS Score.

Key characteristics:

• License: MIT (open-source)
• Compatibility: ERC-3643/T-REX identity layer
• Deployment: Ethereum mainnet + L2s (Arbitrum, Polygon, Base)
• Audit: Open-source audit by PTCE Technical Board

7.2 Verifiable Claim Structure

Each Verifiable Claim contains:

7.3 Claim States and Transitions

7.4 Circuit Breaker Actions

When a Verifiable Claim transitions to EXPIRED or REVOKED, the smart contract automatically triggers protective actions:

EXPIRED (Score 0-49 or 90-day lapse):

• Trading warnings displayed
• Increased haircuts on collateral value (25%)
• Re-audit required within 90 days

REVOKED (Score < 50 or material degradation):

• Trading paused (circuit breaker)
• Margin calls triggered for leveraged positions
• LTV auto-adjusted (Loan-to-Value ratio reduced)
• Notification sent to all token holders
• Regulatory report filed with relevant NCA

7.5 PTCE Authentication

Only authorized PTCEs can inject Verifiable Claims. PTCE authorization is managed through the ONCHAINID identity layer, ensuring only verified judicial experts can perform inspections.

Pillar IV: PTCE Network

8.1 Network Architecture

The Prop Trust Certified Expert (PTCE) Network is a decentralized network of sworn judicial experts authorized to perform PTVS v1.0 inspections.

Key characteristics:

• Decentralized: No single entity controls the network
• Jurisdictional: PTCEs operate in their licensed jurisdictions
• Revenue model: 85% to PTCE, 15% to network (via Stripe Connect split payments)
• Certification: 40-hour training program + examination

8.2 PTCE Certification Requirements

To become a PTCE, candidates must:

1. Hold valid judicial expert certification in their jurisdiction
2. Demonstrate 5+ years of forensic practice
3. Complete 40-hour training program:
   • Module 1: Legal framework (MiCA, eIDAS 2.0) — 8 hours
   • Module 2: PTVS methodology — 10 hours
   • Module 3: Technical tools (PDF/A, SHA-256, QES) — 8 hours
   • Module 4: Smart contracts (ERC-3643, PTVSClaimInjector) — 6 hours
   • Module 5: Real cases (Navarrés + 2 anonymized) — 4 hours
   • Module 6: Supervised practice — 4 hours
4. Pass certification examination (minimum score: 75/100)
5. Maintain professional liability insurance (minimum €1,000,000)
6. Sign PTCE Code of Conduct

8.3 Revenue Model

PTCEs earn revenue through inspection fees:

Payment processing: Stripe Connect split payments ensure automatic revenue distribution.

8.4 Geographic Coverage

PTCE Network targets coverage across:

• European Union: 27 Member States
• United Kingdom: Post-Brexit regulatory alignment
• Switzerland: FINMA compliance
• United States: SEC/CFTC coordination (future)

Target: 500+ certified PTCEs by 2028

PTVS Score Methodology

9.1 Score Calculation

The PTVS Score is a 0-100 quantitative measure of asset integrity, calculated from weighted sub-scores:

9.2 Sub-Score Definitions

9.3 Score Interpretation

Verifiable Claims Specification

10.1 Claim Lifecycle

Each Verifiable Claim follows this lifecycle:

1. Creation: PTCE performs inspection, generates canonical JSON
2. Signing: Report signed with QES, timestamped with RFC 3161
3. Hashing: SHA-256 hash generated from canonical JSON
4. Injection: PTVSClaimInjector receives claim on-chain
5. Validation: Smart contract verifies PTCE authorization and claim integrity
6. Enforcement: Circuit breaker actions triggered based on PTVS Score
7. Renewal: Claim expires after 90 days; re-audit required for renewal
8. Revocation: Claim revoked if material degradation detected

10.2 Claim Verification

Any party can verify a Verifiable Claim:

1. Retrieve on-chain claim (assetId, ptvsScore, forensicHash, timestamp)
2. Obtain original PDF/A report from PTCE or archive
3. Recompute SHA-256 hash from canonical JSON
4. Compare recomputed hash with on-chain forensicHash
5. Verify QES signature against PTCE’s public certificate
6. Confirm RFC 3161 timestamp validity

Result: Cryptographic proof that the on-chain claim corresponds to the original inspection.

PTVSClaimInjector Technical Specification

11.1 Contract Architecture

11.2 Key Function Signatures

11.3 Events

Integration with ERC-3643/T-REX

12.1 Compatibility Layer

PTVSClaimInjector is designed to integrate with ERC-3643/T-REX identity infrastructure:

12.2 Integration Points

PTVSClaimInjector integrates with ERC-3643/T-REX at three points:

1. Identity verification: PTCE authorization checked via ONCHAINID
2. Compliance coordination: Circuit breaker actions coordinated with T-REX compliance module
3. Token enforcement: Trading pauses enforced at ERC-3643 token contract level

12.3 Deployment Options

PTVSClaimInjector can be deployed:

• Standalone: Independent contract with direct ERC-3643 integration
• Modular: As a module within T-REX compliance framework
• Layer 2: On Arbitrum, Polygon, or Base for reduced gas costs

Regulatory Alignment Matrix

13.1 MiCA Regulation (EU 2023/1114)

13.2 Solvency II Directive (2009/138/EC)

13.3 Eurosystem Collateral Framework (Guideline EU 2015/510)

13.4 eIDAS 2.0 Regulation (EU 2024/1183)

Governance Model

14.1 PTVS Technical Board

The PTVS Technical Board is the open governance body overseeing the evolution of PTVS v1.0.

Total: 17 seats (13 voting + 2 observers)

14.2 Decision Thresholds

• Ordinary resolutions: Simple majority (7/13 votes)
• Constitutional amendments: Qualified majority (10/13 votes + Founder affirmative vote)
• Working Group creation: Simple majority (7/13 votes)
• Standard version updates: Qualified majority (10/13 votes)

14.3 Working Groups

Six specialized Working Groups drive the standard’s evolution:

14.4 Intellectual Property

• Core specification: MIT License (open-source)
• PTVSClaimInjector.sol: MIT License (open-source)
• Canonical JSON schema: MIT License (open-source)
• Trademarks: Prop Trust Verified™, PTVS™, Forensics Oracle™, PFOI™ (Aurema Group L.L.C.)
• Code escrow: Independent third-party agent; transitions to public domain if Aurema ceases operations

Capability Matrix (Prior Art Documentation)

PTVS v1.0 defines 20 distinct capabilities, each documented with implementation specifications. This capability matrix serves as prior art documentation for PTVS v1.0. Any subsequent standard addressing the Physical Oracle Problem must explicitly differentiate itself from these 20 documented capabilities.

Timestamp of creation: 2026-08-14T18:30:00Z · Permanent registry: CERN/Zenodo DOI 10.5281/zenodo.21719175 · Document reference: FOI-RA-2026-001

Comparison with Existing Alternatives

16.1 PTVS vs. Price Oracles (Chainlink, Pyth, Band)

Key insight: Price oracles answer “what is the market price?” PTVS answers “does the asset physically exist and what is its condition?” They are complementary, not competitive.

16.2 PTVS vs. Proof of Reserve (Traditional PoR)

Key insight: PoR verifies quantity. PTVS verifies physical integrity. PTVS encompasses PoR as a subset.

16.3 PTVS vs. IoT Sensors

Key insight: IoT sensors provide continuous data but lack judicial admissibility. PTVS provides judicially admissible attestations. Future integration: PTVS certifies IoT sensor methodologies.

16.4 PTVS vs. Traditional Audit (Big Four)

Key insight: Traditional audits produce PDF reports. PTVS produces cryptographically anchored, smart-contract-enforced Verifiable Claims. Big Four firms can adopt PTVS methodology.

16.5 PTVS vs. Registry Oracles (Legal Oracle)

Key insight: Registry oracles verify legal status. PTVS verifies physical condition AND legal status. PTVS can certify registry oracle data.

Implementation Roadmap

Security Considerations

18.1 Smart Contract Security

• Open-source audit: PTVSClaimInjector.sol is publicly auditable
• Bug bounty program: Planned for Q1 2027
• Formal verification: Planned for v1.1
• Upgrade mechanism: Technical Board approval required for contract upgrades

18.2 PTCE Security

• Identity verification: ONCHAINID-based authentication
• Credential revocation: Technical Board can revoke PTCE authorization
• Liability insurance: Minimum €1,000,000 professional liability coverage
• Code of Conduct: Mandatory adherence, enforced by Ethics Committee

18.3 Data Security

• Canonical JSON: Deterministic serialization prevents manipulation
• SHA-256: Cryptographic integrity ensures tamper-evidence
• QES: Qualified signatures ensure non-repudiation
• RFC 3161: Qualified timestamps ensure temporal integrity

18.4 Governance Security

• Multi-stakeholder governance: No single entity controls the standard
• Qualified majority: Constitutional amendments require 10/13 votes
• Code escrow: Independent third-party agent holds source code
• Regulatory oversight: ESAs and ECB as observers

Official Terminology

A.1 PFOI (Physical Forensic Oracle Infrastructure)

Definition: A multi-billion dollar market 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.

Scope: PFOI encompasses all infrastructure, methodologies, standards, and networks that enable deterministic physical verification of off-chain assets backing tokenized securities.

Relationship to PTVS: PTVS v1.0 is the first and defining standard within the PFOI category.

A.2 PTVS (Prop Trust Verified Standard)

Definition: A deterministic, four-pillar standard for the physical verification of tokenized Real-World Assets, combining eIDAS 2.0 qualified forensic audits, SHA-256 cryptographic lineage, smart contract circuit breakers, and a decentralized expert network.

Version: 1.0.0 (current) · License: MIT (core specification), CC BY-NC-ND 4.0 (documentation)

Governing body: PTVS Technical Board

A.3 PTCE (Prop Trust Certified Expert)

Definition: A sworn judicial expert certified under PTVS v1.0 methodology to perform on-site forensic inspections of Real-World Assets. PTCEs hold valid judicial expert certifications in their jurisdictions and have completed the 40-hour PTVS training program.

Requirements: Judicial expert certification + 5 years experience + 40-hour training + examination + insurance + Code of Conduct

A.4 PTVS Claim (Verifiable Claim)

Definition: A cryptographically signed on-chain attestation of the physical state of a Real-World Asset, containing assetId, ptvsScore, forensicHash, inspectionTimestamp, ptceAddress, and status.

Lifecycle: Creation → Signing → Hashing → Injection → Validation → Enforcement → Renewal/Revocation

A.5 PTVSClaimInjector

Definition: An open-source (MIT License) smart contract that receives Verifiable Claims from off-chain PTVS inspections and enforces automated protective actions (circuit breakers) based on PTVS Score.

Compatibility: ERC-3643/T-REX identity layer · Deployment: Ethereum mainnet + L2s

A.6 Physical Oracle Gap

Definition: The structural inability of Distributed Ledger Technology (DLT) systems to attest to the physical existence, structural integrity, and legal encumbrances of off-chain assets backing tokenized securities.

Resolution: PTVS v1.0 resolves the Physical Oracle Gap through its four-pillar architecture.

A.7 Verified by PTVS

Definition: A public certification badge indicating that a Real-World Asset has been verified under PTVS v1.0 methodology, with a current PTVS Score ≥ 70 and a valid Verifiable Claim on-chain.

Display: Widget embeddable on platform websites, investor materials, and regulatory filings.

A.8 PTVS Score

Definition: A 0-100 quantitative measure of asset integrity, calculated from weighted sub-scores: Structural (40%), Legal (25%), Environmental (20%), Documentation (10%), Insurance (5%).

Interpretation: 70-100: VERIFIED · 50-69: CONDITIONAL · 0-49: REVOKED

A.9 Circuit Breaker

Definition: An automated smart contract mechanism that triggers protective actions (trading pause, margin call, LTV adjustment) when a Verifiable Claim transitions to EXPIRED or REVOKED status.

Trigger conditions: PTVS Score < 50 or 90-day lapse without re-audit

A.10 Physical Proof of Reserve (PPoR)

Definition: An extension of traditional Proof of Reserve that includes physical verification of asset integrity, not just quantity. PPoR answers: “Does the asset physically exist, what is its condition, and what evidence exists?”

Relationship to PTVS: PTVS v1.0 implements PPoR through its four-pillar architecture.

Canonical JSON Schema

B.1 Schema Definition

B.2 Canonicalization Rules

1. Keys sorted lexicographically (alphabetical)
2. No whitespace between tokens
3. UTF-8 encoding (no BOM)
4. Numbers represented without trailing zeros
5. Strings use minimal escaping
6. No duplicate keys

Smart Contract Interface

C.1 PTVSClaimInjector Interface

References

22.1 Regulatory Documents

1. Regulation (EU) 2023/1114 (MiCA) — Markets in Crypto-Assets
2. Directive 2009/138/EC (Solvency II) — Insurance and Reinsurance
3. Directive (EU) 2016/2341 (IORP II) — Institutions for Occupational Retirement Provision
4. Regulation (EU) 2024/1183 (eIDAS 2.0) — Electronic Identification and Trust Services
5. Guideline (EU) 2015/510 — Eurosystem Collateral Framework
6. Regulation (EU) 2022/858 — DLT Pilot Regime
7. Regulation (EU) 2024/1156 (CRR III) — Capital Requirements

22.2 Technical Standards

8. ISO 19005 — PDF/A (Document Management)
9. RFC 3161 — Internet X.509 Time-Stamp Protocol
10. FIPS 180-4 — SHA-256 Secure Hash Standard
11. ERC-3643 — T-REX (Token for Regulated EXchanges)
12. ONCHAINID — Decentralized Identity Standard

22.3 PTVS Documents

13. PTVS v1.0 Core Specification — CERN/Zenodo DOI: 10.5281/zenodo.21719175
14. PTVS v1.0 Computer Science Validation — HAL/CNRS: hal-05713062v1
15. PTVS v1.0 Reproducible Datasets — OSF DOI: 10.17605/OSF.IO/7D2SJ
16. PTVSClaimInjector.sol — GitHub: github.com/aurema-group/prop-trust-verified-standard

22.4 Academic Literature

17. A Taxonomy of Real-World Asset Tokenization for Blockchain-Based Financial Infrastructure — arXiv:2606.08534
18. SoK of RWA Tokenization: A Systematization of Concepts, Architectures, and Legal Interoperability — arXiv:2604.06608

Document Metadata