Key findings
- Measure completed user tasks, not only submitted transactions or theoretical throughput.
- Retries and failed execution belong in the cost and latency of a successful task.
- Keep the task, observation window and completion definition constant when comparing performance.
A fast chain can still produce a slow product
Users want a transfer, swap or registration completed. Connecting a wallet, understanding a signature, preparing balances, submitting and confirming the result can each dominate the experience. Effective localization explains recovery from failure, not just the happy path.
Solana documentation describes transactions containing multiple instructions, with state changes reverted if an instruction fails. A processed failed transaction can still incur fees. Batching reduces interactions while making the whole task depend on each component. [1]
Use the right unit for fees
The documentation distinguishes a base fee of 5,000 lamports per signature from an optional priority fee generally tied to the requested compute limit and price. These are specifications at access time, not measured historical user costs. [2]
Total cost per completed task includes failed attempts and waiting. Higher priority fees cannot fix insufficient balances or invalid inputs. Combine a spending ceiling with failure classification rather than assuming every problem is congestion.
| Observation | First investigation | Product response |
|---|---|---|
| Abandonment before signing | Permission explanation and mobile connection | Clarify purpose and return path |
| Submitted but unconfirmed | Status, expiry and network response | Check state without duplicate execution |
| Processed but failed | Inputs, balances and instruction error | Cause-specific guidance and safe retry |
| Chain success, unhappy user | Delivery and screen refresh | Reconcile business outcome with chain state |
CBK analysis. This is an analytical framework, not observed customer performance or a market benchmark.
Averages hide the slowest customer
If nine hypothetical tasks finish in one second and one takes 30 seconds, the mean is 3.9 seconds. The delayed user experiences 30, not 3.9. Report medians, tail delays, failures and recovery after retry using consistent start and end points.
Mobile app switching can add substantial perceived delay. A task may settle while the app is backgrounded or before the user returns from a wallet. Device-level return-path testing is therefore separate from a chain benchmark.
| Group | Tasks | Elapsed time |
|---|---|---|
| Normal completion | 9 | 1 second each |
| Delayed completion | 1 | 30 seconds |
| Overall mean | 10 | 3.9 seconds |
Illustrative arithmetic, not a Solana benchmark or measured service result.
More submissions can mean a worse experience
Suppose 100 people start tasks. Eighty succeed on their first attempt; the other 20 submit three times each, and only ten of them ultimately succeed. There are 140 submissions but 90 completed tasks. A 40% increase in submissions would describe retry burden, not new user demand.
Group submissions by a single intended task and define how duplicate success is prevented. This need not require linking every task to personal identity. Minimal state records can explain both performance and user experience.
| Hypothetical observation | Value | Interpretation |
|---|---|---|
| Tasks started | 100 | Desired user outcomes |
| Chain submissions | 140 | Includes retries |
| Tasks completed | 90 | 90% task completion |
| Unfinished tasks | 10 | Investigate by cause |
CBK analysis. This is an analytical framework, not observed customer performance or a market benchmark.
When a comparison becomes meaningful
Hold transaction type, wallet, connection path and network conditions consistent. A simple transfer and a multi-instruction workflow are not interchangeable. Business completion and finality may also require different end points.
Detailed instrumentation costs effort. An early product can begin with four timestamps: start, signature, submission and result confirmation. Translating a chain’s capabilities into value requires an explainable recovery path as well as speed.
Scope & limitations
Official documentation describes specifications at access time, not reconstructed 2025 performance. This design analysis makes no claim about measured TPS, outages or superiority over another chain.
CryptoBridge Korea analysis based on public materials. Source facts are distinguished from interpretation and hypothetical calculations. References to organizations or projects do not imply their sponsorship or review of this paper.
Sources & scope
- Solana documentation, Transactions ↗Official explanation of transaction structure and atomic execution.
- Solana documentation, Fees ↗Specification at access date, not a historical fee dataset.