A website, a database and application logic can share a blockchain home. Understanding the Internet Computer means following one request through that system—and separating its operating costs from the ICP investment story.

Imagine a neighborhood association building a shared maintenance log. Residents report broken lights, volunteers record repairs, and everyone can read the history. The useful question is not whether this application sounds revolutionary. It is what keeps the record available, who can change its rules, and whose balance falls when somebody presses “submit.”

The Internet Computer offers an unusual answer: a canister, its unit of software, combines executable code with persistent state rather than treating the blockchain solely as a place to settle transactions.[2] That makes it worth examining as an application platform before examining it as a token.[2]

Start with the application, not the coin

A canister is not a rented desktop or a machine you remotely administer. Its code runs as WebAssembly, a compiled execution format; users and other canisters interact with it through messages.[3] Think of a service with its own memory and a defined set of buttons, rather than an unrestricted server account.

Canisters can serve web content and maintain application data, so a project’s blockchain component need not stop at its token contract.[2] For our hypothetical maintenance log, the interface, list of reports and rules for accepting repairs could live in canisters. That is a design possibility, not evidence that an arbitrary app calling itself “onchain” has moved every dependency there.

The distinction has a research history. A 2023 technical paper describes stateful serverless computing and illustrates it with a small key-value service: one operation inserts a value, another retrieves it.[13] That modest example is more illuminating than a claim to replace the entire cloud. The important change is where application state lives and how its next state is agreed—not a promise of infinite processing power.[13]

One button, two very different paths

Opening the maintenance list and submitting a repair should not be treated as equivalent operations. The interface specification distinguishes replicated update calls from non-replicated query calls; a query does not preserve changes to application state.[3]

An update takes the consensus-backed route, allowing a change to become part of the shared record. A normal query takes a faster route through a single replica, without making that same agreement process happen for the request.[3] The practical tradeoff is stronger execution agreement versus a cheaper way to read.[3]

Current documentation says ordinary query calls have no cycles charge, while updates incur costs.[1] That does not mean every action that looks like reading in a browser is free: the application’s implementation determines which call it makes.[3] A developer can choose a replicated call when stronger guarantees matter.[2]

Nor does a fast response automatically prove that the displayed record matches agreed state. ICP’s response-certification mechanism lets a canister provide cryptographic evidence connecting returned data to certified state.[10] In plain English, the reader needs a checkable receipt, not just a server’s answer.[10]

For web responses, a verifying gateway checks that proof if the canister supplies certification; raw access bypasses that check, and application API calls need their own appropriate verification path.[10] For the maintenance log, an attractive page and a trustworthy repair history are therefore separate engineering requirements.[10]

Reverse gas moves the bill; it does not erase it

The project’s reverse-gas explanation makes the customer-facing proposition straightforward: developers fund execution so visitors need not acquire tokens merely to use an application.[4] A resident could submit a report without first learning how to buy blockchain gas.[4] The app can still charge subscriptions or impose access conditions; “no gas purchase required” is not a promise that every service is free.[6]

Underneath, a canister pays with cycles. Funding can come from its developer, another canister, a user or an automated service, and the protocol meters resources including execution, storage and messaging.[1] Reverse gas is therefore better understood as sponsored infrastructure than as costless infrastructure.[4]

ICP and cycles are different things. The protocol burns ICP to create cycles; the documented reference is one trillion cycles to one XDR, the IMF’s basket-based unit of account.[6] The conversion is not a promise that one ICP always buys the same amount of computing.[1]

The XDR relationship stabilizes the accounting unit, not every variable in an application’s budget. Resource prices and the amount consumed still matter, and the published cost tables distinguish execution, message handling, storage and subnet replication factors.[12] Do not turn an XDR peg into a permanent dollar-price guarantee or an all-inclusive quote.[12]

A builder’s budget starts with behavior

For the maintenance log, the first useful estimate is a workload sketch: how many reports arrive, how large they are, how long they remain, and what processing each submission triggers. Counting visitors alone would conceal the expensive parts.

The cycle-cost reference separates the update execution base charge from instructions executed, incoming-message charges and storage over time.[12] A rough budget should preserve those categories rather than multiply every click by one advertised transaction price.[12] A different subnet configuration can also change the resource bill.[12]

The operator then needs a funding policy. ICP’s cycles documentation describes a configurable freezing threshold and the responsibility to keep balances topped up.[1] For our example, someone should receive a low-balance alert before residents discover they cannot submit a repair. An application can have distributed execution and still depend on an inattentive person to replenish its operating budget.[1]

There is a second uncomfortable question: what happens if a stranger floods the form? The project’s security guidance explicitly identifies cycle-depletion attacks as a consequence builders must address under reverse gas.[11] Sponsoring every accepted request gives an attacker an opportunity to spend the sponsor’s resources.[11]

That guidance recommends monitoring, early authentication and rate limiting; it also warns that preliminary single-node message inspection is not a substitute for security-critical access checks.[11] For this hypothetical product, bounded report sizes and controlled submission frequency belong in the initial design, not a future cleanup. These are design considerations, not a claim that this example has been deployed or tested.

“Onchain AI” needs a more precise description

An AI feature might suggest a category for each maintenance report. Before discussing decentralization, ask which model produces that suggestion and where its inference runs.

The current ICP guide describes a shared LLM canister that accepts prompt and chat requests, lists Llama 3.1 8B, and distinguishes that route from calling an external AI provider through HTTPS.[5] That is a specific documented service—not evidence that any model can run inside any application canister.[5]

The same guide lists rollout limits of ten chat messages, a 10 KiB prompt and 1,000 output tokens, with no streaming; it describes inference as free during the initial rollout rather than publishing a permanent zero-cost commitment.[5] Those constraints would shape our classifier or assistant. They do not establish its accuracy on local maintenance reports, its production reliability or its eventual economics.

Separately, code executed within a regular canister faces instruction, memory and message-size limits. The resource reference lists a 40-billion-instruction update-call ceiling and a five-billion-instruction query-call ceiling.[9] These are execution constraints, not model-quality benchmarks or a measure of available GPU capacity.[9]

For a builder, the sensible comparison is concrete: a bounded network-hosted inference service, model code that actually fits the canister runtime, or an external provider with its own dependencies. The label “onchain AI” cannot answer the workload question for you.[5][9]

Distributed execution is not the same as distributed control

Even a faithfully executed application can faithfully execute bad rules. More importantly, today’s rules may not be tomorrow’s.

Controllers have authority over canister management, including code upgrades.[2] The trust guide consequently asks two separate questions: whether the running code matches its advertised behavior, and who can change that behavior later.[7] For our maintenance log, the association should know whether one developer can rewrite the submission policy or whether changes require a collective decision.

Published source code is only part of the evidence. Reproducible builds and a comparison with the deployed module hash help connect readable source to the code actually running.[7] They do not establish that the code is bug-free.[7] A governance label also needs examination: voting concentration and configuration matter, not simply the presence of a DAO.[7]

At the network layer, the Network Nervous System governs matters including protocol upgrades, subnet creation and membership, and authorization of node providers.[8] At the application layer, the Service Nervous System offers a governance framework for an app’s canisters.[8] Those are distinct control surfaces.[8] Handing an app to community governance does not remove the underlying network’s governance dependencies.[8]

That is the useful trust map: inspect application authority, the evidence behind responses, and the network rules beneath both. None should be replaced by a blanket claim that blockchain hosting makes an application secure.

Usage is not automatically token-holder income

The operating-cost story does connect to ICP: conversion into cycles burns tokens. But node providers are compensated through newly minted ICP, not by receiving each app’s consumed cycles as a direct fee transfer.[6] Governance rewards introduce another issuance mechanism, with maturity becoming newly minted ICP when converted.[6]

This is why burn alone cannot establish net deflation, and application activity cannot establish a return for passive token holders. That conclusion follows from having both issuance and burn mechanisms, not from a forecast about price.[6]

A serious demand assessment would separate externally funded resource consumption from subsidized experimentation, then examine repeat use and who ultimately pays. A serious supply assessment would compare burns and issuance over the same dated interval. Neither can be replaced by a cumulative canister count, a promotional ecosystem list or one large number labeled “transactions.”

For the builder, the decision is narrower and more useful. Does this execution model make the application’s record and upgrade process easier for its users to verify? Can its workload fit the documented limits? Can its sponsor sustain the bill and resist abuse?[7][9][11]

The Internet Computer’s distinctive proposition is not that servers, costs or trust disappear. It is that application code and state can run inside a blockchain-managed environment, with an explicit funding mechanism and inspectable control choices.[2][8] The strongest evaluation starts there: follow the request, find the payer, and check who is allowed to change the program.

Sources