Whitepaper
  • 1.0 Introduction
    • 1.1 Migration from XEND to RWA
    • 1.2 New Vision - Xend V2 and Xend V3
      • 1.2.1 Principles overview
      • 1.2.2 Xend V2 & V3 - Roadmaps
      • 1.2.3 Xend V2 Roadmap
      • 1.2.4 Xend V3 Roadmap
  • 2.0 OAE - Onchain Assets Environment
    • 2.1 OAE Core Idea
    • 2.2 OAE Framework
    • 2.3 OAE - Products Overview
      • 2.3.1 Asset Chain
      • 2.3.2 Origin Studio
      • 2.3.3 Social Hub
      • 2.3.4 Xend Connect
      • 2.3.5 GOR
      • 2.3.6 Xend Solutions
    • 2.4 Asset Smart Contract
    • 2.5 IAC Framework
      • 2.5.1 Importance Of IAC to OAE
      • 2.5.2 (b) IAC in Practice
    • 2.6 Asset Credibility
      • 2.6.1 Authentication Rating
      • 2.6.2 Compliance Rating
      • 2.6.3 Asset Insurance Rating
      • 2.6.4 Events Mirroring
      • 2.6.5 Visual Summary
    • 2.7 IAC Partners
      • 2.7.1 IAC Provider
      • 2.7.2 Conflict Resolution Process
      • 2.7.3 I - AC Interdependence
    • 2.8 Assets Policy in OAE
      • 2.8.1 Web3 Token Issues
      • 2.8.2 AssetChain 10 Cardinal Rules
      • 2.8.3 Assets As Smart Contracts, Tokens As Rights
      • 2.8.4 Verifiable Legal Binding
      • 2.8.5 Intrinsic Legalization
      • 2.8.6 Multi-Level Asset & Token Structures
      • 2.8.7 Token Bonding
      • 2.8.8 Separating Ownership, Possession And Holding
      • 2.8.9 Structured Asset Administration Policy
    • 2.9 AssetChain - 4 Execution Levels
    • 2.10 P2P Lending In OAE
      • 2.10.1 Basics of P2P lending
      • 2.10.2 Appraisers And Custodians
      • 2.10.3 Xend Fundraising Platform On OAE
    • 2.11 AI Stack
      • 2.11.1 Watchdogs
      • 2.11.2 Assistants
      • 2.11.3 Improvers
      • 2.11.4 Concepts
  • 3.0 Xend Browser
    • 3.1 One-4-All
    • 3.2 NodeOs
    • 3.3 Subnet
    • 3.4 Explorer
    • 3.5 Node Enterprise
    • 3.6 e-Admin
    • 3.7 NodeBox
  • 4.0 Progressive Synchronization (V3)
    • 4.1 Objectives Of The IAC Councils
    • 4.2 Progressive Adoption Of Public AssetChains
    • 4.3 Progressive Adoption Of Public Subnets
    • 4.4 OAE Marketplace
  • Practical Use Cases
    • Business & Banking
    • Real Estates
    • Compliance - by - Design
    • Tokenization Beyond Ownership
    • Global Assets Accessibility
    • Green Impact
    • Software, Gaming and Entertainment
    • Global Transparency and E-Administration
  • RWA (OAE) Token Economy 1.0
    • RWA Token
    • RWA Economy Ecosystem Participants
    • RWA Staking
    • RWA Incentives
    • RWA LP Tokens, Market Makers, & Trading Competitions
    • Gamification Of OAE User Experience
    • RWA Token Utilities
    • OAE & RWA Macro-Economy
    • Future Legal Status Of RWA Tokens
  • Litepaper
    • Solving ASR Issue
    • OAE From User Standpoint
    • Xend Solutions
    • Future Roadmap
  • Appendices
    • Appendix A: Understanding RWA
      • Assets Classification
      • Narrow Understanding Of RWA
      • Wide Understanding Of RWA
      • UWA - Unreal World Asset
      • RWA versus UWA - They Key Difference Lies In Legal Context
      • Examples Of RWAs Definitions Incoherence
      • Key Takeaways
    • Appendix B: Digitization vs Tokenization
      • Existence vs Ownership
      • Hierarchy Of Terms
      • Digitation Of Asset
      • Documenting The Asset
      • Tokenization Of The Asset On Gen2 Blockchain
      • Legal Causality Of Gen2 Tokenized Asset
      • Key Takeaways
    • Appendix C: Rise Of AssetChains
      • Theses A
      • Theses B
      • Theses C
      • Theses D
      • Theses E
      • Theses F
    • Appendix D: Brief Analysis On Who Owns The Internet
    • Appendix E: Market Research
      • RWA Solutions - Scope Of Work Overview
        • Centralized
        • Decentralized
        • In-depth Scope Comparison
      • Statistics
        • CEFI - Territorial Coverage
        • CEFI - Funding Ranges Popularity
        • CEFI - Funding Values Breakdown
        • Visual Data Metrics
      • Research Summary
  • FAQs
Powered by GitBook
On this page
  1. 2.0 OAE - Onchain Assets Environment
  2. 2.6 Asset Credibility

2.6.2 Compliance Rating

Previous2.6.1 Authentication RatingNext2.6.3 Asset Insurance Rating

Last updated 7 months ago

Compliance Checkpoint & Rating

Compliance validators publish compliance checkpoints to evaluate compliance validity of

  • asset legal status

  • asset onchain onboarding

The actions executed within this checkpoint vary depending on the approach employed in asset .

As such:

  1. When legal status data is sourced either fully or in part from public or external private records, the established compliance checkpoints must encompass:

    1. Source Verification: Validation of the information source's reliability.

    2. Data Cross-Verification: A secondary review to confirm the data's accuracy.

  2. If the compliance validator is responsible for manually inputting the legal status, the compliance checkpoint should include:

    1. Direct Data Entry: The manual input of legal status information.

    2. Automated Confirmation: Systematic verification of the data submitted.

  3. If asset administrators updates the legal status on their own, manually, compliance checkpoint needs to include:

    1. Data double check

    2. Data approval

No matter the scenario, the compliance checkpoint consistently incorporates:

  • Compliance Status Indicator: Determination of the asset's legal compliance and its on-chain onboarding through one of the options: Yes, No, or Yes - with restrictions.

  • Restrictions and Missing Data Overview: A detailed account and justification of any noted compliance restrictions or constraints, along with an enumeration of data absent that is critical for complete compliance assessment.

  • Compliance Validity Rating: An overall evaluation score reflecting the asset's compliance standing.

The compliance validity rating is assigned as follows:

  • 0 Points: Assigned to assets deemed non-compliant.

  • 100 Points: For assets fully compliant without any restrictions.

  • Between 0 to 100 Points: Applies to assets where compliance is conditionally confirmed with certain restrictions.

Minus points: When identifying restrictions, compliance validators allocate ‘minus points' per each restriction, ranging from 1 to 100. The total amount of minus points that can be granted is 100, if all are spent, it means the asset and/or its on-chain onboarding has been deemed as fully non-compliant (e.g. ownership right tokens have been allocated to IDs that are not actual owners, or ownership homogeneity hasn’t been maintained).

Compliance checkpoints and their ratings are accessible on the asset's GOR profile. Multiple compliance validators may participate, each contributing an independent rating. These ratings are adjusted by the validator's reputation score and decrease over time due to elapsed days, similar to the process for authenticity ratings.

For each compliance rating provided by an compliance validator, we calculate a weighted score (Cws) as follows:

Cws=Cr × (1−n)t

Where:

Cws = Weighted compliance rating from the single validator

A = Rating (from 1 to 10)

r = Validator’s reputation

n = time-elapse based logarithmic daily decrease rate (e.g. 0.25%)

t = amount of days that have elapsed from rating submission

Then, to find the overall Asset Compliance Validity Rating (ACR), we average all the weighted ratings:

ACR = ∑(Cws) / Total number of ratings

Similarly to authentication rating, compliance validity rate provides possibility for dynamic adjustment of n variables, and ensures that the value of such ratings decrease over time, naturally pushing for eventual re-validation.

event mirroring policy