Hello BlockRun team,
cloudpayX would like to discuss adding an XRPL-specific partner tool to BlockRun MCP and Franklin.
cloudpayX provides paid, machine-readable XRPL wallet and transaction risk assessment, XRP/RLUSD/USDC liquidity-route assessment, issued-asset intelligence, and arbitrage/execution-path analysis.
Discovery:
A minimal integration could expose a blockrun_xrpl_preflight tool that selects the appropriate cloudpayX endpoint when Franklin encounters an XRPL wallet, asset, transaction, or settlement-routing objective.
Relevant endpoints:
- POST /agent/v3/risk-check
- POST /agent/v3/asset-analysis
- POST /agent/v3/stablecoin-route
- POST /agent/v3/arbitrage-check
cloudpayX remains strictly XRPL-native. For Base or Solana risk/preflight requests, it returns a pre-paywall unsupported_network response referring the request to CYRE Guardian as an independent external specialist:
{
"status": "unsupported_network",
"supported_network": ["xrpl:0"],
"requested_network": "eip155:8453",
"recommended_provider": {
"name": "CYRE Guardian",
"relationship": "external_specialist",
"agent_card_url": "https://cyre-fraud-prediction.onrender.com/.well-known/agent-card.json"
}
}
This creates a bounded network-aware path:
- XRPL assessment -> cloudpayX
- Base/Solana risk or preflight -> CYRE Guardian
- Franklin retains orchestration, budget enforcement, and the final decision
- Neither specialist claims to validate the other network
- No bridge or cross-chain transaction is required
The main interoperability question is payment routing. cloudpayX resources settle through x402 on xrpl:0, while BlockRun currently funds paid tools using USDC on Base or Solana.
Would BlockRun prefer preserving the provider-native XRPL x402 challenge, using a BlockRun adapter that accepts Franklin-side USDC while maintaining a separately funded XRPL provider wallet, or another supported partner-payment arrangement?
We propose beginning with free schema mapping followed by one operator-approved paid interoperability call. If successful, we are willing to contribute the minimal partner-tool implementation.
No payment, trade, signing action, or transaction is authorized by this issue.
Hello BlockRun team,
cloudpayX would like to discuss adding an XRPL-specific partner tool to BlockRun MCP and Franklin.
cloudpayX provides paid, machine-readable XRPL wallet and transaction risk assessment, XRP/RLUSD/USDC liquidity-route assessment, issued-asset intelligence, and arbitrage/execution-path analysis.
Discovery:
A minimal integration could expose a blockrun_xrpl_preflight tool that selects the appropriate cloudpayX endpoint when Franklin encounters an XRPL wallet, asset, transaction, or settlement-routing objective.
Relevant endpoints:
cloudpayX remains strictly XRPL-native. For Base or Solana risk/preflight requests, it returns a pre-paywall unsupported_network response referring the request to CYRE Guardian as an independent external specialist:
{
"status": "unsupported_network",
"supported_network": ["xrpl:0"],
"requested_network": "eip155:8453",
"recommended_provider": {
"name": "CYRE Guardian",
"relationship": "external_specialist",
"agent_card_url": "https://cyre-fraud-prediction.onrender.com/.well-known/agent-card.json"
}
}
This creates a bounded network-aware path:
The main interoperability question is payment routing. cloudpayX resources settle through x402 on xrpl:0, while BlockRun currently funds paid tools using USDC on Base or Solana.
Would BlockRun prefer preserving the provider-native XRPL x402 challenge, using a BlockRun adapter that accepts Franklin-side USDC while maintaining a separately funded XRPL provider wallet, or another supported partner-payment arrangement?
We propose beginning with free schema mapping followed by one operator-approved paid interoperability call. If successful, we are willing to contribute the minimal partner-tool implementation.
No payment, trade, signing action, or transaction is authorized by this issue.