ICP’s HTTP Trust Dial: Faster Integrations, Weaker Consensus by Design

Internet Computer canisters can call public HTTPS services directly through the management canister, avoiding a separate oracle service for many API integrations. The current developer documentation makes the important design choice explicit: HTTPS outcalls have a replicated mode and a non-replicated mode.

In replicated mode, every replica in the subnet sends the request. Responses are normalized through a transform function, and the subnet reaches consensus on the result. This preserves the strongest integrity model, but it can multiply traffic to the external API. The documentation notes that a typical 13-node subnet may send 13 requests within milliseconds, which can trigger rate limits.

Non-replicated mode sets is_replicated = false. Only one randomly selected replica makes the request, removing duplicate submissions and reducing pressure on rate-limited APIs. That makes the mode useful for webhooks, carefully designed POST operations, and endpoints where the response is not itself used as a high-value consensus input.

The trade-off is fundamental, not cosmetic. Because only one replica makes the request, the returned response is not confirmed by subnet consensus; a faulty or malicious replica could theoretically alter it. The official announcement therefore frames non-replicated calls as experimental, and the current documentation recommends them only when developers can accept or independently verify that trust assumption.

The feature also changes ordinary integration advice. Replicated POST requests should use idempotency keys because each replica may submit the operation. Developers should set max_response_bytes tightly because cycle costs depend on the declared maximum, not just the bytes ultimately returned. API credentials stored in canister state are visible to replicas, so sensitive credentials require additional care.

The broader lesson is that ICP is exposing infrastructure policy to application developers. An outcall is no longer simply an HTTP request: it is a choice among consensus strength, API compatibility, cost, and trust. For price feeds or security-sensitive state transitions, replicated mode remains the safer default. For low-risk notifications and rate-limited services, non-replicated mode can remove a practical bottleneck—but only if the application is designed around its weaker guarantee.