Developers
Build on hardware-rooted device trust
Answer one question — is this a real, distinct device, not a script or a rented cloud server? — using the security chip built into virtually every modern laptop and phone (the TPM or Secure Enclave). One integration returns that answer, without CAPTCHAs, fingerprint scripts, or collecting any personal data.
What you build
One integration, one question answered: is this a real, distinct, healthy device? Shield is a drop-in device-verification call you put in front of the actions abuse targets.
The whole model in 90 seconds
Five plain ideas. Each term is defined before any jargon.
- Device — a physical machine, identified by the security chip built into it (its TPM, Secure Enclave, or Android security key). Enrolled once.
- Attestation— the device cryptographically proving it's a specific, real, physical machine (not a script, not a rented cloud server), checked against your rules. By default, your app collects a sealed evidence bundle from the machine (no keys, no Root Herald contact) and hands it to your server; your server calls Root Herald with its secret key (
rh_sk_) and a named policy, and gets the answer back directly. - Chip kind (TPM class) — what kind of chip is at the root:
hardware,firmware-tpm,cloud-vtpm(a rented cloud server or software emulator pretending to be a real chip),mobile-hardware,emulated. You decide which kinds you accept; full table in the taxonomy reference. - Acceptance policy — your rule for how strict to be: which chip kinds and assurance levels pass. The default (
rootherald:builtin:strict-hardware) rejects every virtual or emulated chip. - Verdict — the answer your server gets back: a
pass/warn/failplus a stable, anonymous per-device ID (device.ueid, no personal data). It's returned directly byrh.verify()— no token to handle. The typedAttestationVerdictalso carries the assurance level (acr) and a device health status (earStatus: affirming / warning / contraindicated).
the verdict you get back (AttestationVerdict)json
{
"acr": "urn:rootherald:device:high",
"device": {
"ueid": "2f9c8a14…", // stable per-tenant device id (no PII)
"verdict": "pass", // pass | warn | fail
"earStatus": "affirming", // affirming | warning | contraindicated
"attestationType": "tpm20",
"secureBootVerified": true,
"trustworthinessVector": { "hardware": 2, "configuration": 2 }
}
}Get started
SDKs
JavaScript
Coming soon@rootherald/browser · browser
React
Coming soon@rootherald/react · <RootHeraldGate>
Node.js
Available@rootherald/node · server-side
.NET
In developmentRootHerald.AspNetCore · ASP.NET Core
Java
In developmentSpring Boot starter · @RootHeraldGuard
Go
In developmentchi + gin middleware · sentinel errors
PHP
In developmentLaravel · Symfony · WordPress
Ruby
In developmentRails controller concern
Python (server)
In developmentFastAPI + Flask · pip install rootherald
Native C++
In developmentRootHerald.lib / .a static-link
Native C#
In developmentP/Invoke for desktop .NET
Android (Kotlin)
Coming soonKey Attestation · StrongBox
iOS (Swift)
Coming soonApp Attest · iOS 14+
React Native
Coming soonExpo · keyless evidence collector
Unity
Coming soonUPM plugin · all platforms
Unreal Engine
Coming soonUE5 plugin · Blueprint + C++
Wire protocol
Reference
Guides by use case
Device trust — enroll only your devices
Trusted-enrollment pattern: gate with your own secret, persist the hardware id.
Web3 — Sybil-resistant airdrops
One-wallet-one-device enforcement.
Games — anti-cheat & smurf control
Device-rooted ban list under your anti-cheat.
AI — protect a free tier
Keep credits real without phone-OTP heuristics.
Cloud-permissive without the replay loophole
Accept real cloud users without one 'pass' becoming thousands of fake accounts.
Embedded game SDK
Wire the native SDK into a launcher.