The introduction of bounded-wait calls to the Internet Computer (ICP) marks a significant shift for developers and dapp creators. With the official launch of this feature, users can now experience a new way of calling across the network that provides tighter control over how their messages are processed, along with clear time limits. This development represents a major leap in making the Internet Computer even more reliable and user-friendly for developers, especially those working with complex applications that require higher levels of stability.
Bounded-wait calls, initially launched as “best-effort” calls, are now generally available and have seen steady implementation across various dapps on the ICP. The first to make the switch were OpenChat, who migrated most of their traffic to this new call format. From there, other decentralized applications (dapps) within application subnets followed suit. Recently, system subnets also received support for bounded-wait calls, expanding the feature’s reach across the entire network.
The release of bounded-wait calls has been an intensive, cross-team effort. The ICP’s Message Routing, SDK, Motoko, and Execution teams have worked in close collaboration with external dapp developers to make this feature a reality. This includes input from projects like Cross Chain, Financial Integration, and OpenChat, all of whom have contributed valuable feedback to ensure the feature functions smoothly in various environments.
But what does this new functionality mean for developers and users alike? First and foremost, bounded-wait calls provide a way to handle message processing within a set time frame. Previously, dapps using unbounded-wait calls had no such constraint, meaning that calls could linger indefinitely, leading to potential issues with reliability. Now, with bounded-wait calls, developers have the ability to set a timeout period—meaning that if a call is not completed within the specified time, it will fail rather than hang indefinitely.
This may sound like a small change, but it has massive implications for how developers build and manage applications on the ICP. By introducing a time-limited call process, the ICP offers developers more control over system performance. It ensures that resources are used efficiently and prevents situations where calls could potentially get stuck in the system, causing delays and frustrating the end-user experience.
The technical execution of bounded-wait calls has been designed to be relatively simple for developers to implement. For developers using Motoko, the language on which many ICP applications are built, implementing a bounded-wait call is straightforward. By simply including a timeout parameter, developers can specify exactly how long the system should wait before a call is automatically cancelled. Similarly, those coding in Rust can achieve the same functionality using the ic_cdk framework. It’s clear that these changes are geared towards making ICP a more versatile and developer-friendly platform.
As is often the case with new features, there are a few areas still being refined. One key issue being worked on is ensuring the reliable transfer of cycles during bounded-wait calls. Cycles, the computational resources needed to execute canister calls, could potentially be lost if the message carrying them times out or is affected by system load. While this is generally a manageable issue for smaller cycle amounts, it can be problematic for larger transactions, such as those involved in funding canisters with significant cycles. The solution to this issue is a priority, and the team is actively working on a method to ensure reliable cycle transfers during bounded-wait calls.
Another challenge on the horizon is ensuring compatibility with legacy, non-idempotent APIs. To understand this, it’s important to know that bounded-wait calls require the use of idempotent APIs. An idempotent API is one that can safely be called multiple times without creating unintended side effects, even if the outcome of the call is unknown. This is crucial for calls that may timeout or fail for any reason. If a system can’t guarantee the idempotency of its APIs, developers face the risk of inconsistent states or unexpected results. The ICP team is working on ensuring that developers can still interact with legacy APIs that don’t provide idempotency, using safe methods for retrying calls and ensuring compatibility.
The community has also been engaged in conversations around improving the overall experience with idempotent APIs. To help ease the process, a client library is being developed that can automate retry strategies for invoking both idempotent and non-idempotent APIs using bounded-wait calls. This will make it easier for developers to ensure their applications run smoothly, even when dealing with complex legacy systems. As the library nears open-source release, it promises to be a valuable resource for the ICP developer community.
Looking ahead, the next step for the ICP network will be expanding support for bounded-wait calls beyond just canister-to-canister communications. Although this feature is already in place for calls within canisters, developers have long speculated on the possibility of extending it to boundary nodes as well. Boundary nodes, which handle ingress messages, could benefit from a similar system of timeouts. However, due to the nature of ingress messages, it’s uncertain whether they will be able to incorporate bounded-wait calls. In any case, this remains an area of active exploration, with potential updates expected in the coming months.
All of this comes as part of the ongoing efforts to make the Internet Computer a more robust and developer-friendly platform. With the introduction of bounded-wait calls, ICP has addressed a key gap in its messaging system, giving developers the tools to better manage their applications. While there are still some rough edges to smooth out, the general availability of bounded-wait calls represents a big leap forward for the network, providing the much-needed stability and reliability that dapp developers have been asking for.
The new feature will also have broader implications for users interacting with applications built on the ICP. As developers implement bounded-wait calls across their services, users can expect a more consistent experience. With tighter control over call timeouts and fewer instances of calls hanging indefinitely, it’s likely that ICP-powered apps will become smoother, more responsive, and more user-friendly. This is important for building trust in the network and encouraging further adoption among dapp developers.
ICP’s move towards providing developers with greater control over their applications has significant potential. The general availability of bounded-wait calls represents a forward-thinking approach to solving some of the most pressing issues facing decentralised platforms today. By addressing concerns around reliability, efficiency, and compatibility, ICP continues to push the boundaries of what’s possible on the blockchain.
As the Internet Computer evolves and these new features are fine-tuned, it’s clear that the platform’s future is looking brighter than ever. Developers can expect more powerful tools to create high-quality applications, while users will benefit from improved performance and reliability. With these changes, ICP remains at the forefront of the decentralised web movement, constantly evolving to meet the needs of the community.
