WebSocket Terms of Service

Effective: 14 days after SolidRPC sends the material-change notice for this revision

Revision: terms-2026-09-15-v5

Last updated: September 15, 2026

These terms govern your use of SolidRPC, a blockchain RPC service operated by SolidRPC, Inc., a Delaware corporation, at solidrpc.io. By creating an account or sending a request to our endpoints, you agree to them.

Service

SolidRPC provides JSON-RPC endpoints for supported blockchain networks. We aim for high availability but do not guarantee 100% uptime. Eligible paid plans may include Covered Request Availability and automatic next-invoice service credits under the accepted Service Level Terms. Free, Builder, PAYG, manually granted free trials, evaluation access, and other service not expressly enrolled under the Service Level Terms have no monetary SLA.

Acceptable use

• Do not abuse, probe, or attempt to exploit our infrastructure.
• Do not relay traffic for unlawful activity.
• Do not share your API keys publicly.
• Do not create multiple Free accounts to evade plan or rate limits.

We may suspend or terminate accounts that violate this section without prior notice.

Billing

Paid plans are charged monthly via Stripe. Refunds are issued at our discretion for unused portions of a billing period. Service credits are awarded only under the Service Level Terms and are not cash refunds.

Pay as you go

Pay as you go ("PAYG") is an optional standalone billing mode and does not require a fixed plan. The default commercial configuration is $3.00 per 1,000,000 billable response units, 300 response units per second account-wide, burst capacity 1,500, five API keys, email support, and no monetary SLA. Your authenticated Billing page displays the price and limits that apply to your account. Account-specific terms may differ. Prices are in United States dollars, before applicable tax.

Before PAYG is enabled, you must review and accept the current PAYG Terms linked from authenticated Billing, provide a card through Stripe Checkout setup mode, and expressly authorize SolidRPC to save that payment method and charge it off session for PAYG usage. SolidRPC records the applicable Terms and PAYG revisions and hashes, your account's commercial configuration, and your off-session authorization with that acceptance. PAYG activates only after SolidRPC receives and validates Stripe's signed confirmation of a succeeded SetupIntent and saved card. You may later designate a replacement card through authenticated Billing under the PAYG authorization already recorded at enrollment. A replacement takes effect only after SolidRPC validates Stripe's signed confirmation. We charge only the designated PAYG payment method and do not substitute an arbitrary attached card.

One billable unit is one valid JSON-RPC method call that SolidRPC proxies, including each method call in a batch. Proxied HTTP 200–499 responses are billable even when they contain a node-returned JSON-RPC error. Invalid, blocked, malformed, quota-rejected, rate-limited, gateway 5xx, and upstream 5xx calls are not billable. A response that was proxied before the client disconnected remains billable.

Unless threshold collection is disabled for your account, PAYG charges are collected as follows:

• The first threshold is $5 of new unpaid usage. After that invoice is paid, the next threshold is $10, then $20, $40, $80, and $160 maximum.
• The next threshold persists across billing periods, disabling and later re-enabling PAYG. It advances only after a threshold invoice is paid. Processing delay can cause usage above a threshold. The excess remains part of the unpaid balance.
• Disabling threshold collection stops new mid-period threshold invoices but does not reset progression or waive usage.

PAYG periods follow the UTC anniversary of activation. At the natural end of a PAYG period, or when PAYG is disabled, closed after a payment failure, or switched to a paid plan, SolidRPC subtracts usage already reserved for threshold invoices and issues a final invoice for every positive remainder. A positive final invoice is at least $1, even if threshold invoices were already paid. No final invoice is issued when the remaining amount is zero. Re-enabling PAYG begins a new anniversary.

You may disable PAYG at any time. New traffic switches to your effective fallback immediately. Usage already incurred remains payable, and final settlement waits until in-flight requests finish and metering is reconciled. If you select a fixed plan, PAYG remains active while checkout is pending, abandoned, or unsuccessful. Only confirmation of a paid initial plan invoice activates the plan and closes PAYG. The final PAYG invoice remains separately payable, and fixed-plan overage starts disabled and must be enabled separately. Cancelling that plan later returns the account to Free. PAYG does not reactivate automatically.

Failure of any PAYG threshold or final collection immediately removes PAYG and restores the account's effective fallback. Stripe may continue retrying the invoice. PAYG and paid-plan overage remain blocked until every PAYG debt is paid or a separately confirmed administrator action expressly waives it. Marking an invoice uncollectible does not waive debt. Refunds and lost payment disputes can reopen debt. A won dispute restores the paid state. A paid fixed plan remains active despite PAYG debt, but its overage remains unavailable. Late payment restores eligibility only and never silently reactivates PAYG.

We may approve account-specific PAYG pricing, rate, burst, API-key, support, or threshold settings. A price change applies immediately to calls authorized after the audited administrator change. Calls authorized earlier retain the price captured when they were authorized. Other entitlement changes can also apply immediately. Increased PAYG throughput is discretionary and normally requires a support review of traffic and rate-limit evidence.

WebSocket

WebSocket is an optional transport for eligible paid plans and active PAYG accounts on networks identified as available in the dashboard and network API. Free, public and demo access do not include WebSocket. Supported subscription types are published per network. The initial service supports native newHeads subscriptions and ordinary stateless JSON-RPC calls.

Each native head notification successfully written to your WebSocket connection consumes one existing response unit at the price and entitlement captured when that delivery was authorized. A completed socket write is not an acknowledgment from your application. Ordinary JSON-RPC calls retain the documented billable-result rules. WebSocket calls, HTTPS calls and pushed heads share the same account allowance, rate and burst limits, overage settings and PAYG invoice bounds. There is no separate WebSocket subscription price.

Connection setup, subscription and unsubscription acknowledgments, ping and pong messages, internal retries and suppressed upstream duplicates are free. Each separately requested subscription creates a separately counted delivery, even when the service shares an upstream feed. The account limit is 100 connections and 100 subscriptions across service replicas, with no more than 10 subscriptions per connection. The service also bounds frame sizes, connection churn and outbound queues. Rate exhaustion, slow consumers, invalid or revoked credentials, expired JWTs and unavailable native sources can cause explicit connection closure.

Notifications are live-only and are not durably replayed. After disconnection, your application must reconnect, resubscribe and reconcile missed or reorganized blocks through SolidRPC. Upstream failover preserves the subscription ID while the customer connection remains open. If all native sources are unavailable, the service retries internally for up to 30 seconds and then closes affected connections. HTTP polling is not used to generate notifications.

All WebSocket traffic is excluded from monetary SLA evidence and service credits in the initial WebSocket release. This exclusion also applies to ordinary JSON-RPC calls transported over WebSocket. Existing accepted Service Level Terms and accrued credit records remain governed by their accepted revisions. This general-terms revision does not rewrite a historical consent or SLA period.

Overage billing

Paid plans include a monthly response-unit allowance. The Free plan includes a daily allowance. A response unit is one billable JSON-RPC method call, including each call inside a batch, or one native WebSocket head notification successfully written to a client connection. Gateway rejections and upstream transport failures are excluded as described in the documentation. By default, further RPC calls are rejected once that allowance is exhausted until the applicable quota resets. On eligible paid plans, you may opt in to overage billing from the dashboard, in which case:

• Response units beyond your plan allowance are billed at a per-unit rate equal to your monthly plan price divided by the response units included in your plan. For example, a $25 plan with 10M included response units is billed at $2.50 per additional 1M response units.
• Accumulated overage is invoiced separately at the start of your next billing cycle and charged to your payment method on file.
• Whenever your unbilled overage reaches one full plan allowance, we immediately issue an invoice equal to one monthly plan price and charge it right away. This repeats for each further full allowance consumed.
• If an overage charge fails, overage billing is disabled on your account and further RPC calls are rejected again until the open invoice is settled and you re-enable overage.
• You can enable or disable overage billing at any time. Disabling it does not waive charges for overage already consumed.

Service levels

Covered Request Availability is measured from eligible customer calls observed by the SolidRPC gateway. Requests that never reach that boundary cannot enter the measurement. The accepted Service Level Terms and current Service Level Terms define exclusions, maintenance, credit bands, and the evidence-claim window.

PAYG has no monetary SLA, service credits, or uptime commitment. Purchasing PAYG usage does not create coverage under the Service Level Terms.

JSON-RPC notifications without an id are excluded because they have no response or terminal result to measure. Selecting covered networks and confirming an eligible purchase, upgrade, or initial enrollment records acceptance of the displayed terms revision and SHA-256 hash. Coverage continues while the eligible paid plan and selected networks remain active.

To the maximum extent permitted by law, service credits awarded under the Service Level Terms are your sole and exclusive monetary remedy for a failure to meet Covered Request Availability. Scheduling cancellation or any downgrade immediately and irrevocably forfeits unapplied service credits, and reversing that scheduled change does not restore them.

Liability

SolidRPC is provided "as is" and "as available", without warranties of any kind, express or implied, including merchantability, fitness for a particular purpose, and non-infringement. We are not liable for losses caused by transactions you broadcast through our endpoints, including but not limited to MEV exposure, gas-price decisions, or chain reorganizations.

To the maximum extent permitted by law, our total liability for any claim arising from your use of the service is limited to the fees you paid us in the 12 months before the claim, and we are not liable for indirect, incidental, or consequential damages.

Governing law

These terms are governed by the laws of the State of Delaware, United States, and any disputes are subject to the exclusive jurisdiction of the courts located in Delaware.

Privacy

Our handling of personal data is described in our Privacy Policy.

Account deletion is unavailable while a PAYG period or PAYG debt is open. Settled financial, consent, and audit records may be retained after service access is deleted as described in the Privacy Policy and applicable financial-retention requirements.

Changes

We may update these terms. Material changes will be announced by email at least 14 days before they take effect. A Service Level Terms revision does not retroactively change an active or closed SLA period governed by an earlier accepted revision.

Contact

Questions may be sent to [email protected].