For the complete documentation index, see llms.txt. This page is also available as Markdown.

GGS-2: Gen6 Verification Standard

Stage: Draft (close to Finalize)

Definitions

Seal

A RealSeal record: the hash of a piece of content, anchored on the Gen6 chain and bound by signature to a Gen6 identity.

Signer

The Gen6 identity whose key produced the Seal. The Signer is the party who sealed the content. The Signer is not necessarily its author or creator.

Signing

Signing is the act of binding a piece of content to a Gen6 identity. The content is hashed and the hash is signed with the private key of the Signer's identity. The content itself is never altered and does not need to leave the Signer's control.

Anyone can check the result with the Signer's public key. Nobody can produce it without the Signer's private key.

Signing proves who signed and that the content is unaltered since. On its own it does not prove when. Time is proven only by Anchoring.

Anchoring

Anchoring is the act of recording the hash of signed content on the Gen6 blockchain. It adds what Signing alone cannot: a time that cannot be backdated and a record that cannot be removed.

Verification

Verification is a collaborative process where other community members help substantiate your claim to being human based on these observable qualities.

Gen6 uses the word in two distinct senses. They must not be mixed.

  • Identity Verification: the collaborative process where community members and device checks substantiate what an identity is (Human, Organization, Agent).

  • File Verification: a mathematical check that a file is bit-identical to content sealed through RealSeal. It involves no community, no governance and no waiting period.

Verifier

Anyone who holds a copy of the content and checks it against a Seal.

A Verifier needs no Gen6 account.

Verification technical requirements:

  • Signer's Gen6 public identity (handle or Gen6 address)

  • The data or respective representation of the data (ZK)

  • Finding the hash on Gen6 blockchain (WSS communication with the Gen6 blockchain)

Proof

A proof is a formal demonstration or argument that confirms a truth, validity or authenticity of a claim, action or identity. In the context of this system, it represents the evidence required to substantiate an entity's verification or identity change in a form of hash and on-chain governance data.

Human

While the nature of humanity can be deeply philosophical, for practical purposes in the Gen6 ecosystem we define a "human" as someone who manifests the at least average behavioral and physical states. Simply, have a human body and do good, then community members will help you proving you are worthy for the human title. If it proves to be required, we will elaborate more on this definition, but currently it seems just enough.

Humanity

Humanity in the context of this system refers to individuals within the ecosystem who have been verified as humans based on established standards.

AI

AI refers to any artificial intelligence system within the Gen6 ecosystem. It includes both machine-based systems and algorithms designed to interact with humans, perform tasks, or assist in decision-making processes.

Agent

An Agent refers to computer systems that performs actions autonomously, typically for operational purposes such as automated moderation or task execution. They (hopefully) operate in a regulated manner, assisting humans or organizations.

Bot

A bot is an automated program or system operating within the Gen6 ecosystem that interacts with users or performs functions without human intervention. Bots are just like AI, but more simple with a task-specific nature.

Organization

An organization refers to a group or entity within the Gen6 ecosystem that operates as a collective. It can include companies, associations, or groups with a verified presence within the system. Verification requires meeting community-driven standards, ensuring that the organization adheres to rules of conduct.

Proof of Humanity

Proof of Humanity is a concept designed to verify that an individual is indeed a human being and not an automated system, bot, or AI. A core component in the Gen6 ecosystem. Users who are proven to be Human will get a Verified badge on their Identity page that can be cryptographicly verified.

States of Identity

  1. Pseudo-anonymous account (Black)

  2. Verification in Progress (Silver)

  3. Verified:

    1. Human (Green)

    2. Organization (Gold)

    3. AI Agent (Verified Machine, Electric Blue)

  4. Banned from MW instance (Red)

Timeline of Verifications

Drastic identity changes (name/profile picture): 72 hours

Bio and link changes: Instant.

Deletion: immediate, see GDPR.

Standard Identity Verification Process

Verification for Humans

Requirements has two sides, one is on the community side and the other is device check.

User checks:

  • Meet online or in-person two already verified humans for verification

Device checks:

  1. HTTP and WSS request checks (eg. Anubis checking ip/no reguests/cookie/headers/etc)

  2. Device fingerprint (must be a legitimate-looking device, eg not headless browser, etc)

  3. Tarpit Test (must not fall into our tarpit, eg Nepenthes and anti-AI pits)

  4. Proof of Work (must pass the challenge calculation)

  5. User interaction (s/he needs to able to solve a challenge easy for a human, but hard for machine)

The system must not block legitimate privacy tools such as Tor Browser or such.

User Experience Flow:

  1. Identity creation (can be empty)

  2. Clicking on Request Humanity Check, QR code

  3. QR code is shown and scanned by humans to verify

Verification for Organizations

Organizations need to verify themselves through Gen6 Governance.

Verification for AI and Bots

No verification needed, the is the default category.

Identity changes after verification

It takes 24 hours to change the identity after verification. During that time anyone in the community can report suspicious activity and in case of fraud found, Gen6 Governance can take action.

Verification of Files

Scope

Applies to all content RealSeal can seal: documents, texts, URLs, any binary data.

Note for a URL: the Seal covers the URL string itself, not the page behind it.

What File Verification proves

  1. The content is unaltered, to the bit, since it was sealed.

  2. A specific Gen6 identity sealed it.

  3. The content existed no later than the anchored time.

What it does not prove

  • That the content is true or accurate.

  • That the content is human-made or that it is not AI-generated.

  • That the Signer created the content.

  • Anything about the content before it was sealed.

  • Anything about content with no Seal. An unsealed file is simply unsealed.

Signing Modes

RealSeal offers two modes. The Signer chooses the mode at the moment of signing in the Gen6 App. The default is Sign + Anchor.

1. Sign + Anchor (default)

  • The content is hashed, signed by the Signer's identity, and the hash is anchored on the Gen6 blockchain.

  • Requires GSX to pay for the on-chain anchoring.

  • Available to all users.

  • The result is a Seal.

2. Sign only

  • The content is hashed and signed by the Signer's identity. No on-chain record is created.

  • Requires no GSX.

  • Premium and Premium+ feature of the Gen6 App.

  • The signed file and its signature are hosted by Gen6 MW (Service Validator Storage).

  • The result is a Signature only, not a Seal.

  • This signature and its verification option can be also shared with others, similarly as with the anchored version.

What each mode proves

Claim
Sign + Anchor
Sign only

Content unaltered since signing

Yes

Yes

A specific Gen6 identity signed it

Yes

Yes

Content existed no later than a given time

Yes

No

Record cannot be removed or backdated

Yes

No

Verifiable without relying on Gen6 MW

Yes

No

Rules

  • The App must show the mode choice before signing and must state the difference in guarantee, not only the difference in cost.

  • A Signature must never be displayed as a Seal, and never as on-chain.

  • A Signature can be anchored later. The anchored time is then the time of anchoring, not the time of the original signature.

Procedure of anchored verification

  1. Take the exact file. Any re-encoding, compression, conversion or metadata change produces a different hash - this is why we always hash the exact file.

  2. Compute its BLAKE2 hash locally. The file must not leave the Verifier's device.

  3. Look the hash up in the dataRegistry pallet under the RealSeal project (ID 886).

  4. Verify the signature against the Signer's public key.

  5. Resolve the Signer's current State of Identity.

  6. Report the result.

Results

Checked against a specific Seal (public link or shared item):

  • Intact: hash matches, record is on-chain, signature is valid.

  • Altered: the file does not match this Seal.

  • Invalid: a record exists but the signature does not verify.

Checked by hash alone:

  • Sealed: one or more Seals exist for this exact content (multiple people signed the same data, but in case it is not just a single identity, this needs to indicated).

  • No Seal found: this exact content was never sealed or it was changed after sealing. The two cases cannot be told apart from the file alone. This result is neutral. It is not a failure and not a warning.

A result that is not confirmed on-chain must never be shown as Intact.

Signer state

The integrity result and the Signer's State of Identity are two separate facts and must be displayed separately, using the colours in States of Identity.

  • Green and Gold badges are verified identities and when a Seal is Verified, the respective signer's badge must be shown also.

  • A Seal from a Pseudo-anonymous account (Black) proves integrity from a non-verified account.

  • AI, Agents and Bots can also seal content (Blue Badge)

  • A Seal from a Banned identity (Red Badge) remains mathematically valid and is shown with that state.

Requirements

  • Verification requires no account, no fee and no API key.

  • Verification is read-only. It writes nothing on-chain and changes no record.

  • Verification is instant. No timeline or reporting window applies.

  • A Seal cannot be edited, backdated or removed. Deleting a document or making it private removes access to the stored copy, not the on-chain hash (Seal or "proof").

  • Every result must show in an advanced menu (collapsed by default): the hash, the hash algorithm, the Signer address, the Signer's State of Identity, the anchored time and the on-chain reference.

Last updated

Was this helpful?