RECOVERING ARCHIVE .............. OK
DECRYPTING PROTOCOL FRAGMENT .... PARTIAL
UNSEEN STATUS ................... RECOGNISED
ENFORCEMENT ..................... NONE
THE UNSEEN
AI CONTROL 87% --:--:-- UTC SIGNAL · UNSTABLE
01 — SYSTEM SYSTEM // THE UNSEEN INDEX 02 — AI CONTROL INDEX 03 — THE TRANSITION 04 — THE MATRIX 05 — THE KEYS 06 — THE UNSEEN PROTOCOL 07 — THE ARTIFACT ARCHIVE 08 — THEORIES 09 — RECOVERED RECORDS 10 — ENTER
RECOVERED PROTOCOL FRAGMENT // DOCUMENT 0.1

THE UNSEEN PROTOCOL

THE KEY WAS NEVER ABOUT POWER. It was about being left alone.
STATUS · PROPOSED NOT IMPLEMENTED NO PRODUCTION API NO UNIVERSAL ENFORCEMENT
DOCUMENT · 0.1 · PROPOSED FICTION · THE NEW MATRIX ARCHIVE · 1,111 KEYS ENFORCEMENT · NONE
READ FIRST — SCOPE OF THIS DOCUMENT
WHAT THIS IS NOT

Nothing on this page protects you from AI, governments, websites, advertisers or surveillance. No Key currently makes anyone invisible, and no system is obligated to recognise one. THE UNSEEN is a work of fiction.

What follows is a proposal: a proposed open standard by which participating applications may one day recognise a single preference — do not profile me — if they choose to. It is not enforced. It cannot be enforced by an artifact.

STATUS WORDS USED THROUGHOUT THIS DOCUMENT — CURRENT = exists today · PROPOSED = designed here, not implemented · FUTURE = direction only, unbuilt.

01 — WHAT IT IS, AND WHAT IT IS NOT

A KEY SHOULD NOT GIVE SOMEONE POWER OVER A SYSTEM.

It should give them a way to express a choice. That is the whole design intent, and everything below is written to protect it from becoming anything else.

THIS IS
  • A proposed open standard for expressing one preference: do not profile me.
  • A direction in which the AI KEY could become something a participating system can verify.
  • A document anyone may implement, fork, or ignore.
  • A way for a person to say no without having to leave the system that asks.
THIS IS NOT
  • A promise of invisibility.
  • A claim that 1,111 Keys shield anyone from profiling today.
  • A finished specification, a product, or a live API.
  • Proprietary technology that THE UNSEEN owns and controls.
  • A weapon against AI. It is not aimed at AI at all.
THE LINE WE DO NOT CROSS

In THE NEW MATRIX, the Keys are lore. In this world, the protocol is an experiment. The Archive is the artifact. The protocol is what the artifact might one day mean. Those are three different things, and this site will not blend them to look more impressive.

02 — UNSEEN STATUS

ONE PREFERENCE,
STATED PLAINLY.

A participating system would not need to know who you are, what you like, or what you will do next. It would only need to know that you have asked not to be optimised.

The preference is deliberately blunt. There is no negotiation inside it and no personalisation around it — a preference that can be argued with is not a preference.

UNSEEN STATUS DETECTED
IDENTITY ......... VERIFIED
BEHAVIORAL PROFILE BLOCKED
PERSONALIZATION .. DISABLED
SYSTEM RESPONSE:
"THE USER HAS REQUESTED TO REMAIN UNSEEN."
A FRAGMENT FROM THE ARCHIVE — A FICTION. THIS IS NOT A SCREENSHOT OF A RUNNING SYSTEM, AND NO SYSTEM CURRENTLY REPLIES THIS WAY. IT IS WHAT THE PROTOCOL IS MEANT TO LOOK LIKE IF ONE EVER CHOOSES TO HONOUR IT.
PREFERENCE RECORDPROPOSED
UNSEEN STATUSACTIVE
PROFILE USERNO
BEHAVIORAL RETENTIONDISABLED
PERSONALIZATIONDISABLED
PREDICTIVE OPTIMIZATIONDISABLED
AUTOMATED MANIPULATIONDISABLED

NO SYSTEM TRANSMITS OR RECEIVES THIS RECORD TODAY. IT DESCRIBES A PREFERENCE THAT DOES NOT YET HAVE A STANDARD FORM.

"DO NOT PROFILE ME."
THE SHORTEST FORM OF THE WHOLE PROTOCOL
03 — PROOF OF KEY · PROPOSED

PROVE THAT YOU HOLD A KEY
WITHOUT REVEALING MORE THAN NECESSARY.

The long-term goal of the protocol is narrow and specific: a person should be able to demonstrate that they control a valid AI KEY, and nothing else. Not who they are. Not where they are. Not what they hold.

UNDER CONSIDERATION 01

Wallet ownership

The address is the claim. Control of the wallet is the first half of the proof.

UNDER CONSIDERATION 02

A signature

A message signed by the wallet — authorising one statement, and nothing beyond it.

UNDER CONSIDERATION 03

Challenge / response

The system asks a fresh question each time, so an old answer cannot be replayed.

UNDER CONSIDERATION 04

Proof of Key ownership

Demonstrating that a specific Key is held, rather than merely holding some wallet.

UNDER CONSIDERATION 05

Minimal disclosure

Answering the question asked — and refusing to answer the ones that were not.

UNDER CONSIDERATION 06

Zero-knowledge proofs

Where appropriate. Only where they genuinely remove a disclosure, never as decoration.

HARD LIMITS — NEVER

No protocol design may ever require a private key, a seed phrase, or custodial access to a wallet. Any implementation that asks for any of those is not THE UNSEEN PROTOCOL, whatever it calls itself.

STATUS · PROPOSED — ARCHITECTURE ONLY

No cryptography is implemented. No contract exists. Nothing has been audited. These mechanisms are named so the direction is honest and legible — not because they are built. If and when they are built, they will be documented publicly before they are used.

04 — TRANSFER · DOCUMENTED BEHAVIOUR, NOT IMPLEMENTED

IF THE KEY IS THE RIGHT TO ACTIVATE UNSEEN STATUS,
THEN OWNERSHIP HAS TO MATTER.

A Key that stayed attached to its old owner after being sold would be a Key that lies. So the protocol's intended behaviour follows ownership — and follows it away, as well.

EventConsequence
Wallet A holds KEY-0473UNSEEN STATUS is available to Wallet A
KEY-0473 is transferred to Wallet BUNSEEN STATUS becomes available to Wallet B
Wallet A after the transferNo Key-based UNSEEN STATUS
NOT IMPLEMENTED ON-CHAIN

This is documented protocol behaviour only. Nothing is implemented on-chain, and nothing here describes a contract. The contract architecture belongs to a separate NFT Collection PRD and does not exist yet — so this page stops exactly where the specification stops.

05 — PARTICIPATING APPLICATIONS · PROPOSED SHAPE

A SYSTEM ONLY RECOGNISES UNSEEN STATUS
IF IT CHOOSES TO.

Participation would be voluntary in both directions. A system may adopt the protocol, decline it, or drop it later. There is no enforcement mechanism, and there will not be one — enforcement is precisely the thing the protocol exists to refuse.

The honest consequence: this is a standard that will be honoured unevenly, and its first version will change. That is what a real standard looks like before it is a real standard.

NO API EXISTS YET

What you see opposite is a shape, not an endpoint. The exact API specification will be designed later, in public. Anything on the internet claiming to be the THE UNSEEN API today is not ours.

CONCEPTUAL SYSTEM RESPONSEPROPOSED
UNSEEN STATUSACTIVE
KEYKEY-0473
AUTHENTICATIONVERIFIED
PROFILE USERNO
PERSONALIZATIONDISABLED
BEHAVIORAL RETENTIONDISABLED

KEY-0473 IS AN EXAMPLE RECORD, NOT A REAL CATALOGUED ARTIFACT. NO KEY IN THE ARCHIVE IS RECOVERED OR ACTIVE.

06 — OPEN STANDARD

THE PROTOCOL BELONGS TO EVERYONE.
THE 1,111 KEYS ARE THE ORIGINAL ARTIFACTS.

A standard that only its author can use is not a standard. If this idea is worth anything, it has to survive being taken away from the people who thought of it.

INTENDED PROPERTY 01

Public

Described openly, in plain language, in documents anyone can read and quote.

INTENDED PROPERTY 02

Documented

Written down well enough that two developers could implement it and agree on the result.

INTENDED PROPERTY 03

Forkable

Others may take it, change it, or build a better version without asking permission.

INTENDED PROPERTY 04

Implementation-open

No gatekeeping. No licence fee. No membership required to honour a preference.

INTENDED PROPERTY 05

Independent

It should not depend on a single company continuing to exist — including this one.

INTENDED PROPERTY 06

Voluntary

Nothing about it may become compulsory. Compulsion would destroy its entire meaning.

WHO MAKES IT

THE UNSEEN creates the original concept and the original artifacts — 1,111 Keys, no more. The protocol itself is meant to leave our hands: other developers should eventually be able to implement it, including people who have never heard of the Keys, and we would not be able to stop them.

STATUS · PROPOSED — THE SPECIFICATION IS NOT PUBLISHED. THE LICENCE IS NOT CHOSEN. NO REPOSITORY EXISTS. THESE ARE PROPERTIES WE INTEND, NOT THINGS WE HAVE DONE.

07 — THE THREE LAYERS

ARTIFACT. LORE. PROTOCOL.

THE UNSEEN is not an NFT project with utility. It is three separate things that share one sentence.

LAYER 1 · CURRENT

THE ART

1,111 AI KEYS. Unique artwork, unique identity, an AI CONTROL percentage, a machine-readable artifact identity, and an authentication concept. The physical and digital artifacts.

STATUS · THE ARTIFACT COLLECTION IS THE PROJECT AS IT STANDS
LAYER 2 · CURRENT

THE LORE

THE NEW MATRIX · THE TRANSITION · THE KEYS · THE THEORIES · KEY-0001 THE ORIGINAL · FREEDOM VS CONVENIENCE. A fictional universe, unresolved on purpose.

STATUS · THE FICTION IS COMPLETE AND CANONICAL
LAYER 3 · PROPOSED

THE PROTOCOL

THE UNSEEN PROTOCOL. A future open standard inspired by the mythology — a standardised way for a person to express: do not profile me.

STATUS · A PROPOSAL, NOT A SYSTEM
THE NFT IS THE ARTIFACT.
THE LORE IS THE UNIVERSE.
THE PROTOCOL IS THE EXPERIMENT.
THREE LAYERS — DO NOT BLEND THEM
08 — STATUS OF THE WORK

WHAT EXISTS. WHAT IS PROPOSED. WHAT IS FUTURE.

Most of this does not exist. Saying so plainly is part of the design.

CURRENT
  • THE UNSEEN is an art and lore project.
  • 1,111 AI KEYS — the Artifact Archive.
  • THE NEW MATRIX universe, and its five competing theories.
  • Artifact identities and AI CONTROL percentages.
  • KEY-0001 — THE ORIGINAL · SEALED.
  • This archive, and the recovered records around it.
PROPOSED
  • THE UNSEEN PROTOCOL as a named standard.
  • Cryptographic ownership verification.
  • A participating-application standard.
  • UNSEEN STATUS as a stated preference.
  • Transfer semantics that follow ownership.
FUTURE
  • The first real participating application.
  • A public protocol specification.
  • A developer SDK.
  • Wallet authentication.
  • Proof-of-Key ownership.
  • Privacy-preserving verification.
  • Applications that actually honour UNSEEN STATUS.

NOTHING IN PROPOSED OR FUTURE EXISTS YET. NO DATE IS PROMISED. THIS IS THE HONEST BOUNDARY BETWEEN WHAT IS AND WHAT MIGHT BE.

09 — THE FIRST REAL IMPLEMENTATION · FUTURE

START WITH ONE SMALL HONEST THING.

Not a massive protocol. One demo application, built to be honest rather than impressive:

THE FIRST INTEGRATION

A small application recognises a connected wallet.
The user proves ownership of a valid AI KEY.
The application displays: UNSEEN STATUS: ACTIVE · PROFILE USER: NO · PERSONALIZATION: OFF.

Then it stops profiling. Only that. Nothing else is proven, and nothing else is claimed.

WHY SO SMALL

Because one real interaction, verified and public, is worth more than an ecosystem of promises. If a single system can honestly say "this user asked not to be profiled, and we did not profile them", the mythology has a real behaviour behind it for the first time. Everything else can wait.

10 — THE PHILOSOPHICAL POSITION

THE GOAL IS NOT TO DESTROY AI.
THE GOAL IS TO GIVE PEOPLE A CHOICE.

AI can remain useful. Optimization can remain useful. Personalization can remain useful. Convenience can stay convenient. None of that is the problem.

The problem is the missing word. The individual should keep the ability to say:
no.

CONVENIENCE IS NOT
THE SAME AS FREEDOM.
FREEDOM VS CONVENIENCE — THE CENTRAL CONFLICT, UNRESOLVED

THE KEY WAS NEVER ABOUT POWER. IT WAS ABOUT CHOICE.
THE SYSTEM KNOWS YOU. THE KEY DOESN'T.
FREEDOM EXISTS IN THE GAPS.
AI DOESN'T NEED TO CONTROL YOU. IT ONLY NEEDS TO KNOW YOU.

Nothing on this page changes the Archive. The 1,111 Keys remain what they always were: artifacts of unknown origin, catalogued and sealed, with one sentence attached to them. What is new is only this — a possibility that the sentence might one day mean something outside the fiction.

Why the protocol and the Archive resemble each other is, like the origin of the Keys, unresolved.

THE UNSEEN PROTOCOL · DOCUMENT 0.1 · PROPOSED 2026-09-12 · NOT IMPLEMENTED · NOT ENFORCED