ProofWork — Cryptographic Proof-of-Work Verification

The Problem

Service work runs on trust. Trust breaks.

Every dispute between a worker and a client comes down to one thing: there is no proof. This application changes that with mathematics, not promises.

Without ProofWork

x"You did not complete the job."

x"You were only here for twenty minutes."

x"That damage was already there when you left."

x"I am not paying. I have no way to verify anything."

xNo legal recourse. No evidence. No protection for either side.

With ProofWork

+Cryptographic before and after proof of work completed.

+External TSA timestamp anchor, independently verifiable, legally defensible.

+GPS coordinates proving physical presence during the work window.

+Client verifies everything locally on their own device, no backend trust required.

+Tamper detection catches any modification to any part of the proof, instantly.

Workflow

Two sides. One proof.

The worker captures and signs. The client verifies locally. The cryptography does not lie.

Worker Flow

Open the App and Select Role

Tap "Proceed Ahead", then select "I am a Worker" to begin a new capture session.

Configure the Time Session

Set a work window of 1 to 10 minutes. This defines the minimum session duration that gets cryptographically anchored. It cannot be skipped.

Capture the Before Photo

Document the starting condition. GPS coordinates and device metadata are captured automatically alongside the image.

SHA-256 hashed from raw image bytes

Complete the Work

The job is done during the active session window. The timer runs. There is no way to advance it.

Capture the After Photo

Document the finished state. GPS and metadata are recorded again for the end location.

SHA-256 hashed from raw image bytes

Proof Generation (5 to 7 seconds)

The app canonicalizes all proof data, signs it with the worker's Ed25519 private key, and anchors the timestamp to the external TSA server. A hash chain is assembled linking every component of the proof.

Ed25519 + RFC 3161 TSA (freetsa)

Receive the Verification Code

A unique 10-digit code is generated and linked to the signed proof. Share it with the client directly or via the built-in QR code.

Expires after 24 hours

Client Flow

Open the App and Select Role

Select "I am a Client". No account or registration of any kind required.

Enter the Verification Code

Type the 10-digit code received from the worker, or scan the shared QR code directly.

QR scanner supported

Local Signature Verification

The app fetches the signed proof and verifies the Ed25519 signature locally on the client's device. No trust in the backend is required or assumed at any point in this step.

Zero-trust — runs entirely on device

View the Full Proof

If valid and within the 24-hour window, the client sees timestamps, cryptographic hashes, GPS data, worker ID, proof ID, and the full integrity status.

Ephemeral Memory Sandbox

All data viewed on the client side runs in an isolated in-memory sandbox. It never touches persistent storage on the device. The moment the client exits the verification screen, all data is immediately and completely destroyed.

Zero data retention

Under the Hood

What happens during proof generation

High-level logic only. No proprietary implementation details are disclosed.

proof_generation.pseudo
FUNCTION generateProof(beforePhoto, afterPhoto, session):

  // Step 1 — Hash actual image bytes, not file paths or URIs
  beforeHash = SHA256( readBytes(beforePhoto) )
  afterHash  = SHA256( readBytes(afterPhoto) )

  // Step 2 — Bundle all proof components
  proofData = {
    beforeHash,  afterHash,
    gpsStart:    session.gpsStart,    // lat, lng, accuracy in metres
    gpsEnd:      session.gpsEnd,
    timeStart:   session.startTime,
    timeEnd:     session.endTime,
    deviceMeta:  getDeviceInfo(),
    auditTrail:  session.auditLog
  }

  // Step 3 — Sign with the worker's Ed25519 private key
  canonical = canonicalize(proofData)
  signature = Ed25519Sign(workerPrivateKey, SHA256(canonical))

  // Step 4 — Anchor to external TSA (RFC 3161 / freetsa)
  tsaToken  = requestTSA("freetsa", SHA256(canonical))

  // Step 5 — Assemble final proof with immutable key versioning
  proof = { proofData, signature, tsaToken, workerKeyId }

  // Step 6 — Generate Fireflower visual fingerprint from proof hash
  fireflower = generateFireflower(afterHash)

  // Step 7 — Link to 10-digit code, store with 24-hour expiry
  code = generateCode()
  storeProof(code, proof)

  RETURN code

client_verification.pseudo
FUNCTION verifyProof(code):

  // Step 1 — Fetch the signed proof
  signedProof = fetchProof(code)
  IF expired OR not_found  RETURN ERROR

  // Step 2 — Fetch the exact public key that signed this proof (by key_id)
  workerPublicKey = fetchPublicKey(signedProof.workerKeyId)

  // Step 3 — Verify the Ed25519 signature locally on the client device
  isValid = Ed25519Verify(
    workerPublicKey,
    signedProof.signature,
    SHA256(signedProof.proofData)
  )

  IF isValid  status = "VERIFIED"
  ELSE        status = "TAMPERED"    // any data change invalidates this

  // Step 4 — Render in ephemeral sandbox, destroy everything on exit
  renderInSandbox(signedProof, status)
  destroyOnExit()

Cryptographic Architecture

Every design decision has a reason.

The cryptographic stack was not chosen for its names. Each component solves a specific and concrete trust problem.

Digital Signatures

Ed25519

Every proof is signed with the worker's Ed25519 private key immediately after capture. Any modification to any field, whether a single GPS digit, a pixel in a photo, or a timestamp, invalidates the signature and the proof is immediately flagged as tampered. Immutable key versioning (key_id-based) ensures that old proofs remain permanently verifiable even after a device change or reinstall. Old keys are never overwritten. They are appended, and each proof records the exact key that signed it.

64-byte signatures · deterministic · equivalent to 3072-bit RSA security · key_id versioning

Timestamp Anchoring

RFC 3161 TSA

Proof timestamps are anchored to freetsa, an independent third-party timestamp authority compliant with RFC 3161. This means neither the application, the worker, nor the backend server can alter or fabricate the time a proof was created. The TSA token is embedded in the proof and independently verifiable by any party with access to the standard. This is what makes proofs legally defensible.

freetsa · RFC 3161 compliant · independent third-party · court-admissible

Image Hashing

SHA-256 on Raw Bytes

Photos are hashed from their actual binary content read directly from disk, not from a file path or URI string. This means two photos at the same file path with different content produce different hashes. Any edit to a photo after capture, including compression, cropping, or pixel-level changes, produces a completely different hash and breaks the Ed25519 signature. Proofs generated with the earlier URI-based hashing method are treated as legacy and should be regenerated.

reads raw image bytes via expo-file-system · not URI-based · any change detected

Visual Fingerprint

Fireflower

A deterministic visual fingerprint generated from the proof's cryptographic hash. Each proof produces a visually unique image derived entirely from its data state. If any field is altered, the Fireflower changes completely. This provides an instant visual signal that something has changed before a user even examines the raw hash values. It appears in the worker's proof list and in the full proof detail view.

derived from afterHash · deterministic output · unique per proof state

Tamper Detection

VERIFIED versus TAMPERED

Original ProofVERIFIED

beforeHash:
a3f8c2d14e90b5671c3a8f20e49d...

afterHash:
9d72e1f045cb38a6b2d71c930a8...

signature check:
PASS — data matches signed state

The Ed25519 signature is valid. TSA timestamp confirmed. All GPS coordinates and hashes match the signed proof exactly. No modifications detected anywhere in the proof chain.

After Photo ModifiedTAMPERED

beforeHash:
a3f8c2d14e90b5671c3a8f20e49d...

afterHash (photo edited):
9d72e1f045cb38a6b2d71c930a8...
f1c90a3d72e81b4506fda2c771b...

signature check:
FAIL — hash mismatch detected

A single pixel change in the after photo produces a completely different SHA-256 hash. The Ed25519 signature no longer corresponds to the current data. The proof is immediately and permanently flagged as tampered.

Proof Contents

Everything in the Proofs tab.

Every piece of data visible when a worker opens a completed proof. All of it is part of the signed, tamper-evident record.

Before and After Images

Full resolution photos with thumbnail preview in the proof list. Verification status is shown inline. All images are cryptographically hashed and stored asynchronously.

Fireflower Fingerprint

Deterministic visual fingerprint derived from the proof hash. Unique to each proof state. Changes completely if any proof data is altered.

Verification Code

The unique 10-digit code tied to this signed proof. Shareable directly or via QR code. Valid for 24 hours from the moment of generation.

Integrity Status

Real-time VERIFIED or TAMPERED indicator based on live Ed25519 signature validation. Binary output. No ambiguity.

GPS Coordinates

Precise latitude and longitude for both before and after photo locations, with accuracy reported in plus or minus metres for each reading.

Distance Between Photos

Automatically calculated distance between the before and after GPS locations. Useful for verifying work completed across a defined area.

Time Analysis

Work start time, work end time, and the computed work window duration. All timestamps are cryptographically anchored via the external TSA server.

External Timestamp Anchor

Full TSA token data from freetsa. RFC 3161 compliant. Independent, third-party verifiable proof of when the session occurred.

Device Metadata

Device name, platform, and cryptographic algorithm used. Logged as part of the signed proof data for full traceability and audit purposes.

Technical Hash Details

Before hash, after hash, and proof hash displayed in full. The proof hash and the hash shown beneath the Fireflower image are identical by design.

AI Narrative

An AI-generated contextual description of the before and after images. A human-readable account of what work was performed, derived from the photo pair.

Audit Trail

Complete session history including cancelled sessions and any tampering events. If a "cancel before photo" action occurred, it is recorded here. Fully exportable for legal or compliance use.

Export Capabilities

Take the proof anywhere.

Every proof can be exported in multiple formats for legal, operational, or record-keeping purposes.

JSON Report PDF Report Legal JSON Evidence Legal PDF Evidence Audit Trail Export Share Verification Code QR Code Share

Demo Videos

See it in action.

Two real captures. One clean. One tampered. Watch how the cryptographic layer catches the difference the moment a client enters the verification code.

What this demo covers

Complete worker-to-client flow. Session setup, before photo, time window, after photo, 5 to 7 second proof generation, code output, and full client-side verification. The proof passes the Ed25519 signature check. All fields display correctly. Integrity status shows VERIFIED.

What this demo covers

A proof where the after photo is modified after capture. The SHA-256 hash of the modified image no longer matches what was signed with Ed25519. When the client enters the verification code, the signature check fails and the proof is flagged as TAMPERED. The Fireflower visual fingerprint also changes, providing immediate visual confirmation that the proof state has been altered.

Who It Is For

Any service where proof of work matters.

Primarily for independent service workers and gig economy contractors who lack institutional backing and need to protect themselves — and for clients who want verifiable assurance without trusting anyone's word.

Cleaning Services

Residential, commercial, carpet cleaning. Before and after proof that the scope of work was completed.

Maintenance and Repair

HVAC, plumbing, electrical. Cryptographic evidence that the fault existed before arrival and the fix was applied.

Landscaping

Lawn care, tree work, snow removal. GPS-confirmed proof of work performed at the correct location.

Delivery and Logistics

Package condition documentation, GPS delivery confirmation, and proof of correct handoff.

Construction

Daily progress records, punch list items, warranty work. Timestamped evidence for every stage of a project.

Property Management

Move-in and move-out condition records. Maintenance completion documentation with full timestamp and GPS data.

Auto Detailing

Vehicle condition before and after service. Protection against false damage claims from either side.

Pest Control

Infestation severity before treatment. Post-treatment verification with signed, timestamped photo evidence.

Inspection Services

Building, safety, and quality control inspectors who require tamper-proof, legally admissible records.

Painting

Surface preparation, coverage quality, finished result. Full before and after documentation that is independently verifiable.

Technical Stack

Built from first principles.

Each choice in the stack was made to solve a specific problem, not to follow convention.

Cryptography

Ed25519

Fast, small, deterministic signatures. 64 bytes. High security margin. Same input always produces the same output.

Hashing

SHA-256

Applied directly to raw image bytes. Any pixel-level change to a photo produces a completely different hash value.

Timestamping

RFC 3161 TSA

External anchoring via freetsa. Independent of the application. Cannot be modified by any party after issuance.

Backend

Golang

Proof storage, code generation, and API endpoints. All cryptographic verification runs client-side.

terminal — client verify

$ ./verify --code 4829103756 Fetching signed proof from backend... Fetching public key [key_id: a3f8c2d1]... Running Ed25519 signature verification locally... Checking TSA token (freetsa · RFC 3161)... Validating SHA-256 image hashes against signed values... Verifying GPS coordinate integrity... + Signature valid + TSA timestamp confirmed + Image hashes match signed state + GPS coordinates intact STATUS: VERIFIED

Security Model

Zero-trust by design.

The client trusts the mathematics. Not the application, not the worker, and not the backend.

Architecture

Zero-Trust Verification

All signature verification executes locally on the client's device. The Ed25519 check runs before any proof data is rendered to the screen. If the backend is compromised, the cryptographic verification still passes or fails based on the original signed state. A compromised backend cannot produce a false VERIFIED result.

Key Management

Immutable Key Versioning

Every device reinstall or change generates a new key with a new key_id. Old keys are never overwritten. They are appended to an immutable record. Each proof stores the exact key_id that signed it, and verification fetches that specific key. Old proofs remain permanently verifiable and show an informational flag if the signing key was subsequently superseded. Cryptographic continuity is maintained across the full proof history.

Client Data

Ephemeral Memory Sandbox

The client-side proof view runs in an isolated in-memory sandbox. Proof data never touches persistent storage on the client device. When the user exits the verification screen, all data is immediately and completely destroyed. No recovery path exists and no data trail is left on the client device.

Code Expiry

24-Hour Window

Verification codes expire after 24 hours. This follows established best practices for short-lived tokens, reduces the attack surface for code interception, and balances security with the practical requirement of same-day job verification and client sign-off.

Work that's impossible to fake.