Launch on 01/01/2027Licenses available from 01/01/2027
Verify

You don’t have to trust us. Check.

Most of this category asks you to book a call, sit through a demo, and take the cryptography on faith. Ydentifi does the opposite: everything you’d evaluate us on is public before you talk to anyone, and the parts that carry the risk are built to be checked, not asserted.

Check it from the outside

No login, no sales call, no NDA. Every one of these is public, on this site or at launch:

The complete API

All 21 relying-party RPCs, with their request and response fields and the typed errors each one raises — not a summary, the surface your backend actually calls.

The exact limits

Plan caps and the per-user rate-limit numbers across all three tiers, written down. You can see where a wall is before you hit it.

What works and what breaks

A load-balancer matrix that names specific products — which ones pass the mutual-TLS handshake through, and which ones silently break it.

A running deployment

One container and a database, up on your laptop with a working ceremony in an afternoon — before any conversation.

The signing code

The device SDK — the part that holds the keys, builds the signed response, and talks to your server — is open source under Apache 2.0, published at launch. The security-critical code on the phone is yours to read, fork, and audit.

The price

A flat number, published, with a slider. No “contact us” to find out what a seat costs.

What is inside what shipsFive artifacts, each with a machine-readable inventory that the build keeps current.THIRD-PARTY COMPONENTS PER SHIPPED ARTIFACTydentifi-serverthe licensed product12ydfithe operator’s tool10ydentifi-admin-serverthe operator interface4licensing-serverYdentifi’s own service5YdentifiAuthenticatorthe phone application22It cannot go staleOne command regenerates every inventory and thelicense notices with it. A second fails the buildif what is committed no longer matches what thecode would produce.Small numbers are the pointA dozen third-party components in the licensedproduct is a small surface to review, to patch,and to answer questions about. It is a consequenceof the finite-product position.
The third-party components inside each shipped artifact. One command regenerates every inventory; a second fails the build if what is committed no longer matches what the code would produce.

Built to be right, not just tested

The server’s key design and operational principles stay closed. But the way it is built to be correct is not a marketing line; it is a method:

What is proven rather than testedFour models, each covering a property that testing can only sample.SPECIFIED AND CHECKED BY MACHINE, NOT SAMPLED BY TESTSSingle-use claiman invite can be claimed exactly once, whatever the orderingRULES OUTtwo phones racing on one tokenRate limiterthe counting is correct under concurrent charges, and cannot deadlockRULES OUTconcurrent requestsdouble-spending a budgetLock orderingno two operations can wait on each other for everRULES OUTa deadlock between device and useroperationsThe ceremoniesan attacker with the network cannot forge or replay an exchangeRULES OUTmessage interception, replay,reflectionEvery model is run twice, and must fail the second timeA model that passes proves nothing on its own — it might be passing because it checks nothing at all. Soeach one is paired with a deliberately broken version of the design, and the checker must reject it. Achecker that cannot tell the two apart is reported as broken rather than as green.Where the checking tools are absent, those steps report as skipped — never as passed.
Four formal models, the property each one proves, and the failure it rules out.
Adversarial testing with independent agentsThe method, and the sequence that shows why one round would not have been enough.THE RULES, AND WHY EACH ONE IS THERENo list of expected attacksan agent is given a surface and told to break it. A list bounds what gets found to what somebodyalready thought ofBlind to each otheragents in a round cannot see each other’s work, so they do not converge on the same ideaBlind to the recordthey cannot read what previous rounds found, so a defect that was fixed badly gets found againTwo different modelsreasoning and empirical approaches find different thingsRepeat until dryrounds continue against each fix until findings decay to test gaps and accepted risksWhat repeated rounds found that a single round would notRound 1a defect is found in how records are timestampedRound 2the fix introduces a new defect — a poisoned timestamp propagatesRound 3the second fix is incomplete; the root cause is identifiedRound 4the root fix holds — and clearing the noise reveals a worse, older defectRound 5that one is fixed, and the fix introduces two moreRound 7clean, empirically, across every legFive of these were introduced by the fixes for the ones before them.
The five rules the adversarial programme runs under, and a seven-round sequence of independent models.
One list, ten implementationsIncluding the two that run on phones, reached through the test-only mirrors.46 scenariosone list, held in the repositoryGodirectPythondirectTypeScriptdirectRustdirectJavadirectPHPdirectRubydirect.NETdirectSwiftvia a mirrorKotlinvia a mirrorrun against one real server containerZero divergences permittedAn error in Ruby differing from the same error in Go is a build failure, not an ecosystem quirk.A separate check fails the build if the list has a gapAny call in the contract with no scenario is reported by name. The list cannot fall behind the interface quietly.
One scenario list run against every language implementation against a real server — a disagreement anywhere is a defect somewhere.
Tests organised by the question they answerNot by layer, and not by how fast they run.SIX CATEGORIES, APPLIED TO EVERY CALLSuccessthe call works, and the database afterwards says what it shouldAuthenticationthe certificate checks, the fingerprint pin, the context isolationLimitsthe budgets, the lockouts, and what happens at the boundaryAttackinjection, cross-tenant attempts, replay, malformed inputFailurewhat a broken dependency or a bad input producesContractthe same scenario, run against every client libraryEach call carries a checklistA file beside every call lists the six categoriesand marks each one implemented, deliberatelyskipped with a reason, or missing. It is updatedin the same change as the test.Why not a coverage numberA percentage says how much code ran. A checklistsays which questions were asked, and which weredecided not to apply, and by whom. The second iswhat an auditor can argue with.
Six categories of test applied to every call, with the per-call checklist.

What we don’t publish is the server’s key design and operational principles. What you need to evaluate us on isn’t in there; it is all above.

Start checking

Quickstart →See pricing
Opens on 01/01/2027

Available at launch

Until then, you can try the whole ceremony on your own phone.

Try the live demo