Umarise is an operational service around an open protocol. We run the servers, hosting and operations on our side; partners get access to that operation via an API key. In that sense there is an IaaS-like layer: we manage infrastructure, partners consume it through the API.
But the crucial difference from classic infrastructure-as-a-service lies in what happens if we cease to exist:
Stop Umarise, and the proof remains
The infrastructure we run implements an open protocol. The protocol exists independently of Umarise as operator. That makes it a separate category: an operational service around an open protocol, not a closed product.
Why it is not .. SaaS is a closed software product you use through an account; the vendor manages the entire stack and the user logs in. Gmail, Salesforce, Slack. With SaaS you lose access, data and functionality if the vendor shuts down. With Umarise the "software" is an open protocol, not a closed product. There is no account to lose, no feature set that is exclusively ours. What partners buy from us is operational access to an implementation of a public specification. That is a different product model.
Why it is not .. PaaS provides a platform to build your own applications on — Heroku, Google App Engine. Partners bring their own code, runtime and data; the platform handles hosting, scaling and runtime. Umarise provides no platform to build something on. We provide one specific function (existence anchoring) through one Core API. Partners don't build "on Umarise" the way they would host an application "on Heroku"; they integrate our API into their own system. That is integration of a primitive, not platform usage.
Whit it is IaaS-like, in the sense that we run infrastructure that partners consume via API. But the XaaS categories all share the same pattern: stop the vendor, stop the product. Gmail gone = inbox gone. AWS EC2 gone = server gone. Heroku gone = app must be rebuilt. With Umarise: stop Umarise, the proof remains. That shifts the whole model out of the XaaS categorization, no matter how much infrastructure we run.
In practice Umarise delivers two layers at once: an infrastructure layer (the servers, hosting and operations on our side — what partners actually purchase) and a protocol layer (the open spec and public verifiability — what gives the proof its value). Those two layers do not coincide, as they do in SaaS, but interact. The infrastructure implements the protocol. Partners pay for the operational infrastructure that implements the protocol; the implementation is replaceable, the protocol is not. Exactly the same pattern as Gmail implementing SMTP: if Gmail stops, SMTP remains and another provider can take over the role.
| category | vendor manages | what if vendor operations cease to exist? |
|---|---|---|
| IAAS (AWS EC2) | Infrastructure | Server gone, you must migrate your data |
| PaaS (Heroku) | Infra + runtime | App must be rebuilt, data migrated |
| SAAS (Google) | The entire stack | Access gone, export your data or lose it |
| Umarise | A service around an open protocol | Proof remains. Spec is open. Anyone can run an equivalent service on the same open specifications |
The fundamental question at the infrastructure as well as the protocol is:
“how much do you stand to lose if the vendor is no longer offering the services you rely on?"
The Umarise answer is: nothing; the proof is already anchored in Blockchain. The spec is open. Someone else can run an equivalent service”
The sales model is an annual retainer per partner, not usage-based pricing. That is a deliberately chosen doctrine, not an administrative preference.
That distinction determines everything around it. Partners are not buying a meter; they are buying annual access to an operational service built around an open protocol. One annual amount, one contract, one invoice. No meter between partner and anchoring. No dashboard to maintain. No billing disputes over how many anchors were created in which month.
An anchor has value. Usage-based pricing reduces that value to a meter tick. That conflicts with what the product is. Proof of existence at moment T is not a consumable; it is a one-time cryptographic statement whose value plays out over years or decades. Billing per call would reduce it to something like an SMS bundle, undermining the entire proposition.
Operational access to the Core API, plus everything around it that makes that access reliable: OTS workers, calendar monitoring, batching, retries, proof rotation, SDK maintenance, RFC tracking, integrations, and — in higher tiers — SLA, webhooks, audit bundles, support and compliance reference documentation. Not API calls. No seats. No users. No volume meter.
The Core API runs on Umarise infrastructure, on Umarise hosting, at Umarise's cost. Partners get an API key that gives them access to that operation. What they buy is the management they don't want to run themselves: servers, calendar monitoring, retries, batching, keys, monitoring, upgrades. Architecturally, everything can be self-hosted based on the open spec. Operationally, almost no one does — for the same reason almost no one runs their own mail server: doing it yourself costs more than it is worth.
No exclusive access to the verification layer. No lock-in. No customer dashboard, no metrics portal, no account-management tooling. Verification stays client-side and publicly available via anchoring-spec.org and verify-anchoring.org. Partners who want to can, in principle, hash, bundle and submit to OpenTimestamps themselves. What they buy from Umarise is convenience, scale and maintenance.
are not about what the API does, but about what surrounds it. The API is identical for Community, Partner Standard, Partner Regulated and Strategic Partner. The difference is in support, SLA, webhooks, audit bundles, response times and compliance documentation. Not in the functionality of the primitive itself.
Service availability may depend on Umarise. Verification itself never. The retainer covers the first; the open spec and the public anchor cover the second. That is precisely the difference from classic SaaS retainers, where service availability and proof-persistence are the same dependency.
If a partner engineer asks: What are you, really?
Answer: a verification primitive. Umarise runs the operational side of an open protocol. If Umarise stops, the proof stays verifiable. Partners aren't buying access; they're buying convenience and scale around something that works even without Umarise.
If they then ask: so why would we pay you?
Answer: because running your own OTS workers, setting up calendar monitoring, configuring proof rotation, keeping up with RFC tracking and guaranteeing SDK parity is far more expensive than buying it in. Just as anyone can run their own mail server but uses Gmail or Microsoft 365. We sell a retainer on an open protocol, not access to a closed product.
Two sentences. No jargon. No exaggeration.
Amounts to be determined.
| Tier | Intended for |
|---|---|
| Community | Free tier for developers — in return, they help build and shape the verification primitive |
| Partner Standard — Tier 1 | Annual entry cost — low enough to get started (incentive) |
| Partner Regulated — Tier 2 | Medium size / enterprise |
| Strategic Partner — Tier 3 | Custom-made / strategic partner |