PDARP Developer Docs

PDARP is the onchain delivery layer for Particula's independent risk ratings - purpose-built for tokenized real-world assets and stablecoins. Any protocol can read a current rating grade and the full risk metadata of a rated asset - including asset backing, pricing, and reserve data - with a single permissionless view call - no allowlist, token, or fee required.

The rating score represents an independent, data-based risk assessment of a tokenized asset, expressed as a letter grade from AAA (Highest Quality, Minimal Risk) to D (Full Exposure). The full rating methodology is documented in the Particula Digital Asset Risk Framework (PDARF).

Ratings are continuously maintained by Particula and cover the complete product wrapper: underlying asset quality, legal structure, issuance and redemption mechanics, operational infrastructure, smart contract risk, token economics and counterparty exposure among others.

These docs cover the testnet sandbox. For production / mainnet integration, reach out to the Particula team (integrations@particula.io).

1. Concepts

The PDARP is Particula's onchain risk credential - a dynamically updated NFT that encodes risk ratings for tokenized assets. It is readable by any smart contract on any supported chain via a standardized oracle interface. This document covers the data model (§2-§4), how to read ratings onchain (§5), integration patterns with working code (§6-§7), and what is coming next (§8).

If your protocol accepts tokenized assets as collateral, or gates access based on asset quality, PDARP gives you a verified, near real-time risk signal.

How it works: Particula assigns and publishes rating scores offchain. The rating is encoded as an integer score and a hex-packed grade, propagated to 160+ chains, and served onchain via the risk oracle infrastructure. Your contract calls getRating(assetAddress) and gets back structured data.

1.1 What you can read

PDARP is the Rating Passport - a single onchain risk credential per token. You read the passport's data by accessing the token's rating key:

1. Rating score - the headline risk rating on the AAA (Highest Quality, Minimal Risk) … D (Full Exposure) letter scale, as an encoded value plus a timestamp.
2. Risk dimension sub-scores - the four PDARF risk dimension scores: Issuer & Counterparties (e.g. issuer, legal entities, service providers), Issuance Structure & Technical Implementation (e.g. token architecture, smart contracts, technical implementation, reserve verification), Underlying Asset (e.g. asset quality, custody, portfolio), and Transparency Score (data completeness, consistency, and reliability of input data). Reading dimension-level scores lets your protocol react to a specific risk dimension rather than the composite alone.
3. Report pointer - an IPFS CID linking to the full human-readable rating report and its metadata.
4. Provenance - the Particula signer and attestation reference attached to each published rating, so you can verify it came from Particula.

The passport is delivered onchain as a non-transferable (soulbound), dynamically updated NFT - the token form of the credential, which anchors the token and indexes the data above (see §3.4). Reads are plain view calls and within the current stage permissionless and free of charges; ratings are published and maintained by Particula; your contracts can read only.

1.2 How a token is identified - the rating key

Tokens are addressed by a string key, not a contract-address argument:

"<Blockchain>-<TokenAddress>"
e.g.  "Ethereum-0x7712c34205737192402172409a8f7ccef8aa2aec"

You pass this key to the read functions. Some data is also addressable per-dimension using a key suffix (see §3.2). The same key works across the supported networks.

1.3 The rating encoding

A rating is returned as a uint128 code plus a uint128 timestamp. The code is a 4-nibble value 0x[L1][L2][L3][M]:

• L1..L3 are letter positions: A = 0xA, B = 0xB, C = 0xC, D = 0xD, right-padded with 0x0.
• M is the modifier: 0 = "-", 1 = (none), 2 = "+".

Grades AA through CCC support +/- sub-notches (e.g. AA+ = 0xAA02, AA- = 0xAA00); AAA, CC, and D do not. Call getValueString to receive the decoded letter grade directly and avoid raw code handling. A full decoder and reference table are in §6.

2. Quickstart (EVM)

Read a grade in under five minutes. Offchain sanity check with Foundry's cast:

cast call <PDARP_RATING_READER> \
  "getValueString(string)(string,uint128)" \
  "Ethereum-0x<tokenAddress>" \
  --rpc-url <sepolia_rpc>
# → ("AA+", 1718700000)

From a contract:

interface IPDARPReader {
    function getValue(string calldata key) external view returns (uint128 code, uint128 timestamp);
    function getValueString(string calldata key) external view returns (string memory grade, uint128 timestamp);
}

contract Example {
    IPDARPReader public pdarp;

    function gradeOf(string calldata key) external view returns (string memory) {
        (string memory grade,) = pdarp.getValueString(key);
        return grade; // e.g. "AA+"
    }
}

3. EVM read reference

3.1 Rating score

interface IPDARPReader {
    /// Encoded grade code + timestamp. Reverts if no fresh rating is available.
    function getValue(string calldata key) external view returns (uint128 code, uint128 timestamp);

    /// Diagnostic read that does not apply freshness checks.
    function getValueView(string calldata key) external view returns (uint128 code, uint128 timestamp);

    /// Decoded grade string (e.g. "AA+") + timestamp. Returns "" for an unknown key.
    function getValueString(string calldata key) external view returns (string memory grade, uint128 timestamp);
}

• The recommended reader aggregates multiple sources and applies staleness filtering. getValue therefore reverts when there is no fresh rating (users should treat a revert as "no rating right now," not a zero score), and getValueView is the unchecked diagnostic variant.
• On that aggregated reader, the returned timestamp is the aggregation time, not the moment the rating was published. If you need the exact publish time, read the per-source value.
• getValueString returns an empty string for an unknown key.

3.2 Risk dimension sub-scores

Beyond the headline rating, you can read the PDARF risk dimensions behind it with a single call that returns the composite plus per-dimension values, in the same grade encoding as the headline (§1.3) - decode with the helper in §6.

interface IPDARPDimensions {
    /// Composite + per-dimension values + timestamp.
    function getTokenRatings(string calldata key) external view returns (
        uint128 composite,
        uint128 counterparty,
        uint128 structural,
        uint128 underlying,
        uint128 transparency,
        uint128 timestamp
    );
}

This lets a protocol react to a specific risk dimension before it affects the composite - for example increasing collateral requirements when the Issuer & Counterparties sub-score drops due to issuer-level developments (e.g. regulatory, financial, or governance related matters), even if the headline rating has not yet moved.

Note: The getTokenRatings return fields (counterparty, structural, underlying) are stable - the ABI will not change for these. The fourth field is currently named transparency and will be renamed to data_confidence (or equivalent) in an upcoming release. The four dimensions are labeled Issuer & Counterparties, Issuance Structure & Technical Implementation, Underlying Asset, and Data Confidence respectively. Plan for the transparency → data_confidence rename before integrating that field in production.

3.3 Report pointer (IPFS)

Every rating links to its full report - the human-readable assessment, methodology context, and metadata - stored on IPFS. Read the CID onchain, then fetch the document from any IPFS gateway. Anchoring the report CID onchain creates a tamper-proof, content-verified link between the credential and the full analytical assessment. Because IPFS CIDs are content-addressed, the onchain reference proves exactly which report version backed the rating at time of issuance - an audit trail neither party can alter retroactively.

interface IPDARPReport {
    /// IPFS CID for the full rating report, + timestamp.
    function getValue(string calldata key) external view returns (string memory cid, uint256 timestamp);
}

const [cid] = await report.getValue(key)
const url = `https://ipfs.io/ipfs/${cid}`   // or your preferred gateway

3.4 The passport token (onchain form of the PDARP)

The PDARP is delivered onchain as a non-transferable (soulbound) NFT - this token is the Rating Passport. The token does not store the score itself; it anchors the asset and indexes the rating key(s) used to resolve the live data in §3.1-§3.3, and carries the credential metadata and report pointer. Read it when you want a single, stable onchain handle for "this token is covered by Particula" that you can reference, display, or gate on.

interface IRatingPassport {
    /// Metadata URI for the passport (points to the credential document).
    function tokenURI(uint256 tokenId) external view returns (string memory);
    /// Report CID currently associated with a passport token.
    function cidOf(uint256 tokenId) external view returns (string memory);
}

Typical flow: resolve a token's passport → read its metadata → use the embedded rating key(s) to read the live grade and pillars.

Market participants are invited to submit feedback to refine the accompanying metadata in accordance with their requirements.

Note: Currently, only the rating grade and pillar sub-scores are readable via the passport. Metadata such as pricing, NAV, and proof-of-reserve will be accessible in a future release.

3.5 Events to index

Track rating changes in your indexer or keeper by subscribing to update events.

/// Emitted whenever a rating value for a key is published or updated.
event OracleUpdate(string key, uint128 code, uint128 timestamp);

Subscribe by reader-contract address and decode in your indexer. OracleUpdate fires on any score change - including single-integer moves (e.g. 94 → 93) - not only on grade-level notch changes (e.g. AA → AA+). Watch the sequence per key to detect upgrades, downgrades, and staleness.

3.6 Verifying provenance (the rating signer)

Every published rating is signed by an authorized Particula key. You can verify this fully onchain - useful when a protocol must prove that a risk-parameter change was driven by a genuine Particula rating.

interface IPDARPProvenance {
    /// Rating value + timestamp + the Particula signer that attested it + an attestation reference.
    function getOracleData(string calldata key) external view returns (
        uint256 value,
        uint256 timestamp,
        address signer,
        bytes32 attestationRef
    );

    /// Whether an address is an authorized Particula rating signer.
    function isAuthorizedSigner(address signer) external view returns (bool);
}

Pattern: read the rating with its signer, assert isAuthorizedSigner(signer) is true, and check the timestamp against your freshness window before acting. attestationRef is a stable handle to the specific attestation, for audit trails.

This verifies Particula - not the token issuer. Particula publishes both solicited and unsolicited ratings. For unsolicited ratings, no action by the token issuer is required. For solicited ratings, the issuer participates in the onboarding process and may contribute metadata to the passport - but the rating itself remains Particula's independent assessment in all cases. The check above confirms a genuine Particula signer, nothing more.

Onboarded issuers receive a verified onchain identity and, subject to Particula approval, can contribute authorized metadata - such as NAV, proof-of-reserve, or compliance attestations - directly into their token's passport. Where present, that issuer identity is an optional attribute you can inspect, but it is never a precondition for a rating. This is part of the multi-party credential model described in §8.1.

3.7 Behavior notes

• All reads are view; currently no permission, fee, or token is needed.
• Prefer the aggregated reader (§3.1) for the headline grade - it applies staleness and consensus filtering.
• A revert on getValue means "no fresh rating," not a zero score.
• Decode any grade code (composite or pillar) with the helper in §6, or use the *String convenience getters.

4. Solana read reference

On Solana, the rating for a key lives in a program-derived account you read directly.

4.1 Derive the account and decode

import { keccak256, toUtf8Bytes } from 'ethers'
import { PublicKey, Connection } from '@solana/web3.js'

const conn = new Connection('https://api.devnet.solana.com')
const pdarpProgram = new PublicKey('<PDARP_SOLANA_PROGRAM>')   // see §6

// Store PDA (singleton)
const [storePda] = PublicKey.findProgramAddressSync([Buffer.from('Store')], pdarpProgram)

// Per-key rating account: seeds = ["OracleData", store, keccak256(key)]
const key = 'Ethereum-0x7712c34205737192402172409a8f7ccef8aa2aec'
const keyHash = Buffer.from(keccak256(toUtf8Bytes(key)).slice(2), 'hex')
const [dataPda] = PublicKey.findProgramAddressSync(
  [Buffer.from('OracleData'), storePda.toBuffer(), keyHash],
  pdarpProgram,
)

const info = await conn.getAccountInfo(dataPda)
// decode the account (see layout below), then:
const ratingU16 = Number(decoded.price & 0xffffn)   // grade code; decode via §6

4.2 Account layout

The rating account is laid out (little-endian) as:

discriminator(8) | store(32) | keyHash(32) | symbolLen(u32) | symbol(≤64)
  | price(u128) | timestamp(u64) | signer(20) | attestationRef(32) | updatedAt(i64) | bump(1)

The grade code is the low 16 bits of price (price & 0xffff) and decodes with the same scheme as EVM (§1.3, §6). The signer and attestationRef fields give you the same provenance you get on EVM (§3.6). A Rating Passport is also available on Solana as a Metaplex Core NFT that indexes a token's rating keys.

5. Networks & addresses (testnet sandbox)

Sandbox RPCs: Sepolia - any public Sepolia endpoint; Solana - https://api.devnet.solana.com.

Sandbox addresses are for evaluation and may rotate. For stable production addresses and mainnet availability, contact integrations@particula.io.

6. Reference decoder

Decode a grade code to its letter string in any environment:

// 4-nibble code → letter grade, e.g. 0xAA02 → "AA+"
function decodeGrade(code: number): string {
  const l1 = (code >> 12) & 0xf, l2 = (code >> 8) & 0xf, l3 = (code >> 4) & 0xf, m = code & 0xf
  const L = (n: number) => (n === 0 ? '' : String.fromCharCode(n + 55)) // 10→'A' … 13→'D'
  const mod = m === 0 ? '-' : m === 2 ? '+' : ''
  return `${L(l1)}${L(l2)}${L(l3)}${mod}`
}

If you instead read a raw numeric score (0-10000, e.g. from the demo), map it to a grade with the band table below. The canonical encoding remains the 4-nibble code above; prefer getValueString when you can.

// numeric score (0–10000, higher = better) → letter grade
function gradeFromScore(score: number): string {
  if (score >= 9500) return 'AAA';
  if (score >= 9400) return 'AA+';  if (score >= 9200) return 'AA';   if (score >= 9000) return 'AA-'
  if (score >= 8700) return 'A+';   if (score >= 8400) return 'A';    if (score >= 8000) return 'A-'
  if (score >= 7700) return 'BBB+'; if (score >= 7400) return 'BBB';  if (score >= 7000) return 'BBB-'
  if (score >= 6700) return 'BB+';  if (score >= 6400) return 'BB';   if (score >= 6000) return 'BB-'
  if (score >= 5500) return 'B+';   if (score >= 5000) return 'B';    if (score >= 4000) return 'B-'
  if (score >= 3500) return 'CCC+'; if (score >= 3000) return 'CCC';  if (score >= 2000) return 'CCC-'
  if (score >= 100)  return 'CC';
  return 'D'
}

7. Integration patterns

PDARP is designed as a composable onchain data layer whose value lies in the combination of components it delivers per rated token. The current release exposes:

1. Third-party risk assessment - Particula's independent rating (AAA...D), an analytical opinion on the overall quality and redeemability risk associated with a tokenized asset
2. Risk dimension sub-scores - a breakdown across the six risk clusters and three assessment pillars.

The following are on the roadmap and not yet available in the current release (see §8 for detail):

3. Raw metadata - pricing, proof-of-reserve, NAV, and other data points attached to the credential and readable onchain.
4. Identification and verification layer - signer and attestation references creating an auditable liability trail per data point, extending beyond Particula to other authorized data sources.
5. Alerts and monitoring signals - changes across any data point (rating, sub-scores, raw metadata) to support automated responses beyond rating thresholds.

Integration patterns fall into two broad archetypes, which you can mix:

• Direct feed - your contract reads the rating inline and derives a parameter (e.g. a risk threshold or collateral factor) on the fly. Fully autonomous, tightest coupling.
• Governance / risk-steward signal - you read the rating (onchain or offchain) and feed it to your governance or risk process, which adjusts parameters. Lowest coupling, keeps a human or DAO in the loop.

The patterns below draw from the lending protocol demo and are provided as orientation. They are sample implementations - parameter choices, thresholds, and integration logic are defined entirely by your protocol.

7.1 Rating-derived LTV parameters

From the rating signal, your protocol can derive the parameters governing a collateral position - chiefly the Loan-to-Value ratio (LTV) and its associated liquidation thresholds. The mapping below and its institutional calibration are explained in turn.

CF = min(maxCF, rating-implied factor)

function ratingCF(string calldata key) public view returns (uint256) {
    (uint128 code, uint128 ts) = pdarp.getValue(key);
    require(block.timestamp - ts <= maxStaleness, "stale rating");

    // Define your own grade-to-CF mapping, e.g.:
    // AAA → 9000 bps (90%), AA → 8500 bps (85%), A → 8000 bps (80%)
    // BBB → 7000 bps (70%), BB and below → 0 (not accepted)
    uint256 cf = yourCFMapping(code);

    return cf < maxCF ? cf : maxCF;
}

The function returns a collateral factor (CF) expressed in basis points - the protocol-internal representation of maximum LTV, capped by your governance-set ceiling:

LTV_effective = min(maxLTV, rating-implied LTV)

Responsibility boundary. PDARP supplies the rating signal only. The grade-to-LTV mapping, cap logic, and any downstream parameter changes are your protocol's responsibility - Particula's rating is an input to your risk framework, not an automated trigger.

Institutional Calibration

The recommended mapping is not invented. It is calibrated to the same risk-differentiation logic used by the ECB for collateral operations, by Basel III for capital requirements, and by the institutional repo market for secured lending - translated into a machine-readable format that DeFi protocols can consume directly.

Recommended Parameter Ranges

The table below translates each Particula rating into recommended LTV and liquidation parameters. These are governance-discretion ranges - your spoke or risk committee sets the exact values within the bounds shown.

Each step down in rating corresponds to a 3-8 percentage point tightening in max LTV - consistent with the haircut differentials observed across ECB, Basel, and repo market conventions.

7.2 Downgrade → liquidation

Because CF is derived from the live grade, a rating downgrade automatically reduces the health factor of positions backed by that token. Positions that fall below your liquidation threshold become liquidatable through your normal flow. Index OracleUpdate (§3.5) to react in the same block as a downgrade if you want proactive keepers.

7.3 Instability gate (block new borrows)

Use the rating's update history as a risk signal. If a token's grade has changed more than a defined number of times within a rolling window, treat it as exhibiting instability and restrict new positions while still allowing existing ones to be unwound. This pattern is analogous to price-volatility circuit breakers used in other oracle-driven protocols.

7.4 Multi-asset portfolio health

Reading a PDARP grade per collateral asset lets you derive a risk-weighted view across a portfolio. Cascading rating downgrades on composed assets surface as a deteriorating composite signal - useful as an input to a governance or risk-steward review process.

7.5 Dimension-targeted policy

Read the risk dimension sub-scores (§3.2) and set policy on a specific dimension. For example: tighten LTV requirements if the Issuer & Counterparties sub-score drops due to issuer-level developments (e.g. regulatory, financial, or governance related matters), or apply higher overcollateralization thresholds if the Issuance Structure & Technical Implementation sub-score weakens - even when the headline rating is unchanged.

7.6 Rating alongside a NAV feed

For tokenized real-world assets, PDARP and a NAV feed are complementary signals. NAV reflects the current value of the underlying assets; the PDARP rating reflects the assessed quality and structural integrity of the product wrapper. A rating change may signal structural or counterparty risk that does not yet appear in the NAV - giving protocols an earlier input for governance or parameter review.

7.7 Provable, auditable parameter changes

When governance changes a parameter based on a rating, record the signer and attestationRef (§3.6) alongside the change. Anyone can later verify onchain that the change was driven by a genuine, Particula-signed rating at a known time.

In all cases: check the timestamp against your own freshness threshold before acting.

8. On the roadmap

The current release delivers rating grades and risk dimension sub-scores. The sections below describe the planned expansion of PDARP into a full multi-party risk credential - a digital asset's complete risk profile, delivered onchain as a composable, continuously-updated credential your contracts can consume. As the framework grows, more of that profile becomes directly fetchable.

8.1 From a rating feed to a multi-party risk credential

Today you read a rating. The direction of travel is a rating passport that is a multi-party onchain data object: a single credential per token whose fields are written by the parties authorized to attest them, each within strict write permissions enforced onchain - for example the rating score by Particula, Net Asset Value (NAV) by the fund administrator, and proof-of-reserve by the custodian. The result is a composable, cryptographically verifiable credential with a full, auditable contribution history - so a consumer can see not just the rating, but who attested each data point and when.

The passport carries a stable lifecycle state - Active, Suspended, Revoked, or Expired - that a consuming protocol can gate on directly (e.g. freeze new positions when a token's passport is Suspended), independent of the numeric score.

8.2 Future data points (illustrative)

The passport is organized into expanding data blocks. Representative fields we are working toward exposing onchain:

A few of these are worth calling out for risk logic:

• Monitoring Signals - discrete per-attribute indicators you can gate on without interpreting the full score.
• Trend Detector - identifies sustained directional shifts in a token's risk profile based on a minimum 90-day trend in risk-rating-relevant attributes.

Plus capabilities to consume them: onchain rating history for trend-aware logic, push / subscribe so contracts and keepers react in the same block as a change, verifiable rating proofs, portfolio / batch queries, and the same keys and read surface across more EVM chains and non-EVM ecosystems.

8.3 Tiered and credentialed access

Consumption-based billing will be introduced alongside tiered access, replacing the current fully permissionless read model. Existing integrations will be retired with advance notice before any billing change takes effect.

• Tiered reads - summary scores at the public tier; full sub-scores, pricing, lifecycle, alert detail, and the data-contributor panel at credentialed and protocol tiers.
• Credentialed write / autonomous actions - protocols issued revocable onchain identities that define which PDARP-triggered operations they may execute (e.g. adjust collateral parameters, pause deposits, update allowlists, initiate liquidations) within hard, contract-enforced boundaries, with every read and write logged for a tamper-proof audit trail.

If a specific data point would unblock your integration, tell us at integrations@particula.io - roadmap priority is shaped by integrator demand.

9. FAQ

General

What is the Particula Digital Asset Risk Framework (PDARF)? PDARF is Particula's proprietary, fully quantitative framework for assessing the risk characteristics of asset-backed digital tokens. It evaluates tokenized and natively issued onchain instruments across legal, structural, technical, and operational dimensions, producing standardized, machine-readable risk indicators. The framework draws on established structured finance principles while incorporating the distinct risk dimensions introduced by tokenization - including smart contract logic, blockchain infrastructure, and decentralized governance.

What is the purpose of a PDARF assessment? A PDARF assessment measures the degree to which a token can be redeemed as contractually promised - in full, on time, and in accordance with its defined structure. It is not a credit rating, does not assess default probability or expected loss, and does not constitute an investment recommendation. Outputs are intended to improve transparency, support risk classification, and inform institutional decision-making.

Is PDARF a credit rating? No. PDARF produces point-in-time risk indicators derived exclusively from observable on- and offchain data using deterministic scoring logic. It does not incorporate forward-looking assumptions, analyst discretion, or scenario analysis, and its outputs do not meet the regulatory definition of a credit rating.

Scope and Eligibility

Which tokens are covered by PDARF? PDARF applies to asset-backed tokens that represent identifiable claims, rights, or ownership interests backed by verifiable underlying assets. This includes:

• Financial assets (fixed income, equity, derivatives)
• Commodities (precious metals, gemstones, carbon credits)
• Real assets (real estate, land, infrastructure)
• Pegged payment tokens (fiat- or asset-pegged)
• Structured or wrapped tokens (tranches, rebase tokens, vault tokens)

Eligibility is governed by the Particula Digital Asset Classification System (PDACS). Coverage is continuously expanding - contact the Particula team for the current list of rated tokens and their onchain keys.

Which tokens are excluded? PDARF explicitly excludes cryptocurrencies, memetic or speculative tokens without defined economic structure, utility and governance tokens, and unpegged or algorithmic payment tokens. The framework is not applicable to any instrument lacking a defined claim structure or verifiable asset backing.

Does PDARF cover tokens across all jurisdictions? PDARF is designed to apply to digital assets issued in jurisdictions covered by the World Bank's Worldwide Governance Indicators (WGI). WGI coverage is used as a contextual reference for evaluating legal and institutional environments, not as a strict eligibility filter. In cases where classification is uncertain or data availability is limited, eligibility is determined through internal review.

Solicited vs. Unsolicited Ratings

What is the difference between a solicited and an unsolicited rating? An unsolicited rating is initiated by Particula independently, based on publicly available data and proprietary analysis. No issuer involvement is required, and the assessment proceeds solely on the basis of verifiable on- and offchain information.

A solicited rating involves direct engagement with the token issuer, who may submit documentation, contribute verified metadata, and receive a verified onchain identity through the Particula Digital Asset Risk Passport (PDARP) onboarding process. Issuers participating in a solicited assessment may also benefit from the right to review and comment on the draft report prior to publication.

In both cases, the rating reflects Particula's fully independent assessment. Issuer participation is voluntary, non-determinative, and does not influence the scoring methodology or its outcome.

Can an issuer influence its rating outcome? No. Issuer participation is limited to submitting documentation and providing factual clarification. Final assessments remain solely at the discretion of Particula's analytical teams. The framework operates on deterministic, rule-based logic - issuer engagement may improve data completeness and the Data Confidence Score, but does not alter the scoring methodology or its outcome.

What rights does an issuer have prior to publication? In solicited assessments, issuers are granted the right to review and comment on relevant portions of the draft report prior to publication. Comments must be submitted within five (5) business days of receipt. This right is limited to factual accuracy, interpretive clarity, and descriptive content - it does not extend to scoring outcomes or methodology. Failure to respond within the review window does not delay publication.

Is issuer participation disclosed in the published assessment? Yes. Where issuer input has been provided, Particula includes a corresponding disclosure indicating that the issuer's management has reviewed and commented on the assessment content. The data source classification - public, issuer-provided, or third-party verified - is disclosed for all assessments.

Methodology

How is a PDARF score constructed? PDARF aggregates risk across three structural pillars:

1. Counterparty Risk - issuer and ecosystem evaluation, including governance, regulatory compliance, financial stability, and business continuity
2. Structural Risk - token architecture, smart contract implementation, token standards, and third-party dependencies (e.g., oracles)
3. Underlying Risk - asset quality, custody arrangements, valuation transparency, and reserve segregation

These pillars feed into six Risk Clusters: (1) Legal and Regulatory Framework, (2) Asset and Reserve Quality, (3) Operational and Governance Risks, (4) Technology Risks and Third-Party Dependencies, (5) Market and Liquidity Risks, and (6) Issuer and Custodial Risks. Across this architecture, 199 attributes are assessed, normalized, and aggregated to produce the final score.

What is the rating scale?

Sub-notches (+/-) are applied within grades to support scoring granularity. Ratings from BBB and above are considered Investment Grade; BB and below are Speculative Grade.

What does a rating score represent in practice? A rating expresses the assessed likelihood that a token holder may be unable to redeem the instrument in full and on time, based solely on observed risk factors at the point of review. A higher score indicates a lower assessed risk profile. Scores do not incorporate projections, forward-looking assumptions, or macroeconomic scenarios.

What is the Data Confidence Score? In parallel with the Risk Rating Score, PDARF produces a Data Confidence Score that measures the completeness, consistency, and reliability of the data underlying the assessment. A higher Data Confidence Score indicates greater assurance in the sufficiency of available information. A lower score signals potential disclosure gaps or data inconsistencies and should be used to contextualize the associated risk score. The Data Confidence Score is an independent signal - it does not modify the risk score itself.

Is the methodology public? Yes. The Particula Digital Asset Risk Framework (PDARF) is publicly available and governs all assessments. Assessments can be challenged or contextualized against the published methodology criteria. The full public methodology is available at https://particula.io/methodology

Monitoring and Updates

How often do ratings update? There is no fixed cadence. Ratings are continuously monitored and republished whenever assessed inputs change materially. For time-sensitive integrations, rely on the OracleUpdate event (§3.5) rather than polling on a schedule.

What are Red Flags? Red Flags are live event-based signals that highlight discrete, high-impact developments exceeding predefined risk thresholds. A Red Flag is triggered when a variable exhibits a material deviation - typically exceeding two standard deviations - from recent patterns. Red Flags do not alter the Risk Rating Score but serve as supplementary signals supporting enhanced monitoring and may indicate the need for closer review or reassessment of risk exposure.

What is the Trend Detector? The Trend Detector (upcoming) identifies sustained directional shifts in a token's risk profile using AI-driven models. It detects upward or downward movements based on a minimum 90-day trend in risk-rating-relevant attributes. It is not predictive but signals observed directional movement in real time, offering early insight into material changes in risk conditions.

Can I receive notifications when a specific rating changes? Yes. Subscribe to the OracleUpdate event (§3.5) for the relevant key to receive real-time onchain updates without polling.

How is a rating change interpreted? A rating change signals a material shift in one or more assessed inputs across the framework's risk clusters. The OracleUpdate event carries the updated value and timestamp. Historical rating data is available on request.

Onchain Access and Integration

Do I need permission or an API key to read a rating? No. All reads are permissionless view calls - no credentials required.

Is there a fee? Reads are currently free. Consumption-based access tiers are planned for a future release; all sandbox and production reads prior to that launch carry no fee.

What does a revert on getValue mean? No fresh rating is currently available for that key. A revert does not indicate a score of zero - treat it as a data gap, not a rating outcome.

Can I verify that a value came from Particula? Yes. Verify provenance onchain via the rating signer and the authorized-signer registry (§3.6).

Which networks is the contract deployed on? The rating passport is designed as an omnichain credential. Supported networks and stable contract addresses are provided on request - contact integrations@particula.io.

Is mainnet available? Yes. Mainnet addresses and integration details are provided on request - contact integrations@particula.io.

Governance and Independence

How does Particula ensure analytical independence? Particula maintains a strict operational separation between analytical functions and commercial activities. Risk assessments are conducted independently of sales, marketing, and revenue-generating units. Analysts participating in an assessment are subject to the firm's Code of Conduct and are prohibited from holding financial interests in the assets under review. The full Code of Conduct is available at https://particula.io/code-of-conduct.

What happens if an issuer disputes a rating? Particula operates independently. Issuers may submit documented evidence or factual corrections through the formal review process. Particula will assess any new material information and republish if warranted. A dispute does not suspend a live rating, and final assessments remain solely at the discretion of Particula's analytical teams.

How does PDARF evolve over time? The framework is subject to ongoing governance review to reflect market developments, regulatory changes, and stakeholder feedback. Material changes follow a structured process including quantitative backtesting, peer review, and approval by the Framework Oversight Committee. All versions are archived with version identifiers and effective dates. Market participants are invited to submit feedback to inform the ongoing development of the framework and its accompanying metadata.

Limitations and Disclaimers

What are the key limitations of a PDARF assessment? PDARF provides a point-in-time view based on verifiable data available at the time of review. It does not capture real-time developments occurring between data validation intervals, incorporate forward-looking assumptions, or independently audit all data sources. The reliability of outputs is dependent on the quality, completeness, and timeliness of input data. Gaps in issuer disclosure or reliance on third-party representations may affect precision.

Can PDARF outputs be used as investment advice? No. PDARF outputs do not constitute investment advice, credit opinions, endorsements, or recommendations to buy, sell, or hold any digital asset. Users remain solely responsible for any decisions taken based on PDARF results and are advised to seek appropriate professional guidance where necessary.

10. Support

• Integration support and production access: integrations@particula.io
• Website: particula.io

Particula's risk ratings are independent analytical assessments and do not constitute investment advice, credit ratings, or regulatory opinions. Particula operates as a risk rating provider and is not a credit rating agency as defined under applicable regulatory frameworks, including EU Regulation (EC) No 1060/2009. Particula's assessments do not include forward-looking assumptions and do not assess creditworthiness or default likelihood.