GetBlock RPC customer research synthesis
Scope: public-signal mining pass using the customer-research method.
Sources checked: HN comments/search, GitHub issues, StackExchange Ethereum/Solana, competitor landing pages.
Limit: This is not yet first-party VOC from GetBlock customers, sales calls, churn, or support tickets.
Short answer: best ICP to target first
Primary ICP: Production Web3 application teams that depend on RPC reliability for user-facing product flows.
Best subsegments:
1. Wallets, exchanges, trading apps, payment apps — buyer/champion: CTO, Head of Infra, backend lead, SRE — urgent because RPC downtime/latency breaks customer-facing transactions and trust.
2. Web2 → Web3 fintech/product teams — buyer/champion: CTO, VP Eng, Product Lead — urgent because they need blockchain infra without becoming node operators.
3. Analytics / indexing / compliance / risk platforms — buyer/champion: data infra lead, CTO, product/data lead — urgent because they need reliable historical/archive access and clean data.
4. Agencies / dev shops building Web3 products for clients — buyer/champion: founder, tech lead — urgent because they need repeatable infra choices and support across many chains.
5. AI/Web3 agent builders — buyer/champion: technical founder, infra engineer — emerging segment; needs reliable read/write on-chain access, but market is earlier.
Recommended lead message: Reliable multi-chain RPC infrastructure for production Web3 teams that can’t afford public endpoint limits, node maintenance, or silent provider failures.
Avoid: Best Web3 RPC provider for everyone.
The pain is strongest when a team already has production traffic, customer impact, or launch pressure.
Ranked ICP hypotheses
| Rank | ICP | Confidence | Pain intensity | Budget likelihood | Sales motion |
|---|---|---|---|---|---|
| 1 | Production dApp / wallet / exchange / trading teams | High | High | High | Sales-assisted + enterprise |
| 2 | Web2 fintech / payments / product teams entering Web3 | Medium-high | High once building starts | High | ABM + consultative |
| 3 | Blockchain analytics / indexing / data products | Medium-high | High | Medium-high | Sales-assisted |
| 4 | Web3 agencies / dev shops | Medium | Medium-high | Medium | Partner/self-serve |
| 5 | Protocol / foundation ecosystem teams | Medium | Medium | Medium-high | Partnership |
| 6 | AI/Web3 automation and agent platforms | Low-medium | Emerging | Unknown | Experimental / thought leadership |
| 7 | Hobby developers / hackathon builders | High as users, low as buyers | Low-medium | Low | Free/self-serve only |
Core painful jobs-to-be-done
Segment A — production Web3 app teams
| JTBD | Confidence | Customer language / evidence |
|---|---|---|
| Keep app-critical RPC calls fast and available | High | Repeated public complaints around timeouts, 429s, provider lag, failed subscriptions. |
| Avoid public/free RPC limits | High | “limit exceeded”, “429 Too Many Requests”, “rate limited”. |
| Reduce user-visible failures in wallets, deposits, swaps, transaction history | High | StackExchange and GitHub issues show app behavior breaking from RPC/provider errors. |
| Have fallback / dedicated endpoints when shared infra fails | Medium-high | Developer tooling issues discuss fallback transport, execution errors, provider errors. |
| Get support when infrastructure behavior is confusing | Medium | Users ask “what is the limit?”, “why is endpoint lagging?”, “do I need Infura/Alchemy?” |
Segment B — Web2 → Web3 teams
| JTBD | Confidence | Customer language / evidence |
|---|---|---|
| Add blockchain functionality without learning node operations | Medium-high | Questions like “what do Alchemy and Infura actually do?” / “Do I really need it?” |
| Make infra choice understandable to non-Web3 engineering org | Medium | Buyers need simple explanation, not Web3 jargon. |
| Avoid hiring dedicated blockchain infra/SRE too early | Medium | Job postings and HN profiles show “RPC infrastructure, node operations, benchmarking, monitoring, incident handling” as a specialized skillset. |
| De-risk launch before real users arrive | Medium | Strong hypothesis; needs interviews. |
Segment C — analytics/indexing/data products
| JTBD | Confidence | Customer language / evidence |
|---|---|---|
| Access historical/archive data without running archive nodes | High | Archive node sync/storage pain is repeatedly visible. |
| Avoid indexer delay or unreliable data freshness | Medium | Public issues around The Graph/indexing are relevant but need deeper mining. |
| Get consistent multi-chain data access | Medium | Competitor positioning strongly emphasizes RPC + data APIs + indexed data. |
| Reduce infra cost while keeping data completeness | Medium | Needs more pricing/win-loss evidence. |
Segment D — Web3 agencies/dev shops
| JTBD | Confidence | Customer language / evidence |
|---|---|---|
| Pick reliable RPC provider for each client without custom infra work | Medium | Strong market hypothesis, weaker direct quotes in this pass. |
| Avoid embarrassing client launch failures | Medium | Needs interviews. |
| Use one provider across multiple chains/projects | Medium-high | Multi-chain positioning common across providers. |
Voice-of-customer quote bank
RPC limits / reliability
| Quote | Source | Segment signal | Confidence |
|---|---|---|---|
| “Using web3.js with any of public RPC Nodes I often get `Error: Returned error: limit exceeded` on `getPastEvents`.” | Ethereum StackExchange: source | Developer hitting public RPC limits | High |
| “I am working with the Solana RPC API… yet I'm encountering a `429 Too Many Requests` error.” | Solana StackExchange: source | Solana developer / data fetcher | High |
| “When my Alchemy project exceeds its monthly capacity limit, the RPC returns a 429 error immediately, but ethers keeps retrying for about 3–4 minutes before throwing.” | ethers.js GitHub #5071: source | Production developer; provider capacity limit pain | High |
| “JsonRpcProvider failed to detect network and cannot start up; retry in 1s (perhaps the URL is wrong or the node is not started) — this message is misleading because the URL is valid.” | ethers.js GitHub #5071: source | Reliability/debugging pain | High |
| “When hit…” [rate limiting/internal errors] “do not trigger the retry mechanism, even though HTTP-level errors do.” | viem GitHub #3680: source | App developer needing resilient RPC retries | High |
Provider lag / correctness
| Quote | Source | Segment signal | Confidence |
|---|---|---|---|
| “I notice that my alchemy endpoint lags behind mainnet-beta in several situations.” | Solana StackExchange: source | Wallet/app developer comparing providers | High |
| “Sometimes it doesn't get a websocket account update, but the worst obvious case is after doing a swap SOL/USDC: my sol balance has changed and the mainnet-beta endpoint captures that, but not the alchemy endpoint.” | Solana StackExchange: source | Wallet/trading UX correctness pain | High |
| “WebSocketProvider: a rejected `eth_subscribe` is an uncatchable unhandled rejection… takes down the process.” | ethers.js GitHub #5178: source | Backend reliability / subscription pain | Medium-high |
Archive node / self-hosted node pain
| Quote | Source | Segment signal | Confidence |
|---|---|---|---|
| “Is it possible to upgrade a fully synced node to archive node? … or I will have to start from scratch?” | Ethereum StackExchange: source | Developer facing archive-node operational complexity | High |
| “Syncing a full history archive node… from scratch took us close to half a year… Took us around 1-2 months on a dedicated Xeon server with striped Samsung enterprise NVMe drives…” | Hacker News: source | Infra-heavy buyer / self-hosting pain | High |
| “I'm currently working on setting up my own RPC node for the Solana blockchain… I encountered a problem where the process got killed after running for some time.” | Solana StackExchange: source | Developer trying and failing to self-host | High |
Category confusion / onboarding
| Quote | Source | Segment signal | Confidence |
|---|---|---|---|
| “I deployed a contract via (?) alchemy, then deleted the alchemy app. The contract still works… for which part of the deployment is alchemy actually necessary?” | Ethereum StackExchange: source | Web2/new Web3 developer confusion | Medium-high |
| “Do I really need it? Frankly, most of the things are going above my head. Can somebody explain it to me in simple terms?” | Ethereum StackExchange: source | New Web3 buyer needing simple infra explanation | Medium-high |
Infra role / production ops language
| Quote | Source | Segment signal | Confidence |
|---|---|---|---|
| “RPC infrastructure, benchmarking, monitoring, incident handling” | Hacker News hiring post: source | Web3 infra/SRE role language | Medium |
| “node and RPC operations, observability, CI/CD, data pipelines, performance tuning, and infrastructure cost reduction” | Hacker News hiring post: source | Buyer vocabulary for infra teams | Medium |
| “No trusted intermediaries, no API keys, no ‘please don't rate limit me’ prayers at 2am.” | Hacker News hiring post: source | Strong pain language around centralized indexers/API limits | Medium |
Top themes ranked by frequency × intensity
| Rank | Theme | Confidence | Summary |
|---|---|---|---|
| 1 | Rate limits and 429s break workflows | High | Developers frequently hit public/free/provider capacity limits; exact terms: “429”, “limit exceeded”, “rate limited”. |
| 2 | Provider lag/correctness matters for wallets/trading | High | Users compare providers when balances, websocket updates, or transaction state differ. |
| 3 | Self-hosted/archive nodes are operationally painful | High | Archive/full nodes require specialized hardware, time, tuning, and chain-specific expertise. |
| 4 | RPC errors are hard to debug inside app frameworks | Medium-high | Errors surface through ethers/viem/wagmi with misleading or delayed failures. |
| 5 | Buyers want multi-chain coverage but not multi-chain ops burden | Medium | Strong provider-positioning signal; needs more customer quotes. |
| 6 | New Web3 teams are confused about why RPC providers matter | Medium | StackExchange shows basic category education gaps. |
| 7 | SLA/support matters when production is affected | Medium | Implied by production incidents; direct support complaints need more mining. |
Alternatives and competitor map
| Alternative | What buyers use it for | What they like | What frustrates them / GetBlock opening |
|---|---|---|---|
| Public/free RPC | Early dev, prototypes, low-volume apps | Free, fast to start | Rate limits, instability, no SLA, no support, poor production trust. |
| Self-hosted nodes | Control, sovereignty, compliance, high-volume infra | Independence, no vendor lock-in | Expensive, hard to maintain, archive sync painful, chain-specific ops burden. |
| Alchemy | Mainstream dev platform, RPC/data APIs | Brand, docs, tooling, multi-chain | Rate/capacity limits, potential lag/correctness issues, cost at scale. |
| Infura / MetaMask Developer | Ethereum/IPFS access, default provider mental model | Familiar, established | Centralization concerns, Ethereum-heavy perception, rate limits/free-tier limits. |
| QuickNode | Performance-focused RPC + streams + indexed data | “Fastest RPC”, broad stack | Pricing sensitivity, enterprise upsell pressure; GetBlock needs price/support/dedicated-node angle. |
| Chainstack | Managed nodes, enterprise infra | “Build/run/scale” infra message, managed nodes | Similar positioning; GetBlock must differentiate by chain coverage, support, pricing, or dedicated nodes. |
| Ankr | Free/public RPC endpoints, broad chain access | Easy free access | Less premium/support-led; users may outgrow free endpoints. |
| Moralis | Web3 APIs + app backend abstractions | Higher-level APIs | Less pure infra; may not fit teams needing dedicated RPC/node control. |
| The Graph / SubQuery / Subsquid | Indexed blockchain data | Query abstraction | Indexing delay, coverage gaps, custom subgraph/indexer maintenance. |
| BigQuery/Snowflake datasets | Analytics/historical data | SQL/data-team friendly | Not for low-latency production RPC/write flows. |
| Blockdaemon | Institutional node infrastructure | Enterprise-grade, staking/custody-adjacent | May be overkill/expensive for mid-market teams. |
| dRPC / NOWNodes / Blast/Bware | RPC alternatives | Coverage/pricing alternatives | GetBlock must prove why its reliability/support/coverage is better. |
Buyer segmentation: who buys vs who champions
| Role | Likely buying role | Pain they care about | Message angle |
|---|---|---|---|
| CTO / VP Engineering | Economic buyer / approver | Risk, uptime, build-vs-buy, team focus | “Don’t turn your product team into a node-ops team.” |
| Head of Infra / DevOps / SRE | Champion / evaluator | Monitoring, latency, failover, incident handling | “Predictable RPC infrastructure with dedicated endpoints and support.” |
| Web3 backend engineer | Strong champion | API limits, timeouts, websockets, SDK errors | “Stop debugging public RPC weirdness in production.” |
| Blockchain protocol engineer | Technical evaluator | Node correctness, archive, client behavior | “Reliable chain access without client maintenance overhead.” |
| Product lead for wallet/exchange/dApp | Influencer | User-visible failures, launch readiness | “Protect transaction UX from infra failures.” |
| Founder / technical founder | Buyer in startups | Shipping speed, cost, reliability | “Launch multi-chain without hiring infra.” |
| Data / analytics lead | Champion for data products | Historical data, freshness, completeness | “Archive and data access without archive-node burden.” |
| Quant/trading infra lead | Buyer/champion | Latency, correctness, websocket reliability | “Low-latency dedicated RPC for trading-critical flows.” |
| Web2 fintech entering Web3 | Buyer with product/engineering | Simplicity, risk, support | “Web3 infrastructure your Web2 team can operate.” |
| AI/Web3 agent builder | Emerging champion | On-chain reads/writes, monitoring, rate limits | “Reliable blockchain IO for autonomous agents.” |
Messaging implications
Best homepage positioning
Hero option 1: Reliable RPC infrastructure for production Web3 apps.
Subhead: GetBlock gives wallets, exchanges, trading platforms, and Web3 teams instant access to shared and dedicated blockchain nodes — without public RPC limits or self-hosted node maintenance.
Hero option 2: Stop losing users to RPC limits, lag, and node maintenance.
Subhead: Multi-chain RPC endpoints, dedicated nodes, and infrastructure support for teams whose product depends on blockchain access working every time.
Hero option 3: Blockchain RPC your product team can trust in production.
Subhead: Launch and scale wallets, dApps, exchanges, analytics tools, and Web3 payment flows without becoming a node-ops company.
Segment-specific landing angles
Wallets / exchanges / trading apps headline: RPC reliability for transaction-critical Web3 products.
Pain bullets: Balance updates lagging behind chain reality; websocket subscription failures; rate limits during traffic spikes; transaction history or deposit flows breaking; need for dedicated endpoints and priority support.
Proof needed: uptime/status history; latency benchmarks by region/chain; failover story; dedicated node SLA; customer logos/case studies.
Web2 → Web3 teams headline: Add blockchain access without building a node infrastructure team.
Pain bullets: Web2 engineers do not want to maintain Geth/Erigon/Solana nodes; archive data is confusing and expensive; multi-chain roadmap creates infra sprawl; production launch needs support/SLA.
Proof needed: onboarding guide “from REST/Web2 infra to RPC”; architecture diagrams; simple pricing; customer success/support promise.
Analytics / data platforms headline: Historical blockchain data without archive-node pain.
Pain bullets: archive sync takes too long; node storage/IO cost; indexing freshness; multi-chain historical access; data completeness.
Proof needed: archive coverage by chain; query examples; data freshness metrics; comparison vs self-hosting.
Agencies / dev shops headline: One RPC provider for every client chain.
Pain bullets: each client uses a different chain/provider; launch firefighting damages agency reputation; need predictable endpoint setup; support matters when client demo breaks.
Proof needed: partner plan; multi-project dashboard; white-label or client workspace story; predictable pricing.
AI/Web3 agents headline: Reliable blockchain IO for AI agents and autonomous workflows.
Pain bullets: agents hit rate limits; agents need stable read/write endpoints; on-chain monitoring needs uptime; workflows need logs and predictable API behavior.
Proof needed: example agent workflows; API docs; monitoring/webhook integrations; rate-limit guarantees.
Outbound hooks by segment
CTO / VP Engineering
Subject: RPC infra before it becomes your team’s bottleneck
Noticed [Company] depends on [chain/product flow]. Teams usually hit the same wall when public RPC or self-hosted nodes stop being “good enough”: rate limits, lag, archive-node maintenance, and unclear ownership during incidents.
GetBlock gives production teams shared/dedicated multi-chain RPC endpoints without turning product engineers into node operators.
Worth comparing against your current [Infura/Alchemy/self-hosted/public RPC] setup?
Head of Infra / SRE
Subject: Reducing RPC incident surface for [Company]
For Web3 teams, RPC failures often show up as app bugs: delayed balances, websocket issues, 429s, transaction-history gaps, or misleading SDK errors.
GetBlock provides managed shared and dedicated blockchain nodes across multiple chains, so infra teams can move RPC reliability into a supported layer instead of debugging every provider edge case themselves.
Open to a 15-minute infra fit check?
Web2 → Web3 product/engineering
Subject: Web3 infra your Web2 team doesn’t have to operate
If [Company] is adding wallet, payment, token, or on-chain features, the hidden work is usually not the UI — it’s reliable blockchain access.
GetBlock gives your team RPC/API access and dedicated node options without hiring chain-specific node operators before launch.
Happy to map the lowest-risk setup for your first production chain.
Trading / quant infra
Subject: Dedicated RPC for latency-sensitive chain reads
Trading and monitoring products usually outgrow public RPC fast: rate limits, provider lag, websocket reliability, and inconsistent fallback behavior become real P&L/product risk.
GetBlock can provide dedicated RPC/node access for production-grade chain connectivity.
Worth benchmarking against your current provider?
Sales discovery questions
1. Which chains are currently production-critical for you?
2. What do you use today for RPC/API access?
3. Have you hit rate limits, 429s, websocket drops, or provider lag?
4. What happens in your product when RPC is slow or wrong?
5. Which flows are most sensitive: balances, deposits, swaps, transaction history, trading, monitoring, analytics?
6. Are you using public/free RPC, paid shared endpoints, dedicated nodes, or self-hosted nodes?
7. Have you tried running your own nodes? What was harder than expected?
8. Do you need archive/historical access? For which chains and methods?
9. Do you need SLA, dedicated support, private endpoints, compliance/security review?
- What would cause you to switch providers in the next 30 days?
- What would make GetBlock obviously safer than your current setup?
- Who signs off on infra spend: engineering, product, finance, founder?
Objections to prepare for
| Objection | Likely segment | Response direction |
|---|---|---|
| “We already use Alchemy/Infura/QuickNode.” | Most production teams | Don’t attack directly. Ask where they still see limits: dedicated chains, support, pricing, archive, redundancy. |
| “Public RPC is fine for now.” | Early teams | Agree; position GetBlock as migration path when traffic/user trust matters. |
| “We can run our own nodes.” | Infra-heavy teams | Compare total cost: hardware, sync time, monitoring, client upgrades, archive, incident handling, multi-chain ops. |
| “RPC is a commodity.” | CTO/procurement | Reframe around reliability, latency, support, chain coverage, dedicated endpoints, incident cost. |
| “We need data/indexing, not just RPC.” | Analytics/data | Offer RPC + archive/data angle; be honest where indexer product is required. |
| “We need enterprise SLA/security.” | Enterprise/Web2 | Need proof: SLA docs, security posture, support process, status transparency. |
| “Switching provider is risky.” | Production teams | Offer benchmark/fallback setup first, not rip-and-replace. |
Recommended proof assets
| Asset | Purpose |
|---|---|
| Public RPC vs paid RPC migration guide | Capture teams hitting rate limits. |
| Self-hosted node TCO calculator | Convert “we can run our own nodes” into cost discussion. |
| Archive node explainer | Target analytics/indexing customers. |
| RPC reliability checklist for wallets/exchanges | ABM lead magnet for production apps. |
| Alchemy/Infura/QuickNode comparison pages | Capture alternative-search traffic. Must be factual, not attack ads. |
| Latency/uptime benchmark page by chain/region | Needed to make reliability claims credible. |
| Incident-response/support promise page | Differentiates from commodity RPC. |
| Web2-to-Web3 infra architecture guide | For fintech/product teams entering crypto. |
| Dedicated node use-case pages | For trading, exchanges, custodians, high-volume dApps. |
Research gaps
Highest-priority first-party data:
- GetBlock win/loss against Alchemy, Infura, QuickNode, Chainstack.
- Churn reasons.
- Support ticket themes.
- Chains most tied to paid conversion.
- Dedicated node vs shared RPC conversion triggers.
- Deal size by segment.
- Current customers by use case.
- Enterprise blockers.
- Pricing sensitivity / overage complaints.
Public-signal gaps:
- Reddit direct quotes.
- G2/Capterra competitor reviews.
- X/Twitter outage complaints.
- Discord developer communities.
- Customer logos / case studies.
Two-week validation plan
Week 1 — mine internal + public signal:
- Day 1–2: collect 20–30 sales call notes/transcripts, 20 lost deals, 20 churned accounts, 50 support tickets, top 50 customers by revenue, top 50 by RPC volume, dedicated-node customers, archive/API-heavy customers.
- Day 3–4: mine competitor/community signal around Alchemy alternatives, Infura alternatives, QuickNode pricing/alternatives, StackExchange RPC questions, GitHub ethers/viem/wagmi/Hardhat/Foundry issues, public RPC status incidents, Web3 infra job posts.
- Day 5: synthesize ICP ranking, VOC quote bank, 3 landing-page message tests, 3 outbound tests, interview recruitment list.
Week 2 — primary research:
- Existing high-value GetBlock customers: 4
- Churned/lost customers: 3
- Prospects using Alchemy/Infura/QuickNode: 4
- Web2 → Web3 teams: 3
- Agencies/dev shops: 3
- Analytics/indexing teams: 3
Minimum: 10 interviews. Better: 20.
Outreach copy:
Subject: quick question about your Web3 infra setup
Hi [Name] — I’m researching how teams choose RPC/node infrastructure once Web3 apps move beyond prototype stage.
Not selling on this call. I’m trying to understand what actually breaks: public RPC limits, provider reliability, archive data, self-hosted nodes, support, pricing, or something else.
Would you be open to a 25-minute call? Happy to send a $50 thank-you or donate it to an open-source project you choose.
Interview script:
1. What product are you building, and which chains are production-critical?
2. What do you use today for RPC/node/API access?
3. How did you choose that provider?
4. What was the moment you realized public/free RPC was not enough?
5. Have you hit rate limits, timeouts, lag, websocket drops, or wrong/stale data?
6. What happens to your users or team when RPC fails?
7. Have you tried self-hosting nodes? What was harder than expected?
8. What alternatives did you compare?
9. What would make you switch providers?
- What would make you not trust a provider?
- How do you evaluate reliability: uptime, latency, support, benchmarks, references?
- If you could wave a magic wand, what would blockchain infrastructure handle for you?
Final recommendation
Target first: Production Web3 app teams where RPC reliability maps directly to customer-visible failure.
Best verticals:
1. wallets
2. exchanges
3. trading platforms/bots
4. crypto payment/stablecoin products
5. high-volume dApps
6. analytics/compliance platforms needing archive/data
Secondary: Web2 → Web3 fintech/product teams.
They need education and trusted onboarding. The message should be less “developer RPC” and more: Launch blockchain features without building node infrastructure.
Deprioritize for now: Hobby developers / hackathon users / generic dApp builders with no production traffic.
They create volume but weak budget. Keep self-serve/free funnel, but don’t build core positioning around them.
Messaging to test first:
- Stop losing users to RPC limits, lag, and node maintenance.
- Don’t turn your product engineers into node operators.
- Blockchain RPC your wallet, exchange, or trading app can trust in production.
- Web3 infrastructure your Web2 team can operate.
Recommended next action this week:
1. Build a VOC spreadsheet from GetBlock’s real sales/support/churn data.
2. Interview 10 production users/prospects: 3 wallets/exchanges/trading, 3 Web2 → Web3 teams, 2 analytics/indexing teams, 2 agencies/dev shops.
3. Launch 3 message tests: public RPC limits, self-hosted node maintenance, production RPC reliability.
4. Create one ABM landing page: RPC infrastructure for wallets, exchanges, and trading apps.
5. Create one comparison page: Public RPC vs dedicated RPC: when production teams should switch.
Recommended next action
Use this page as the source for one ABM landing page, one public-RPC migration guide, and ten buyer interviews this week. Internal VOC from GetBlock sales/support should replace assumptions before scaling paid acquisition.