FAQs.

You can verify three properties of a proof cryptographically, without trusting Octet at runtime:

• The signing key is in hardware on a genuine device. On iOS, Apple App Attest shows that the proof came from your app on a genuine Apple device with a Secure Enclave key. On Android, hardware key attestation shows that the signing key is in the TEE or StrongBox and chains to Google's hardware-attestation root. The key cannot be extracted from the chip. The appattest build of octet-verify checks both attestations offline against Apple's and Google's roots.

• Nothing in the proof has changed since it was signed. Every stage signature in the eight-stage attestation chain can be checked again. If any field (the verdict, the level, the commitment, the nullifier, the attestation token) is substituted, the chain breaks.

• The proof has not been replayed. Each proof carries a nullifier, a single-use replay token bound into the signed proof. Octet's backend rejects a nullifier it has already seen when a proof is uploaded, and octet-verify --nullifier-store <file> runs the same check across your own verifications.

You have to trust two things today:

• The pipeline that produced the verdict. The SDK is closed-source. The pipeline runs on the device, and its inputs are bound into the attestation chain, so you can audit which inputs produced the verdict. You cannot yet read the code that combined them.

• The platform-attestation roots. You trust Apple and Google to operate App Attest and Android key attestation as documented. If you would not trust Apple Pay or Google Pay on a device, you should not trust a proof from that device either.

You verify everything else with octet-verify, our open-source verifier.

Yes, along two planned paths:

• Zero-knowledge proofs. A ZK backend is in development. The wire format is fixed today, so the backend can ship into existing deployments without breaking your verifier. You keep the chain you have, and your verification recipe gains one optional check.

• An audited program hash. We are scoping three steps: a published binary hash of each released SDK, a third-party security audit, and a way to bind the audited binary's hash into the proof. A verifier could then check that the audited code produced the verdict.

The verdict comes out of a multi-stage signal pipeline. Proving that whole pipeline inside a zero-knowledge circuit is not feasible on a phone at today's prover speeds.

The proof is a commitment chain signed at the hardware root. Every stage of the proof is signed with the same P-256 key, which stays in the device's hardware: the Secure Enclave on iOS, the Trusted Execution Environment on Android. Each stage links to the stage before it, and the final stage binds every prior signature and the verdict into one value. A change to any stage, or to the verdict, breaks the chain. octet-verify checks the whole chain offline.

Zero-knowledge proofs for individual stages are future work. No part of today's proof is a zero-knowledge proof.

The proof gives you four cryptographic guarantees (hardware-bound, time-bound, replay-resistant, tamper-evident) and exposes every input the verdict was computed from. The proof does not give you the source code. Publishing the binary hash, a third-party audit and binding the audited hash into the proof are being scoped. Until those ship, treat a proof as a high-integrity signal in your existing decision model, not as the only basis for authorizing a transaction.

A self-contained, serialized LocationProof: a binary artifact that an independent verifier can check offline from its bytes alone. The verifier makes no call to the device, and Octet's servers are not in the trust path.

The proof carries three things:

• A cryptographic commitment to the device's location at a declared precision (for example country, region, city or area). The verifier can confirm a claim like "this device was inside region X at time T" without learning the exact coordinates. Only the device holds the secret that opens the commitment to a specific value.

• Hardware-rooted attestations. Each step in the proof pipeline is signed by a hardware-backed key. On Android the attestations chain to Google's hardware-attestation root, and on iOS to Apple's. The proof records which security tier signed it: a dedicated secure element when the device has one, otherwise the device's trusted execution environment.

• Integrity context. A spoofing assessment, freshness markers, a single-use anti-replay token and, in continuous-monitoring mode, a link to the previous proof in the chain. With these, the verifier confirms that the proof is fresh, has not been replayed and was generated from signals the SDK accepted.

The verifier never sees the raw (latitude, longitude, altitude). The commitment is a sealed cryptographic reference to the location. The verifier can confirm that the device committed to one specific place and cannot later swap in a different one, but cannot read the coordinates from the commitment.

Every step of the proof pipeline (raw signal capture, anti-spoof analysis, location commitment and final assembly) is signed by a hardware-backed key inside the device. Each signature also binds the result of the previous step, so the pipeline forms one tamper-evident chain. The chain ends in a final signature over every input that produced the proof.

The chain provides three properties:

• Tamper evidence. If anything in the proof is altered after generation (coordinates, timestamps, attestation results), at least one stage signature fails, and every signature after that stage fails too. The verifier reports the failing stage by name.

• Hardware grounding. The keys that sign each stage cannot be exported and are protected by hardware. On Android the keys live in the platform Keystore (StrongBox or the TEE, depending on the device) and chain to Google's hardware-attestation root. On iOS the Secure Enclave guards the keys, and they chain to Apple's App Attest infrastructure. A compromised app process cannot produce a signature without the secure hardware.

• End-to-end coverage. The final assembly step signs the proof's identifying metadata together with the rolling hash of all earlier stages. The transport-layer signature covers that final signature, so verifying the outer envelope verifies the entire pipeline.

octet-verify walks the chain step by step and prints PASS or FAIL for each link and for the linkage between links. Any tampering after signing produces a named failure that anyone can reproduce from the published proof bytes.

ProofLevel is a ladder of precision and confidence attached to every proof. A low level makes a weak claim ("this device is somewhere on the planet"). A high level makes a strong claim ("this device is inside a small volume and has stayed there across several proofs"). The levels in between match common claims: country, region, city and smaller.

Two properties make the level reliable:

• A proof claims only the level its evidence supports. A higher level is a stronger claim, and the SDK issues it only when the device's signals support it.

• The claimed level is cryptographically bound into the proof. The level travels inside a signed stage of the attestation chain, alongside the inputs that produced it. octet-verify rejects a proof whose level was edited after signing.

• You don't need them. Your verifier needs to know whether the device satisfies your predicate, and the predicate is evaluated on the device. You receive the YES or NO and the commitment. The commitment is binding: the device cannot later open it to different coordinates without breaking ECDSA-P256 or stealing the hardware key.

• Coordinates are a liability. Coordinates you never receive are coordinates you never store, never have to protect under GDPR and never lose in a breach. Octet does not hold them either. The blinding factor exists only in the device's volatile memory.

The commitment is a hash of the coordinates plus a fresh random blinding factor. The commitment is binding (the device cannot substitute coordinates after the fact) and hiding (nobody outside the device can recover the coordinates from it). The commitment gives future ZK proofs over the same coordinates a stable reference to build on.

The nullifier is a per-proof identifier derived deterministically from the commitment and the proof context. You record each nullifier in an anti-replay set. Two genuine proofs made at the same place at the same instant still have different nullifiers, because each commitment uses a fresh blinding factor. The nullifier check therefore catches replays without linking separate genuine proofs from the same location.

Run octet-verify, our open-source reference verifier, on your own infrastructure. Proofs are self-contained, Octet is never on the verification path, and the verifier treats Octet's backend as untrusted.

octet-verify is a single-binary Rust CLI. It runs every check in the verification spec and prints PASS, FAIL or NOT-CHECKED for each one. A NOT-CHECKED line names a check that did not run, so the report shows exactly what was validated. In the default build, the hardware-attestation checks against Apple's and Google's roots are NOT-CHECKED. The appattest build runs them. Run octet-verify in CI or by hand against a proof file or a proof id pulled from the backend. The exit codes are 0 authentic (valid, with signatures verified), 1 invalid (a check failed), 2 usage, IO, decode or backend error, and 3 inconclusive (structurally valid, but the signatures could not be verified).

Each PASS line corresponds to a specific guarantee: every stage is signed by the hardware-backed P-256 key the proof carries, stage linkage is intact, the commitment, nullifier, region, level and spoofing verdict match what was signed, and the proof is within the age window you allow. With the upload envelope (--envelope), the verifier also checks the Ed25519 transport signature that ties the proof to the enrolled device identity.

The ZK layer is additive. When the proving backend ships, your verifier gains one optional check. The proofs you already verify, and the checks you already run, stay the same.

Keys. Each device generates its signing key inside its secure hardware (StrongBox or the TEE on Android, the Secure Enclave on iOS), and the private key never leaves the chip. Octet cannot sign on a device's behalf. Revocation works at the license layer (revoking a license or a single device activation), not by changing device keys.

Proofs. Where proofs go depends on how you configure the SDK:

• No upload. Leave proofUploadUrl unset (the default). The SDK generates proofs locally and you handle transport. Nothing is uploaded.

• Octet-hosted (our demo apps). When your app sets proofUploadUrl to https://api.octetproof.com, the SDK uploads each proof to Octet's backend. The backend holds proofs for less than 24 hours and then deletes them permanently, with no long-term storage, no backups and no extraction. The backend holds proofs so that a verifier (yours, ours or a third party's) can fetch a proof shortly after it was generated and audit it. The backend does not analyze proof contents.

Verification path. When you run octet-verify on your own infrastructure, Octet's backend can at most transport and index proofs. The backend cannot change what a verifier concludes about a proof's authenticity.

One call. Your app calls the SDK's proof-generation method with the claim it wants to back, usually a region ("is this device inside the US right now?"). The SDK reads the available device signals, runs them through the anti-spoof pipeline, signs the result in hardware and returns a serialized LocationProof with an inline verdict.

Attach the proof bytes to your existing transaction payload. Your server verifies them locally as described above. Octet is never on this path.

Octet supplies the answer, and your app acts on it.

The verdict has three states:

• YES. The predicate is satisfied. A proof is attached.
• NO. The predicate is not satisfied. A proof is still attached, so you can audit the decision.
• INDETERMINATE. The SDK could not produce a reliable answer. No proof is attached, and a ReasonCode says why.

The SDK never returns a YES it cannot prove. Your business logic decides what to do with INDETERMINATE: block the transaction (recommended for high-stakes, irreversible flows), step up to additional verification, route to a higher-risk lane, or allow it and log it for pattern analysis.

Some work runs once and some runs for every proof.

Once, at activation. The SDK loads the device's hardware-backed signing key, generating it on first run, and attests it: App Attest on iOS, hardware key attestation on Android.

Per proof. The SDK runs its anti-spoof pipeline over the latest window of sensor data, then signs each stage of the attestation chain with the ECDSA-P256 key in the secure hardware, and signs the transport envelope with Ed25519. On Android, each proof can also carry a Google Play Integrity token, a separate signal about the app and device environment.

Both attestation services are free. Google's Play Integrity API has no per-request fee (the default quota is 10,000 requests per day and can be raised on request), and Apple's App Attest has no usage charge.

Each independent sensor stream an attacker fakes must stay consistent with every other stream, so the cost of faking rises with each one.

To get a high-level proof for a place the device is not, an attacker must pass several independent checks at once: a hardware device-integrity check signed by a key that cannot leave the device's secure element, spoof detection, consistency between the device's independent sensor streams, and behavioral anomaly detection. On a jailbroken or rooted device, the SDK makes no proof and returns INDETERMINATE with the reason code TAMPERING. Faking one sensor is not enough. The attacker has to fabricate a consistent picture across every sensor stream, on attested hardware, without failing any of the checks.

On a rooted or jailbroken device, data can be modified after it leaves the kernel and before it reaches the SDK. The SDK detects root and hooking, makes no proof, and returns INDETERMINATE with the reason code TAMPERING. Android has worked this way since SDK 3.0, as iOS already did. Your policy decides what happens to the user next, for example a step-up check.

Each proof carries a nullifier, a single-use replay token bound into the signed proof. Octet's backend rejects a nullifier it has already seen when a proof is uploaded. To run the same check yourself, use octet-verify --nullifier-store <file>, which records each nullifier and rejects a proof whose nullifier is already in the file.

For predicates that span a session (the device has been inside this region for the last 30 minutes), the previous_token_hash field links each proof to the one before it. Checking that linkage across proofs, as one audit trail, is on the SDK roadmap. Until it ships, treat each proof as standalone, and contact us about session-spanning use cases.

Every input that fed the SDK's verdict is cryptographically bound into the proof. Months later, you, your security team or a regulator can take a stored proof and inspect:

• Device context. Which hardware produced the proof, its OS version, and the platform attestation at the time the proof was generated (App Attest on iOS, and on Android hardware key attestation plus a Play Integrity token when present).

• The spoofing assessment. The verdict and the confidence summary the SDK used to reach it.

• A cryptographic commitment to the device's location. Nobody can read the raw coordinates from the commitment without the device, but the commitment fixes exactly what the SDK claimed. You can compare a stored proof with later evidence (witness reports, server logs, billing records) and check whether they agree.

All of it is signed in hardware and linked in the chain, so tampering after the fact, by an attacker, by you or by Octet, fails verification. Your audit trail rests on cryptography rather than on logs, and the verifier that walks it is open-source and runs on your infrastructure.

The SDK does not need a network connection to generate a proof. Sensing, predicate evaluation and signing all run on the device.

The SDK goes online once to activate, when it attests its key (App Attest on iOS, hardware key attestation on Android).

The verifier runs offline. The appattest build of octet-verify embeds Apple's and Google's roots, and --nullifier-store keeps your replay set in a local file. Octet is not on the verification path.

No coordinates reach Octet. The device computes whether your predicate is satisfied and returns a yes-or-no proof. In the default direct mode, a country or state check calls the operating system's geocoder (CLGeocoder on iOS, Geocoder on Android), so Apple or Google receives the coordinates, as for any app that uses the geocoder. A check against an area you define needs no geocoder. Octet never collects personal location data, so Octet has no database of user locations to query, secure or breach. When a regulator asks where you store user locations, the answer is that you don't, because neither you nor Octet ever receives them.

The proof contains the commitment (a hash, not coordinates), the level, the device attestation and state derived from the signals. None of these is a record of a person's location.

The sensor streams the host app already has access to:

• the inertial sensors (accelerometer, gyroscope, magnetometer, barometer)
• the platform's fused-location API (position, accuracy, timestamp, velocity, satellite quality and, on capable Android handsets, Galileo's authenticated signal where available)
• the Wi-Fi and cellular networks the device observes
• a motion-state classifier that outputs STATIONARY, WALKING or DRIVING

The SDK does not keep raw samples. It reduces them to derived values (step rate, fused heading, pressure altitude) before any later stage uses them.

The SDK reads what your host app already has permission to read, and requests no permissions beyond what location verification needs. Permissions are disclosed in your app's privacy disclosure, in your wording. We provide reference language, and you own the customer relationship.

Those tools infer location from OS-level GPS, IP, Wi-Fi and cell data, and flag signals that look suspicious or inconsistent. When a device spoofs GPS, tunnels through a VPN, sits in an urban canyon or uses network routing that hides its position, those tools cannot place the device on a map. They produce a confidence score, not a cryptographic proof.

Octet produces a hardware-signed YES or NO against your predicate, bound to a specific device at a specific time, with every input preserved in the chain for audit. You verify the answer instead of inferring it.

• Liability. If Apple or Google attested that a device's reported location is a fact, that attestation would become evidence in financial crime cases, sanctions enforcement, regulated gambling decisions and insurance disputes. Both companies explicitly disclaim location accuracy in their Maps Platform terms.

• Architecture. The OS location stack infers position from Wi-Fi and cell-tower signals, with GPS as the anchor. Without a satellite fix to calibrate them, the inferred positions drift. OS location data is not cryptographically bound to a time, a device identity or a specific event.

Octet runs in the app layer and uses Apple's and Google's hardware primitives (Secure Enclave, App Attest, StrongBox, Keystore and key attestation) to produce a signed proof against a predicate the developer defines.

The secure hardware that signs a proof, the Secure Enclave on iOS and StrongBox on Android, can only be reached from a native app. An app and a browser also see different signals, with some overlap, and each product uses the signals it can reach. On a website, Octet Browser returns a country verdict with a confidence score. In an app, the Mobile SDK returns a signed proof you verify offline. The docs describe what each product returns and how far to trust it.

Each device creates an ECDSA-P256 key when the SDK first runs. The key is generated in the Secure Enclave, StrongBox or the TEE and never leaves the chip. On Android, the SDK creates a new key before the key's attestation chain expires (the intermediate certificate lasts about 14 days). A factory reset or an app reinstall destroys the key, and the SDK enrolls a new one.

Octet revokes at the license layer, by revoking a license or a single device activation. On Android, Octet's backend also rejects devices on Google's keybox-revocation list.

Yes. The signing key lives in the device's secure hardware (StrongBox, the TEE or the Secure Enclave), not in the SDK binary. An SDK update replaces application code and leaves the key in place. The key handle persists across SDK updates, host-app updates and OS updates.

Three events invalidate the key. The SDK detects each one and enrolls a new key automatically:

• A factory reset of the device. The platform destroys all hardware-backed keys.
• Uninstalling and reinstalling the host app. On most platforms, removing the app clears its keychain or keystore entries.
• "Clear app data" on Android, or an OS update that affects the Keystore on certain Android versions.

When the SDK cannot load the existing key, it enrolls a new one, and your server receives the new public key with the next proof. Proofs your server has already accepted remain valid, and later proofs are signed with the new key. You don't need to migrate anything.

Yes. A proof can be passed from one verifier to the next. Each verifier runs the same checks independently with the device's public key. If the proof is posted to a public chain, every verifier on that chain reads the same artifact, at the cost of added latency and a public record of timing. The core product does not require a blockchain. Customers verify proofs with public keys held in their own infrastructure.

The wire format is versioned in sdk_version, and the proof structure changes only with a version bump. Empty stages can be filled in later (for example by the ZK backend) without changing the shape of the chain. Newer verifiers read older proofs: octet-verify 1.5.0 and later verify semantic-binding v1, v2 and v3 proofs. Each SDK release names the verifier it needs, for example octet-verify 1.5.0 or later for SDK 3.0.