Pricing

The Ratify Protocol is Apache-2.0 open source and free forever — every SDK, every primitive, every cryptographic interface. Running your own verifier with the open SDKs costs you nothing and never will.

Ratify Verify is the managed layer maintained by Identities AI. It exists for teams who don’t want to run their own verifier infrastructure, want compliance-grade audit chains, or need to deploy in sovereign / regulated environments. It is sold across four motions, each with a different shape, a different buyer, and a different commitment level.

The four motions

Motion	What it is	Who buys it	Commitment	Price
Open Protocol	The protocol, the spec, and five open SDKs	Anyone	None	Free, forever
Verify Operational	Managed verifier endpoint with metered verification, audit trail, and delegation controls	Engineering teams putting Ratify into production	Pay-as-you-go	$0.002 / verification (orgs: $50/mo minimum; personal workspaces: no minimum)
Verify Trust	Signed-receipt audit chain, anchor-bound identity, custom constraint registry (capabilities scoped per engagement)	Compliance officers, CTOs, regulated industries	Annual design-partner contract	From $30,000 / year
Verify Sovereign	Licensed self-hosted Verify control plane, no phone-home, customer-owned keys (scoped per engagement)	EU institutions, federal / defense, regulated finance, healthcare with strict residency	Annual design-partner license	From $50,000 / year

Cutting across all four motions is one horizontal capability — the Platform Registry — which is free for any platform that wants to publish a verifiable identity in the Ratify ecosystem. It’s a Plaid-style directory, not a tier. See the dedicated section below the four motions.

Each motion is explicit about what it enables and what it doesn’t. There is no tier ladder to climb — you choose the motion that matches what you’re actually doing, and you can combine them (a customer can be on Operational for day-to-day usage and Sovereign for one regulated workload at the same time).

Surfaces are not pricing-gated

Ratify’s four product surfaces are not pricing tiers. Agentic API is the current alpha wedge, delivered through the managed Verify endpoint and integrated into customer middleware or gateways. Conversational AI is the next managed integration target. The Meetings control plane and Zoom adapter are under validation. Physical AI is a later managed integration, while its protocol primitives are already available in the open SDKs.

Surface	What it authorizes	Example platforms
Agentic API	AI agents making programmatic calls via MCP, A2A, REST	Any MCP server, A2A agent, REST API
Conversational AI	AI agents in real-time conversations, voice or video	Bland, Retell, Vapi, ElevenLabs, HeyGen, Tavus
Meetings	AI agents in structured, multi-party sessions	Zoom, Teams, Google Meet
Physical AI	Embodied AI agents in the physical world	Drones, robots, vehicles, infrastructure

Voice and video are unified under Conversational AI — the authorization model is identical whether the channel is audio or video. Platforms like HeyGen and Tavus (real-time video avatars) and Bland or Retell (voice agents) both fit here. The channel is an adapter configuration detail, not a product distinction.

Capability matrix

Verify Trust and Verify Sovereign are design-partner offerings. Capabilities and deployment requirements are scoped contractually. Items marked roadmap are not currently available.

	Verify Operational	Verify Trust	Verify Sovereign
Surface pricing access	Not gated	Not gated	Not gated
Agentic API	Managed Verify API alpha	Managed Verify API alpha; Trust evidence capabilities per the rows below	Roadmap: customer-deployed Verify
Conversational AI	Roadmap	Roadmap	Roadmap
Meetings	Control plane implemented; Zoom under validation	Same	Deployment packaging unverified
Physical AI	Managed integration later	Managed integration later	Protocol primitives available; managed packaging later
Hash-chained audit trail (organization scope)	Alpha	Included	Customer-controlled (Sovereign scope)
Audit retention	30 days (alpha)	365 days, through design partnership	Customer-defined (Sovereign scope)
Signed VerificationReceipts	—	Available through design partnership	Available through design partnership
Anchor-bound identity in audit	—	Available through design partnership	Available through design partnership
Custom constraint registry	—	Design-partner development	Design-partner development
SOC2 / ISO evidence export	—	Roadmap	Roadmap
SAML / SSO	—	Under validation	Under validation
Custom DPA	—	Available by agreement, subject to legal review	Available by agreement, subject to legal review
Priority support	—	Scoped contractually	Scoped contractually
Self-hosted deployment	—	—	Roadmap; available for design-partner development
No phone-home	—	—	Required design target; verified per deployment
Customer-owned keys / HSM	—	—	Roadmap

For the custom constraint registry: the protocol extension mechanism is implemented; the managed registry distribution is not yet available.

The motions differ in what each engagement is scoped to deliver, not in artificial feature flags:

Operational → Trust: the goal is cryptographic evidence your verifications happened and are defensible in an audit; not just logs, but tamper-evident, independently verifiable receipts, scoped per engagement.
Trust → Sovereign: the goal is data residency. The Verify control plane moves inside your infrastructure, so no third party, including Identities AI, sits in your verification data path.

Platform catalog — publisher trust levels

Any platform can publish to the Ratify catalog. The trust badge reflects how the publisher’s identity was verified. Downstream consumers (and their connection policies) decide what trust level they require.

Badge	What it proves	Requirements
Personal Publisher	Verified Ratify account	Email verification
Verified Individual	Real identity with established external anchor	Email + GitHub or Google OAuth
Verified Publisher	Organization that owns its claimed domain	Org + DNS TXT record verification

There is no separate “Trust-Verified” catalog badge — the Verify Trust commercial tier gives the buyer better compliance infrastructure; it is not a signal about the publisher’s trustworthiness. A Verified Publisher on Operational and one on Trust are identical in the catalog, because what matters for the catalog is domain verification, not the buyer’s compliance tier.

Platform Registry — free for any platform

Cutting across all four motions is the Platform Registry, a free, public directory of platforms that participate in the Ratify ecosystem. Platforms here include the verifier side (companies that accept Ratify proofs from external agents — meeting hosts, voice gateways, API platforms, custodial wallets) and the issuer side (companies whose users delegate to agents that go act on other platforms).

Registration is free, regardless of which motion (if any) the platform is on. The incentive structure mirrors Plaid’s institution directory or the GitHub Apps marketplace: Identities AI captures value from network effects, not from charging the platforms.

What a registered platform gets

A verified PlatformID (e.g. platform.otter.ai, platform.slack.com). Once claimed and DNS-verified, the ID is yours; nobody else can publish under it.
DNS domain verification via TXT record (same flow as the Organization domain claim).
A public listing in the platform catalog — discoverable by any other platform looking for who supports what.
A .well-known/ratify-platform.json bundle published at your verified domain. Any verifier anywhere can fetch it offline; this is how third parties discover and trust your public keys.
The “Ratify Protocol Verified Platform” badge for your own site, GitHub repository, README, or product UI.
A profile page with name, logo, what you verify or what you issue, supported scopes, contact, links to your own docs.

What it does NOT cost extra for

Operating a verifier — using the open SDK, your own RevocationProvider, your own audit log — is the Open Protocol motion. Registering as a platform on top of that costs nothing. Many platforms will only ever use the Open Protocol + Platform Registry combination and never pay for Verify managed infrastructure. That’s fine; you’re a brand-credibility signal for the protocol.

Where it lands inside the motions

Account type	Platforms you can claim
Personal Account (Operational)	1 platform under any domain you can DNS-verify
Organization (Operational / Trust / Sovereign)	Unlimited platforms under the Organization’s verified domain

A Personal Account user wanting to register a second platform creates an Organization (the Org owns the platforms, the human is the Owner-role member). This mirrors how GitHub treats @me’s 1 free private repo vs. unlimited under an Organization.

What this means concretely

Otter.ai (verifier-side platform): stays on Open Protocol. Implements verify_bundle() at the meeting-join handler. Registers platform.otter.ai for $0. Gets a public listing and the verified badge. Pays nothing to Identities AI.
Slack (verifier + issuer): registers platform.slack.com for $0. Probably uses Verify Operational ($0.002/verification) because they want centrally managed revocation checks across their infrastructure, but the registry profile itself is still free.
A solo dev’s hobby project: signs up with Personal Account, registers platform.solodev.dev for $0 under their own verified domain. Starts with $50 in alpha credits (≈25,000 verifications); the platform listing is permanent.

How to register

In the alpha console at https://dev.identities.ai, the flow is:

Sign in with Google, Microsoft, or email magic link.
Choose “Register a platform” from the Studio dashboard.
Enter the domain you want to claim. Studio shows you a DNS TXT record.
Add the TXT record at your DNS provider; click “Verify.”
Fill out the profile page (name, logo, description, supported scopes, contact).
Optional: tick “Publish to public directory.”

Detailed registration steps live at Onboard a platform.

Open Protocol — free, forever

The protocol is yours. Implement it, fork it, run it in production behind your firewall, build a competing managed verifier with it — none of that is gated by anyone.

What you get

The protocol specification (CC-BY-4.0) — the normative source of truth at SPEC.md.
Five reference SDKs (Go, TypeScript, Python, Rust, C/C++) under Apache-2.0. All five produce byte-identical canonical JSON and verify each other’s proofs.
Every cryptographic primitive: hybrid Ed25519 + ML-DSA-65 signing and verification, delegation chains, scope intersection, first-class constraints, revocation lists, session tokens, transaction receipts, witness entries.
Every provider interface defined in SPEC §17: RevocationProvider, PolicyProvider, AuditProvider, ConstraintEvaluator, AnchorResolver. Each comes with a working no-op default; you supply your own implementations.
The full 63-fixture cross-language conformance suite and the cross-SDK byte-equivalence corpus (10 vectors covering BundleHash, VerifierContextHash, PolicyVerdictSignBytes, VerificationReceiptSignBytes).

What you don’t get (without Verify)

A hosted verifier endpoint; you operate your own.
Hosted revocation checks; you operate your own revocation provider and synchronization infrastructure.
A signed, hash-chained audit archive; you can build one against the open VerificationReceipt primitive, but you maintain it.
Managed surface integrations; commercially, Agentic API runs through the managed Verify endpoint today, a Meetings control plane and Zoom adapter are under validation, and further surfaces are on the roadmap.
A managed policy authoring UI (on the Verify roadmap); your team writes policy in code or manages a Rego/OPA service themselves.

Who this is right for

Developers evaluating Ratify before committing.
Open-source projects that need cryptographic agent authorization but don’t need managed infrastructure.
Teams with strong internal infrastructure who prefer to operate the verifier themselves.
Air-gapped deployments where the managed Verify is structurally inappropriate (see Sovereign for an air-gappable commercial alternative).

Verify Operational — managed verifier, pay per verification

Verify Operational provides the managed, metered authorization endpoint for Agentic API workflows. Call POST /v1/ratify/verify from an MCP server, A2A service, API gateway, or application middleware before executing a protected action. Each decision is attributed to the calling connection and recorded in the managed audit trail.

Pricing: $0.002 per verification, $50/month minimum. The $50 minimum is your monthly commitment; it includes the first 25,000 verifications. There is no verification cap above that; usage past the minimum bills at the same per-verification rate.

Two onboarding paths

The Operational plane supports two account types. The Studio renders identically for both; the only differences are how identity is anchored and whether a Verify Trust contract is possible.

Personal Developer Account

For a solo developer building, evaluating, or running a side project under their own identity. The fastest path from “I want to try Verify” to a working API key.

Sign in with Google, Microsoft, or email magic link.
Account ID is auto-generated (usr_xK2pA9...); no domain claim required.
$50 in alpha credits on first sign-in (≈25,000 verifications) so you can integrate and ship before putting in a card. Credits are pre-loaded automatically.
Same Studio, same API, same pricing past the credits ($0.002/verification). Personal workspaces have no monthly minimum — you pay for exactly what you use.
Cannot enter into a Verify Trust contract (Trust requires a verified legal entity).
Can create an Organization later. Creating an Organization does not consume or change your Personal account; both coexist.

Organization

For teams putting Ratify into production behind a company or product.

One human creates the Organization. That human becomes the first Owner. They invite teammates (Owner / Admin / Member roles).
Organization claims a domain via DNS TXT verification. The verified domain becomes the Organization’s Publisher Domain — visible in any Anchor records the Organization signs on behalf of human roots.
Same pricing as Personal: $0.002/verification, $50/month minimum. Organizations do not receive the $50 alpha credit.
An Organization can be the legal-entity counter-party to a Verify Trust or Sovereign contract.

A single human can own one Personal account and be a member of any number of Organizations. The Studio’s top-left context switcher (same UX as GitHub, Stripe, Vercel) lets you move between contexts; each has its own billing, audit history, and API keys.

Migration and lifecycle

A Personal account can create an Organization, but cannot convert itself into one. Both coexist after creation.
An Organization can transfer specific platforms to itself from any member’s Personal account, with audit-log entries on both sides.
An Organization can be deleted by an Owner (irreversible, members lose access, billing closes out, optionally exports the audit archive on the way out).
An Organization cannot downgrade to a Personal account. Legal-entity boundaries and audit-trail attribution must stay intact.

What Verify Operational enables

Current capabilities:

Managed, API-key-authenticated verification endpoint, metered per decision.
Hosted revocation checks on every verification.
Delegation and scope controls.
30-day searchable audit retention.
Decision records for successful and rejected verification attempts.

On the roadmap:

Conversational AI integrations.
Managed policy authoring and distribution (PolicyProvider backed).
Managed push-based revocation.
Verification-decision webhooks into your log / SIEM pipeline.
Additional surface adapters.
Meetings control plane and Zoom adapter, currently under validation.
Physical AI managed integration, later.

What Verify Operational does NOT include

Signed VerificationReceipt archive. You can issue receipts via the open SDK; the managed, chained, signed-with-Verify’s-keys archive is part of Verify Trust.
Anchor-bound audit. The open AnchorResolver interface is yours to wire to your own IdP; Verify’s managed SSO-attested identity binding is part of Verify Trust.
Custom constraint type registry. Anyone can register mycompany.* constraint evaluators in their own SDK call; the managed cluster-wide registry that survives the customer’s deployment is part of Verify Trust.
365-day audit retention, SAML/SSO into Studio, custom DPAs. All part of Verify Trust.
Self-hosted / air-gapped deployment. Part of Verify Sovereign.

Verify Trust — annual contract for compliance-grade audit

Trust is the layer that says “if something goes wrong with an agent, this is what defends you.” It is sold as an annual contract because the value is in the contractual commitments (data retention, audit-trail integrity, identity attestation), not in per-call metering.

Trust is a design-partner offering: each engagement scopes the capabilities below contractually, and items marked roadmap are not currently available.

Pricing: design-partner engagements from $30,000 / year.

What a Trust engagement scopes on top of Operational

Signed VerificationReceipt archive. Every verification produces a hybrid-signed, hash-chained receipt (see SPEC §17.5). Signed receipts bind each recorded decision to its predecessor, so modification, reordering, and missing interior entries are detectable when later receipts or an independently retained chain head are available; detecting tail truncation requires external retention or checkpointing. A downloadable SOC2/ISO evidence bundle is on the roadmap.
Custom constraint type registry (design-partner development). Define mycompany.max_daily_spend, mycompany.region_allow, mycompany.parental_consent, etc., with Verify maintaining the cluster-wide registry so any of your tenants’ agents can reference them. The protocol extension mechanism is implemented; the managed registry distribution is not yet available. Issuers using Trust-registered types implicitly require Verify-aware downstream verifiers, which is the moat lever.
Anchor-bound audit. Every verification chain links to the human root’s SSO assertion (Okta, Azure AD, Google Workspace). Auditors can prove “this verification was tied to a SAML-asserted identity from Okta”, not just “this verification happened.”
SAML / SSO for the Studio web app itself. Admins sign in via your IdP.
90-day standard audit retention. Optional 365-day retention for regulated industries.
Custom DPA, sub-processor list, contractual data-residency commitments (US / EU / Switzerland).
Priority support, scoped contractually.

Who Trust is right for

Companies pursuing SOC2 / ISO 27001 / HIPAA / PCI-DSS and needing a defensible audit chain for AI-agent-driven actions.
Mid-market and enterprise customers whose agents touch money, identity, or regulated data.
Anyone selling agent-driven products to enterprise customers who will ask for SOC2 evidence.

Verify Sovereign — licensed, self-hosted, no phone-home

Sovereign is for customers who cannot have a third-party verifier in their data path. The EU institution, the federal agency, the regulated bank with national-residency requirements. They take the Verify binaries, run them inside their own infrastructure, and hold 100% of the root revocation keys themselves.

Sovereign is a design-partner offering: deployment packaging is not yet available, and each engagement scopes delivery, support, and validation contractually.

Pricing: design-partner licenses from $50,000 / year. Support and Technical Account Manager options are scoped contractually.

What a Sovereign engagement scopes

Trust capabilities running entirely inside the customer’s network, per engagement.
No phone-home as a target requirement, verified per deployment: the verifier does not communicate with Identities AI infrastructure.
Customer-owned root revocation keys. Identities AI never has access.
Delivery packaging (Helm chart, Docker image, or hardened VM image) is not yet available; it is scoped by design partnership.
Air-gapped upgrade path: signed Verify releases verifiable via the open VerificationReceipt chain, scoped per engagement.
Contractual data-residency commitment tied to the customer’s chosen geography.

Who Sovereign is right for

EU sovereign deployments (Schrems-II strict residency).
Federal / defense customers requiring FedRAMP-style isolation.
Regulated finance customers with national-residency requirements.
Healthcare systems with HIPAA + state-specific residency.
Customers in F500 industries with internal-only AI deployments and “no SaaS on this data” policies.

Why this model, and not tiered SaaS

The “Bronze / Silver / Gold” SaaS tier ladder works when the underlying product is the same and you’re price-discriminating on feature flags. Verify is structurally different from that. The four motions correspond to four genuinely different things you can be buying:

The Open Protocol is a public good — a standard you can adopt without a vendor relationship.
Verify Operational is a service — managed infrastructure that you pay for as you use it, no commitment, no tier negotiation.
Verify Trust is a contractual artifact — an audit chain that defends you in a dispute, sold on annual contract because the value is the commitment.
Verify Sovereign is a licensed product — software you operate yourself, with contractual support.

These are different motions because they involve different commitments, different relationships, and different buyers. Collapsing them into a tier ladder would have hidden the actual structure of the offering.

Specifically, this model rejects three common SaaS-era pricing patterns that don’t fit:

No per-seat pricing. Agents make calls; seats don’t. Charging per seat is a pre-AI assumption that no longer maps to how AI products operate.
No artificial verification caps as upgrade gates. Volume is metered honestly across motions; it’s never the lever that forces an upgrade. The lever is whether you need signed-receipt-archive (Trust) or self-hosting (Sovereign) — capabilities, not counters.
No black-box “Contact Sales for Enterprise.” Trust starts at $30K/year. Sovereign starts at $50K/year. Both are published floors. Contracts above those numbers are negotiated; nothing below.

When the open protocol is enough

You do not need to pay Verify if you are:

Building an open-source tool that uses the Ratify primitive for local-only checks.
Operating your own verifier infrastructure with self-managed revocation, policy, and audit.
Building inside an air-gapped environment where the managed Verify is structurally inappropriate (and you don’t need a Sovereign license).

Specifically: enforcement, observability, and identity binding are all in the protocol. A PolicyProvider returning false rejects the bundle (enforcement). An AuditProvider sees every verification (observability). An AnchorResolver binds verifications to external identity (attestation). The open SDK ships interfaces and working defaults for all of it.

Ratify Verify sells the managed operational layer around authorization decisions. In alpha today, that means the metered Verify API, hosted revocation checks, delegation controls, and a hash-chained audit trail. Agentic API is the initial wedge: developers place the decision call before MCP tools, A2A requests, REST operations, and other consequential agent actions. Conversational AI and surface-specific integrations build on the same service.

The protocol is a public good. We charge for operating the managed infrastructure around it.

Maintained by Identities AI, Inc. Ratify Protocol™ and identities.ai™ are trademarks of Identities AI, Inc. U.S. patent application pending.