Best RPC providers for MiCA and DORA compliance (2026)

MiCA became fully applicable on December 30, 2024, and DORA went live on January 17, 2025. For every crypto-asset service provider (CASP), asset-referenced token (ART) issuer, and e-money token (EMT) issuer operating in the EU, compliance is no longer a future roadmap item — it is a present operational requirement. The infrastructure stack supporting your on-chain operations, including the RPC providers your systems call thousands of times per second, now sits directly within the scope of EU financial regulation.

What most engineering teams miss is that DORA does not distinguish between “traditional” ICT providers and blockchain node operators. Under DORA’s third-party ICT framework (Articles 28–44), any provider of critical digital services — including the RPC endpoints your settlement engine, monitoring systems, and compliance pipelines rely on — must meet contractual SLA requirements, be subject to audit rights, and satisfy concentration risk controls. Choosing the wrong RPC provider is not just a reliability decision anymore. It is a compliance decision with direct regulatory consequences.

This guide covers the six most relevant RPC providers for regulated EU entities operating across Ethereum, Arbitrum, Base, BNB, and Polygon. It addresses the specific DORA and MiCA requirements your infrastructure team needs to satisfy, the RPC methods that power compliance workloads, and how each provider stacks up for production-grade regulated operations.

💡 Already using Chainstack? Jump straight to the enterprise infrastructure page or deploy your endpoint in minutes.

MiCA and DORA on multi-chain infrastructure: what the regulations actually require

The DORA third-party framework for RPC providers

DORA Article 28 requires financial entities to maintain a comprehensive register of all ICT third-party service providers and to apply a risk-based classification. Providers supporting “critical or important functions” — which includes any RPC infrastructure underpinning settlement, custody, or compliance monitoring — must meet a higher bar.

Article 30 mandates specific contractual provisions for these critical providers. Your contract must include: a full description of services with quantified service levels (SLAs), data processing locations and the data residency obligations that flow from them, guaranteed audit rights for both your compliance team and your competent authority, provisions on availability, integrity, and confidentiality of data, and termination rights with an adequate transition period to avoid lock-in. Self-service SaaS terms on a checkout page do not satisfy Article 30. You need a real enterprise agreement.

DORA also addresses concentration risk (Article 29): regulators expect financial entities to monitor and manage exposure to individual ICT providers. If your entire multi-chain monitoring stack runs through a single RPC vendor with no secondary provider, that is a concentration risk that must be documented and mitigated. The practical implication: your architecture should support at least two independent RPC providers with automatic failover, and your vendor management documentation should reflect this.

MiCA operational resilience requirements

MiCA Title III (for ART issuers) and Title IV (for EMT issuers and CASPs) impose operational resilience obligations that directly translate to infrastructure requirements. CASPs must have business continuity plans covering ICT disruptions, incident classification and reporting procedures (with initial reports to national competent authorities within 4 hours for major incidents), and recovery time objectives for critical functions.

For stablecoin infrastructure specifically, MiCA Article 35 requires issuers to maintain “resilient and secure ICT systems and tools” with appropriate business continuity measures. ESMA’s technical standards interpret this as requiring at minimum: documented SLAs from critical providers, geographic redundancy, and the ability to switch providers without service interruption. If your EMT’s reserve monitoring, redemption processing, or transaction validation pipeline depends on a single shared RPC endpoint with no contractual backing, you have a compliance gap.

RPC methods that power compliance workloads

Eight EVM methods anchor most regulated cross-chain operations. Understanding what each does — and what infrastructure it requires — is prerequisite to choosing the right provider.

• eth_getLogs is the workhorse of compliance event ingestion. It queries historical and recent event logs by contract address, topic, and block range. Every USDC/USDT transfer event, every DEX swap, every governance vote your compliance engine needs to audit flows through this method. It does not require archive node access for recent blocks — a full node suffices for current and recent data. High-volume compliance pipelines typically call this method at 50–200 RPS across multiple chains simultaneously.
• eth_getTransactionByHash retrieves complete transaction data including calldata. It is used for transaction verification and building audit trails. For compliance reporting, you need to be able to reconstruct the full transaction record — this method is the primary mechanism.
• eth_getTransactionReceipt returns the post-execution transaction receipt including status (success/failure), gas consumed, and emitted logs. It is essential for settlement confirmation: you cannot mark a payment as settled until you have a receipt with status: 1. Batching receipt lookups is common in high-throughput settlement pipelines.
• eth_call executes a contract read at the current or a specified block. For compliance, this means querying token balances, allowances, reserve ratios, and smart contract state at any point in time. Calling at a historical blockNumber requires archive access; calling at "latest" does not.
• eth_getBlockByNumber retrieves full block data including all transaction hashes or full transaction objects. Compliance pipelines that reconstruct the full transaction set for a given block period — for example, to produce daily settlement reports — rely heavily on this method. It is also used to verify block finality timestamps.
• eth_subscribe (via WebSocket) provides real-time event streaming for logs and newHeads topics. For live compliance monitoring — catching a suspicious transfer event within seconds of it being mined — a persistent WebSocket subscription is far more efficient than polling. Providers that drop WebSocket connections under load, or that rate-limit subscription events, are unsuitable for real-time compliance applications.
• debug_traceTransaction produces a full execution trace of a transaction, including internal calls and state changes. This is the primary tool for forensic analysis: understanding why a transaction reverted, tracing the flow of funds through a multi-hop DeFi operation, or producing evidence for a regulatory inquiry. It requires archive node access and is computationally expensive — latency of 500ms–2s is normal.
• trace_block returns execution traces for all transactions in a block simultaneously. It is used for batch forensic analysis and for compliance reporting workflows that must reconstruct complete block-level activity. Like debug_traceTransaction, it requires an archive node with trace support (Erigon or equivalently configured nodes).

For a full reference of these methods across all supported EVM chains, see the Chainstack blockchain API reference.

Infrastructure requirements for regulated operations

Beyond individual method support, regulated operations impose infrastructure requirements that go beyond what consumer and developer-tier RPC services provide.

Uptime SLA: MiCA and DORA operational resilience standards imply near-continuous availability. A 99.9% uptime SLA means roughly 8.7 hours of acceptable downtime per year — inadequate for a settlement engine processing redemptions. Production compliance infrastructure should target providers with a contractual 99.99% SLA (≤52 minutes downtime per year).

Geographic redundancy: DORA’s resilience requirements effectively mandate multi-region deployment. Your RPC provider must serve requests from geographically distributed nodes so that a single data center failure does not cause a service outage. Geo-balanced load balancing across at least three independent regions is the minimum adequate configuration.

Dedicated vs shared infrastructure: Shared RPC endpoints pool your traffic with thousands of other users. A traffic spike from a popular NFT mint or mempool storm can saturate shared capacity and cause latency spikes or rate limit enforcement precisely when your compliance pipeline is under the highest load. For critical-function infrastructure under DORA, dedicated nodes — where your capacity is isolated from other users — are the architecturally correct choice.

Data residency: Some EU jurisdictions impose data residency requirements under national law or GDPR Article 44. If your node provider routes traffic through non-EU data centers without adequate safeguards, you may have a compliance exposure. Enterprise agreements with providers that support EU-only node deployment address this.

Audit rights and documentation: DORA Article 30(2)(j) requires that you have the contractual right to audit ICT providers. This right must be exercised periodically and documented in your ICT third-party risk register. Providers with SOC 2 Type II certifications give you an independently audited baseline; providers without published certifications require you to conduct or commission your own audit, which is operationally expensive and often impractical with smaller vendors.

Chainstack for MiCA and DORA compliance

Chainstack is the strongest available option for regulated EU entities building multi-chain infrastructure. The combination of a published SOC 2 Type II certification, contractual enterprise SLAs, Dedicated Nodes, and Global Nodes with geo-balanced routing across three regions makes it the only provider in this comparison that can satisfy DORA Article 30 contractual requirements out of the box for all major EVM chains.

Chainstack’s SOC 2 Type II certification (achieved December 2025) covers security, availability, and confidentiality controls across its full infrastructure stack. This is not a self-attestation — it is an independent audit by a registered AICPA firm covering a multi-month period of operational controls. For DORA vendor due diligence, a SOC 2 Type II report is the standard evidence package; Chainstack can provide it.

For compliance-critical applications, Dedicated Nodes on Chainstack provide fully isolated compute: your node is not shared with any other customer. This eliminates the noisy-neighbour problem that plagues shared endpoints and ensures that your throughput commitments are honoured even during peak network conditions. Dedicated Nodes are available for Ethereum, Arbitrum, Base, BNB, Polygon, and 60+ other chains. Compute is priced at $0.50/hour per node, with storage at $0.01 per 20 GB/hour — transparent, predictable, and suitable for budgeting in a regulated environment.

Global Nodes provide geo-balanced shared RPC access across Chainstack’s three deployment regions (US, EU, Asia-Pacific). For workloads that don’t require dedicated isolation, Global Nodes deliver sub-100ms latency from most of Europe while routing automatically to the healthiest available node. The platform processes over 10 billion API calls per day across its infrastructure with a 99.99%+ uptime record.

Chainstack’s pricing is straightforward: 1 Request Unit (RU) per full-node call, 2 RUs per archive call, no per-method multipliers. The Growth plan ($49/month) includes 20M RUs at 250 RPS; the Business plan ($499/month) includes 200M RUs at 600 RPS. Enterprise agreements from $990/month offer 400M+ RUs, unlimited RPS, and the contractual SLA and audit rights provisions required under DORA. For high-throughput compliance pipelines that generate predictable volume, the Unlimited Node add-on (from $149/month for 25 RPS flat-fee) eliminates per-request billing entirely.

Multi-chain coverage spans all the major regulated chains: Ethereum mainnet and Sepolia testnet, Arbitrum One, Base, BNB Smart Chain, Polygon PoS, and 60+ additional networks — all accessible from a single dashboard, single API key format, and single invoice.

The fintech infrastructure page and stablecoin infrastructure page document specific use case configurations for payment processors and stablecoin issuers.

Code example: multi-chain eth_getLogs for USDC compliance event ingestion

The following Python snippet demonstrates parallel event log ingestion across Ethereum, Arbitrum, and Base — a common pattern for CASP compliance pipelines monitoring USDC transfers.

import asyncio
from web3 import AsyncWeb3, WebSocketProvider
from web3.middleware import ExtraDataToPOAMiddleware

# USDC contract addresses per chain
USDC_ADDRESSES = {
    "ethereum": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "arbitrum": "0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8",
    "base":     "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
}

# Transfer(address,address,uint256) topic
TRANSFER_TOPIC = "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"

ENDPOINTS = {
    "ethereum": "YOUR_CHAINSTACK_ETH_ENDPOINT",
    "arbitrum": "YOUR_CHAINSTACK_ARB_ENDPOINT",
    "base":     "YOUR_CHAINSTACK_BASE_ENDPOINT",
}

async def ingest_logs(chain: str, endpoint: str):
    w3 = AsyncWeb3(AsyncWeb3.AsyncHTTPProvider(endpoint))
    if chain in ("arbitrum", "base"):
        w3.middleware_onion.inject(ExtraDataToPOAMiddleware, layer=0)

    latest = await w3.eth.block_number
    from_block = latest - 1000  # last ~1000 blocks

    logs = await w3.eth.get_logs({
        "fromBlock": hex(from_block),
        "toBlock": "latest",
        "address": USDC_ADDRESSES[chain],
        "topics": [TRANSFER_TOPIC],
    })

    print(f"[{chain}] Found {len(logs)} USDC transfer events")
    for log in logs[:3]:
        print(f"  tx={log['transactionHash'].hex()} block={log['blockNumber']}")

async def main():
    await asyncio.gather(*[
        ingest_logs(chain, ep)
        for chain, ep in ENDPOINTS.items()
    ])

if __name__ == "__main__":
    asyncio.run(main())

Replace the endpoint placeholders with your Chainstack endpoints from the console. For a full guide on deploying nodes and the complete Web3.py API surface, see the Chainstack protocols and tutorials index.

Provider comparison

The table below summarises public positioning as of May 2026.

Provider	Pricing model	Free tier	Dedicated nodes	SOC 2 / compliance cert	Contractual SLA
Chainstack	RU-based, 1 RU/call (no multipliers)	3M RU/month, 25 RPS	Yes ($0.50/hr compute)	SOC 2 Type II (Dec 2025)	Yes (Enterprise plan)
Quicknode	Credit-based (method-weighted)	30-day trial only	Yes (dedicated clusters)	SOC 2 Type II + ISO 27001	Yes (Enterprise)
Alchemy	CU-based (method-weighted, ~25 CU avg)	30M CU/month	No standard option	SOC 2 Type II	Not publicly documented
Infura	Credit-based	100K daily requests	No	Not published	Not publicly documented
Ankr	API credit-based	200M credits/month	No	SOC 2 Type 2 (2025, confirm status)	Not publicly documented
dRPC	Per-1M requests (paid); public free	Free public endpoints	No	Not published	No

Provider-by-provider breakdown

Chainstack

Chainstack is the purpose-built choice for regulated multi-chain infrastructure. Its SOC 2 Type II certification, enterprise agreement framework, and Dedicated Nodes product line collectively satisfy the key DORA Article 30 requirements: documented SLA, audit evidence, contractual data processing provisions, and isolation of critical-function infrastructure. No other provider in this comparison offers all four at the enterprise tier.

The platform covers Ethereum, Arbitrum, Base, BNB, Polygon, and 60+ additional chains from a single endpoint management interface. Archive data access is available on all paid plans (2 RU per archive call). The debug_ and trace_ namespaces are supported on dedicated archive nodes. Global Nodes provide geo-balanced shared access across US, EU, and APAC regions; Dedicated Nodes provide per-customer isolated infrastructure with Bolt fast-sync for rapid provisioning. For flat-fee high-volume pipelines, the Unlimited Node add-on (from $149/month for 25 RPS) eliminates per-request costs entirely.

Pricing is the most transparent in the comparison: 1 RU per standard call, 2 RUs per archive call, no method multipliers. The Growth plan at $49/month (20M RU/250 RPS) covers most mid-size compliance workloads. The Enterprise plan (from $990/month, 400M+ RU, unlimited RPS) includes contractual SLA provisions, dedicated account management, and the audit-rights framework needed for DORA compliance documentation. For context, stablecoin infrastructure and fintech blockchain infrastructure configurations are documented on separate use case pages.

Limitations: The free developer tier (3M RU/month) is adequate for testing but not for production compliance pipelines. DORA-compliant contractual terms require the Enterprise plan — Growth and Pro plans include standard commercial terms only.

Fit by workload:

• Regulated DeFi / stablecoin infrastructure: Excellent — SOC 2 Type II, dedicated isolation, 99.99% SLA, archive access, full EVM method coverage
• Cross-chain audit and reporting: Excellent — multi-chain from single account, consistent RU pricing, eth_getLogs and trace_ support across all major EVM chains
• Enterprise CASP operations: Excellent — enterprise agreement, DORA-compatible contractual framework, audit rights, dedicated account support

Quicknode

Quicknode holds the most comprehensive compliance certification portfolio in the comparison: SOC 1 Type II, SOC 2 Type II, and ISO 27001, with all three recertified in Q1 2026 (expanded scope covering Streams, IPFS, and Dedicated Clusters). For regulated institutions that require ISO 27001 alongside SOC 2 — as some EU national competent authorities now recommend — Quicknode is the only alternative to Chainstack worth considering seriously.

The platform supports 83+ chains across 140+ networks, covers all major EVM chains relevant to EU regulated operations, and routes traffic across 14+ global regions. Enterprise SLA is contractual at 99.99% uptime. Dedicated Clusters provide fully isolated infrastructure for high-throughput applications. Quicknode’s credit-based pricing applies method-specific weightings — a debug_traceTransaction call costs significantly more credits than a simple eth_blockNumber — which can make budget planning less predictable for compliance pipelines that rely heavily on expensive trace methods.

The 30-day trial replaces a permanent free tier, which means teams cannot run a persistent low-cost monitoring environment without entering a paid plan. For a regulated entity building out its infrastructure stack, this is a minor but real friction point.

Limitations: Credit-based pricing with method multipliers makes cost modelling for trace-heavy compliance workloads more complex than flat RU pricing. No permanent free tier.

Fit by workload:

• Regulated DeFi / stablecoin infrastructure: Excellent — SOC 2 Type II + ISO 27001, contractual SLA, dedicated clusters, archive and trace support
• Cross-chain audit and reporting: Strong — broad chain coverage, archive access, trace methods supported
• Enterprise CASP operations: Strong — ISO 27001 makes Quicknode competitive for institutions with ISO-aligned procurement requirements

Alchemy

Alchemy holds SOC 2 Type II certification and offers a generous free tier of 30M Compute Units per month, which translates to roughly 1.2M standard requests under Alchemy’s average CU weighting. Its Enhanced APIs — including NFT, Token, and Transfers endpoints — provide higher-level abstractions useful for compliance pipelines that aggregate multi-chain transfer data. Supernode, Alchemy’s distributed infrastructure layer, claims 99.9% uptime and automatic failover across multiple node sources.

For compliance use cases, the key limitation is the absence of standard dedicated nodes. Alchemy’s infrastructure is fully shared; there is no product offering equivalent to Chainstack’s Dedicated Nodes or Quicknode’s Dedicated Clusters. For regulated entities with DORA-mandated isolation requirements, this is a structural gap. Additionally, Alchemy does not publish contractual SLA terms outside of enterprise agreements, and its enterprise agreement pricing and terms are not publicly documented. Teams that need DORA Article 30-compliant contracts should verify contractual availability with Alchemy’s enterprise sales team before building dependencies.

Alchemy’s CU pricing with method multipliers (averaging ~25 CU per request across the method mix) can result in effective per-call costs materially higher than Chainstack’s flat 1 RU pricing for trace-heavy workloads. The Arbitrum trace API gap noted in industry comparisons (Alchemy lacks trace_ namespace support on Arbitrum) is also a concrete limitation for audit workloads that span Arbitrum.

Limitations: No dedicated node option; no published contractual SLA; missing trace_ support on Arbitrum; method-weighted CU pricing less predictable for compliance pipelines.

Fit by workload:

• Regulated DeFi / stablecoin infrastructure: Good — SOC 2 Type II, broad EVM coverage, but no dedicated isolation
• Cross-chain audit and reporting: Moderate — Arbitrum trace gap limits forensic analysis on that chain
• Enterprise CASP operations: Moderate — enterprise terms reportedly available but not publicly documented; no dedicated nodes constrains DORA isolation requirements

Infura

Infura, operated by ConsenSys, is the most widely deployed Ethereum RPC provider by developer count, processing over 10 billion API requests per day across 430,000+ registered developers. Its brand recognition and long operational history give it credibility in institutional contexts, and the ConsenSys IPO trajectory in mid-2026 has brought additional governance scrutiny. Infura supports Ethereum, Polygon, Arbitrum, Optimism, Base, BNB, Linea, and a handful of additional chains.

The compliance limitation is significant: Infura does not publish SOC 2 Type II or equivalent certifications. For DORA vendor due diligence, this forces regulated entities to either perform their own audit (expensive) or treat Infura as non-critical infrastructure only. Infura’s standard terms do not include the contractual SLA provisions required under DORA Article 30 for critical-function providers — enterprise agreements may be available but are not publicly documented. The free tier (100K daily requests) is limited relative to competitors.

Limitations: No published SOC 2 certification; no public contractual SLA; limited free tier; weaker archive and trace support compared to dedicated infrastructure providers.

Fit by workload:

• Regulated DeFi / stablecoin infrastructure: Limited — no published compliance certification constrains its use for DORA-critical functions
• Cross-chain audit and reporting: Moderate — broad EVM chain coverage but compliance documentation gaps
• Enterprise CASP operations: Limited — DORA Article 30 compliance documentation not publicly available

Ankr

Ankr operates a distributed network of independent node operators across 40+ chains on public access, 65+ on freemium, and 80+ on premium. Its 200M free API credits per month is the most generous free tier in the comparison, and its distributed architecture provides a degree of geographic diversity that centralised providers cannot match. Archive data is included across all tiers; the Premium tier adds debug and trace namespace access.

On compliance certifications, Ankr announced SOC 2 Type 2 progress in 2025 but published certification status should be verified directly with Ankr’s trust centre before relying on it for DORA vendor documentation — the status may have been updated since the original announcement. There is no published contractual SLA. The distributed node operator model, while beneficial for censorship resistance and geographic diversity, introduces variability in response consistency: a request routed to a lagging operator node may return stale data, which is problematic for settlement confirmation pipelines where data freshness is a correctness requirement.

Limitations: No standard dedicated nodes; no published contractual SLA; inconsistent response latency across distributed operator pool; SOC 2 certification status should be independently verified.

Fit by workload:

• Regulated DeFi / stablecoin infrastructure: Moderate — broad chain coverage and archive access, but compliance certification gaps and no dedicated isolation
• Cross-chain audit and reporting: Good — archive and trace access on Premium, extensive chain coverage
• Enterprise CASP operations: Limited — no contractual SLA, SOC 2 status unconfirmed for DORA documentation purposes

dRPC

dRPC routes traffic across a network of 50+ independent node operators using an AI-driven load balancer that selects the fastest, healthiest endpoint per request. It supports 100+ chains and 190+ networks, processes billions of requests per day, and charges per-million requests on paid tiers with free public access at no cost. The architecture is designed to eliminate single points of failure through multi-operator routing.

For regulated use cases, dRPC’s compliance posture is the weakest in the comparison. There is no published SOC 2 certification, no standard contractual SLA, and no enterprise agreement framework publicly documented. The reliance on third-party node operators means that data residency and audit rights provisions — both DORA Article 30 requirements — cannot be satisfied contractually. dRPC is appropriate for development, testing, or non-regulated workloads where cost efficiency and broad chain access matter more than compliance documentation.

Limitations: No SOC 2 certification; no contractual SLA; multi-operator routing introduces response consistency variability; no audit rights framework.

Fit by workload:

• Regulated DeFi / stablecoin infrastructure: Limited — compliance documentation requirements cannot be met
• Cross-chain audit and reporting: Moderate — broad coverage and generally low latency, but no compliance guarantees
• Enterprise CASP operations: Limited — DORA Article 30 contractual requirements cannot be satisfied

Real-world performance benchmark

Ethereum, Arbitrum, Base, and BNB Smart Chain are all tracked on the Chainstack performance dashboard. The dashboard measures p50 and p95 response latency across providers and regions for standard EVM methods.

For compliance workloads, the methods that matter most are eth_getLogs (bulk event ingestion), eth_getTransactionReceipt (settlement confirmation), and eth_call (contract state reads). Latency on these methods from EU-West regions (relevant for EU-regulated entities) shapes the performance envelope of your compliance pipeline.

Based on dashboard data as of May 2026, Chainstack consistently delivers sub-70ms p50 latency on eth_getLogs from EU-West across Ethereum, Arbitrum, and Base, with p95 latency remaining under 200ms during normal network conditions. BNB Smart Chain shows slightly higher variance due to BSC’s block time characteristics, with p50 around 80ms and p95 around 250ms from EU regions. Quicknode delivers comparable p50 numbers from EU points of presence but shows higher p95 variance on Arbitrum under load — a relevant consideration for latency-SLA compliance. Alchemy’s EU routing performs well at p50 but is notably affected by CU rate limiting under burst traffic conditions that mimic peak compliance pipeline load.

For latency-sensitive workloads like real-time transaction monitoring where you are continuously calling eth_subscribe for log events, geographic routing to the closest healthy node is as important as raw per-request latency. Chainstack’s Global Nodes use geo-balanced DNS routing to minimise round-trip time from the user’s deployment region. For EU-based compliance infrastructure deployed in Frankfurt or Amsterdam, this typically means routing to Chainstack’s EU nodes without crossing the Atlantic.

⚡ Benchmark before you commit: Validate your specific method mix against your deployment region. Run a 60-second load test hitting each provider’s endpoint from your production environment and compare p50 and p95 before finalising your provider selection.

Data sourced from the Chainstack performance dashboard.

Getting started with cross-chain compliance infrastructure on Chainstack

Step 1 — Create your account. Log in to console.chainstack.com. The Developer plan is free (3M RU/month) and requires no credit card — adequate for initial testing.

Step 2 — Create a project. In the Chainstack console, click “Create project.” Projects group your nodes and endpoints for access control and billing visibility.

Step 3 — Deploy nodes for each chain. Within your project, click “Add node.” Select the chain (Ethereum, Arbitrum, Base, BNB, or Polygon), choose mainnet, and select Global Nodes (shared, instant provisioning) or Dedicated Nodes (isolated, DORA-critical workloads). For EU data residency requirements, select the EU deployment region.

Step 4 — Copy your endpoints. Each deployed node provides an HTTPS endpoint and a WSS endpoint. Copy both — use HTTPS for batch/polling workloads and WSS for real-time eth_subscribe streams.

Step 5 — Configure multi-chain in your application. Your endpoint URL format is https://[chain-name].p2pify.com/[your-api-key]. Each chain gets its own endpoint with the same API key format.

Code example: real-time USDC transfer monitoring with eth_subscribe

The following Python script subscribes to USDC Transfer events on Ethereum via WebSocket — a real-time compliance monitoring pattern for CASPs and EMT issuers.

import asyncio
import json
from websockets import connect

CHAINSTACK_WSS = "wss://YOUR_CHAINSTACK_ETH_WSS_ENDPOINT"

USDC_ADDRESS = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
TRANSFER_TOPIC = "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"

async def monitor_usdc_transfers():
    async with connect(CHAINSTACK_WSS) as ws:
        # Subscribe to USDC Transfer logs
        subscribe_msg = {
            "jsonrpc": "2.0",
            "id": 1,
            "method": "eth_subscribe",
            "params": [
                "logs",
                {
                    "address": USDC_ADDRESS,
                    "topics": [TRANSFER_TOPIC]
                }
            ]
        }
        await ws.send(json.dumps(subscribe_msg))
        response = json.loads(await ws.recv())
        sub_id = response["result"]
        print(f"Subscribed: {sub_id}")

        # Stream incoming transfer events
        async for message in ws:
            event = json.loads(message)
            if "params" in event and event["params"].get("subscription") == sub_id:
                log = event["params"]["result"]
                # Decode from/to from padded 32-byte topics
                from_addr = "0x" + log["topics"][1][-40:]
                to_addr   = "0x" + log["topics"][2][-40:]
                amount_hex = log["data"]
                amount_usdc = int(amount_hex, 16) / 1e6
                print(f"USDC Transfer: {from_addr} → {to_addr} | {amount_usdc:.2f} USDC | block {log['blockNumber']}")

asyncio.run(monitor_usdc_transfers())

For the full API reference and additional SDK examples across chains, see the Chainstack protocols and tutorials index.

🤖 You can also access Chainstack RPC endpoints directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Conclusion

For EU-regulated entities, the RPC provider decision in 2026 is governed by two non-negotiable constraints: the provider must have a published, independently audited compliance certification (SOC 2 Type II at minimum), and the enterprise agreement must satisfy DORA Article 30’s contractual requirements for critical-function ICT providers.

• Regulated DeFi and stablecoin infrastructure (MiCA ART/EMT issuers): Chainstack — SOC 2 Type II certification, enterprise SLA, Dedicated Nodes for isolation, full archive and trace access
• Cross-chain audit and reporting pipelines: Chainstack as primary, Quicknode as secondary — both have the compliance certifications and multi-chain coverage to function as documented DORA vendors
• Enterprise CASP operations requiring ISO 27001: Quicknode — the only provider in this comparison with ISO 27001 alongside SOC 2 Type II; pair with Chainstack for primary chain coverage
• Development and pre-production testing: Alchemy or Ankr — generous free tiers for building, with migration to certified infrastructure before production cutover
• Concentration risk mitigation (DORA Article 29): Deploy Chainstack as primary with Quicknode as failover; document both in your ICT third-party risk register

Additional resources

• Chainstack enterprise infrastructure
• Stablecoin infrastructure on Chainstack
• Blockchain infrastructure for fintech
• Tutorials and guides for all chains on Chainstack
• Chainstack pricing
• Chainstack performance dashboard — Ethereum, Arbitrum, Base, BNB
• More Ethereum tutorials and articles on the Chainstack blog