Identity layer

Identity verified by consensus, revealed by proof

VEID (Verifiable Electronic Identity) turns identity verification into a protocol function: encrypted identity scopes are scored by the validator set's shared machine-learning models, and users prove what matters with zero-knowledge proofs — nothing more.

identity.org.au VEID documentation
People checking a phone together — an active liveness step.
A real person, one active check — then only proofs travel.
Fig. 01The capture wallet

The device does the sensitive work.

Capture, liveness and attestation all happen on the handset. The network receives a sealed scope — never a document archive.

VEID wallet demo — choose a step

01 · Capture

Read on the handset

Documents are read with OCR on the handset. Nothing is uploaded at capture time.

Stays on the handset
Document image · OCR text · 5 detected fields
Crosses the boundary
Nothing — 0 B leaves the handset
device console · on-handset

09:41:02 camera.start · rear · 60 fps

09:41:03 frame.quality · edges · glare · blur

09:41:04 ocr.detect · type=AU_DL · confidence 0.98

09:41:04 ocr.extract · 5 fields · on-device only

09:41:05 upload · 0 B · nothing leaves the handset

02 · Liveness + attestation

Prove a present human

An active challenge proves a present human; hardware attestation binds the capture to secure silicon.

Stays on the handset
Selfie frames · depth map · secure-element key
Crosses the boundary
Nothing — frames are discarded
device console · on-handset

09:41:05 camera.start · front · face centred

09:41:06 anti-spoof · depth · reflection · replay

09:41:07 challenge.1 · blink · watching

09:41:07 attestation · Play Integrity / App Attest

09:41:07 key.bind · secure element · …A9F3

03 · Prove without revealing

Share the proof, not the data

Name, date of birth, address and document number stay sealed on the device. Only the proof is shared.

Stays on the handset
Name · date of birth · address · document number
Crosses the boundary
One threshold proof — no personal fields
device console · on-handset

09:41:12 scope.select · trust ≥ threshold · consent recorded

09:41:13 zk.prove · circuit=veid-threshold · 1.8 s

09:41:13 sign · holder key · …A9F3 · nonce 7C3A

09:41:14 share → marketplace.virtengine.com

09:41:14 payload · 1 assertion · 0 personal fields

09:41:14 receipt.issued · expires 2026-10-19

tap a step above — or the button inside the app — to walk the flow

The wallet is a reference implementation — mobile/veid-capture-app/ in the protocol repository — and the consumer-facing identity programme is presented at identity.org.au.

Pipeline

From device to ledger

Six stages take a user from document capture to a consensus-committed trust score they can use across the marketplace.

Fig. 02 — the verification pipeline Six stages
fig 02 — capture → liveness → attestation → encryption → consensus scoring → zk tiers

Stage 01 — Capture

The VEID wallet captures identity documents on-device and runs OCR/checks locally. Original images stay on the user's device; the user reviews any derived data.

Stage 02 — Liveness

Active liveness challenges confirm a real, present human — not a photo, replay, or injection attack.

Stage 03 — Hardware attestation

Biometric hardware attestation (fingerprint or iris) plus device integrity checks — Play Integrity on Android, App Attest on iOS — bind the capture to trusted hardware.

Stage 04 — Encrypted submission

Only minimum derived fields or features separately approved by the user may enter an encrypted VEID scope. Original document images are never uploaded.

Stage 05 — Consensus scoring

Validators open the scopes only inside attested enclaves (x/enclave), score the evidence with shared machine-learning models, and commit an identity trust score to the ledger by consensus — the patented core of the protocol.

Stage 06 — ZK verification

Zero-knowledge proofs (x/veid/zk) let users prove facts about their verified identity — score thresholds, attributes — without revealing the underlying data.

Trusted processing · x/enclave

Scoring happens where no operator can look

Encrypted scopes are opened only inside hardware-sealed enclaves — confidential VMs whose attestation the chain verifies before any data is released to them.

The vault

A room built out of silicon

Scoring runs in confidential VMs — AMD SEV-SNP, Intel SGX or AWS Nitro — where the processor encrypts memory itself. There is no operator login, no debug console, and no memory dump: no access path exists for the provider hosting the hardware, the foundation, or anyone else.

The gate

Attestation before data

Before any scope is released, the enclave produces a hardware-signed measurement of the exact code it is running. The chain verifies it on-chain in x/enclave against the approved record. If a single byte of code were different, the measurement would not match — and no data would be sent.

The key

Forged inside the enclosure

The key that opens a scope is derived inside the hardware from the hardware's own secrets and sealed to that exact enclave (vTPM sealing). There is no key to hand over — not to an operator, not to a provider, not in response to a demand.

The three properties compound: there is no access path into the vault, the code inside is measured and attested before data arrives, and the key that opens a scope is sealed to that exact hardware. Original identity document images and full OCR output remain on the user's device. Only separately approved minimum derived fields/features and other consented evidence may be submitted for protected processing; the chain carries results and required references, never source document images.

The same machinery serves confidential workloads in the marketplace: attested enclave capability is a verifiable provider attribute, and tenant secrets are delivered only after attestation verifies — proof first, secrets second, enforced by protocol machinery rather than provider goodwill.

How trusted processing works x/enclave module x/encryption module
Leaves the enclave

Attestation records, a trust score, and pass/fail outcomes — written to chain state for verifiers and zero-knowledge proofs to build on.

Stays sealed

Only data separately submitted under an approved scope, and the hardware-sealed keys that protect it. Original document images and full OCR output remain on the user's device and never enter the enclave.

Attestation proves genuine hardware running exactly the approved code — nothing more. The other half is what that code does: verify, report, destroy. Both halves are open source.

Selective disclosure

What a verifier learns — and what it never sees

A zero-knowledge proof answers exactly one question. Pick a scenario to see the full accounting of what crosses the boundary.

The service asks: is this person over 18?

proof verified · expires in 24 h

Crosses the boundary

  • Over 18 — true — the age band, not the birth date
  • Proof is genuine — signed by the validator consensus result
  • Proof is unexpired — issued moments ago to this verifier
  • Bound to one purpose — not reusable by other services

Stays sealed on the device

  • Full name — never leaves the device
  • Date of birth — the exact date is not revealed
  • Address — not part of this scope
  • Document number — sealed on the handset

Threshold proofs are the smallest useful disclosure: one bit of truth, nothing attached.

The counterparty asks: does this account clear the trust threshold?

gating result · verified

Crosses the boundary

  • Trust score ≥ threshold — true — the score itself stays hidden
  • Account is VEID-verified — approved-clients-only upload path
  • Client signature valid — the chain's approved-client list applied
  • Bound to this lease — not replayable against other orders

Stays sealed on the device

  • The score value — hidden even from the counterparty
  • Original identity document images — remain on the user's device and are never uploaded
  • Biometrics and selfie — covered by their separate consent scope and notice
  • Location history — outside the scope of this proof

VEID can help assess counterparty risk. Providers may set a disclosed requirement for an individual offer; the marketplace does not require VEID for everyone.

The programme asks: is this operator resident in an accepted jurisdiction?

attribute proof · verified

Crosses the boundary

  • Residency attribute — accepted — jurisdiction class, not the address
  • Proof is unexpired — re-attested at the network's cadence
  • Issued to this programme — not a general disclosure
  • Threshold list applied — accepted jurisdictions are chain state

Stays sealed on the device

  • Exact address — sealed on the device
  • Tax identifiers — never part of an attribute proof
  • Original document images — remain on the user's device; only separately approved derived data may be processed by VEID
  • Other scopes — a proof covers exactly one question

Attribute proofs generalise the idea: any scope the network can verify can be proven without being shown.

Conventional verification

Hand over the document

A service photographs your ID, stores an archive it must then protect forever, and you lose track of which copies exist. Verification and data collection become the same act.

VEID verification

Hand over a proof

The network verifies once, by consensus, and you share proofs thereafter. The counterparty can check that a fact holds without ever receiving the data behind it.

Design principles

Privacy is the architecture, not a policy

x/encryption

Encrypted end to end

Raw identity data is never public on-chain. Scopes are public-key encrypted so only intended validator recipients can decrypt — in transit and at rest.

x/config

Approved clients only

Validators verify that uploads were produced by an approved client interface and signed by the user. The approved-client list is chain configuration, governed on-chain.

x/veid/zk

Selective disclosure

Zero-knowledge verification tiers mean a counterparty learns that your score clears a threshold or that an attribute holds — never the document, biometric, or score itself.

In the marketplace

Why a cloud marketplace needs identity

VEID is an optional, privacy-preserving trust signal in the marketplace. Where the deployed protocol and client support it, providers may choose whether a particular listing requires a defined VEID proof, and that requirement should be visible before an order. Tenants can choose listings that do not require VEID. Verification can help assess risk, but it does not guarantee that a provider, listing, hardware, or service is genuine. Sensitive transactions, including account recovery, are additionally protected by on-chain multi-factor authentication (x/mfa). Validators are compensated for identity work through governance-controlled, conservative network incentives.

The VEID wallet reference implementation lives in the protocol repository at mobile/veid-capture-app/. The consumer-facing identity programme is presented at identity.org.au.

The full VEID explainer x/veid module reference VEID source