Skip to main content
GET
Get Payment Risk Assessment
Returns a comprehensive risk assessment for blockchain payments by analyzing both sender and recipient addresses across 8 independent risk dimensions. Provides real-time risk evaluation for payment flows across multiple blockchain networks. See Understanding Risk Scores for general methodology. The overall risk level uses a maximum risk approach: if any individual assessment returns “high”, the overall risk is “high”.
This is the most comprehensive risk endpoint. It includes address risk scoring (malicious connection analysis) and attributed address checks (including sanctions and blacklist data) for both sender and recipient, plus payment-specific risk factors.If you only need to screen a single address without payment context, use the simpler Address Risk Score endpoint. For sanctions-only pass/fail checks, use Sanctions & Blacklist Check.

Query Parameters

Validation:
  • Sender and recipient addresses must be different
  • Amount must be greater than 0
  • Address minimum length: 10 characters

Supported Networks

Full payment data support for: solana, stellar, and all Cosmos ecosystem chains (celestia, osmosis-1, cosmoshub-4, dydx-mainnet-1, neutron-1, and others). See Supported Chains for the full list. Networks without full payment data (EVM chains, Bitcoin, Tron) still benefit from attribution checks and malicious connection analysis.

Response Schema

Risk Factor Object

Example Response Structure


Risk Assessments Performed

Analyzes recipient’s transaction history to determine if the wallet is newly created or established.Factor names: new_wallet_recipient, established_wallet_recipient
  • HIGH: 0 transactions (completely new wallet)
  • MEDIUM: <3 transactions OR first transaction <7 days ago
  • LOW: ≥3 transactions AND >7 days old
Example descriptions: "Recipient is a completely new wallet with no transaction history", "Recipient has substantial transaction history (500+ transactions over 6 months)"
Checks if recipient has been inactive for an extended period and is now reactivating.Factor names: dormant_wallet_recipient, active_wallet_recipient
  • MEDIUM: Last transaction >180 days ago
  • LOW: Active within 180 days
Example descriptions: "Recipient wallet was dormant for 200+ days and is now reactivating", "Recipient wallet was active within the last 7 days"
Detects if the recipient address matches poison address patterns associated with the sender (4-char prefix/suffix matching).Factor names: address_poisoning_attack, no_address_poisoning
  • HIGH: Recipient matches a poison address pattern
  • LOW: No poisoning pattern detected
Example descriptions: "Potential address poisoning attack detected - recipient matches poison address pattern", "No address poisoning pattern detected between sender and recipient"
Examines previous transaction relationships between sender and recipient. Uses network-specific index for same-network payments and payments_interchain index for cross-chain.Factor names: first_interaction, limited_interaction_history, established_interaction_history
  • HIGH: 0 interactions (first time transacting)
  • MEDIUM: 1–2 interactions
  • LOW: 3+ interactions (established relationship)
Example descriptions: "First ever interaction between these addresses", "Limited interaction history: 2 previous interactions found", "Strong interaction history: 15 previous interactions found"
Uses Range’s ML-powered malicious distance endpoint to identify connections to known malicious addresses for both sender and recipient.Factor names (sender): malicious_connection_sender_direct, malicious_connection_sender_high, malicious_connection_sender_medium, malicious_connection_sender_low, clean_address_senderFactor names (recipient): Same pattern with _recipient_ suffix.
  • HIGH: 0–2 hops from malicious addresses
  • MEDIUM: 3 hops from malicious addresses
  • LOW: 4+ hops OR no connections found
Example descriptions: "Sender is directly connected to known malicious addresses (0 hops)", "Sender is 2 hops away from known malicious addresses (riskScore: 1)", "Sender address has no known connections to malicious addresses"
Verifies both addresses against known entity databases. Network-independent, runs even for unsupported networks.Factor names: malicious_address_sender, malicious_address_recipient, attributed_address_sender, attributed_address_recipient, known_attributed_sender, known_attributed_recipient
  • HIGH: Address flagged with malicious=True
  • LOW: Known attributed entity (exchange, protocol, system address)
Example descriptions: "Address attributed to 'Binance Hot Wallet' (Entity: Binance, Category: Exchange, Role: Hot Wallet)", "Sender is a known attributed address | identified as 'Token Program' | (entity: Solana) | Category: SYSTEM | Role: Program | Not flagged as malicious"
When sender_token or recipient_token is provided, evaluates token-specific risk factors. Currently Solana only.Factor names: token_risk_sender_low, token_risk_sender_medium, token_risk_sender_high (and _recipient_ variants)Maps from token risk score to payment risk level (low/medium/high).Example descriptions: "Sender token EPjFWdd5Au... has low risk (established stablecoin)", "Recipient token shows medium risk factors"
Handles both same-network and cross-chain payment scenarios with appropriate index selection.
  • Same network: Uses network-specific index (e.g., payments_solana)
  • Cross-chain: Uses payments_interchain index

Network Support


Examples

High Risk, First Interaction with New Wallet

Low Risk, Established Relationship

Cross-Chain Payment


Errors


Best Practices

  • The overall risk is determined by the highest individual risk factor, a single “high” factor makes the entire payment “high” risk.
  • Always pass sender_token/recipient_token for Solana payments to get token-level risk assessment.
  • For cross-chain payments, provide the correct network identifiers for both sides.
  • Use processing_time_ms to monitor API performance and set appropriate timeouts.
  • An "unknown" overall risk level means insufficient data, not safety, treat it with caution.

Authorizations

X-API-KEY
string
header
required

Authorization method required to allow user to access the api endpoints.

Query Parameters

sender_address
string
required

Sender blockchain address

Example:

"TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"

recipient_address
string
required

Recipient blockchain address

Example:

"7UX2i7SucgLMQcfZ75s3VXmZZY4YRUyJN9X1RgfMoDUi"

amount
number
required

Payment amount in USD equivalent (must be positive)

Required range: x >= 0.01
Example:

1000

sender_network
string
required

Sender blockchain network (e.g., solana, osmosis, ethereum)

Example:

"solana"

recipient_network
string
required

Recipient blockchain network

Example:

"solana"

sender_token
string

Token/denom being sent (optional, enables token risk assessment)

Example:

"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"

recipient_token
string

Token/denom being received (optional)

Example:

"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"

timestamp
string

Payment timestamp in ISO 8601 format (optional)

Example:

"2025-01-15T10:30:00Z"

Response

200 - application/json

Payment risk assessment with individual risk factors and overall risk level

overall_risk_level
enum<string>
required

Overall risk level determined by maximum risk approach. Possible values: low, medium, high, unknown

Available options:
low,
medium,
high,
unknown
Example:

"high"

risk_factors
object[]
required

List of individual risk assessments performed

processing_time_ms
number
required

Processing time in milliseconds

Example:

4159.017

errors
string[]
required

List of errors encountered during analysis (empty if no errors)

request_summary
object
required

Echo of the original request parameters for verification

Last modified on June 17, 2026