How Agent Identity Companies Make Money, and What Our Own Meter Says We Intend

This is a hypothesis page and here is why

And other companies' revenue is not ours to report. Our internal notes carry funding figures and scoring tables for several of them; none of it was verified and none of it appears here, on the same rule the comparison pages in this estate applied.

What is left is structure, and one thing that is genuinely measurable: what our own code is built to charge for.

The shapes this category can take

Charge for issuance. Per credential, or per agent registered.

Charge for verification. Per check performed by a relying party.

Charge a subscription against a capacity limit.

Take a share of a transaction, which requires being in the payment path.

Or license to an enterprise and stop counting.

Those are the shapes. Which one a company chose is legible in what it instruments, and that is where the rest of this page goes.

What our code is actually instrumented to bill for

A meter table with exactly two permitted event types, constrained in the schema itself: a credential verification and an authorisation check.

CONTROL that makes the set complete rather than sampled: the constraint enumerates the two values, so nothing else in the backend can write a third kind of billable event.

The rollup counts distinct agents with at least one metered event in a window and reports that figure to an external billing system as monthly active agents.

So the intended model is usage-based, priced on how many of your agents were actually exercised rather than on how many you registered.

And the payer is the operator while the trigger is somebody else

The metered event is attributed to the agent's operator, and it is generated when a relying party verifies that agent's credential.

That is a defensible design. You pay when your agents are being checked by somebody, which is the moment the credential did work for you, rather than paying to hold an inventory of registrations.

And the meter defends against inflating itself: a repeated presentation is deduplicated so that a replayed envelope contributes at most one metered event per interval. Somebody thought about the incentive to over-count their own revenue and wrote the guard.

The meter records verifications that come through our live endpoint.

The product's recommended verification mode is offline. Checking a proof needs no call to us and no account with us, which is the property that makes the credential worth anything to a party who has no relationship with us.

So the more the product succeeds in the form it was designed for, the less its meter sees. A relying party doing exactly what the documentation recommends generates no billable event at all.

That is not a defect. It is a tension between an architecture that maximises usefulness and a meter that can only count what passes through us, and any pricing decision here has to resolve it rather than discover it later.

And the trigger event is this estate's standing zero

A metered event requires a relying party to verify a credential.

So the instrumented model is built on the one event that has never happened. The meter is correct, the design is coherent, and the revenue it would produce today is nothing, by construction rather than by pricing.

What a reader should take from this

Judge an identity company by what it meters, not by what it says it charges for. The instrument is harder to change than the marketing page and it tells you where the company thinks value lands.

Ours meters verification, attributes it to the operator, and cannot see the offline path. That is our answer, and it is a design rather than a business.