We have re-deployed sub_utility, our hosted ICRC-79 subscription utility for the Internet Computer.
The goal is simple: make recurring payments easier for teams building real utility services on ICP, without forcing every project to build its own approval flow, subscription UX, payment history, operator tooling, and audit surface from scratch.
This re-release includes a refreshed frontend, updated supported-token metadata, better subscription and payment visibility, deep-link tooling for service developers, and token-aware revenue and transaction views.
Mainnet endpoints:
-
Subscription utility canister on the fiduciary subnet:
hl3xq-uiaaa-aaaar-qbxqa-cai
If you are building a SaaS-style canister, data product, content product, developer tool, API service, or any other recurring on-chain service, this utility is meant to be a practical starting point.
Who controls the service
Right now the service is operated by ICDevs.org.
The intention is not to keep it as a permanently organization-controlled utility. The plan is to contribute governance of the service to the emerging ICRC-137 veto-based governance model once that path is ready for production use.
For anyone interested in that direction, the governance discussion is here:
What sub_utility is
sub_utility is a shared subscription service built around the ICRC-79 pattern for recurring payments.
At a high level:
-
A user grants token allowance through ICRC-2.
-
The user creates a subscription against a service canister.
-
The utility executes recurring payments on schedule.
-
The subscriber and service can both inspect the resulting records.
-
The transaction history remains auditable through ICRC-3 logs.
The current production deployment is backed by the icrc79.mo implementation and uses a supported-token registry refreshed from live mainnet metadata.
What is available on the frontend
The frontend is meant to be useful to both subscribers and service operators.
It currently includes:
-
a public dashboard with supported tokens, recent ICRC-3 blocks, and a token-aware revenue leaderboard
-
a hosted subscribe flow where users can choose a supported token, enter the service canister, set amount and interval, and optionally provide product IDs, target accounts, broker fields, end dates, and memos
-
user views for subscriptions and payments, with token symbols shown alongside copyable principals
-
a service admin area with service subscriptions, service payments, revenue views, DFX command generation, and a service deep-link builder
-
a service notifications view for operators who need to inspect subscription and payment events
-
a transaction explorer and an About page that explains the flow and includes an interactive deep-link builder
-
authentication through Internet Identity at
https://id.aiand Plug wallet integration
One important frontend change in this re-release is that revenue is now shown separated by token, so the leaderboard does not mix unrelated assets into a single misleading total.
Why the deep-link builder matters
One of the most useful parts of this re-release is the deep-link flow.
A service can send users to a pre-filled subscription link with the important parameters already set. That means you can keep your own product pages, pricing pages, or service UI and hand off the actual subscription authorization flow to the utility frontend.
That reduces implementation effort for teams that want recurring payments but do not want to build a full approval-plus-subscribe UX themselves.
The key thing to understand is this:
-
the
serviceparameter should be your service canister principal -
it should not be the end-user principal
In other words, the service principal represents the canister that owns the product relationship and that will make or verify service-side ICRC-79 calls.
How to best use the system from your canisters
The most effective way to integrate with sub_utility is to treat your service canister as the canonical service identity.
Recommended model
-
Your service canister defines the products, intervals, and pricing it wants to offer.
-
Your frontend or website generates a deep link into
sub_utilitywith the user-facing subscription parameters prefilled. -
The user grants token approval and submits the subscription.
-
Your service canister uses the service-side query and confirmation methods to track and validate subscriptions.
-
Your accounting, entitlement, and support flows key off the resulting subscription IDs and payment records.
Best practices for service teams
Use your service canister principal as the service identifier
The serviceCanister should be the canister that actually represents your application or backend service on-chain. That keeps ownership, reporting, reconciliation, and downstream automation coherent.
Use productId for plan mapping
If you offer multiple tiers or products, assign stable productId values and use those as your internal mapping layer. That gives you a deterministic way to connect a subscription record to a specific product or entitlement.
Use targetAccount when settlement should go somewhere specific
If your revenue should settle to a treasury account or a non-default account, supply targetAccount. If omitted, the default service account path is used.
Use memo for correlation
If you need to connect subscriptions or payments to your internal order system, customer record, invoice reference, or provisioning pipeline, use memo consistently.
Use canister-side confirmation when you need stronger service guarantees
The ICRC-79 flow includes confirmation support for checking the status of the next payment. The documented icrc79_confirm_subscription flow is intended to be called by a canister and requires cycles per request item.
That means this is not just a frontend utility. A serious service can make canister-native calls to validate and reason about subscription state from within its own backend logic.
Query the service views, not just user views
For operations, accounting, and support, services should query the service-facing data rather than relying only on what a user sees in the UI.
In practice that means building around methods such as:
-
icrc79_get_service_subscriptions -
icrc79_get_service_payments -
icrc79_get_service_notifications -
icrc79_confirm_subscription -
icrc3_get_blocks
This gives your service a reliable source of truth for provisioning, renewals, dispute handling, and audits.
Treat ICRC-3 as your audit trail
If you need to reconstruct what happened, explain a payment to a customer, or verify state transitions, the ICRC-3 log is the right place to look.
Why this matters for open-source funding
We care about this utility for a bigger reason than subscriptions alone.
Open-source software on ICP needs durable funding models.
Many useful services are not meme assets and are not governance experiments. They are practical things:
-
API-backed canisters
-
hosted data services
-
developer tools
-
storage or indexing utilities
-
compliance or notification services
-
analytics products
-
infrastructure add-ons
-
content and community services
Those systems need recurring maintenance. They need bug fixes, security review, UX work, monitoring, support, upgrades, documentation, and operator time. A usable subscription utility lowers the friction for teams trying to build exactly that kind of business.
This deployment also continues to reflect our view that utility software should help fund the commons it depends on.
In the current implementation:
-
98.5%of a subscription payment is delivered to the service canister or configured target account -
1.5%is delivered as a donation to the configured public goods account managed by ICDevs.org
That split is not just accounting trivia. It is a concrete mechanism for channeling recurring utility activity back into open-source development, education, research, and ecosystem maintenance.
The underlying libraries also follow OVS-oriented behavior by default, because we think sustainable software funding should be built into the way serious infrastructure gets shipped and maintained.
We also want to push this further than the hosted utility itself. A big next step is shipping ready-to-deploy JavaScript and TypeScript clients, along with first-class Motoko and Rust client libraries, so teams can integrate recurring payments much faster from their own stacks.
That work is valuable, but it is not free. It needs sustained funding for implementation, documentation, examples, testing, maintenance, and release support.
If people want to directly support that buildout, one straightforward path is minting ICDevs Tokens here:
Why we think utility-based services matter on ICP
The IC is at its best when it supports real software with real users and real maintenance budgets.
Recurring payments are part of that.
A healthy ecosystem should make it straightforward for a team to launch a service canister that charges for ongoing value, while keeping the entire flow transparent, on-chain, and inspectable.
That includes:
-
token approvals through standards users already understand
-
clear subscription records
-
canister-native service integration
-
queryable logs
-
operator tooling
-
public goods support baked into the economics
That is the direction we want to keep pushing.
Current production notes
The current production rollout includes:
-
refreshed token metadata from live mainnet canisters
-
supported-token registry handling on the frontend
-
token-aware payment and transaction displays
-
revenue views separated by token
-
service deep-link tooling
-
improved production deployment and burn-in planning
If you want to try it
Frontend:
Backend canister:
hl3xq-uiaaa-aaaar-qbxqa-cai
If you are building a service on ICP and want recurring payments, the easiest place to start is:
-
define your service canister principal and product IDs
-
choose which supported token you want to accept
-
generate a deep link into the hosted subscribe flow
-
wire your service canister to query and confirm subscription state
-
use ICRC-3 logs and service-side views for audit and support
Feedback
We are especially interested in feedback from teams building:
-
developer tooling
-
data or API products
-
creator or media services
-
AI or compute-backed services
-
infrastructure utilities
-
public-goods-aligned commercial services
If you want to use the system from your canisters and need example integration guidance, that is a good place for follow-up discussion in this thread.
icrc79.mo - GitHub - icdevsorg/icrc79.mo: Subscriptions for the Internet Computer · GitHub
subscription utility - GitHub - icdevsorg/nns-sub-utility at develop · GitHub