01

Abstract

TataTech is a trust registry for creators, studios and institutions. It turns a document or a digital presence into two things: a SHA-256 fingerprint that proves the record has not changed, and a short public code that anyone can look up without holding the original.

The blockchain whitelist extends that proof on chain. Approved members register a wallet against their member code, and the registry keeps a public, revocable list of those admissions. Nothing private is written to a chain. The whitelist publishes identity to wallet bindings, and the fingerprint stays the evidence.

02

The problem

Credentials are easy to fake and hard to check. A contract, licence or portfolio screenshot can be edited in seconds, and the person receiving it has no practical way to tell the copy from the original.

Blockchains solve settlement, not provenance of everyday documents. Writing a contract on chain is expensive and permanent, and it publishes information that should stay private. What the market actually needs is a cheap proof that a specific file existed in a specific state, plus a controlled way to bind that proof to a public identity.

  • Verification today depends on emailing the issuer and waiting.
  • Copies of copies lose every audit trail.
  • Wallet addresses alone say nothing about who is behind them.
03

How a record is sealed

Fingerprints are computed in the member's browser with the Web Crypto API. The file never leaves the device to be hashed, and the resulting digest is what gets stored. The same applies to a digital presence: the address is normalised and hashed, so the same claim always produces the same value.

The uploaded document is stored privately and is never published. Only the fingerprint, the title, the category and the verify code are public.

  • Hash: SHA-256 over the exact bytes of the file or the normalised address.
  • Code: a short public identifier, TT-XXXX-XXXX, derived from the record.
  • Storage: private object storage, reachable only through a short lived signed link.
  • Revocation: a record can be revoked by its owner or an administrator, and the reason stays on the public record.
04

The blockchain whitelist

The whitelist is the admission layer between a verified member and their wallet. A member submits a wallet address and the chain it belongs to. An administrator reviews the request against the member's tier and history, and either approves the listing or declines it with a reason.

An approved listing carries a whitelist code, for example TT-WL-4F9A-2B7C, and is published on the public whitelist page. Third parties can confirm that a wallet belongs to a named member code without asking TataTech, and without the member exposing any document.

  • Chains supported at launch: Ethereum, Base, Polygon, Arbitrum and Solana.
  • One member may hold several listings, one per wallet and chain pair.
  • Approval is revocable: a listing can be revoked without touching the member's sealed records.
  • Wallet addresses are public by design. Documents, files and contact details are never part of a listing.
05

Admission rules

Whitelisting is a trust decision, so the bar is deliberately simple to state and to audit. Every listing is reviewed by a person, and every decision is attached to the member code.

  • The member must hold an active membership record: Verified, Professional or Institution.
  • The wallet must be controlled by the member. TataTech may ask for a signed message from that address before approval.
  • Professional and Institution members may bind more wallets, in line with their plan limits.
  • Suspended or revoked memberships take their listings out of the public list automatically on the next review.
06

Membership and limits

Membership defines how much a member can seal, not how strong the proof is. Every fingerprint is computed the same way for every tier; tiers govern volume, placement and how many wallets can be admitted.

  • Verified: three fingerprints, one directory category, whitelist review on request.
  • Professional: twenty five fingerprints, preferred categories, multiple wallet bindings.
  • Institution: two hundred and fifty fingerprints, priority placement, bulk issuance and bulk whitelist review.
07

Verification protocol

A verifier has two routes to certainty. With the code alone they can open the public record and read the fingerprint, the issuer and the status. With the original file they can re-hash it in their own browser and compare the two digests directly.

Member releases follow the same idea. Media and documents issued to a member carry a unique code, and the code resolves only for the member it was issued to and for administrators. The file itself is delivered through a short lived signed link.

  • Code lookup: proves the record exists, who sealed it, and whether it is still active.
  • File comparison: proves the bytes are identical.
  • Release verification: proves a member is entitled to a specific media or document release.
  • Every check is read only and leaves no copy of the document behind.
08

Data protection

TataTech keeps the minimum on record. Fingerprints are one way functions, so a published digest does not reveal the contents of a document, and no document content is written to any chain.

Members can revoke a certificate or ask for a listing to be removed. Revocation keeps the audit trail visible while marking the record as no longer valid, which is the behaviour regulators and counterparties expect from a trust registry.

  • No document body, contact detail or private key is published.
  • Wallet addresses are published only while a listing is approved.
  • Private files are reachable through signed links that expire.
  • Access to member releases is enforced on the server, not in the interface.
09

Governance and roles

Members manage their own records: sealing, profile, membership, whitelist requests and releases. Administrators manage the platform: membership decisions, whitelist admission, release issuance and member status. No member can approve their own listing, and no listing enters the public register without an administrator decision.

10

Roadmap

  • Signed whitelist attestations: a counter signed statement per approved wallet.
  • On chain anchoring of the whitelist root, published on a public chain at a fixed interval.
  • Verifier API for institutions that need automated checks.
  • Portable release bundles for agencies issuing media to clients.

The registry stays useful only while it stays verifiable. Every addition is judged against one question: can an outsider check it without trusting us?

Next step

Seal a record, then request a wallet listing from your dashboard. Approved listings publish on the public whitelist with a code of their own.