I Built Trace to Understand What Avail DA Actually Guarantees

I built Trace to answer a question I had about Avail DA: once you hash a file, who gets to store the hash everyone will trust later?

Trace creates a SHA-256 fingerprint of a file inside your browser. The file never leaves your device. It publishes the fingerprint to Avail and gives you a receipt pointing to the exact transaction.

Later, someone can use the original file and the receipt to check whether the file has changed.

Why not use a database?

PostgreSQL could store every fingerprint and provide fast searches, easy updates, backups, and lower costs. It would also leave Trace (me) in control of the evidence. That is exactly what I do not want. Once the fingerprint has been published, the verifier should not have to trust me or my application.

If I can update the database, I can replace a fingerprint after the original registration. I can delete a record or change its timestamp. The verifier has no independent way to know whether I did.

The database shows what Trace says now. It cannot independently establish what Trace published earlier.

That matters when the publisher and verifier are different people:

• A company registers the final copy of a contract before sending it to several parties.
• An auditor publishes a report that will be downloaded from different websites.
• A software team registers a release before mirrors begin distributing it.
• A school registers a certificate that an employer may inspect years later.
• An organization publishes a policy and later needs to show which version was active.

Each case needs a shared reference that the publisher cannot quietly rewrite inside its own application.

Why Avail fits

Avail DA gives Trace a publication layer outside its database.

Trace submits the fingerprint under an App ID. Avail places the submission in a block, orders it with other transactions, and finalizes it. Trace then returns a receipt containing the exact block and transaction location.

Verification starts with that receipt. Trace retrieves the transaction and checks the network, block, finality, transaction, sender, App ID, execution result, and submitted data. Only then does it compare the registered fingerprint with a new fingerprint created from the local file.

The App ID keeps Trace data in its own namespace. It does not prove who submitted the data, so Trace checks the signing wallet separately.

Building Trace clarified the boundary for me: Avail publishes the data and makes it available, while the application decides what qualifies as a valid record.

Why Trace does not need a database

Trace uses a receipt-first design. The receipt points directly to an Avail transaction, so Trace does not need a database that maps files to records. The user keeps the receipt and presents it during verification.

The tradeoff is that Trace cannot search for a lost receipt.

I could add an index later to help users find possible records. It would remain a discovery tool, and every result would still have to pass the full Avail verification process.

Where RISC Zero fits

I have also worked with RISC Zero, which addresses another part of the trust problem.

RISC Zero can prove that a program ran correctly and produced a particular result. Avail can show that a value was published and made available.

Put plainly:

• A database tells you what value an application currently stores.
• Avail tells you what data was published to the network.
• RISC Zero tells you whether a computation produced its result correctly.

A RISC Zero proof could show that an agreed program produced a fingerprint. Avail could publish that fingerprint or proof so other people can retrieve it.

Trace does not need that combination yet. During verification, the user already provides the file, and the browser creates the fingerprint again. Adding a zero-knowledge proof would increase complexity without strengthening the comparison Trace currently performs.

The boundary

Trace V1 uses an Avail RPC to retrieve records. It is not light-client verified, so it still depends on that RPC for access to historical chain data.

Avail also cannot tell you whether a document is true, legal, or trustworthy. A matching fingerprint establishes one precise fact: the file being checked contains the same bytes as the file represented by the registered fingerprint.

That is the guarantee Trace V1 is designed to provide.