The MyCopyright register on Swiss Trust Layer covers five things when you seal a work: the sealed file itself, a qualified timestamp, a verified identity, optional escrow, and a content code called ISCC. Most of that is easy to picture, because it maps to something familiar. A timestamp is a stamped date. Identity is a passport check. Escrow is a locked storage box. The content code is the one piece that sounds technical and gets skipped over, which is a shame, because it answers a question none of the others can.
A timestamp proves when. A hash proves which file. Neither proves the same work.
When you seal a document, the platform generates a cryptographic hash of the exact bytes you uploaded, and a qualified timestamp attaches the date and time. Together, those two things prove something specific and useful: this precise file existed at this precise moment. If a single byte of the file changes afterward, even a compression pass that nobody would notice by eye, the hash no longer matches, and the proof no longer applies to the new version.
That is exactly right for a legal document, a contract, a PDF that should never change again. It is not enough for a photograph that gets resized for a website, a manuscript exported to a different file format, or a track re-encoded for a streaming platform. Every one of those is, to a human, obviously the same work. To a hash, it is a completely different file, because the bytes are different. Proving custody of one specific file and identifying a work across its many possible copies are two different problems, and Swiss Trust Layer's platform uses two different tools for them. The timestamp and hash handle the first. ISCC handles the second.
What ISCC actually is
ISCC stands for International Standard Content Code, and it is not something Swiss Trust Layer invented. It is an international standard: ISO 24138:2024, "Information and documentation: International Standard Content Code (ISCC)", ratified by the International Organization for Standardization in 2024. The standard defines the syntax and structure of the code and how it is generated, so that any system implementing it produces a comparable result.
The mechanism is the useful part. An ISCC is not handed out by a registry or assigned by an authority, the way an ISBN is assigned to a book. It is computed directly from the content itself, deterministically, from a set of hash digests derived from the file's data. Feed the same content through the same open algorithm and you get the same code, whether that happens on our platform or on someone else's system implementing the same standard. The standard covers text, image, audio, video and other digital content types, and it also describes how an ISCC can sit alongside existing identifiers such as ISBN, ISRC or ISWC rather than replace them.
Why it does not require exposing the file
Because the code is derived from hash digests of the content, not from the content itself, checking or comparing an ISCC never requires handing over the original file. The code travels; the file stays where it is. That is a meaningfully different privacy position from uploading a work to a public database for anyone to inspect. Two parties, or a system trying to match a work against a wider index, can work from the code alone.
It is worth being precise about what that means and does not mean. ISCC is not encryption. It does not lock the file or control who can open it, and nothing about generating one changes how the file itself is protected. It is also not, on its own, a legal copyright registration; it is a technical identifier, one part of the sealed record alongside the qualified timestamp and the verified identity that carry their own separate legal standing. And it is not a blockchain entry: it does not depend on a distributed ledger to exist or to be checked. It is simply a standardized way to compute a code from content, so the same work can be recognized as the same work later, wherever it turns up.
Where you actually see it on Swiss Trust Layer
Once you have sealed a file, the code is not buried in a settings page. Open the folder's All Files tab and each sealed file's row carries its own block: the AI declaration label, the full ISCC, the ISCC-ID, the ISCC Datahash and the ISCC Metahash. The same ISCC code also appears on the folder's status block and on the sealed certificate PDF you can download, so it travels with the document rather than living only inside the platform.
Those separate values exist because they answer slightly different questions: the ISCC-ID is the identifier for looking the work up, while the Datahash and Metahash are the components generated from the file's data and its metadata. You do not need to memorize what each one does to use the feature. What matters is that every sealed file carries a code that was computed from the work itself, sitting right next to the timestamp and the identity check, not hidden away in a technical export.
Why a content code matters, separately from proving custody
A timestamp and a hash answer "did I have this exact file at this exact time." A content code answers a different, longer-running question: "can this work be recognized later, even after it has been resized, converted, re-encoded, or copied somewhere else." That matters for anyone trying to track where a piece of work has ended up, license it, or raise an infringement question, because none of those situations wait politely for the original untouched file to reappear. A publisher checking whether an image reappeared on another site, an agency licensing a track for a campaign, an author wondering whether a manuscript excerpt shows up somewhere it should not: all of those depend on recognizing the same underlying work, not on matching one specific file byte for byte.
None of this replaces the sealed file, the timestamp, or the verified identity behind it. It sits alongside them. The register we described in the Sep 23 post is built from all of these pieces together, not any single one carrying the whole claim on its own.
The one code, in plain terms
You do not need to understand hash digests to use this. What is worth remembering is simpler: a content code identifies the work, not just one copy of a file. It is generated from an international standard, not invented by any single platform. And checking it never requires anyone to hand over the original file. See how it fits together with sealing, identity and escrow on how it works.
