VeriphyVERIPHY
DEFI ORACLES PROOF OF RESERVES ACCOUNT OWNERSHIP AI DATA PROVENANCE COMPLIANCE & AUDIT CREDIT CLAIMS SUPPLY SIGNALS DEFI ORACLES PROOF OF RESERVES ACCOUNT OWNERSHIP AI DATA PROVENANCE COMPLIANCE & AUDIT CREDIT CLAIMS SUPPLY SIGNALS

Proof you can
verify,
not trust.

what veriphy does

It turns the real screen of a live mobile app into a cryptographically verifiable claim. A local vision-language agent reads the UI and seals it into a proof-bundle with a device-bound signature and freshness proof — and raw data never leaves the device.

6.2K
proofs sealed
9
active nodes
1.84s
verify median
01the problem

The internet runs on apps.
Almost none of it is verifiable.

As everything scales, synthetic and processed data blends with authentic sources — usually with no clear provenance back to the origin. Trust is assumed; it is rarely proven.

TODAY

Oracles relay APIs

Most oracles just paraphrase an API response — not what the user actually sees in the app. Along the way data is cropped, reworded, mixed with noise and reposted without provenance.

THE GAP

Trust ≠ verification

Cryptography was built for continuous verification, yet in practice it protects the infrastructure layer — not the consumer-facing state people rely on every day.

VERIPHY

Capture provable state

We move from blindly relaying data to capturing a provable state transition — sealed at the UI of a real device, signed, time-bound, and independently checkable.

trust model

Trust comes from verifiable state transitions — not from the reputation of an operator.

// the team only defines task formats
// devices execute scenarios autonomously
// bundles are generated & signed by the system
02the pipeline

From real execution to sealed proof.

Raw app detail never leaves the device. Only verified proof-bundles cross the boundary.

01

Task format

A node receives a task definition — “verify state X in app Y”. The protocol only defines formats; it never touches execution or results.

NODE · TASK
task: { app: 'Revolut', assert: 'balance.gt', tier: 'anchored' }
live · proof-bundle builder

Watch a bundle seal in real time.

The local agent reads the UI, extracts a typed claim, signs it with the device key, binds a freshness watermark and selective reveal — then seals an independently verifiable proof-bundle. Raw data never leaves the device.

proof-bundle.builder
● LIVE
CLAIM · REVOLUT
balance > $10,000
·
VLM reads UI layer
screen → structured state
2
claim extracted
balance.gt · selective
3
device key signs
secp256r1 · TEE-bound
4
freshness watermark
run · seen · captured
5
selective reveal
predicate, not value
6
anchored to registry
tier · ANCHORED
bundle0x0000000000000000000000000000000000000000BUILDING…
03live network

The network is running.

A live, node-powered mesh of devices sealing proof-bundles right now. State persists — these counters never reset.

CONNECTING…
proofs sealed
6,200
+150 today
active nodes
9
of 14 registered
claims verified
5.8K
372 challenged
network uptime
23d 0h
median 1.84s verify
verification tiers · distributionanchor rate 16.0%
liveness · 2.8Ksigned · 2.5Kanchored · 930
PROOF-BUNDLE FEEDnewest first
TOP NODES · STANDING0 shown
04verification tiers

Pick your depth of proof.

Different scenarios need different guarantees. The buyer chooses a tier to match their risk model — verification is always independent, trust is never assumed by default.

T1

Liveness

Analytics · dashboards

A lightweight liveness check — proof a real run happened on a real device.

  • Liveness guarantee
  • Execution metadata
  • Run watermark
MOST USED
T2

Signed

Oracles · ownership

Device-bound signature plus authenticity proofs. The default for on-chain consumption.

  • Everything in Liveness
  • Device-bound signature
  • Authenticity proofs
  • Freshness binding
T3

Anchored

Compliance · legal · audit

Anchored to an open attestation registry — immutable timestamps and full composability.

  • Everything in Signed
  • Registry anchoring
  • Immutable timestamp
  • Composable proof
05selective reveal

Prove the fact. Hide the number.

Built-in selective disclosure lets a node prove “balance exceeds $10,000” without ever exposing the exact figure. Full integrity, full privacy, fully checkable.

on device · privatenever transmitted
Revolut · available balance
$48,210.74
raw_state = { balance: 4821074, ccy: "USD" }
// stays inside the device — isolated
verifier receives · publicindependently checkable
proof predicate
balance > $10,000
claim: balance.gt
reveals: predicate only
value: withheld · zero-knowledge
verify(bundle): true
The verifier learns the fact is true — and nothing more.
06use cases

Where provable state matters.

Anywhere trust is currently assumed about what an app shows — Veriphy replaces the assumption with a proof.

DEFI

DeFi-adjacent oracles

Verifiable signals only visible inside an app — retail prices, availability, configs — turned into provable claims.

RESERVES

Reserves & balances

After FTX, transparency isn't a slogan. On-device checks emit a claim when a balance clears a threshold — exact sums stay hidden.

OWNERSHIP

Account ownership

Control is usually guessed via OAuth. Here it's a claim, backed by crypto. Credentials are never revealed.

AI DATA

AI training provenance

Quality tracks origin. Veriphy captures the run as it happens — bound to device and time, attached at the start, not backfilled.

COMPLIANCE

Compliance & audit

Screenshots aren't enough. A verifiable bundle shows when, where, what and how — built for rigorous independent review.

CREDIT

Credit-relevant claims

Narrow assertions without full disclosure: “account age over threshold”, “no recent overdrafts”, “status in good standing”.

MARKETS

Market & supply signals

Listings, prices, stock indicators — captured as verifiable claims without depending on API access.

07proof-bundle anatomy

What's inside a proof-bundle.

Verification doesn't depend on trusting Veriphy — it rests on the artifacts below, each independently checkable.

proof-bundle.jsonSEALED
{
claim:{ type: "balance.gt", predicate: "> $10,000" }
reveal:"selective" · value withheld
device_sig:secp256r1 · 0x9f3a…e1c7
attestation:key registered · standing 96.4
freshness:{ run, seen, captured } · nonce
metadata:{ os: "Android 14", device: "Pixel 8" }
anchor:registry://attest/0x44b2… (optional)
verify:→ true // no operator trust
}
09

Device attestation

Each device mints a cryptographic identity on the spot; its public key is registered and proofs are signed locally. Standing accrues over time.

10

Freshness proof

A watermark binds run-instant, seen-condition and captured result — preventing replay and pinning the exact moment the data was valid.

11

Authenticity proofs

When it matters, prove the data source and server authenticity, hide sensitive parts, and stay independently checkable — no special server cooperation.

12

Anchoring

Optionally bind the bundle to an open attestation registry for immutable timestamps, public verifiability and composability.

what sets veriphy apart
01

App-layer capture

Data is read from the same UI a real user sees — not an API.

02

Data isolation

Raw data never leaves the device; only proof-bundles do.

03

Independent verification

No trust in the operator required.

04

Flexible proof depth

Tiers match your risk model.

05

Privacy by default

Selective reveal instead of a full data dump.

Veriphy

Stop trusting.
Start verifying.

Run a node, generate proof-bundles, and earn standing on a network where truth is cryptographic — not reputational.