Home
Home/How it works/Evidence Rooms
Ed25519 signaturesSHA-256 hashes8 SDKs
Status
Sign inStart free
Home
How it works · Evidence Rooms

How Evidence Rooms works.

Capital calls, wire instructions and closing documents, delivered exactly as sent, with signed proof of who opened what. This page covers the mechanism: what happens to a file, what is signed, and how someone outside your company checks it.

Product pageVerify a file
sha-256 · 3a352297…2592
sha-256 · ec878cd3…f328
The room's signed log, liveapp.invoance.com · no API needed
acme.com · room: Fund IV capital call 7Live
6 entries · no gaps, each chained to the one before
The path of a file
  1. 01 · Your browserSHA-256 of the fileAnchored in the document ledger before upload
  2. 02 · Before uploadAES-256-GCMFile and name encrypted, key locked per recipient
  3. 03 · InvoanceCiphertext + locked keysNo key that opens a file, no plaintext
  4. 04 · Their deviceDecrypt, hash, compareSaved only if it matches your fingerprint
  5. 05 · Room logSigned entryseq, prev_hash, Ed25519, exportable
Step by step
  1. The file is fingerprinted and encrypted in your browser

    Your browser computes the SHA-256 of the file and anchors it in the document ledger, then encrypts the file and its name with a key of its own. Only the encrypted copy is uploaded. Invoance receives the fingerprint and the ciphertext, not the file.

  2. The room key is locked for each recipient

    Each room has a key that unlocks its file keys. Your browser locks a copy of it for every recipient you name. The key that opens that copy travels in the recipient's link, after the #, which browsers never send to any server. Invoance stores the locked copies and no key that opens them.

  3. The recipient opens with an emailed code or a passkey

    The link opens a page on rooms.invoance.com that asks for a 6-digit code sent to the address you named. No account. On a later visit the recipient can use a passkey saved on their device, and a room can require one, so a code alone never opens it.

  4. Their device checks each download against the version sent

    The file is decrypted on the recipient's device, hashed again and compared with the fingerprint you anchored before it is saved. A copy with one changed byte does not match. Anyone holding a copy can run the same check on the file's public proof page.

  5. Every open, download and refusal is appended to the signed log

    Room created, file added, recipient added, link opened, file downloaded, access refused, access revoked, policy changed, key rotated. Each entry takes the next sequence number, carries the hash of the entry before it and is signed with your organization's Ed25519 key. The database refuses updates and deletes on the log.

  6. The evidence package is exported and checked offline

    One export per room holds every entry with its signature, every file fingerprint with its ledger anchor, the recipients and your public key, with instructions for checking it without Invoance. Entries about who could open the files, from the organization's own signed log, travel with it.

Technical facts
FingerprintSHA-256 of the file, computed in your browser and anchored in the document ledger before upload
EncryptionAES-256-GCM in the browser, one key per file, locked by the room key. The server holds ciphertext and hashes, no plaintext and no key that opens a file
Recipient keysThe room key is locked separately for each recipient. The link key lives in the URL fragment, which is not sent with any request
InvitationCopy the link and send it your own way, or email it through Invoance, which renders the link into the message and does not store it
OpeningA 6-digit code emailed to the named address, no account. Later visits can use a saved passkey. Wrong tries and resends are limited
Log entryseq without gaps per room, prev_hash of the entry before, the exact signed bytes, an Ed25519 signature from your organization's key
Policy per roomAccess window, allowed countries, passkey requirement. Outside it the server serves nothing: a refused download is logged, a refused link when the person asks the sender for access
Evidence packageEvery entry, every file hash with its anchor, the recipients and the public key. Checked offline
File sizeUp to 100 MB per file

How a third party verifies

Verification does not need an Invoance account or access to the room. The verifier checks the evidence package against your organization's public key, then hashes the copy of the file they hold and compares it with the fingerprint of the version sent. The public proof page runs the file check in the browser.

  1. 01 · AnyoneOpens the evidence packageExported from the room. No account, no access to Invoance
  2. 02 · LogChecks each signature and the chainEvery entry against your public key, every prev_hash against the entry before
  3. 03 · FileHashes the copy they holdSHA-256 against the fingerprint of the version sent. Match or no match

Check a file against the version sent.

Drop a copy on the public proof page. No account needed.

Verify a fileAll mechanisms

Verified documents and records. Invoance records the exact version of every invoice, report and notice your company sends, so the people who receive them can confirm they have the version you sent, without taking your word for it.

Products

  • Evidence Rooms
  • Audit Logs
  • Event Ledger
  • AI Attestation
  • Document Anchoring
  • Traces

Developers

  • Documentation
  • API reference
  • SDKs
  • How it works
  • How traces seal
  • System status

Verify

  • Audit Log
  • Event
  • AI Attestation
  • Document
  • Trace

Company

  • Company overview
  • What is Invoance
  • Pricing
  • Security
  • Compliance teams
  • Finance teams
  • Partners
  • Brand assets
  • Resources
  • Help center
  • Contact
© 2025 – 2026 Invoance, Inc. All rights reserved.© 2026 Invoance, Inc. All rights reserved.
PrivacyLegal noticeLegal FAQ