XRPL Wallet Scoring: On-Chain Due Diligence for Any XRP Address

The XRP Ledger is fully transparent — every wallet's complete transaction history is public. The challenge is translating raw on-chain data into actionable intelligence quickly. Wallet scoring does exactly that: distilling years of on-chain behavior into a single score and tier for any address.

On-chain due diligence is one of those capabilities that sounds like a niche developer tool but has practical applications at every layer of XRPL infrastructure. Token issuers screening subscribers. Applications gating premium features. Counterparties assessing payment risk before large transfers. Market makers classifying DEX participants. All of these use cases benefit from a quick, standardized answer to the question: "What does this wallet's history tell me about its operator?"

How Wallet Scoring Works

XRPL wallet scoring aggregates four dimensions of on-chain history into a composite 0–100 score:

The resulting score maps to five tiers:

NEW 0–20   BASIC 21–40   ACTIVE 41–65   ESTABLISHED 66–80   VETERAN 81–100

Accessing the Score via API

The XRPL Analytics wallet scoring API is public and requires no API key at standard rate limits:

curl https://api.xrplanalytics.com/api/v1/wallet/rAddress.../score

Response:

{
  "success": true,
  "data": {
    "address": "rAddress...",
    "score": 74,
    "breakdown": {
      "balance": 26,
      "activity": 24,
      "diversity": 17,
      "ownerObjects": 7
    },
    "tier": "established"
  }
}

Additional endpoints return the full wallet profile:

GET /api/v1/wallet/{address}              # Balance, account info
GET /api/v1/wallet/{address}/tokens       # All token holdings
GET /api/v1/wallet/{address}/transactions # Transaction history
GET /api/v1/wallet/{address}/escrows      # Active escrows

Five Practical Applications

1. Token Subscription Pre-Screening

For tokenized security offerings where you're using XRPL's RequireAuth to gate trust lines, wallet scoring provides a rapid first-pass filter before investing compliance review resources. A subscriber submitting a trust line request with a NEW tier score (0–20) warrants additional scrutiny — freshly created wallets are a signal of potential bot activity, script-based subscription attempts, or low-quality investor interest. A ESTABLISHED or VETERAN score doesn't replace KYC/AML — but it provides useful context.

2. Application Feature Gating

Applications that allow users to connect their XRPL wallet can use the score to gate access tiers. Require at minimum a BASIC score (21+) to access core features. Display a trust badge for ESTABLISHED wallets. Restrict high-value operations (large transfers, pro features, privileged access) to ACTIVE and above. This reduces bot and throwaway-account exploitation without adding friction for legitimate users who already have established wallets.

3. Payment Counterparty Assessment

Before receiving a large, unsolicited payment from an unknown address, a quick score lookup provides context. A NEW wallet sending $50,000 worth of XRP is a different risk profile than a VETERAN wallet with years of activity. This doesn't prove legitimacy, but it provides relevant signal for a decision about whether to return or hold the funds while you verify the sender.

4. DEX Participant Classification

Building market analysis tools on XRPL's native DEX? Wallet scoring lets you classify market participants quickly: established market makers (high score, high activity, large diversity), retail participants (moderate score, intermittent activity), and new entrants or bots (low score, burst activity). This classification enables better liquidity analysis and anomaly detection in DEX activity monitoring.

5. Development Environment Verification

During XRPL application development, wallet scoring confirms that your test wallets are correctly configured and that activity is being recorded. A freshly funded wallet should score NEW. After completing a test transaction sequence, re-querying confirms that the activity increments are registering correctly in the analytics layer. This is a quick sanity check for any XRPL integration before you move to production.

Integration Pattern

A typical application integration:

// TypeScript: gate feature access by wallet score
async function checkWalletEligibility(address: string) {
  const res = await fetch(
    `https://api.xrplanalytics.com/api/v1/wallet/${address}/score`
  )
  const { data } = await res.json()
  
  if (data.score < 21) {
    return { 
      eligible: false, 
      reason: 'Wallet has insufficient on-chain history',
      tier: data.tier 
    }
  }
  
  return { eligible: true, tier: data.tier, score: data.score }
}

Free tier: 60 requests per minute, no API key required. For higher volume: register at xrplanalytics.com for a free API key with increased rate limits.

What Wallet Scoring Doesn't Tell You

Wallet scoring is a useful heuristic, not an identity verification system. Four limitations to keep in mind:

• Activity can be artificially inflated. A new wallet making 500 rapid, low-value transactions will temporarily inflate its activity score. Combine score with activity pattern analysis (not just count) for high-stakes decisions.
• High score ≠ verified identity. An established wallet is established on-chain — it doesn't tell you who controls the private key. Always pair on-chain scoring with off-chain identity verification for compliance-required counterparties.
• Diversity can be manufactured cheaply. Creating multiple trust lines is inexpensive. The diversity score rewards genuine participation but can be gamed by someone willing to invest time doing so.
• Score is a snapshot. Wallet history is cumulative, but a single large suspicious transaction won't necessarily reduce a score significantly if the wallet has years of clean history. Use transaction history review for specific incident analysis rather than relying solely on aggregate score.

Network Health Alongside Wallet Data

XRPL Analytics also exposes live network status — useful for applications that need to verify ledger health before initiating transactions:

GET https://api.xrplanalytics.com/api/v1/network/status
# Returns: ledger index, server state, peer count, validated ledger hash

If serverState is not full or proposing, the node may be syncing — wait before trusting data from that endpoint for operational decisions.

The combination of wallet scoring, balance/token data, and network status covers the three most common real-time data needs for XRPL application builders: "Who is this counterparty?", "What do they hold?", and "Is the network healthy right now?"