Pay-per-block pricing costs less when call volume is spiky and low on average, and subscription pricing wins once volume is high and steady, because the tier fee amortises across every request. For a high-volume DeFi app the deciding factor usually isn't the headline rate: it's whether the tier's rate limit throttles you during a liquidation cascade, when call volume and revenue spike together.

Key Takeaways

• The crossover is arithmetic: divide the tier fee by your per-unit rate, then compare it against your p99 day.

• Most providers meter a weighted compute unit per method, not a flat request, so an eth_getLogs sweep costs multiples of an eth_blockNumber call.

• Rate limits cap cost and availability at once, and that trade decides more DeFi architectures than price.

• Flexprice isn't an RPC provider. It's the metering and billing layer if you're the one selling metered node access.

What's the difference between pay-per-block and subscription pricing?

Pay-per-block is consumption-based pricing for work performed; a subscription charges for capacity reserved. The first moves with demand, the second stays fixed until you cross the ceiling.

The structural difference:

• Pay-per-request bills each unit, so cost rises linearly with no ceiling.

• Subscription tiers bundle an allowance, then throttle or bill overage charges past it.

• Hybrid tiers, now the common shape, charge a base fee plus metered overage.

How do RPC and node providers price high-volume usage?

Most price a weighted unit rather than a raw request, because methods differ hugely in cost to serve. Check your provider's method weighting table first, since weights change more often than prices.

The levers to read off the page:

• The weight on each JSON-RPC method, especially log and trace queries.

• Whether archive-node access carries a separate multiplier.

• Whether websockets bill per message or per connection-hour.

• Your tier's requests-per-second ceiling, a cost control disguised as a limit.

How do you model cost for a high-volume DeFi application?

Model from a method-level call distribution, not a total request count. Pull a week of real traffic, group by method, apply your provider's weights, and you have a unit count you can price against either model.

1. Export one week of calls grouped by JSON-RPC method.

2. Multiply each method's count by its compute-unit weight and sum it.

3. Divide the subscription tier fee by your per-unit rate to find break-even volume.

4. Repeat the calculation using your p99 day rather than your average day.

If step four puts you over the tier ceiling, price the overage rate too. That's the number you'll actually pay in a volatile week.

How do the two models compare at high volume?

Row by row on what changes between them, from provider docs.

Read the cost behaviour block against your worst week. A model that's cheaper on your average day and unbounded on your worst day isn't cheaper.