The work a fee
does not measure.

A fee quotes a price. A transaction size measures bytes. Neither, by itself, tells a BSV service how much verification work a customer's workload will require or how reliably that work can be supplied.

The decentralisation series has examined independent implementations, signing boundaries, payment evidence and recovery after failure. The next question is what a supplier is actually promising when it offers capacity. An open protocol permits different businesses to make different offers. It does not make their resource costs identical.

Keep validity separate from the offer

The BSV Genesis specification distinguishes validity rules from local policies governing propagation and inclusion. Its transaction-evaluation-timeout discussion is particularly useful: reaching a local evaluation timeout need not establish that a transaction is invalid. It can mean that the implementation stopped before making that determination.

For a commercial service, those are different outcomes. A validity failure should come with the applicable reason. A resource refusal should describe the service condition that was not met. An unfinished evaluation should remain unfinished in the record. Calling all three “rejected” may be convenient for an internal counter, but it gives customers too little information to choose another supplier or repair a request.

Fixed base rules support that choice. A customer should be able to move between implementations without renegotiating the underlying meaning of a valid BSV transaction. Suppliers can still choose hardware, queues, prices and admission policies. Their freedom to make those choices brings responsibility for describing the service they actually offer.

Describe the workload behind the rate

Consider a hypothetical verifier processing requests of similar byte length. One class needs little computation and mostly accesses warm local data. Another requires more evaluation or encounters a less favourable data-access pattern. A throughput claim based on the first class cannot simply be applied to the second.

This is an engineering example, not a benchmark of BSV Node or a claim that any particular script has the assumed cost. Byte length remains important for transport and storage. It is simply insufficient to identify every resource a service uses. CPU work, memory pressure, data availability and dependency checks can change the cost of completing the request.

The inspected BSV Node v1.2.3 configuration interface exposes distinct script-policy and validation-duration settings. That is evidence that an implementation has multiple operating controls. It is not evidence of a measured capacity, nor a prescription that an independent implementation must organise its work in the same way.

A useful comparison would identify the request classes, their proportions, input sizes, relevant dependencies, software versions and cache conditions. It would retain the complete submitted workload, including work refused or not completed. Otherwise a service can improve its displayed rate merely by accepting a narrower product while leaving the change invisible.

Put the arithmetic beside the assumptions

Suppose, only for illustration, that a single worker spends one millisecond on a light request and 100 milliseconds on a heavy request. If one request in a hundred is heavy, mean service time is 0.99 × 1 + 0.01 × 100 = 1.99 milliseconds. The corresponding idealised long-run processing ceiling is approximately 503 requests per second, rather than the 1,000 obtained from an all-light workload.

This calculation assumes one sequential, work-conserving worker, a stable workload mixture and no other overhead or bottleneck. It is not a response-time guarantee. It does not model concurrency, queue discipline, network delay, storage contention or variability within a request class. A real service must measure those effects rather than borrowing the example's numbers.

The example exposes why an apparently small change in workload composition matters. Pricing each byte identically may still be a sensible commercial decision. The provider must then account for the variation elsewhere: through its price, reserved capacity, a declared admission rule or a consciously accepted exposure. The price does not repeal the work.

Make admission create a clear obligation

A service should distinguish a quote, receipt of a request, acceptance of an obligation and completion. If it accepts work before estimating the relevant cost, it needs enough reserve or a clear rule for handling a mistaken estimate. An internal timeout after acceptance should not silently become the customer's responsibility.

Different suppliers may reasonably sell different products. One may offer a low-cost best-effort service with explicit refusal conditions. Another may reserve capacity for a defined workload. A third may specialise in a narrower class of transactions. Voluntary standards can help customers compare those offers without forcing every supplier into the same architecture.

I would standardise the evidence fields before attempting to standardise the machinery: what was submitted, what was accepted, the reason for a refusal, the measured interval and the actual completion state. Such a reporting convention earns adoption by reducing disputes and comparison costs. It should not acquire authority to change base transaction rules merely because an application finds it convenient.

Test costly work without mislabelling it

An expensive valid request is not necessarily malicious. A business may have a legitimate reason to use a demanding transaction. Conversely, an invalid request can consume resources before the defect is discovered. Protecting a public endpoint therefore requires attention to the work incurred before a final answer, as well as to the answer itself.

A proposed evaluation would vary the mixture and arrival pattern, include costly valid cases, include invalid cases discovered at different stages and measure what happens to ordinary customers. The tests should be controlled and authorised, not performed by flooding a public service. Report resource consumption, admission decisions, completion rates and latency distributions for each class.

A supplier may isolate workload classes or reserve resources to stop one class delaying another. That can improve predictability while leaving some capacity idle. Sharing resources may improve utilisation while increasing interference. These are engineering and commercial trade-offs to measure, not grounds for declaring one universal implementation.

Compete on a promise that survives comparison

Independent BSV implementations strengthen competition when a customer can reproduce the request and understand a different result. If two services disagree about validity, preserve the transaction and the relevant validation evidence. If they differ in willingness or ability to serve it, preserve that distinction too. A slower completion and a different validity judgment are not the same disagreement.

Scaling responsibility belongs with the supplier making the capacity claim. It should explain the workload, disclose the admission boundary and account for accepted work that did not finish. Customers can then compare price against the performance they actually need.

The practical decentralisation argument is therefore concrete: keep the foundational rules stable, leave room for competing implementations and make commercial promises inspectable. The freedom to build differently becomes more valuable when buyers can see which differences change the service.