# Stablecoin RPC Evaluation Matrix

**For:** GetBlock / rpc.run  
**Buyer:** CTO, Platform/Infrastructure, Security, Risk, Compliance, Procurement  
**Scope:** Production stablecoin infrastructure; managed RPC vs self-hosted nodes  
**Providers reviewed:** GetBlock, Alchemy, QuickNode, Chainstack, Infura  
**Evidence checked:** 2026-09-14 (MYT / UTC+8)  
**Evidence policy:** official vendor pages and official documentation only. Vendor claims are not independent measurements. `Unknown` means “not verified in the reviewed public official material,” not “absent.” No provider is declared the default winner.

---

## Executive decision

Do not select a production stablecoin RPC provider from a feature-count table. First eliminate candidates that fail a non-negotiable gate; then run the same production-shaped test against the remaining options.

**Recommended shortlist posture:**

- Keep **GetBlock, Alchemy, QuickNode, and Chainstack** in the managed-provider evaluation where their exact chain/method/region coverage is contractually or technically verified.
- Keep **Infura** in the shortlist for an Ethereum/EVM-oriented flow, but resolve the public-site inconsistency around network-count messaging and obtain security, data-location, failover, and support evidence directly.
- Keep **self-hosted nodes** as an architectural option, not as an assumed baseline. Score them only after the buyer documents staffing, client diversity, patching, monitoring, disaster recovery, and total cost.
- For a regulated flow, prefer an architecture that can survive the loss of one endpoint, region, or vendor. A vendor-native fallback is useful, but it is not the same as independent cross-provider failover.

---

## 1. Buyer scenario: production stablecoin flow

> **Hypothetical reference scenario — replace with the buyer’s real chain list, methods, regions, traffic, and regulatory constraints before scoring.**

A regulated fintech issues and redeems a fiat-backed stablecoin. The first production corridor is **Ethereum + Base**; additional EVM networks may follow. The company operates a Web2 ledger, KYC/AML and sanctions controls, treasury workflows, and customer APIs.

### Critical paths

1. **Mint / burn control path**
   - Policy, approval, and signing happen outside the RPC provider.
   - The platform reads nonce, gas, chain state, and contract state; broadcasts a signed transaction; monitors inclusion and a buyer-defined confirmation/finality threshold.
2. **Payments and redemption path**
   - Detect token transfers and administrative events.
   - Match on-chain events to the internal ledger and customer transaction state.
3. **Indexing / reconciliation path**
   - Consume logs or a data-stream/indexing product.
   - Handle duplicates, gaps, reorgs, delayed delivery, replay, and historical backfill.
4. **Monitoring / incident path**
   - Detect stale heads, elevated latency, errors, rate limits, missed events, and provider incidents.
   - Fail over safely without double-broadcasting or corrupting reconciliation state.
5. **Audit / security path**
   - Preserve request, change, access, and incident evidence according to internal retention rules.
   - Restrict endpoint access; rotate credentials; support vendor-risk and regulatory review.

### Production stress events

- redemption spike or market dislocation;
- chain congestion or reorg;
- regional/provider outage;
- rate-limit exhaustion;
- client upgrade or node falling behind;
- leaked endpoint credential;
- delayed or duplicated stream delivery;
- mismatch between on-chain events and the Web2 ledger.

### Architectures to test

- managed provider primary + independent managed-provider fallback;
- dedicated managed node + vendor shared-pool fallback + independent emergency endpoint;
- self-hosted primary + managed fallback;
- managed primary + self-hosted verification/read path.

---

## 2. Evaluation criteria and weights

| # | Criterion | Weight | Pass condition for this scenario |
|---|---|---:|---|
| 1 | Chain / API fit | 15% | Ethereum and Base; every required JSON-RPC method; HTTP + WebSocket where needed; archive/trace semantics documented and tested. |
| 2 | Failover and resilience | 15% | Health signal, trigger, routing target, recovery behavior, RTO/RPO, region/provider independence, and write-safety are documented and chaos-tested. |
| 3 | Observability | 10% | Per-method latency/error/rate-limit visibility, head-lag monitoring, alert integrations, export/API, and retention meet operations needs. |
| 4 | Incident response and SLA | 15% | Plan-specific legal SLA, exclusions, measurement, credits, support severity matrix, escalation, communication, and RCA expectations are accepted. |
| 5 | Security | 10% | Endpoint restrictions, RBAC/SSO/MFA, audit logs, encryption, secret rotation, vulnerability process, and evidence pack pass security review. |
| 6 | Compliance and data location | 10% | Exact processing/storage/transit locations, subprocessors, retention/deletion, audit reports, and applicable regulatory mappings are confirmed. |
| 7 | Support and governance | 8% | Named owner, 24/7 production escalation, response vs resolution targets, change notices, chain-upgrade handling, and QBR/governance are contractual. |
| 8 | Migration | 7% | Inventory, compatibility test, shadow traffic, cutover, rollback, and dual-run plan are executable. |
| 9 | Exit plan / portability | 5% | Standard APIs where possible; configuration/log/data export; credential revocation; deletion evidence; notice period; tested provider swap. |
| 10 | Capacity and commercial fit | 5% | Production-shaped throughput, burst, heavy methods, stream volume, overage behavior, and total cost are tested against written terms. |

**Scoring rule:** unknowns are **not zero and not a pass**; they remain unscored until evidence is supplied. A failed hard gate eliminates a candidate regardless of weighted total.

### Hard gates

- exact production chain + method + interface support;
- acceptable failure-domain design and tested recovery;
- accepted data-location/retention position;
- security evidence accepted by the buyer;
- plan-specific SLA/support exhibit;
- executable rollback and exit path.

---

## 3. Decision matrix

Evidence IDs refer to the exact-quote ledger in section 4.

| Provider / option | Verified official evidence | Important unknowns | Buyer questions | Best fit / honest trade-off |
|---|---|---|---|---|
| **GetBlock** | Base JSON-RPC is documented (GB1). Dedicated-to-shared automatic failover and its shared-pool limit are documented (GB2–GB3). Dashboard and dedicated-node analytics expose request, status, method, latency, error, key, and region views (GB4–GB5). IP allowlisting is documented (GB6). Legal SLA distinguishes shared, dedicated, and load-balanced dedicated tiers (GB7). Migration runbook exists (GB8). EVM Data Streams documents live topics, launch networks, and no initial historical backfill; Base is “next up” (GB9). Dedicated page states deployment/security options (GB10), but contains SLA/support headline language that needs reconciliation with the legal SLA (GB11). | Exact required method behavior under load; cross-region/cross-provider failover; failover detection thresholds and RTO; stream delivery/reorg/replay guarantees; Base Streams production availability; telemetry export/API and retention; customer-data flow, residency, subprocessors and deletion; full SOC 2 report scope; contract-specific support resolution targets; exit/export package. | Is failover only dedicated→shared, or can it span regions and independent failure domains? What happens to `eth_sendRawTransaction` during an ambiguous timeout? Can the buyer set health thresholds? Which Base methods, archive ranges, and trace calls are supported on the purchased tier? What are stream deduplication, ordering, reorg and replay semantics? Which SLA wording controls the contract? | **Potentially good fit** for teams wanting shared RPC, dedicated nodes, custom infrastructure, private networking/on-prem options, and an explicit migration path. **Trade-off:** the documented native failover shares the same vendor and falls back to a rate-limited shared pool; EVM Streams is currently narrower than the RPC footprint and publicly says historical backfill is outside the initial release. |
| **Alchemy** | Enterprise page states 24/7 access to account team/engineers (AL1), 99.99% uptime headline plus custom uptime/support SLA language (AL2), SSO/MFA/RBAC, TLS, KMS, and named cloud providers (AL3). Pricing page lists Node API, Smart WebSockets, Token/Transfers/Portfolio/NFT APIs, Webhooks, request logs, custom alerts, analytics, usage reporting, archive data and plan-dependent controls (AL4). Throughput is account-level and uses a rolling-window model (AL5). | Exact Ethereum/Base method matrix and archive/trace constraints for the proposed contract; architecture and customer-controlled failover; regional placement and data storage/processing location; Alchemy’s own audit/certification evidence (the reviewed page refers to cloud-provider SOC 2 status); incident RCA commitments; exact enterprise support targets; webhook delivery/reorg/replay guarantees; configuration/data export and termination process. | Is 99.99% contractual for the quoted service boundary, and how are partial/degraded responses counted? Which regions and failure domains serve this account? What audit reports cover Alchemy itself? How do Transfers API/Webhooks handle reorgs, duplicates, ordering, retries and replay? Can all production usage/config/audit data be exported? | **Potentially good fit** for teams that want RPC plus higher-level data APIs, webhooks, wallet/transaction tooling, and enterprise IAM in one platform. **Trade-off:** higher-level APIs can reduce build effort but expand portability work; public evidence reviewed here does not establish data location, exact failover design, or Alchemy’s own compliance attestations. |
| **QuickNode** | Enterprise page states contractual 99.99% commitments, credits, production-endpoint measurement, named architect and 24/7 on-call engineering, RBAC/audit logs, and reports on request (QN1). Streams states automatic reorg handling/retries plus historical backfill and delivery options (QN2). Security page states SOC 1 Type 2, SOC 2 Type 2 and ISO/IEC 27001, plus encryption and layered controls (QN3). Enterprise page says capacity spans RPC, Streams, SQL Explorer, Yellowstone gRPC and Webhooks (QN4). | Exact per-chain/per-product coverage for Ethereum/Base and required methods; customer-specific regions and data residency; stream guarantee wording in the contract; independent cross-region/provider failover; retention/deletion and subprocessor details; benchmark methodology behind comparative speed language; exit/export process; contract price and overage behavior. | Do “no rate limits on supported methods” and stream delivery claims appear in the signed order/SLA, with exclusions? Where are requests, logs and stream payloads processed and stored? Is failover multi-region and/or multi-cloud? What are stream ordering, duplicate, reorg depth, replay window, and RPO? What can be exported at exit? | **Potentially good fit** for buyers wanting a broad integrated RPC + Streams/Webhooks/gRPC/SQL toolset and publicly stated enterprise certifications/support. **Trade-off:** product coverage differs (for example, Core endpoints and Streams use different network-count language), and the buyer must verify exact chain/product coverage, data location, and guarantee boundaries. |
| **Chainstack** | Enterprise page describes globally distributed intelligent load balancing, adaptive fault tolerance, custom uptime SLAs, 24/7 monitoring, notification channels, and a 1-hour priority-response SLA (CS1). Pricing page lists enterprise custom throughput, tailored load balancing, archive access, and dedicated/self-hosted options (CS2). Security page states ISO/IEC 27001 certification and offers SOC 2 and penetration-test reports (CS3). Official docs expose dedicated monitoring, hybrid hosting, access rules, authentication, and migration sections in the platform navigation (CS4). | Exact SLA denominator/exclusions/credits for the proposed service; exact Ethereum/Base methods and node modes; failover topology and recovery behavior; data processing/storage/retention locations; scope/dates of reports; indexing/streaming semantics for stablecoin reconciliation; support resolution targets; exit/export and deletion process; self-hosted responsibility split. | What does “adaptive fault-tolerance” do during stale-head, partial method failure, or region loss? Which cloud/region combinations and data locations apply? Is the 1-hour target acknowledgment or engineering engagement? What is included in Hybrid hosting, and who patches/monitors/owns incident response? How are logs and configs exported? | **Potentially good fit** for buyers comparing elastic, dedicated, and hybrid/self-hosted deployment models and wanting location/configuration choice. **Trade-off:** public marketing is strong on architecture and support claims, but the buyer still needs the contract, failure-mode design, data-governance pack, and stablecoin indexing semantics. |
| **Infura** | Pricing page states access to 40+ supported networks and full archive data on Core, Debug/Trace API on Developer, and Enterprise auto-scaling/burst capacity plus enhanced support SLA (IN1). Networks page explicitly displays Ethereum and Base among supported networks (IN2). Official status page publishes outages/incidents/maintenance and offers Email, SMS, Webhook, Slack and RSS subscriptions (IN3). | The network page’s hero says Ethereum plus 8 networks while pricing says 40+; exact current production coverage must be reconciled. Exact Base/Ethereum methods and archive/trace limits; failover architecture and contractual uptime; security controls and audit reports; regional/data-location/retention details; observability/export; indexing/stream product for reconciliation; enterprise response/resolution targets; migration and exit plan. | Which official source is authoritative for network coverage? Is Base included in the buyer’s exact plan and method set? What uptime/failover commitments and failure domains apply? Which security certifications and data-location terms can procurement review? What replaces or complements `eth_getLogs` for guaranteed event delivery/replay? | **Potentially good fit** for an Ethereum/EVM-oriented buyer that wants a familiar RPC service, archive access, Debug/Trace on qualifying tiers, and a mature public status channel. **Trade-off:** based on the reviewed public pages, more procurement-critical fields remain unknown than for some peers, and network-count messaging is internally inconsistent. |
| **Self-hosted nodes** | No vendor claim is treated as evidence. Evidence must come from the buyer’s own architecture, cloud/client documentation, runbooks, tests, incident history, and cost model. | Staffing/on-call; client diversity; patching and upgrades; multi-region replication; chain-head correctness; backups/snapshots; monitoring; DDoS/network security; data residency; capacity; indexing; 24/7 support; TCO; exit from the chosen cloud/client stack. | Can the team operate two clients/regions through upgrades and chain incidents? What are measured RTO/RPO and stale-head detection? Who owns 24/7 response? What is the fully loaded cost, including engineering and incident burden? | **Potentially better fit** when control, bespoke clients/indexers, deterministic data location, or infrastructure sovereignty outweigh operating burden—and the team already has serious SRE/blockchain operations capability. **Trade-off:** control is not resilience by itself; all reliability and support evidence must be created and maintained internally. |

---

## 4. Exact-quote evidence ledger

All checks below were performed **2026-09-14**. Quotations are first-party vendor statements, not independent validation.

### GetBlock

| ID | Criterion | Exact quote | Official URL | Checked |
|---|---|---|---|---|
| GB1 | Chain/API fit | “GetBlock provides fast and reliable access to Base nodes via JSON-RPC API. Connect to the Base network without running your own infrastructure.” | https://docs.getblock.io/api-reference/base.md | 2026-09-14 |
| GB2 | Failover | “Automatic RPC Failover keeps your application online when your dedicated node degrades. If the node falls behind or starts to fail, the system moves your traffic to **GetBlock shared RPC** and moves it back once the node recovers. The switch is automatic, and your endpoint URL never changes.” | https://docs.getblock.io/extra-services-for-dedicated-nodes/automatic-rpc-failover.md | 2026-09-14 |
| GB3 | Failover limitation | “The shared pool has its own rate limits. Failover is there to keep you online during a problem; it is not a way to get unlimited dedicated capacity on demand.” | https://docs.getblock.io/extra-services-for-dedicated-nodes/automatic-rpc-failover.md | 2026-09-14 |
| GB4 | Observability | “All data is displayed through infographics, including: * Number of requests and CUs * Response statuses * Method call distribution * Rate limit rejections” | https://docs.getblock.io/getting-started/monitoring-and-analytics.md | 2026-09-14 |
| GB5 | Observability | “Advanced Analytics is a private Grafana workspace for your dedicated node. It records every request the node handles… It shows request counts, latencies, and errors.” | https://docs.getblock.io/extra-services-for-dedicated-nodes/advanced-analytics.md | 2026-09-14 |
| GB6 | Security | “When the allowlist is active, only requests from addresses you have approved can reach your node. Every other request is blocked at the gateway, before it reaches the node and before any processing takes place.” | https://docs.getblock.io/extra-services-for-dedicated-nodes/ip-allowlist.md | 2026-09-14 |
| GB7 | SLA | “GetBlock shall provide the following levels of Availability for the following categories of Nodes:” followed by “Shared Nodes 99%”, “Dedicated Nodes 99.9%”, and “Dedicated nodes with the load-balancer 99.99%.” | https://getblock.io/sla/ | 2026-09-14 |
| GB8 | Migration | “The agent fetches this page and walks through the migration in three phases: **Assess**, **Plan**, and **Implement**. It stops after Plan and waits for your approval before making any changes to the code.” | https://docs.getblock.io/migration/migrate-to-getblock-with-ai.md | 2026-09-14 |
| GB9 | Indexing/streams | “Pending transaction and trace availability varies by network. Events are live; historical backfill is outside the initial release.” The same page lists Ethereum, Polygon, BNB Smart Chain and Robinhood as “LAUNCH LINEUP,” and Base and Optimism as “NEXT UP.” | https://getblock.io/stream/ | 2026-09-14 |
| GB10 | Compliance/location options | “On-premises deployment inside your data center”; “SOC 2 Type II attested, audit-ready documentation”; “Private networking to AWS / GCP / Azure — no public internet routing”; “IP allowlisting, custom access controls, transaction anonymization.” | https://getblock.io/dedicated-nodes/ | 2026-09-14 |
| GB11 | Public-claim qualification | Dedicated page headline cards state “99.99% Uptime SLA” and “5-min Support SLA,” while the legal SLA gives plan-specific availability and lists “<20 minutes” for Level 1 acknowledgment. | https://getblock.io/dedicated-nodes/ and https://getblock.io/sla/ | 2026-09-14 |

### Alchemy

| ID | Criterion | Exact quote | Official URL | Checked |
|---|---|---|---|---|
| AL1 | Support | “Get 24/7 access to your account team and engineers who understand your architecture and operational needs.” | https://www.alchemy.com/enterprise | 2026-09-14 |
| AL2 | SLA | “99.99% uptime” and “Keep critical onchain workloads available with reliable infrastructure built for production traffic and demand.” The same page states: “Custom uptime SLAs” and “Combine reliable infrastructure with uptime guarantees tailored to your enterprise requirements.” | https://www.alchemy.com/enterprise | 2026-09-14 |
| AL3 | Security | “Use multi-factor authentication (MFA) and role-based access control (RBAC) to limit access to the resources employees need.” “All API calls use TLS…” “Cloud-native secrets management helps secure internal secrets and keys.” | https://www.alchemy.com/enterprise | 2026-09-14 |
| AL4 | API/data/observability surface | The plan comparison lists “Node API,” “Smart websockets,” “Token API,” “Transfers API,” “Portfolio API,” “Webhooks,” “Request logs,” “Custom error and usage alerts,” “App and team analytics,” “Usage reporting,” and “Full archive data.” | https://www.alchemy.com/pricing | 2026-09-14 |
| AL5 | Capacity model | “Throughput is now configured at the account level (no longer per app), meaning the combined usage of all your Alchemy apps counts toward your overall throughput limit.” | https://www.alchemy.com/docs/reference/throughput | 2026-09-14 |

### QuickNode

| ID | Criterion | Exact quote | Official URL | Checked |
|---|---|---|---|---|
| QN1 | SLA/support/security | “99.99% uptime commitments documented in your service agreement. Service credits if we miss. Measured across production endpoints, not best-effort averages.” The page also states “Named solutions architect and 24/7 on-call engineering” and “SOC 1 Type 2, SOC 2 Type 2, and ISO 27001 reports on request.” | https://www.quicknode.com/enterprise | 2026-09-14 |
| QN2 | Streams/indexing | “Automatic reorg handling and retries ensure consistency.” “Backfill historical blockchain data seamlessly with guaranteed delivery and built-in scalability.” | https://www.quicknode.com/streams | 2026-09-14 |
| QN3 | Security | “Quicknode maintains AICPA SOC compliance through independently issued SOC 1 Type 2 and SOC 2 Type 2 audit reports…” and “Quicknode is ISO/IEC 27001 certified…” | https://www.quicknode.com/security | 2026-09-14 |
| QN4 | Product fit | “Scales with your workload across RPC, Streams, SQL Explorer, Yellowstone gRPC, and Webhooks.” | https://www.quicknode.com/enterprise | 2026-09-14 |
| QN5 | Security controls | “Customer and platform data is protected using industry-standard encryption, including AES-256 for data at rest and TLS for data in transit.” | https://www.quicknode.com/security | 2026-09-14 |

### Chainstack

| ID | Criterion | Exact quote | Official URL | Checked |
|---|---|---|---|---|
| CS1 | Resilience/incident/support | “A globally distributed, intelligent load-balanced architecture with realtime adaptive fault-tolerance…”; “24*7 Infra Monitoring”; “Multi-Channel Notifications”; and “Get Priority support with a 1-hour response SLA…” | https://chainstack.com/enterprise/ | 2026-09-14 |
| CS2 | Deployment/capacity | Enterprise plan features include “70+ Blockchains,” “100+ Hosting combinations,” “Custom Throughput,” “Tailored Load Balancing,” and “Archive Data Access.” The page also exposes “Dedicated Nodes” and “Self-Hosted” plan sections. | https://chainstack.com/pricing/ | 2026-09-14 |
| CS3 | Security/compliance | “Chainstack is ISO/IEC 27001 certified…” and “The SOC 2 report delivers customers in-depth assurance on controls, addressing all five Trust Service Criteria…” | https://chainstack.com/security/ | 2026-09-14 |
| CS4 | Platform options | Official documentation navigation lists “Dedicated Node monitoring,” “Hybrid hosting,” “Access rules,” “Authentication methods available on Chainstack,” and “Migrate to Chainstack.” | https://docs.chainstack.com/docs/platform-introduction | 2026-09-14 |

### Infura

| ID | Criterion | Exact quote | Official URL | Checked |
|---|---|---|---|---|
| IN1 | Chain/API/capacity/support | Pricing lists “Access to 40+ supported networks,” “Full archive data,” “Debug / Trace API,” and for Enterprise “Elastic auto-scaling,” “Burstable throughput,” and “Enhanced Support SLA.” | https://www.infura.io/pricing | 2026-09-14 |
| IN2 | Chain fit | The networks page says, “Get connected with Infura's easy-to-use APIs and start building on Ethereum, Layer 2s, EVM and non-EVM compatible chains,” and visibly lists both “Ethereum” and “Base.” | https://www.infura.io/networks | 2026-09-14 |
| IN3 | Incident communication | “On this page we will publish service outages and other incidents, as well as scheduled maintenance notices. You may subscribe to status updates via Email, SMS, Webhook, Slack and Atom/RSS.” | https://status.infura.io/ | 2026-09-14 |
| IN4 | Public-source inconsistency | Networks page hero: “Infura’s multichain ecosystem… across Ethereum and 8 different networks.” Pricing page: “Access to 40+ supported networks.” | https://www.infura.io/networks and https://www.infura.io/pricing | 2026-09-14 |

### Verification notes

- Every cited URL above returned HTTP 200 on 2026-09-14.
- No current uptime percentage was inferred from a status page.
- No customer logo or testimonial was used as performance evidence.
- No list price or customer outcome is used in the decision matrix.
- Failed/retired URLs were not used as proof. In particular, reviewed Infura enterprise/security and older MetaMask-hosted Infura security-doc paths returned 404, so those fields remain `unknown` rather than being filled from memory.

---

## 5. Honest comparison-page structure

### Proposed page title

**Stablecoin RPC Infrastructure: Managed Providers vs Self-Hosted Nodes**

### Recommended information architecture

1. **Who this page is for**
   - CTO, platform/infra, SRE, security, risk/compliance, procurement.
   - Explicitly state who it is not for: hobby apps, testnet-only teams, buyers without a defined chain/workload.
2. **Scenario and assumptions**
   - Chains, methods, interfaces, regions, peak load, finality/reorg policy, data-retention rules.
   - Make assumptions editable or downloadable.
3. **Short answer: there is no universal winner**
   - Explain gates vs weighted criteria.
   - Say `unknown ≠ no` and `vendor claim ≠ measured result`.
4. **Reference architecture**
   - Transaction/read path, event/indexing path, monitoring path, primary/fallback, signer separation.
5. **Non-negotiable gates**
   - Chain/method fit, resilience, security, data location, SLA, rollback/exit.
6. **Evaluation methodology**
   - Weights, evidence standard, checked date, plan/tier caveats, update/change log.
7. **Summary matrix**
   - Provider → verified evidence → unknown → buyer question → best fit/trade-off.
8. **Provider detail cards**
   - “Verified,” “Needs contract,” “Needs benchmark,” “Better for,” “Trade-off.”
   - Never use “winner” unless the buyer’s constraints and benchmark results are shown.
9. **Managed vs self-hosted**
   - Responsibility matrix: deployment, patches, upgrades, client diversity, SRE, DR, security, data governance, support, TCO.
10. **Stablecoin-specific test protocol**
    - Reads, broadcast, receipt/finality, `eth_getLogs`, WebSocket reconnect, reorg simulation, duplicate suppression, backfill, stale-head detection, rate-limit/burst, region failure.
11. **Security and procurement checklist**
    - Reports, architecture, subprocessors, locations, retention/deletion, incident/RCA, support, BCP/DR.
12. **Migration and exit**
    - Inventory → shadow → dual-read → cutover → rollback → quarterly failover drill → termination/export/deletion.
13. **Sources and change log**
    - Exact quotes, URLs, checked dates; mark changed/removed claims.
14. **CTA: Technical Architecture Review**
    - Vendor-neutral review before sales qualification.

### Editorial guardrails

- Separate **contractual**, **documented**, **marketing claim**, **measured by buyer**, and **unknown**.
- Tie every availability/support statement to a plan, service boundary, exclusions, and source.
- Do not compare network counts unless products are equivalent (RPC vs Streams vs agent tools).
- Do not score unverified fields as zero.
- Publish raw benchmark methodology and test locations; do not publish a single global latency number.
- Show where each competitor is a better fit.
- Date every page and maintain a claim-level change log.

---

## 6. Proof GetBlock should prepare

### P0 — required before positioning for regulated production

- [ ] **Machine-readable coverage manifest:** chain, network, method, interface, archive/trace mode, region, plan, limits, last tested timestamp.
- [ ] **Plan-specific SLA exhibit:** service boundary, availability formula, exclusions, credits, maintenance, severity matrix, acknowledgment vs engagement vs resolution, escalation and RCA commitments.
- [ ] **SLA wording reconciliation:** align the “99.99% / 5-min” dedicated-page headlines with the legal SLA’s tier-specific 99.9%/99.99% and <20-minute acknowledgment language.
- [ ] **Failover architecture pack:** failure domains, regions/clouds, health checks, configurable thresholds, RTO/RPO, failback, write ambiguity, shared-pool capacity, and independent-provider pattern.
- [ ] **Stablecoin transaction safety runbook:** nonce ownership, idempotency, ambiguous broadcast response, rebroadcast policy, duplicate prevention, confirmation/finality, reorg handling.
- [ ] **Data-governance pack:** request/log/payload data flow, processing/storage/transit countries, subprocessors, retention, deletion, backups, legal transfer mechanism, deletion certificate.
- [ ] **Security pack:** full SOC 2 report under NDA, scope and dates, penetration-test summary, vulnerability disclosure, encryption, key/token lifecycle, RBAC/SSO/MFA/audit-log roadmap or availability.
- [ ] **Incident evidence:** public status history export, sample incident communications, anonymized postmortem/RCA template, notification channels, maintenance/change policy.

### P1 — needed to win the technical evaluation

- [ ] **Observability specification:** metric definitions, p50/p95/p99, head lag, rate-limit and error taxonomy, alert integrations, API/export, retention, role access.
- [ ] **Streams contract/spec:** exact network/topic coverage, ordering, duplicates, reorg depth, retry policy, delivery guarantee boundary, replay window, historical backfill, schema/versioning, destinations, RPO.
- [ ] **Reproducible benchmark kit:** buyer-run scripts, raw outputs, regions, instance type, concurrency, method mix, warm/cold behavior, p50/p95/p99, errors, stale-head checks, heavy methods, burst recovery.
- [ ] **Migration kit:** endpoint inventory, compatibility tests, shadow/dual-run, secrets handling, cutover, rollback, owner/RACI, success criteria.
- [ ] **Exit package:** standards/proprietary dependency map, config and telemetry export, data return/deletion, credential revocation, notice, assistance, tested swap to a second provider.
- [ ] **Support/governance exhibit:** named owner, 24/7 channels, production escalation, chain-upgrade ownership, maintenance notice, quarterly architecture review.

### P2 — trust-building content

- [ ] Verified case studies with customer permission, architecture, baseline, measurement window, caveats, and reproducible outcome definition.
- [ ] Public changelog for chain/method/region and SLA changes.
- [ ] Vendor-neutral “managed vs self-hosted” TCO worksheet including engineering/on-call/incident cost.

---

## 7. CTA: Technical Architecture Review

### Page CTA copy

**Review your stablecoin RPC architecture before you choose a vendor.**

Bring your production chains, RPC methods, regions, peak traffic, finality/reorg policy, security requirements, and data-location constraints. In a technical architecture review, we will:

- map the transaction, indexing, monitoring, and failover paths;
- identify hard gates and unverified assumptions;
- compare managed, multi-provider, and self-hosted options;
- define a production-shaped benchmark, migration plan, rollback, and exit test.

**Leave with a vendor-neutral evaluation plan—not a forced migration commitment.**

**Primary button:** `Book a technical architecture review`  
**Secondary link:** `Download the evaluation matrix`

### Form fields

- work email and company;
- role;
- production chains and testnets;
- required interfaces/methods;
- regions/data-location constraints;
- approximate peak and monthly workload ranges;
- current architecture/provider;
- target launch or migration window;
- biggest unresolved risk.

### Qualification note

Do not promise that GetBlock will be the recommended answer. The review should be allowed to conclude that Alchemy, QuickNode, Chainstack, Infura, a multi-provider design, or self-hosted nodes fit the buyer better.

---

## Final recommendation

Publish this as an **evaluation framework with a live evidence ledger**, not as “GetBlock vs everyone.” GetBlock’s strongest honest story is not automatic superiority; it is willingness to expose plan-specific evidence, surface unknowns, support production-shaped testing, and help the buyer build a reversible architecture.