Most service-level agreements (SLAs) for Web3 infrastructure are vanity metrics dressed up as legal protection. They promise 99.9% uptime while hiding the one metric that actually matters to your users: how long does it take to sign a transaction? If you are integrating an MPC wallet or an account abstraction stack, a generic uptime guarantee is useless without specific performance bounds on the critical path.
In MPC custody architectures, security is distributed across multiple parties. This introduces a fundamental trade-off. While you eliminate single points of failure, you add network round-trips for every signature. A useful SLA must disclose the maximum expected latency for Distributed Key Generation (DKG) and threshold signing under load. If the provider cannot give you a p95 latency figure for signing during peak market volatility, they are selling you a black box.
For teams moving toward smart contract wallets, the bottleneck often shifts to the bundler.
As noted in OpenZeppelin’s account abstraction docs, bundlers simulate UserOperations before submitting them to the chain. An SLA here must cover more than just API availability. It needs to define the maximum time-to-inclusion for a validated operation. If the bundler is congested or simulating too conservatively, your user’s swap fails silently or takes minutes. That is not an uptime issue; it is a usability collapse.
Here is the experiment I want you to run next week. Take your current vendor’s SLA and highlight every mention of “availability.” Now, look for the words “latency,” “throughput,” or “signing time.” If those are missing, you are flying blind. Request a benchmark report showing signing times for 1-of-1, 2-of-3, and 3-of-5 configurations. Compare that against your user’s patience threshold.
The failure condition is simple: your marketing team promises instant swaps, but your custody layer takes twelve seconds to aggregate signatures because it is refreshing key shares. The result is a churn spike that no amount of PR can fix. We see this constantly when teams prioritize security theater over operational reality.
Security is not just about preventing hacks; it is about maintaining trust through consistent performance. If your provider treats latency as an afterthought, treat them as a risk. Demand the numbers. Run the test. If they hesitate, they are likely hiding proprietary inefficiencies or inadequate infrastructure scaling.
Turning abstract SLA debates into measurable latency tests.
Turning abstract SLA debates into measurable latency tests.
What is the maximum signing latency your users will tolerate before they abandon the flow? Have you measured your current provider’s p95 signing time during a high-volume event? What budget do you have for redundancy if the primary bundler or signer goes dark? And what specific result in a latency test would make you switch providers tomorrow?