# Gen6 Wiki This is the definitive resource for all information related to Gen6's community and our innovative verification, authentication, privacy and blockchain technologies. Within this platform you will find comprehensive insights into our ecosystem, key features and educational materials. For an in-depth exploration of our vision *"Get Real: Life in Gen6"*, technical architecture and strategic objectives, we invite you to review our [Whitepaper](https://uncertain-aqua-crawdad.myfilebase.com/ipfs/QmanQhSspYq4puqLVGLPn3FYMoyn7MXGi2LkohdLJWnZjE), offering a detailed understanding of the ecosystem. **Solutions of Gen6:** * Provenance, Verification & Content/Data Signing: RealSeal * Secure End-to-End Encryption: NCrypt * Gen6 Business Solutions: Gen6 Private Chains * Post-quantum signatures and encryption in MVP. **Install Gen6 App, use your GSX and enjoy reality:** * [Gen6 for Android](https://play.google.com/store/apps/details?id=com.gen6.app) ([install without Play Store](https://gen6.app/real-seal-public/Nr49SlUvs7griKyQ2REB7quNlZIEppe7idm1yUx2Fc7xtAah)) * [Gen6 for iPhone](https://apps.apple.com/ie/app/gen6/id6761100893) * [Gen6 for Laptop/Desktop](https://gen6.app/) Click "Next" to discover more about life within the Gen6 ecosystem and how our community thrives. # The Gen6 Story The beginning of the Gen6 Reality Platform. The story began in 2019, when our founder, *six / David Pethes*, started exploring the ideas that would later become the foundation of our ecosystem. The story started in hackerspaces - places built for curiosity, experimentation, open technology, and real builders. In Berlin, six first discovered Polkadot inside a hackerspace environment, where the ideas of decentralization, self-custody, validators and community-owned infrastructure began to shape his thinking. From there, the journey became global. Six became a world-travelling Polkadot Head Ambassador, helping build communities, organize events, connect builders and spread blockchain education across cities and ecosystems. During this period, **Gábor Bóvai** joined as a core partner, and we met some of the first developers who would later contribute to the vision. The path moved through places such as **Berlin, Budapest, Dubai, Amsterdam, Bali, Hong Kong, Thailand and New York.** Each step adding new experience, new partners and a deeper understanding of what the digital world was missing. Over time, one realization became clear: **blockchain alone was not enough**. The AI era was creating a new problem. Identity, content, documents, data and even reality itself were becoming easier to fake and harder to verify. That is why, together we founded the Gen6 Ecosystem. We did not build Gen6 to be just another blockchain project. We built it to become **proof infrastructure for the AI era:** a system that helps people, communities, businesses and institutions prove what is real. These pieces grew from the same mission: to make identity, content, signatures, communication, and data verifiable, secure, and privacy-first. The project’s own history slide already connects this evolution from hackerspaces into concrete Gen6 products such as RealSeal and NCrypt. We believe the internet is moving from: > ***“Trust me.”*** to: > ***“Prove it.”*** Gen6 is our answer to that future. From hackerspaces to global blockchain communities, from Polkadot ambassadorship to a full verification ecosystem, our mission has stayed focused: > **Help people and organizations prove what is real.** Read more by clicking Next to learn how we do it. # Proof of Reality Identity, Content & Verification in Gen6. With privacy in-built. Gen6 is built on a simple principle: **your identity and data needs to remain under your control**. In the Gen6 ecosystem, you create and manage your own identity through the keys you control. You do not depend on a centralized platform to define who you are. If the keys are not yours, the identity is not truly yours either. This approach protects both **privacy** and **personal freedom**. You decide what information you want to disclose, when to disclose it, and to whom. No forced KYC process is required to access the Gen6 ecosystem. At the same time, Gen6 allows you to prove ownership, authorship, or authenticity through your Gen6 identity — without needing to reveal your real-world identity publicly. In short: > **You can prove that something came from you, without exposing more than you choose.** ### Identity Verification in Gen6 Gen6 uses a decentralized verification model. Instead of relying on one central authority, Gen6 allows independent **Verification Experts** to review and approve verification requests. These experts help keep verified identities credible, trustworthy, and aligned with the standards of the ecosystem. Verification may be requested for different identity types: * **Green Badge** — Human identity * **Gold Badge** — Organization identity * **Blue Badge** — Machine or AI Agent identity When a verification request is submitted, it is reviewed by authorized Gen6 Verification Experts. Under the current setup, at least **two experts** must confirm a request before verification is granted. As the network grows, this threshold is expected to increase to make the system even stronger. Example of the verified Gen6 community identity, :
**List of current Gen6 Verification Experts (you can reach them through NCrypt):** * [g6A8CaEo9ECfnatQUvT8DWpXpXQo98jpBEeWoLCgo5PxtdJFU](https://gen6.app/identity/g6A8CaEo9ECfnatQUvT8DWpXpXQo98jpBEeWoLCgo5PxtdJFU) * [g68peU7NpHnfqCLp5zWrVPMppayr3oZ7fiWKYRrjq7A4PKrhz](https://gen6.app/identity/g68peU7NpHnfqCLp5zWrVPMppayr3oZ7fiWKYRrjq7A4PKrhz) * [g6CCJ4jjxqDVnbPaJBf1XAFcrbDfnEXotc8ganYHQnAQsPEtT](https://gen6.app/identity/g6CCJ4jjxqDVnbPaJBf1XAFcrbDfnEXotc8ganYHQnAQsPEtT) * [g69XYZrrDBR7TcfSVcV9uwG8Srh17BJV6KnyYXosKqCGcMvyK](https://gen6.app/identity/g69XYZrrDBR7TcfSVcV9uwG8Srh17BJV6KnyYXosKqCGcMvyK) * [g67iWtLRpUYcLssDr1SFDB3UiJS3SJYVHhnTpqbLS4XwJDpZg](https://gen6.app/identity/g67iWtLRpUYcLssDr1SFDB3UiJS3SJYVHhnTpqbLS4XwJDpZg) * [g6AkUS6zDbmnv1hjwmYT4vTqwg4XrFFKvJZsAL12w9WnJHrc1](https://gen6.app/identity/g6AkUS6zDbmnv1hjwmYT4vTqwg4XrFFKvJZsAL12w9WnJHrc1) * [g68KRNPD8uLmSgqijsWSXQZ1Totnt6MSKbW5SAzorjfZQnkfG](https://gen6.app/identity/g68KRNPD8uLmSgqijsWSXQZ1Totnt6MSKbW5SAzorjfZQnkfG) * [g693RVWSVSUfMAyhRCcntvkUt8CfYs2KibFAsN3J6rs5N2udk](https://gen6.app/identity/g693RVWSVSUfMAyhRCcntvkUt8CfYs2KibFAsN3J6rs5N2udk) Ask the Gen6 Verification Experts to verify you. Under the current setup, at least two experts must confirm your request, and this threshold is expected to increase as the network scales. ### RealSeal: Proving Authorship and Authenticity RealSeal is the Gen6 tool for proving that content, documents, statements, or digital messages are connected to a specific Gen6 identity. With RealSeal, you can create cryptographic proof that answers important questions: * Who signed this content? * Which Gen6 identity is connected to it? * Has the content been changed? * Can others independently verify it? This is especially important in the AI era, where images, videos, documents, voices, and messages can be generated or manipulated at scale. RealSeal helps move digital content from: > **“Trust me.”** to: > **“Verify it.”** Content signed with your identity key can be shared publicly and independently verified by others. To sign content, log in to **Gen6 Apps** and choose **RealSeal**. ### Content Verification Is Open and Free Verification in Gen6 is designed to be open and accessible. Anyone can verify Gen6 identities directly through the **Gen6 Blockchain**. This process does **not** require GSX. Likewise, anyone can verify signed content through the Gen6 Blockchain without needing GSX. This ensures that identity verification and content verification remain transparent, decentralized, and easy to access. Example: The following message was signed by Core Member **six**. Open the link and select **Verify** to confirm that the message was issued from six’s Gen6 identity: ### What Gen6 Delivers Gen6 combines public blockchain infrastructure, privacy-first identity, cryptographic proof, and user-friendly applications into one ecosystem. The goal is not only to store data on-chain. The goal is to make identity, content, communication, and digital actions **verifiable, secure, and privacy-preserving**. #### Reality, Authenticity and Privacy Gen6 is building a digital reality layer for the AI era. As artificial intelligence makes fake content, fake identities, and manipulated data easier to create, Gen6 gives users tools to prove what is real. Core capabilities include: * identity verification; * content authenticity; * cryptographic signing; * data integrity; * privacy-first disclosure; * encrypted communication; * decentralized verification. RealSeal provides tamper-resistant signing and authenticity proof. NCrypt adds encrypted communication. Gen6 Middleware helps ensure that only user-approved data is revealed, supporting privacy by design. #### Seamless Web2 to Web3 Integration Gen6 Middleware allows traditional systems to connect with decentralized applications without completely replacing existing infrastructure. This makes it easier for businesses, institutions, and developers to bring blockchain-based verification into real-world systems. Gen6 is designed to support practical adoption, not just technical experimentation. #### High-Throughput Infrastructure Gen6 uses an Enhanced Proof-of-Authority model designed for fast and efficient transactions with low computational overhead. This makes the ecosystem suitable for real-world use cases where speed, reliability, and operational efficiency matter. #### Governance and Expert System Gen6 is built around a decentralized governance and expert model. The ecosystem includes roles such as: * Experts; * Validators; * Agents; * Community contributors. This structure allows trusted participants to help shape the network, support verification, maintain infrastructure, and contribute to long-term ecosystem development. #### Enterprise-Level Support Gen6 is built for both individuals and organizations. Members of the Gen6 ecosystem receive support from a proactive team focused on professional onboarding, technical guidance, and real-world implementation. For businesses and institutions, Gen6 can support integrations involving identity, document signing, encrypted communication, IoT verification, supply-chain systems, and enterprise-grade proof infrastructure. *** ### In One Sentence > **Gen6 helps people, communities, businesses, and institutions prove what is real — while keeping identity, data, privacy and control in the hands of the user.** # Solutions 1. **Gen6 Me - Self-Sovereign Identity** Gen6 Me empowers users with self-sovereign identity management, giving them full control over their personal data. It uses GGS-1: the G6 Global Standard for Identity. Users can securely store and share verified identities and content while maintaining privacy. The platform allows individuals to verify each other, confirm their status as Gen6 Experts and combat deep-fakes. This ensures the authenticity of shared information and promotes trust in digital interactions. Gen6 Me is set to redefine digital identity by providing secure, decentralized, and verifiable solutions for personal and professional validation. 2. **Real Seal - Digital Statement and Document Signer**\ This solution allows users to digitally sign statements and documents, ensuring authenticity and eliminating the need for intermediaries. **RealSeal IoT** extends this feature to Internet of Things devices, creating new possibilities for secure, tamper-proof data verification. 3. **RealSeal IoT - Digital Statement Signer for IoT (Coming soon!)**\ This extends RealSeal to IoT devices, enabling them to securely sign and verify data, ensuring that the information from connected devices is trustworthy. 4. **NCrypt - Encrypted Communication (Coming soon!)**\ NCrypt provides secure, encrypted messaging, ensuring that communications are private, tamper-proof, and free from censorship. It uses Gen6 addresses and provides message send/read undisputability when consented. 5. **FONO - Gen6's Event Platform (Coming soon!)**\ The Gen6 Event Platform allows organizers to create custom-branded (whitelabel) event management solutions, including secure ticketing and participant verification through blockchain technology. 6. **G6 Tokenizer - Tokenize Real World Assets**\ G6 Tokenizer enables the creation of digital tokens that represent real-world assets, making it easy to trade or transfer ownership securely on the blockchain. # RealSeal Tool to prove reality. **RealSeal** is a blockchain-based digital statement signer that allows users to securely sign and verify documents or messages. By using cryptographic signatures, RealSeal ensures that the content has not been altered after it was signed. It provides a tamper-proof method of proving authenticity, enabling anyone to verify the integrity of a document or statement. This tool is ideal for use cases where trust and verification are critical, such as legal documents, contracts, or official statements. With **RealSeal**, there is no need for intermediaries, and the process is entirely decentralized, ensuring that the signed documents remain secure, transparent, and verifiable by anyone on the blockchain. ### Technical Data * Pallet used: dataRegistry * API used: Gen6 MW * Storage used: Gen6 MW or custom # RS Identity Permissioned Identity Management On-Chain **RS Identity** is RealSeal's identity layer, a powerful tool for managing self-sovereign and decentralized identities, whether for a human, a computer agent, or a collective of people. It allows users to control and verify their online presence securely, giving them full ownership of their digital identity. RS Identity enables access to services across both **Web2** and **Web3** platforms without compromising privacy or security. By leveraging blockchain technology, it ensures that identities are authenticated without relying on centralized authorities, giving users more control and trust over their personal data. It is built on GGS-1: the Gen6 Identity Standard. > ✅ **GDPR compliant.** Personal data is handled responsibly and in accordance with European data protection regulations. Users retain control over their data, including the right to request deletion or restriction of access, without compromising the integrity of the blockchain. In short, RS Identity makes identity management simple: secure, permissioned access to applications, while maintaining privacy and transparency. ### How Does It Work? * Built on **GGS-1** to ensure security and privacy * **GSX owners can create their own identity** — no central authority required * **Merkle Tree based identity hashes** are stored on the Gen6 public blockchain, without exposing any personal details * Identity data is stored behind **G6 Middleware instances**, protecting it from big data scanners, hackers and ill-intended users ### Privacy Levels Identity owners stay in control. You choose one of three privacy levels: * **Private** — the default. Only the Middleware provider and addresses you allow can see your identity. * **Community/Gen6** — all Gen6 community authenticated users can see the identity data. * **Public** — all identity data is publicly available. Ideal for influencers and public profiles. ### Where Your Data Is Stored * **G6 Middleware providers**, or * **Anyone you trust** — you can store your identity data wherever you want, while the proof stays on the Gen6 blockchain ### Technical Data * **Pallet used:** dataRegistry * **API used:** G6 MW * **Storage used:** G6 MW or custom # RS Integrity ### What Integrity Means Here Integrity, in RealSeal, is a precise and deliberately narrow claim: > **A piece of content signed through RealSeal has not changed — by even one bit — since the moment it was signed.** That is the whole guarantee. It is not a claim about whether the content is true, accurate, or created by a human. It is a claim about **sameness over time**, and it is provable by anyone, mathematically, without trusting Gen6 or the person who signed it. This narrowness is a feature. A guarantee that is precisely bounded is a guarantee that can actually be relied on in a dispute, an audit, or a court. A broader claim would be weaker, because it could not be proven. *** ### How Integrity Is Produced RealSeal establishes integrity in three steps. None of them require the content itself to leave the signer's control. **1. Hash — the content becomes a fingerprint** The file is passed through a cryptographic hash function (BLAKE2 / BLAKE3, or SHA-256), producing a fixed-length digest. Two properties matter: * **Deterministic** — the same file always produces the same digest. * **Avalanche effect** — changing a single bit anywhere in the file produces a completely different digest, not a similar one. A hash is one-way. The digest cannot be reversed to reconstruct the content. This is what allows a file to be proven unaltered without ever being published. **2. Sign — the fingerprint is bound to an identity** The digest is signed with the private key of a Gen6 self-sovereign identity (Ed25519 / sr25519). This binds two facts together inseparably: *this exact content* and *this specific identity*. Anyone can later verify the signature using the corresponding public key. Nobody can produce a valid signature without the private key. **3. Anchor — the record is written to the chain** The signed digest and its timestamp are recorded on the Gen6 blockchain, live on mainnet since January 2025 and maintained across 150+ independent validator nodes. Once anchored, the record cannot be edited, backdated, or removed — not by the signer, not by Gen6, not by any single party. The timestamp becomes as immutable as the digest it accompanies. *** ### What Integrity Guarantees A RealSeal record supports four claims, each provable independently: | Claim | What proves it | | --------------------------------------- | ---------------------------------------------------- | | **This content is unchanged** | Recomputed hash matches the anchored digest | | **This identity signed it** | Signature verifies against the identity's public key | | **It was signed at this time** | The anchored timestamp is immutable | | **Nobody has tampered with the record** | The chain record cannot be altered retroactively | Any alteration to the content — a changed pixel, an edited character, a re-encoded video, an adjusted number in a spreadsheet — breaks the hash match. Not subtly. Completely, and visibly. *** ### What Integrity Does Not Guarantee Stated plainly, because overclaiming here would undermine the entire value of the guarantee: * **RealSeal does not verify that a claim is true.** If someone signs a document stating something false, RealSeal proves that they signed *that document*, unaltered, at that time. It does not make the contents accurate. * **RealSeal does not detect deepfakes or AI-generated content.** Detection is a different technical discipline — pattern and artefact analysis on existing media — and is not a Gen6 capability. RealSeal proves that *signed* content is unaltered since signing. It has nothing to say about content that was never signed through Gen6. * **RealSeal does not establish what happened before signing.** Integrity begins at the moment of signature. What a file was, or was edited into, prior to that point is outside the guarantee. * **Absence of a RealSeal record is not evidence of anything.** Most content in the world is unsigned. An unsigned file is simply unsigned. The correct mental model: RealSeal is not a lie detector. It is a **tamper-evident seal**. It tells you with certainty whether the seal has been broken. *** ### Integrity Without Disclosure Because only the hash is anchored — never the content — RealSeal can prove integrity for material that stays entirely private. This matters in practice: * A confidential contract can be proven unaltered without its terms ever being published. * A medical or legal record can be verified without exposing its contents. * A company can prove it held a document on a given date without revealing what the document says. The proof lives on a public chain. The content does not have to. *** ### Integrity Over Time Integrity in RealSeal does not decay, expire, or require renewal. A conventional certificate must be reissued, a signing authority must stay in business, a verification server must remain online. A RealSeal proof depends on none of these. The record persists on a distributed chain maintained by independent validators — it does not depend on Gen6 continuing to exist, on any single company, or on any institution's records survival. This is what makes RealSeal usable for long-horizon purposes: archival records, evidence, institutional history, and any proof that must outlive the organisation that created it. For the long-term cryptographic durability of these proofs — including the migration path to post-quantum signature schemes — see **GGS-6: Post-Quantum Infrastructure**. *** ### Verification Is Permissionless Verification requires no account, no API key, no fee, and no request to Gen6. Anyone holding a copy of the content can: 1. Recompute its hash, 2. Compare that hash against the anchored record, 3. Verify the signature against the signing identity's public key. If the hashes match and the signature verifies, the content is provably unaltered since the anchored timestamp. If they do not match, it has been modified. There is no authority in the middle deciding the answer. This is the operating principle behind the Gen6 statement: *you do not have to trust us — you can verify it yourselves, independently.* *** ### Integrity in RealSeal IoT RealSeal IoT applies the same three-step guarantee to machine-generated data, with signing occurring at the point of capture rather than after the fact. A sensor reading — emissions, temperature, water quality, a production-line measurement — is hashed and signed at the moment it is recorded. From that point forward, the same integrity guarantee applies: the reading is provably unaltered since capture. The practical consequence is that a regulator, buyer, or auditor can verify field data without trusting the operator's internal record-keeping. The data does not become *correct* because it is signed; it becomes **unfalsifiable after the fact**, which removes an entire category of dispute from compliance and supply-chain reporting. *** ### Related Pages * **RealSeal** — product overview * **RealSeal IoT** — sensor and supply-chain data signing * **Identity** — the self-sovereign identity layer that signatures bind to * **GGS-6: Post-Quantum Infrastructure** — long-term cryptographic durability of RealSeal proofs # RS IoT Digital Statement Signer for IoT **RS IoT** extends the **RealSeal** technology to the world of Internet of Things (IoT) devices. It enables IoT devices to securely sign and verify the data they generate, ensuring that the information from these devices is authentic and has not been tampered with. By using cryptographic signatures, **RealSeal IoT** ensures that the data from sensors, machines, or other connected devices can be trusted and verified in real time. This is crucial in industries such as supply chain, healthcare, and smart cities, where the integrity of IoT data is vital for decision-making and automation. In essence, **RealSeal IoT** allows IoT devices to have a tamper-proof way of proving the authenticity of their data, making it more secure and trustworthy for users and systems that rely on this information. ### Technical Data * Pallet used: dataRegistry (IoT calls) * API used: Gen6 MW * Storage used: Gen6 MW or Custom # FONO Freedom for event attendees and organizers. FONO, the **Gen6 Event Platform** is a decentralized solution designed to revolutionize event management by offering secure, transparent, and tamper-proof ticketing and engagement features. It allows event organizers to create, manage, and verify events without relying on intermediaries, using blockchain technology for complete transparency. With **whitelabel options**, organizers can fully customize the platform to reflect their brand and event requirements. Key features include **proof-based ticketing**, which ensures tickets are unique, verifiable, and **fraud-proof**, and the **POAP system** for rewarding attendance. The platform also offers secure participant verification and tamper-proof event records, enhancing both user experience and event integrity. Coming in 2026: # NCrypt **NCrypt is Gen6's encryption layer.** It provides the key generation, key distribution, key exchange, and authenticated encryption that the rest of the Gen6 stack relies on whenever data must be readable by some parties and not others. Encrypted messaging is the most visible application of NCrypt — but it is an application of the layer, not the layer itself. Every Gen6 identity receives NCrypt keys at the moment its wallet is created, which means encryption capability is a property of the identity rather than a feature a user opts into later. ### The Layer NCrypt handles four things on behalf of the wider stack: **Key generation.** NCrypt keypairs are generated on the user's device at wallet creation, in seed-words format alongside the wallet keys. Private keys never leave the device and are never escrowed — Gen6 cannot recover a lost key because Gen6 never holds one. **Key distribution.** The NCrypt public key is published on the Gen6 chain and bound to the identity. This is what allows any party to encrypt data to any Gen6 identity without a prior handshake, an introduction, or a central directory. **Key exchange.** Establishes a shared secret between parties (currently X25519; migrating to hybrid X25519 + ML-KEM-768 — see below). **Authenticated encryption.** Encrypts the payload and authenticates its origin, so that content is both unreadable to outsiders and verifiably unmodified for the recipient. Because these are identity-level rather than app-level capabilities, anything in Gen6 that needs confidentiality or selective disclosure can build on NCrypt instead of implementing its own cryptography — which is the point of having an encryption layer at all. ### Messaging: the primary application NCrypt messaging is decentralized, end-to-end encrypted communication built directly on the layer above. **Only the intended recipient can read a message.** No Gen6 server, node operator, or intermediary can decrypt a conversation. **Messages cannot be altered undetected.** A modified message fails authentication rather than arriving silently changed. **Send and read events can be made indisputable.** Optionally, proof that a message was sent — and read — is anchored on the Gen6 chain. Neither party can later deny it, and no third party is needed to adjudicate. The *content* stays private while the *fact* of communication becomes provable. This is the property that distinguishes NCrypt from conventional encrypted messengers. **Notifications preserve privacy.** Message notifications never carry message content. ### What NCrypt Does Not Claim Stated precisely, because an overstated guarantee is a weaker one: * **Encrypted traffic can still be captured.** Encryption prevents data from being *read*, not from being *observed or recorded*. This is not academic — it is the entire basis of the "harvest now, decrypt later" threat driving the post-quantum roadmap below. The accurate claim is that captured traffic is unreadable, not that capture is impossible. * **Encryption does not conceal that communication occurred**, unless send/read anchoring is deliberately left unused. Content confidentiality and metadata minimisation are different properties. * **Key custody is the user's responsibility.** This is a deliberate design choice, and its cost is that key loss is unrecoverable. ### Technical Data **Infrastructure** | | | | ------- | -------------- | | Pallet | `postman` | | API | Gen6 MW | | Storage | IPFS or custom | **Cryptography (current)** | Function | Primitive | | ------------------ | -------------------------------- | | Key exchange | X25519 (Curve25519 ECDH) | | Authentication | Ed25519 (EdDSA) | | Payload encryption | ChaCha20-Poly1305 (256-bit AEAD) | **Key lifecycle** * Generated at **wallet creation**, seed-words format, on-device * Public key **published on the Gen6 chain**, bound to the identity * Private key never uploaded, escrowed, or recoverable by Gen6 *** ### Post-Quantum Roadmap X25519 and Ed25519 are both broken by a sufficiently capable quantum computer. ChaCha20-Poly1305 is not — at a 256-bit key it remains strong and is retained unchanged. **Because NCrypt is the encryption layer rather than a single feature, its post-quantum migration is the highest-priority work in the entire Gen6 stack.** Two reasons compound: 1. **Retroactive exposure.** Encrypted data captured today can be decrypted years from now. Signature forgery has no equivalent — a signature forged after the fact is worthless. Confidentiality is the only part of Gen6 where the quantum threat is active today rather than pending. 2. **Blast radius.** Anything in Gen6 that relies on NCrypt for confidentiality inherits its cryptographic posture. Migrating the layer migrates everything built on it; leaving it classical leaves all of it classical. Target: hybrid key exchange (X25519 + ML-KEM-768) with ML-DSA authentication, ChaCha20-Poly1305 retained. A working prototype of the post-quantum encryption path already runs at [pqc.gen6.life](https://pqc.gen6.life). ### Technical Data * Pallet used: postman * API used: Gen6 MW * Storage used: IPFS or custom # NC Post-Quantum Cryptography ### Why NCrypt Is High Priority in the Entire Gen6 Stack Across all of Gen6, NCrypt is the **only** component where the quantum threat is active today rather than pending. The reason is an asymmetry between confidentiality and authentication: | | Encryption (NCrypt key exchange) | Signatures (accounts, RealSeal, consensus) | | ---------------- | ------------------------------------- | ------------------------------------------ | | Attack | Record ciphertext now, decrypt later | Forge a signature | | When it pays off | Any time in the future | Only at the moment it is used | | Exposure today | **Active** | None | | Deadline | Already passed for long-lived secrets | Before quantum computers exist | An adversary can capture NCrypt traffic **today**, store it, and decrypt it years from now once a sufficiently capable quantum computer exists. This is **Harvest Now, Decrypt Later** (HNDL), and it means any message whose confidentiality must outlast the arrival of quantum computing is **already at risk** — regardless of when that arrival actually happens. A forged signature has no equivalent problem. Forging a validator signature or an account signature in 2035 is worthless, because the block was finalised and the transaction settled years earlier. As the Web3 Foundation researchers put it: for authentication, "you just need to be far enough ahead to rotate the key." **Consequence:** NCrypt key exchange is Phase 1 of the GGS-6 migration, ahead of every signature-related workstream. *** ### Current Cryptographic Layer | Function | Primitive | Quantum status | | --------------------- | -------------------------------- | ------------------------------ | | Key exchange | X25519 (Curve25519 ECDH) | **Broken by Shor's algorithm** | | Sender authentication | Ed25519 (EdDSA) | **Broken by Shor's algorithm** | | Payload encryption | ChaCha20-Poly1305 (256-bit AEAD) | Quantum-acceptable | The split is clean and worth stating precisely: **the public-key components are the entire problem.** ChaCha20-Poly1305 is not a concern — Grover's algorithm halves its effective security, leaving roughly 128-bit post-quantum strength at a 256-bit key, which remains strong. It is retained without modification. *** ### Target Cryptographic Layer | Function | Current | Post-quantum target | Standard | | --------------------- | ----------------- | ------------------------------- | -------- | | Key exchange | X25519 | **Hybrid: X25519 + ML-KEM-768** | FIPS 203 | | Sender authentication | Ed25519 | **ML-DSA (Dilithium)** | FIPS 204 | | Payload encryption | ChaCha20-Poly1305 | **Unchanged** | — | **ML-KEM-768** is the baseline parameter set (NIST Category 3, roughly AES-192-equivalent). ML-KEM-1024 remains available for high-assurance deployments. *** ### Why Hybrid, and Not Pure Post-Quantum NCrypt does **not** replace X25519. It runs X25519 and ML-KEM-768 **in parallel**, combining both shared secrets through a KDF so that the session remains secure if **either** primitive holds. The rationale is conservative and deliberate: * **ML-KEM is new.** It has received far less side-channel cryptanalysis than X25519, which has been under sustained attack for over a decade. * **A hybrid fails safely.** A flaw in the lattice scheme leaves X25519 protecting the session. A quantum computer defeating X25519 leaves ML-KEM protecting it. Both must break for the session to break. * **This is the field standard, not a Gen6 invention.** OpenSSH has shipped `mlkem768x25519-sha256` — the identical construction — as its **default** key exchange since version 10.0 (April 2025), and OpenSSH 10.1 warns on any connection not using a post-quantum KEX. Chrome and major TLS stacks deploy the same pairing. Pure post-quantum key exchange is deferred until ML-KEM side-channel analysis matures. Hybrid only, for now. *** ### Practical Impact: Sizes and Performance Post-quantum primitives are substantially larger than the elliptic-curve primitives they replace. For a messaging application this is a real engineering consideration, not a footnote. **Public keys (per identity, published on the Gen6 chain):** | | Current | Post-quantum | Increase | | ----------------------- | ------------- | ------------------------------------- | --------- | | Key-exchange public key | X25519: 32 B | ML-KEM-768: 1,184 B | \~37x | | Signing public key | Ed25519: 32 B | ML-DSA-65: 1,952 B | \~61x | | **Total per identity** | **64 B** | **\~3,168 B** (hybrid retains X25519) | **\~50x** | **Per-message overhead:** | | Current | Post-quantum | Increase | | ---------------- | ------------- | ------------------- | -------- | | KEM ciphertext | X25519: 32 B | ML-KEM-768: 1,088 B | \~34x | | Sender signature | Ed25519: 64 B | ML-DSA-65: 3,309 B | \~52x | **What this means in practice:** * **On-chain key storage grows materially.** NCrypt public keys are published on the Gen6 blockchain so that other users can initiate encrypted contact. A \~50x increase in per-identity key size across a growing user base is a storage and bandwidth planning item that must be sized before rollout, not discovered during it. * **Per-message overhead is the more visible cost.** A short text message currently carries under 100 bytes of cryptographic overhead. Post-migration it carries roughly 4.4 KB. For long-form messages this is negligible; for high-frequency short messages it is not. * **Payload encryption cost is unchanged.** ChaCha20-Poly1305 performance is unaffected, so the cost is in key establishment and signing, not in encrypting message bodies. These figures are the reason ML-KEM-768 (rather than 1024) and ML-DSA-65 are the baseline: they meet Category 3 security at the smallest practical size. *** ### Working Prototype: pqc.gen6.life A functioning post-quantum toolkit already exists and runs against the live Gen6 chain: [**pqc.gen6.life**](https://pqc.gen6.life). It is explicitly marked **in development and experimental**, and it is broader than NCrypt — it is a RealSeal Notary PQC prototype with an encryption module. But it matters here because **the ML-KEM encryption path described in this page is already implemented and working end to end.** #### What runs today The prototype is **entirely client-side**. Files and messages never leave the browser, and post-quantum keys are generated in-browser, held in memory only, never uploaded or auto-saved. | Function | What it does | Algorithms | | ------------ | ----------------------------------------------------------------------------------------------------- | --------------------------------------- | | **Notarize** | Hash a file locally, seal the digest on-chain | SHAKE256/256 → `dataRegistry.storeData` | | **Verify** | Recompute the hash, compare, optionally confirm the on-chain record in its block | SHAKE256 | | **Sign** | Generate a PQC keypair in-browser, sign a file's digest, anchor the signature hash on-chain | SLH-DSA (FIPS 205) | | **Encrypt** | Encapsulate a shared secret to a recipient's public key, encrypt the message, full decrypt round-trip | ML-KEM (FIPS 203) + AES-256-GCM | **Encryption module detail — directly relevant to NCrypt:** * ML-KEM parameter sets selectable: **ML-KEM-512, ML-KEM-768 (recommended), ML-KEM-1024** * Optional **encrypt-then-sign** — the ciphertext can be signed with SLH-DSA, giving authenticated encryption with a post-quantum signature * Exportable encrypted bundle, with decryption of bundles produced elsewhere * Verified round-trip: encrypt → export → import → decrypt This is a working demonstration that ML-KEM key establishment plus AEAD payload encryption functions correctly in a Gen6 context. The NCrypt Phase 1 work is therefore an integration and hardening task on a proven path, not a research question. #### Chain integration The prototype connects to the live node (`wss://gen6.app:443/node`) and submits real extrinsics through the existing `dataRegistry` pallet: ``` dataRegistry.storeData(project_id: u32, hash: H256) ``` Signing is delegated to the user's wallet extension — the page never sees the seed or account private key. #### Implementation * **SLH-DSA and ML-KEM:** `@noble/post-quantum` * **AES-256-GCM:** WebCrypto * **Key custody:** PQC keys are separate from the on-chain account key. Held in memory, exportable by the user. If lost they are unrecoverable; if leaked, another party can sign or decrypt as that identity. #### Known limitations — stated by the prototype itself These are real constraints, documented on the page, and each one is informative for the production migration: 1. **Not verifiable by standard Gen6 RealSeal apps.** The prototype hashes with **SHAKE256**, while production RealSeal uses BLAKE2b-256. On-chain records produced here are only verifiable through the prototype's own Verify tab. 2. **On-chain collision resistance is capped at \~128-bit.** The live `dataRegistry` pallet stores a fixed 32-byte `H256`, so the on-chain digest is SHAKE256/256. The full 512-bit SHAKE256 fingerprint is retained off-chain in the receipt. **Raising on-chain collision resistance requires the pallet to accept more than 32 bytes** — a runtime change, not a client-side one. 3. **Signatures are anchored, not stored.** SLH-DSA signatures are KB-scale, so the chain holds `storeData(projectId, SHAKE256(signature))` while the full signature stays in the downloadable receipt. This is the practical consequence of the size figures in the table above. 4. **The account signature remains classical.** Transactions are still signed sr25519/ed25519 by the wallet extension. The prototype demonstrates post-quantum content signing and encryption; it does not make the chain's own account layer post-quantum. That is GGS-6 Phase 2–3 work. #### Divergences from GGS-6 — to reconcile before production The prototype makes several algorithm choices that differ from this standard. None are errors in a prototype, but each needs an explicit decision before production: | Prototype | GGS-6 specifies | Note | | ----------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **SLH-DSA** as the signature | **ML-DSA (Dilithium)** as default; SLH-DSA reserved for long-lived/high-assurance | SLH-DSA signatures are 7.8–17 KB at the prototype's parameter sets vs \~3.3 KB for ML-DSA-65. The SHAKE pairing with SHAKE256 hashing is coherent, but the size cost is significant for routine signing. | | **SHAKE256** hashing | **BLAKE2/BLAKE3** (production RealSeal) | Deliberate in the prototype, but it is precisely why output is not cross-verifiable with production apps. | | **AES-256-GCM** payload | **ChaCha20-Poly1305** (NCrypt) | Reasonable for a browser context — AES-GCM is natively available in WebCrypto. NCrypt production retains ChaCha20-Poly1305. | | **Pure ML-KEM** encapsulation | **Hybrid X25519 + ML-KEM-768** | The prototype demonstrates the PQC half. Production NCrypt requires the hybrid construction, so classical and post-quantum secrets are KDF-combined. | The single most consequential of these is the **hybrid requirement**: a prototype may reasonably demonstrate ML-KEM alone, but production NCrypt must run X25519 in parallel so a flaw in either primitive does not break confidentiality. *** ### Migration Plan NCrypt migration is **Phase 1** of GGS-6, and is gated only by Phase 0 (crypto-agility refactor and inventory). #### Step 1 — Crypto-agility in the NCrypt layer Ensure key exchange, signing, and AEAD are reached through an abstraction with explicit algorithm identifiers, rather than X25519/Ed25519 being hard-coded at call sites. Nothing else can proceed cleanly until this exists. #### Step 2 — Wire format versioning Version the NCrypt message format so that the negotiated suite is **explicit and auditable** in every message. A verifier must be able to tell, without ambiguity, whether a given message was protected by hybrid or classical key exchange. #### Step 3 — Hybrid key exchange Implement X25519 + ML-KEM-768 in parallel with KDF combination. Use an audited library (liboqs, or a Rust PQC implementation with a public audit trail) — no hand-rolled lattice code reaches mainnet. #### Step 4 — Key generation at wallet creation NCrypt keys are generated at wallet creation, in seed-words format alongside the wallet keys. This flow must be extended to generate the post-quantum keypair at the same moment, so that a newly created identity is PQC-capable from its first message rather than requiring a later migration step. Existing identities require a key-rotation path: generate and publish a post-quantum NCrypt public key bound to the existing identity, then negotiate hybrid with any peer that supports it. #### Step 5 — Sender authentication migration Migrate NCrypt sender signatures from Ed25519 to ML-DSA. Lower urgency than key exchange (no HNDL exposure), but it aligns NCrypt with the account and RealSeal signature migration in GGS-6 Phase 2. #### Step 6 — Negotiation, fallback, and sunset Ship backward-compatible negotiation: hybrid where both peers support it, classical fallback only where a peer has not upgraded. Publish a **classical-only sunset date** in advance, and enforce it in Phase 4. Downgrade resistance must be explicitly tested — an attacker must not be able to force a classical-only session between two hybrid-capable peers. *** ### Backward Compatibility * **Existing messages remain readable.** Migration does not invalidate previously encrypted content for their intended recipients. * **Mixed-capability periods are expected.** Not every client updates simultaneously. Negotiation handles this, with the suite recorded explicitly per message. * **Classical fallback is temporary and dated.** It exists to avoid breaking communication during rollout, not as a permanent option. The sunset date is announced ahead of enforcement. *** ### What Does Not Change * **ChaCha20-Poly1305** remains the payload cipher. No migration required. * **Keys remain user-held.** Post-quantum migration does not alter NCrypt's custody model — private keys are generated on the user's device and are never held by Gen6. * **End-to-end property is preserved.** Hybrid key exchange changes how the session key is established, not who can read the message. No server sees plaintext before or after migration. *** ### Related Pages * **GGS-6: Post-Quantum Infrastructure** — the parent standard, covering the full Gen6 stack * **NCrypt** — product overview and encryption layer * **Integrity** — the RealSeal integrity guarantee and its own signature migration path * [**pqc.gen6.life**](https://pqc.gen6.life) — working experimental PQC prototype (notarize, verify, SLH-DSA signing, ML-KEM encryption) # Governance Decentralized, bi-camerial governance Gen6 is built on a [**decentralized governance model**](https://medium.com/@LifeInGen6/gen6s-two-chamber-governance-model-smarter-way-to-make-decisions-together-17eac60edf1e), empowering users and contributors to actively participate in shaping the platform's future. The **Gen6 Expert System** encourages collaboration within the community through roles like **Experts, Validators and Agents**. Read the full Gen6 Governance paper by Alexander Slesarev, PhD and Vera Abramova, PhD: [A two-chamber governance with explicit process ruling and stochastic popular opinion sampling](https://uncertain-aqua-crawdad.myfilebase.com/ipfs/QmaMxWHoDvwc8YpxHvQju9um2AySkejG5yfYF94vdBCwZX) ### Technical Data * Pallet used: resbina * API used: Gen6 MW * Storage used: Gen6 MW or none or custom ### Live Gen6 Governance User Interface You can reach the Gen6 governance through: # Gen6 Governance Explained Bicamerial Governance and Expert System #### What is Gen6 Gov? Our governance model is a two-chamber system designed to make decisions in a balanced, efficient, and fair manner. It combines expert-driven governance with community input, ensuring that decisions are both technically sound and aligned with popular opinion. This approach aims to overcome common challenges in blockchain governance, such as low participation and power imbalances. You can access the Gen6 Gov UI here: {% embed url="" %} Source code can be found at the official git repos for self-hosting and local runs. #### How does it work? The two-chamber system is structured around two distinct chambers: 1. **Top Chamber**: Made up of experienced and proven members of the ecosystem (e.g., core developers and key contributors). They ensure that decisions are rational, technically sound, and aligned with the long-term vision of the platform. 2. **Bottom Chamber**: This chamber represents the broader community. Instead of requiring everyone to vote, it randomly selects a small, accountable sample of the population (similar to jury duty) to ensure that the decisions reflect popular opinion without overwhelming participants. Proposals must be approved by both chambers to pass, ensuring a balance of expertise and public consent. #### Why 2 chambers? The two chambers address two different needs in governance: * **Expertise**: The **Top Chamber** ensures that decisions are driven by individuals who have the necessary knowledge and experience to make informed, rational decisions. * **Legitimacy**: The **Bottom Chamber** ensures that decisions reflect the collective will of the community. By randomly selecting participants, it avoids the issues of voter fatigue and apathy while maintaining democratic legitimacy. Together, these chambers combine the best of technical expertise and popular legitimacy, creating a governance model that is both effective and fair. #### How Experts interact? Experts interact primarily within the **Top Chamber** where they collaborate to review proposals, make decisions, and ensure that any action taken is technically sound and aligns with the project’s vision. Their role is to provide guidance on complex issues, ensure the integrity of the platform, and advise on long-term goals. Experts also interact with the **Bottom Chamber** by presenting proposals that require approval. If a proposal passes in the Top Chamber, it is then sent to the Bottom Chamber for review. This creates a feedback loop, ensuring that expert decisions are aligned with community opinions. #### What are Guilds? Guilds in the context of Gen6 are organized groups within the community that bring together individuals with shared expertise or interests. Guilds may focus on specific areas, such as development, security, or governance, and they play an important role in shaping the platform's future. They act as support networks for experts and are often involved in decision-making and proposal creation. * Who can create guilds? Anybody can create a guild through referenda. You set yourself as Expert, so decide wisely before trying to create one. * How to become a guild member? You need to apply, then Experts in the guild can accept you. * We accept Expert decisions and it will influence what we do. * Frontends/Service providers decide which guilds to show, support. #### How to become an Expert? Becoming an **Expert** within Gen6 requires significant involvement and demonstrated expertise in the ecosystem. This could involve contributing to the platform's development, offering valuable insights, or playing a key role in its growth. Typically, Experts are nominated by the community or recognized by the system based on their contributions. To become an Expert, individuals need to: 1. Actively contribute to the ecosystem (e.g., events, code, governance, or community initiatives). 2. Be recognized by the community or existing Experts for their expertise and leadership. 3. Gain trust within the system through consistent positive contributions. #### How to join a Guild? Joining a **Guild** typically requires active participation in the ecosystem and alignment with the Guild's focus. Each Guild may have its own criteria for membership, which could involve specific contributions, skills, or expertise. Generally, to join a Guild, you would need to: 1. Identify a Guild that aligns with your interests or expertise. 2. Participate in activities or contribute to the Guild's objectives. 3. Be nominated or accepted by current Guild members, depending on the Guild’s membership process. Guilds play an important role in shaping decisions and offering expertise, so joining one can be a way to have a meaningful impact on Gen6's governance. # Education The **Gen6 Education** program is designed to provide individuals with the knowledge and skills required to excel in the world of decentralized technologies, with a specific focus on the Gen6 blockchain ecosystem. It offers comprehensive learning paths for both technical professionals and those interested in understanding the broader social, governance, and economic implications of blockchain. The program is structured into different certification tracks, which include the **Gen6 Blockchain Expert Certificate** and **Gen6 Blockchain Administrator Certificate**, catering to both developers and professionals who want to become experts in managing, building, and governing Gen6-based systems. #### **Gen6 Blockchain Expert Certificate** The **Gen6 Blockchain Expert Certificate** is a specialized certification aimed at individuals who want to become deeply knowledgeable in Gen6 blockchain technology, including its governance, social impacts, and real-world applications. This track is designed for professionals who aim to work with Gen6’s advanced blockchain infrastructure and understand how it can be applied to solve real-world challenges. **What You Will Learn** * **Gen6 Blockchain Technology**: Dive deep into the underlying architecture, consensus mechanisms (EPoA), distributed storage, and middleware that power Gen6’s decentralized ecosystem. * **Blockchain Governance**: Learn how decentralized governance works in the Gen6 ecosystem, including the roles of validators, experts, and contributors. Understand blockchain’s role in transforming governance models, both for organizations and broader society. * **Social and Economic Impact**: Explore how blockchain can create social impact through transparency, trust, and decentralization. Understand the role blockchain plays in redefining ownership, economic models, and financial systems. * **Tokenomics**: Study the design and implementation of tokenomics, including the Gen6 GSX token and its role in the ecosystem’s economy. * **Real-World Blockchain Applications**: Learn about practical use cases for blockchain technology, including supply chain, healthcare, governance, voting systems, and more. **Requirements for Certification** To obtain the **Gen6 Blockchain Expert Certificate**, you need to: 1. **Complete all core modules**: This includes in-depth learning in blockchain technology, governance models, social sciences, and tokenomics. 2. **Pass all assessments**: After each module, you will need to pass assessments, including quizzes and practical exercises to test your understanding. 3. **Final Project**: Complete a final project where you design a decentralized application (dApp) or governance model on the Gen6 blockchain. This project will be reviewed by experts, and you’ll be required to present your solution. 4. **Practical Experience**: Hands-on experience with blockchain development tools like the Gen6 SDK, Gen6 Middleware, and other Gen6 services is encouraged. While not required, it will help in the practical assessment phase. Once you pass all required modules, assessments, and the final project, you will receive the **Gen6 Blockchain Expert Certificate**. *** #### **Gen6 Blockchain Administrator Certificate** The **Gen6 Blockchain Administrator Certificate** is designed for professionals interested in the operational and administrative side of blockchain networks. This certificate is perfect for individuals responsible for maintaining, configuring, and optimizing Gen6 blockchain nodes, managing network infrastructure, and ensuring that blockchain systems run smoothly. **What You Will Learn** * **Blockchain Node Management**: Learn how to deploy, manage, and optimize Gen6 blockchain nodes. Gain expertise in managing full nodes, validators, and the Gen6 OS. * **Consensus Mechanisms**: Understand how the Enhanced Proof-of-Authority (EPoA) consensus mechanism works and how to maintain a secure and efficient network. * **Network Monitoring**: Gain skills in monitoring network health, troubleshooting issues, and ensuring the optimal performance of blockchain nodes and services. * **Security Best Practices**: Learn about securing blockchain networks, handling cryptographic keys, and managing data privacy and compliance (including GDPR). * **System Integrations**: Explore how to integrate Gen6 blockchain with Web2 applications and external services, including utilizing the Gen6 Middleware. **Requirements for Certification** To obtain the **Gen6 Blockchain Administrator Certificate**, you need to: 1. **Complete the Technical Modules**: This includes modules on blockchain architecture, consensus, node management, security, and network operations. 2. **Pass Practical Assessments**: You will be assessed through practical tests and quizzes based on real-world scenarios related to blockchain administration. 3. **Final Hands-On Project**: Develop and deploy a functional Gen6 blockchain environment, demonstrating your ability to manage nodes, ensure network health, and implement security practices. 4. **Demonstrate System Monitoring Skills**: Show your ability to monitor and optimize the Gen6 blockchain network’s performance, ensuring scalability and reliability. Once you successfully complete the required modules, practical assessments, and final hands-on project, you will receive the **Gen6 Blockchain Administrator Certificate**. #### **Why Get Certified?** * **Career Advancement**: Both certifications will boost your credentials in the rapidly growing blockchain industry. Certified blockchain experts and administrators are in high demand as blockchain technology is increasingly adopted across various sectors. * **Hands-On Skills**: The certification programs offer practical experience with Gen6's blockchain infrastructure, tools, and applications, making you job-ready for real-world blockchain projects. * **Industry Recognition**: The **Gen6 Blockchain Expert** and **Blockchain Administrator** certifications are recognized in the industry and can open up new opportunities for career growth and freelance work. By completing these programs, you will gain a comprehensive understanding of **Gen6** and its applications, positioning yourself as an expert or administrator capable of leading blockchain initiatives in any organization. # Communication Rules For Community Members, Sales Representatives, Referrers and Partners ### How to Share the Project Clearly, Positively and Responsibly Gen6 grows through people who believe in the project and are willing to talk about it. Community members, sales partners, referrers and enthusiasts play an important role in helping others understand what Gen6 is building. This guide is here to make communication easier, clearer, and more effective. It is not meant to restrict enthusiasm. On the contrary, it is designed to help everyone speak about Gen6 with confidence, consistency and credibility. ### 1. Purpose These Communication Guidelines are designed to ensure that all public and private communications regarding Gen6, validator rights, GSX, referrals, and related project matters are accurate, responsible and aligned with official Gen6 materials. Anyone communicating about Gen6 in a sales, referral, promotional, educational or community capacity must follow these guidelines at all times. ### 2. Communicate With Confidence You are encouraged to talk about: * The Gen6 vision and ecosystem * The role of validator rights * The utility of GSX * Official milestones and announcements * Product launches, partnerships, and roadmap progress * Your own excitement about the project Authentic enthusiasm is welcome. Positive communication helps others discover the opportunity and understand the broader mission behind Gen6. All communications must be: * Accurate * Balanced * Non-misleading * Based on official Gen6 sources * Clear about risks and uncertainties * Free from promises of profit or guaranteed outcomes Opinions may be shared but they must never be presented as guaranteed results, investment promises or official company statements unless expressly authorized. GSX and Validators are not investment products. ### 3. Stay Aligned With Official Information The best communication is simple: share what Gen6 has officially published. Please rely on: * The signed links and resources by the Official Gen6 Identity: * * Use the Gen6 Wiki * Official company announcements, issued presentations, documents, and public statements What is official? Only the Real Seal signed communication channels! See the identity above for details. This keeps communication consistent and ensures that the community is speaking from the same factual foundation. ### 4. Share the Opportunity Without Turning It Into a Promise It is completely appropriate to speak about Gen6 as a project with ambition, utility, and growth potential. At the same time, future outcomes should not be presented as guaranteed. #### Good examples * “Gen6 is building an ecosystem with long-term utility around GSX and validator participation.” * “The project has reached several important milestones and continues to develop its roadmap.” * “Many people are excited about the future of the ecosystem.” * “Validator rights are designed to play a role within the Gen6 network and its broader economic model.” #### Avoid statements like * “This will definitely increase 20x.” * “Profit is guaranteed.” * “There is no risk.” * “Everyone who joins now will make money.” A strong message is not weakened by being accurate. In fact, responsible communication builds more trust over time. ### 5. Personal Opinions Are Welcome — Just Present Them as Opinions You may absolutely share your own views, expectations, and excitement. For example: * “I personally believe Gen6 has strong long-term potential.” * “In my view, this is one of the most interesting utility-driven Web3 projects.” * “I am optimistic about the ecosystem based on the milestones already achieved.” When expressing a personal view, make it clear that it is your opinion and not a guaranteed outcome or official investment promise. ### 6. Risk Language Is Mandatory when Talking about GSX and Validators Communications must clearly acknowledge uncertainty and risk where relevant. This applies especially when discussing: * GSX * Validator rights * TGE timing * Market access * Future listings * Potential economic benefits * Revenue models * Adoption projections * Roadmap milestones **Required communication posture** Whenever discussing future outcomes, include language such as: * “Subject to execution, regulatory conditions, and market developments.” * “No financial return is guaranteed.” * “Future timelines and project milestones may change.” * “This should not be interpreted as investment advice.” * “Participants should make independent decisions based on official documentation.” ### 7. How to Talk About GSX and Validator Rights When discussing GSX or validator rights, focus on their place in the ecosystem and the official project framework. #### Recommended framing * Explain the utility and role as described in official materials * Discuss the broader validator model and participation structure * Highlight official project milestones and current progress * Share links to the Gen6 Wiki or official announcements for details #### Please avoid * Quoting specific future token prices * Presenting income or returns as guaranteed * Promising liquidity, resale value, or market outcomes * Making claims that go beyond official materials The most persuasive communication is not hype — it is clarity. ### 8. No Investment Promises It must always be clear that personal opinions, projections, or enthusiasm are not investment promises. No communicator may state or imply that: * A validator purchase guarantees returns * GSX tokens will appreciate in value * A future listing will produce liquidity at a specific price * Participation ensures financial profit * Project milestones guarantee market performance **Recommended disclaimer** Where appropriate, use: > “This communication is for informational purposes only and does not constitute financial, legal, tax, or investment advice. No return, liquidity event, token price, or market outcome is guaranteed.” ### 7. Make Risk Awareness Natural, Not Fearful Responsible communication does not require sounding negative. It simply means presenting the project with maturity. For example: * “As with any developing ecosystem, future outcomes depend on execution, adoption, and market conditions.” * “Anyone considering participation should review the official materials and make an informed decision.” * “The project has strong ambitions, while future results naturally depend on many factors.” This type of language reassures people that the communicator is informed and trustworthy. ### 8. Communication About Timelines and Roadmaps Timelines may only be communicated exactly as officially published. Do not independently promise or reinterpret: * Launch dates * TGE dates * Listing dates * Token availability * Product rollout dates * Revenue activation dates **Acceptable phrasing** * “According to the latest official announcement, the current target date is…” * “Please refer to the latest Gen6 communication for the most up-to-date timeline.” * “Roadmap items may be subject to operational, regulatory, or strategic adjustment.” ### 9. Talk About Gen6 in a Way That Builds Trust The community benefits most when communication is: * Positive * Honest * Clear * Consistent * Grounded in official information Trust compounds. A message that is realistic and well-supported is more powerful than one that overreaches. ### 10. Communication About GSX and Validators When discussing GSX or validator rights: **Do** * Explain their role only as officially defined * Refer to published project documentation * Clarify that future utility and market outcomes involve risk * Encourage readers to review official materials directly **Do not** * Promise income * Promise token liquidity * Promise resale value * Promise appreciation * Suggest that validator rights are risk-free * Suggest that token allocation equals guaranteed realizable value ### 10. No Unauthorized Legal, Financial, or Tax Advice Community members, referrers, and sales representatives may not provide: * Legal advice * Tax advice * Investment advice * Regulatory interpretations presented as certainty **Correct approach** Use wording such as: * “Please consult an independent advisor.” * “For legal or tax implications, obtain professional advice.” * “Please rely on the official documentation and your own independent assessment.” ### 11. Examples of Acceptable and Unacceptable Statements
TopicAcceptableUnacceptable
Token price“Future token market performance is uncertain and cannot be guaranteed.”“GSX will multiply after TGE.”
Validator economics“Any economic outcome depends on the project framework, implementation, and future conditions.”“This will generate passive income.”
Project timing“Please rely on the latest official roadmap and announcements.”“The launch date cannot move.”
Resale opportunity“Transferability, resale, or market demand cannot be promised.”“You can always sell later at a profit.”
Personal views“This is my personal view and not an official investment statement.”“The company says this is a guaranteed opportunity.”
### 12. Escalation Rule If you are unsure whether a statement is acceptable: 1. Do not publish it. 2. Check the latest official Gen6 documentation. 3. Ask the designated Gen6 communication or compliance contact for clarification. When in doubt, leave it out. ### 13. When in Doubt, Use Official Sources If you are unsure whether a statement is accurate, the safest and strongest approach is: * Quote or link the official source * Avoid adding assumptions * Ask the Gen6 team for clarification if needed This protects you, the audience, and the credibility of the entire ecosystem. ### 14.Shared Responsibility Everyone communicating about Gen6 contributes to how the project is understood. That is a powerful role. The Company is responsible for its own official statements and publications. Community members, representatives, referrers, and contractors are responsible for ensuring that their own communications remain accurate and aligned with this guide. ### 15. Final Principle ***Be enthusiastic.***\ ***Be clear.***\ ***Be factual.***\ ***Be proud of the project.*** The strongest Gen6 communication inspires confidence because it combines vision with responsibility. #### 16. Suggested Standard Disclaimer The following disclaimer may be used in relevant public-facing communications: > “This material is provided for informational purposes only. It does not constitute financial, investment, legal, or tax advice. No guarantee is made regarding future token utility, liquidity, price, market access, project milestones, or economic outcomes. Readers should rely on official Gen6 materials and make independent decisions based on their own assessment.” # The Gen6 Privacy Guide Verify. Sign. Communicate End-to-End. ### Gen6's Commitment to Privacy At **Gen6**, privacy isn't just a core value - it's the foundation upon which our ecosystem is built. As we strive to empower individuals with digital sovereignty, we recognize that privacy is a fundamental right that must be protected. In today's increasingly interconnected world, where personal data is often exploited, our mission is to create a secure and safe space where users can control their own information. We are not only committed to maintaining the highest standards of privacy within our own platform, but we are also actively seeking strategic partnerships with like-minded privacy-focused projects. By collaborating with other privacy-driven initiatives, we aim to strengthen the ecosystem, ensuring that all participants have access to secure, decentralized tools that protect their data and preserve their freedom in the digital age. ### **Where to start? Your First Gen6 Privacy Week** Don't try to switch everything at once — that's how people burn out and give up. Change these few things first; the rest can follow at your own pace. 1. Install a password manager (Bitwarden) and turn on app-based 2FA (FreeOTP Authenticator) instead of SMS. 2. Switch your browser to LibreWolf or Brave and your default search to Brave Search or Startpage. 3. Open an encrypted email account (Tuta or Proton) with your own custom domain, and start moving important accounts over. 4. Move one important conversation to NCrypt this week. The rest will follow. 5. Turn off non-essential notifications and review app permissions (location, mic, camera, contacts). #### **Digital wellbeing and attention** Privacy and digital wellbeing are the same fight. Every notification, autoplay, and default sync is both an attention hook and a data-collection surface. Stepping back protects your mind and your data at once — and many who leave Google, Facebook and similar platforms report more peace and independence on the other side. * Turn off all notifications: keep only maximum 3 critical notifications from wife, children or parents. * Set your phone to grayscale and remove addictive apps from the home screen. Friction breaks the reflex to open them. * Keep the phone out of the bedroom; try a no-phone first and last hour of the day. * Schedule regular detox windows — an evening, a day, a weekend — where you're fully offline. * Practice digital minimalism: fewer apps, fewer accounts, fewer feeds. Each one you remove is one less thing harvesting you. **Privacy habits that cost nothing** The strongest tools won't help if your habits leak data around them. These cost no money and little effort. * **Compartmentalize with aliases.** Use a separate email alias per service (SimpleLogin, Proton Pass, or Tuta aliases). A breach or data sale then can't link back to the real you. * **Use app-based 2FA, never SMS.** SMS codes can be intercepted or SIM-swapped - and they hand over your phone number. Use FreeOTP. * **Never reuse passwords.** One breach shouldn't unlock everything. Let your password manager generate unique ones. * **Review permissions regularly.** Revoke location, microphone, camera and contacts access from apps that don't truly need them. * **Lock down or step back from social media.** Tighten defaults, or leave the platforms that profit most from profiling you. #### Understanding the need for privacy in the AI era In the AI era, where personal data is constantly collected, analyzed, and leveraged by powerful algorithms, privacy has become more critical than ever. As AI technologies evolve, they can expose individuals to risks such as: * **Unauthorized data usage** * **The erosion of personal autonomy** * **Deepfake-based fraud and scams** * **Illicit and/or unwanted surveillance** Understanding the need for privacy means recognizing that our data should remain under our control, ensuring that we can engage with technology without sacrificing our freedoms or security. Protecting privacy in this digital age is essential to maintain trust, safeguard rights, and foster a future where AI serves humanity without compromising individual freedoms. #### Understanding the need for encryption *End-to-end encryption protects the privacy of your data, puts control over how the data gets used into your hands, and is the best way we have to ensure private conversations remain private. Not enough companies use it as broadly as they should.* \~ #### What Gen6 Offers for Privacy * **Real Seal Identity Verification** - A decentralized, blockchain-based identity system that puts users in control of their data, ensuring privacy and security without third-party involvement. * **Real Seal for Content Verification** - A blockchain-powered solution for verifying digital content authenticity, helping to combat misinformation and ensuring the integrity of media. * **NCrypt for Secure End-to-End Messaging** - An encrypted messaging platform that guarantees private, secure communication with end-to-end encryption and decentralized identity verification. * User guides to privacy for Life of Gen6 - Comprehensive guides (such as this one) and education to help users protect their privacy and navigate the Gen6 ecosystem securely. You can access these solutions from or through self-hosted instances. By prioritizing control, security, and open-source transparency we aim to build a future where users have full sovereignty over their digital identities and communications, ensuring they can navigate the digital landscape with confidence and peace of mind. *Privacy is the foundation for those who live the Life in Gen6.* ### Recommended systems for daily use These systems and tools are used by many people in the Gen6 ecosystem for their security and privacy respecting qualities. #### Mobile phones and OS * Motorola (coming soon) or Pixel with Graphene OS - * e/OS - de-Googled Android with its own app store and cloud; available pre-installed on Murena and Fairphone devices. #### For installing apps on Mobile * F-Droid open-source app store - * Aurora Store de-Googled front-end to the Play Store - #### Laptops and OS * Most business grade laptops are fine (eg. Lenovo ThinkPads or Dell XPS) * Avoid Intel AMT (vPro) and AMD DASH as they are basically hardware backdoors. * Ubuntu, Linux Mint, Debian or Arch Linux. * For the highest threat models: Tails (amnesic live OS) or Qubes OS (compartmentalization by design) #### Run your local AI and preserve privacy * GPT4All - (easy to use) * LM Studio - (graphical, runs local models offline) * Ollama - (for more advanced users, no graphical user interface) #### Password Managers * Bitwarden is easy to use and synchronizes between devices - * KeepassX is local, can run offline - #### Web browsers * Librewolf to maximize privacy - * Brave for decent privacy - [https://brave.com/](https://brave.com/download/) * Tor Browser for maximum anonymity for sensitive browsing - #### Email (replace Gmail) Email was never designed to be private. A standard inbox feeds advertising profiles and, increasingly, AI training data. Move your inbox to an encrypted, zero-access provider — and use your own custom domain so you're never locked in. * **Tuta** — (German, open-source, encrypts subject lines, contacts and calendar; post-quantum encryption; best value) * **Proton Mail** — (Swiss, full ecosystem with VPN, Drive, Calendar and Pass; easiest Gmail-like experience) * **Mailfence** — (Belgian, full productivity suite, supports standard IMAP/SMTP clients) > Tip: True end-to-end encryption only applies when both sender and recipient use an encrypted provider (or a password-protected message). Even with encrypted email, metadata (who, when, how often) is still exposed unless you also use a VPN or Tor. #### Private search (replace Google Search) Your search history is the richest profile anyone can build about you. These engines don't log queries to your identity or bend results to a profile. * **Brave Search** — (independent index, doesn't rely on Google or Bing) * **Startpage** — (Google-quality results with your identity stripped; EU-based) * **DuckDuckGo** — (simplest switch, good extra privacy tooling) * **Mojeek** — (UK, fully independent crawler and index) * **SearXNG** — (open-source, self-hostable metasearch — full control) #### VPN A VPN hides your traffic from your network and ISP and changes your apparent location. It does not make you anonymous on its own — it shifts trust to the provider, so the provider matters more than the feature. Choose audited, no-logs providers that accept anonymous/cash payment. * **AirVPN** - (flat pricing, accepts cash; audited, long trusted community) * **Njalla** - (Swedish anonymous provider, established by The Pirate Bay co-founder Peter Sunde. Trusted.) * **Proton VPN** - (open-source apps, free tier available, bundled with Proton) * **IVPN** - (alternative minimal VPN provider) #### Maps, navigation * **Organic Maps** — (offline, open-source, no tracking) and **OsmAnd** — #### YouTube Frontend * **NewPipe** — (privacy-friendly YouTube front-end, no Google account, no ads, install via F-Droid) #### Network-level protection (DNS and ad-blocking) * **NextDNS** — (configurable encrypted DNS with tracker/ad blocking, per-device) * **Pi-hole** — or **AdGuard Home** — (network-wide blocking on your own hardware) ### Defending your own site from AI crawlers (for self-hosters and operators) If you run a website, blog, Git forge or self-hosted Gen6 instance, aggressive AI scrapers can hammer your server, ignore robots.txt, and harvest your content for training data. These open-source tools push back. They are meant for the people running infrastructure, not for everyday browsing. * **Anubis** — (MIT-licensed; sits between your reverse proxy and app server and puts a lightweight proof-of-work challenge in front of unverified clients, blocking scrapers with minimal friction for real users. The gentlest, most legitimate option — start here.) * **Nepenthes** — (a "tarpit" that lures crawlers into an infinite maze of nonsense pages with no exit links, wasting their time and resources and optionally feeding them garbage to poison training data. Its own author labels it deliberately aggressive software — deploy only if you understand the trade-offs.) * **Iocaine** — (inspired by Nepenthes; focuses on data poisoning, feeding crawlers generated garbage text. Reported to cut bot traffic dramatically.) > Trade-offs to weigh: tarpits consume your own server resources and bandwidth, can catch legitimate search-engine crawlers (hurting your SEO/visibility), and sophisticated scrapers may learn to detect and skip them. Anubis-style gating is usually the safer default; reserve tarpits for cases where you genuinely want to fight back and accept the cost. Anubis can also be configured to hand unverified bots off to a tarpit instead of simply blocking them. ### Important notice on phone numbers and ID requirements Anything that requires a phone number or even worst, a government issued ID, will push you towards a dystopian future and it is better to avoid such services. People who are out of Google, Facebook and similar anti-social sites, privacy exploitative system are more happy, more content. Be cautious of any service that asks for your phone number (and even more cautious of one that demands a government-issued ID). Each small surrender of privacy makes it easier to normalize a world of constant monitoring, pushing us towards a dystopian future. Choose services that respect your freedom instead of quietly training you to give it away. Many who step back from Google, Facebook and similar privacy-exploitive platforms find something surprising on the other side: more peace, more independence and a deeper sense of contentment. ### The De-Google List
Source: ### Championing the shift from Big Tech to privacy-first providers
# Gen6 Trust Academy Gen6 Trust Academy is an educational video series based on the official Gen6 Wiki. The series explains Gen6 step by step in a simple and practical way. ### 1. **Why Digital Trust Is Breaking — And What Gen6 Is Building** **Description:** This opening video explains why AI is making digital identity, content, links, and online information harder to trust. It introduces Gen6 as an ecosystem built around privacy, blockchain technology, identity, and verification. **Wiki Page:** \ **Verify & Watch:** ### 2. How Gen6 Creates Verifiable Digital Reality **Description:** This video explains the basic idea behind verifiable digital proof: how claims, actions, identities, and transactions can become checkable instead of simply trusted. It introduces key concepts such as blockchain, cryptography, middleware and Gen6 Identity. **Wiki Page:** \ **Verify & Watch:** ### 3.The Gen6 App — Identity, Verification & Proof in Practice **Description:** This video shows how Gen6 identity works in practice and why self-sovereign identity matters in the AI era. It focuses on how users can control, store, and share verified identity information while maintaining privacy. **Wiki Page:** \ **Verify & Watch:** ### 4. How to Prove Your Content Is Real **Description:** This video introduces RealSeal and explains how digital statements, documents, links, and content can be signed and verified. It shows why proof of origin becomes critical when AI-generated and manipulated content is everywhere. **Wiki Page:** \ **Verify & Watch:** ### 5. Verified Humans, Verified Businesses & Digital Reputation **Description:** This video explains why verified identity and reputation are becoming essential for both individuals and organizations. It covers how Gen6 can help create signals of legitimacy in a world of fake profiles, impersonation, and AI-driven fraud. **Wiki Page:** \ **Verify & Watch:** ### 6. What Makes Gen6 Different from Other Blockchain Projects **Description:** This video explains how Gen6 is focused on practical verification, privacy, identity, and real-world usability rather than only blockchain infrastructure. It introduces the broader technology foundation behind Gen6, including the G6 Operating System and the connection between blockchain networks and Web2 systems.\ **Wiki Page:** [https://wiki.gen6.life/technology](https://wiki.gen6.life/technology-core)\ **Verify & Watch:** ### 7. Why GSX Exists — Utility, Verification & Ecosystem Growth **Description:** This video explains the role of GSX. It focuses on utility, ecosystem activity, verification usage, incentives, governance and why an economic layer matters for sustainable digital verification. **Wiki Page:** \ **Verify & Watch:** ### 8. How to Protect Yourself in the AI Era **Description:** This video gives practical habits for staying safer online as AI makes scams, fake links, fake identities, and fake content harder to detect. It connects everyday digital safety with Gen6 tools such as identity verification, RealSeal, and private communication. **Wiki Page:** \ **Verify & Watch:** ### 9. The Gen6 Blockchain Administrator Program Explained **Description:** This video explains the role of blockchain administrators in the Gen6 ecosystem. It covers why node operation, updates, monitoring, security, validators, and technical education matter for a reliable blockchain network. **Wiki Page:** \ **Verify & Watch:** ### 10. How Businesses & Developers Can Build on Gen6 **Description:** This video explains how Gen6 can support businesses, developers, and integrations through verification tools, identity systems, middleware, and developer resources. It shows how Gen6 can become a practical layer for apps, organizations, and Web2-to-Web3 use cases. **Verify & Watch:** ### 11. The Future of Human Verification in the AI Era **Description:** This final video brings the full series together and looks at the future of verified humans, verified businesses, verified content, verified communication and digital proof. It frames Gen6 as part of a broader shift toward authenticity and verification in the AI era. **Verify & Watch:** # Support Guides ***Support is the lifeblood of every ecosystem.*** \ Just as no tree can stand tall without the soil beneath it, no bird can soar without the air around it, no person can truly grow without encouragement and cooperation. In every system whether in nature, in business, or in our daily lives: support multiplies strength. It is the quiet force that allows greatness to rise. At **Gen6** we don't just recognize the importance of support, we treasure it. We know that every breakthrough, every milestone and achievement rests on a foundation of people lifting each other up. That is why we place such high value on creating an environment where support isn't an afterthought, but a way of life. So if you wish to thrive, don't just seek support. Be the one who offers it generously. You will find that the more you strengthen others, the more unshakable your own foundation becomes. Explore this of the wiki to discover guides created to make things easier for ***Life in Gen6***. # Connect a physical Gen6 Validator
# Validator Hosting & SLA Guide Guide for running your own validator on VPS (or on a physical machine at home) Running a Gen6 validator is an important part of supporting the network. Validators help secure the ecosystem, maintain infrastructure and participate in the long-term growth of Gen6. For users who do not want to run or host their own validator, Gen6 is preparing a list of trusted **SLA Validator Providers** in this wiki. These providers can help operate and maintain a Gen6 validator on your behalf, making it easier to participate in the network without managing the technical setup yourself. We will list the Gen6 SLA validators in this wiki, so you can contact them if you don't want to run/host your Validator on your own. If you are a Certified Blockchain Administrator, you can get listed on: ### What Is an SLA Validator Provider? An SLA Validator Provider is an external infrastructure partner that offers validator hosting and maintenance services. This may include: * validator node setup; * hosting and uptime monitoring; * software updates; * basic infrastructure maintenance; * technical support; * validator operation guidance. This option is designed for users who want validator participation, but prefer to rely on experienced infrastructure providers instead of running the validator independently. ### Estimated Cost The expected monthly cost for running **1 SLA-hosted validator** is currently estimated to be approximately: > **$15 – $80 per month depending on services added** The final cost may depend on the provider, server specifications, support level, and additional services included. ### In Short > **You can run your Gen6 validator yourself (best) or pay an SLA Validator Provider to handle the technical operation for you.** The goal is to make validator participation accessible, reliable and scalable as the Gen6 network grows. ## Running Your Own Validator - VPS Guide If you prefer to operate your validator independently, Gen6 fully supports self-hosting. Please note that self-hosting is only available for validators with 100% ownership rights. Validators with shared ownership (for example, 50% ownership) cannot be self-hosted, as they represent a shared validator managed by a single Blockchain Administrator. Running your own validator gives you complete control over your infrastructure and contributes directly to the decentralization, resilience and security of the Gen6 network. Before getting started, make sure you have a suitable VPS or dedicated server, a stable internet connection and the recommended operating system. While running your own validator requires basic Linux and server administration knowledge, the installation process has been designed to be as simple as possible. #### Notes on running validators at home You can follow this guide as well, just skip the VPS part. Everything works the same way if you own a physical machine. ### **Step 1**: Renting and setting up the VPS \ Rent a VPS, then install the operating system on it. **Recommended specs**: * AMD, 2 vCPU, 4 GB RAM, 80 GB SSD * ⚠️ This value may change over time as Gen6 node requirements grow — always check the current recommendation. **Recommended OS**: Debian 13. Get a VPS → install OS → select Debian 13 → set the root password → install → start the VPS. Wait until the server shows a RUNNING status. Your recommended VPS providers: * (Hungarian) * (Swedish) * (German) * (German) * (French) ### Step 2: Connet to the server using SSH Open a terminal and connect to the server (VPS): ssh root@\ Note that the provider might give you different usernames, so please refer to their documentation for the exact command. The first time, it will ask you to accept the fingerprint → type yes. Then enter the password *(\) or even better* [*use SSH keys*](https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server)*.* ### Step 3: Update the system apt update && apt upgrade -y This may take 1–2 minutes. Wait until you get the command prompt back. ### Step 4: Download and install Gen6 Manager The Manager automatically handles node download, key generation, chainspec setup, and on-chain registration.\ \ **Link**: Command to download to the server (VPS) and then to make it executable: 
wget https://shepherd.gen6.app/public/gen6-manager
chmod +x gen6-manager
Make sure you run both commands, otherwise you cannot start the manager. Security best practice: Verify the hash (the hash needs to match) using this command: ``` apt install b3sum -y b3sum gen6-manager ``` The b3sum command must return this exact hash: 456d1666e0d736308f202cbb92757ea49cf35323626158a6a6d813b62103dcc6 gen6-manager If it is different, you are being hacked. \ **Command to install in Terminal:** ``` ./gen6-manager install ``` **The installer asks two questions**: * *“Did you read and understood the text above?”* → type YES → Enter * *“Do you wish to start the Gen6 Manager now?”* → type YES → Enter The installer then adds the Podman repository in the background, installs dependencies, starts Podman, and prints: *“Installation complete.”* — answering YES to this as well starts the service, and the Manager’s address is displayed: Service will be available at: **** ### Step 5: Open a tunnel to the server from your machine, so you can access the web interface \ The Manager’s web interface is only accessible through an SSH tunnel. Open a new terminal tab *(cmd+T)* and run: **ssh -L 7154:127.0.0.1:7154 root@\** Please adjust this command to your server's ip address and also the username if needed (from root to whatever the vps provider gives you). This command both logs into the server AND opens the tunnel: this connection must be left open while you manage the validators. Then open the Manager URL in your browser *()*. On the “Welcome” screen, the “Register with remote service” panel appears, with an “Activation password” field: *“Please register your manager with the remote service. Use the password you received from Gen6.”* Enter the password you received from Gen6 (\), then click Register — this activates the Manager. ### Step 6: Adding and activating validator Before adding a validator in the Manager, get your validator ID ready: you can find it at . By default, an average user will only have the Validator ID available — the keys/secrets are provided by Gen6 itself. ***Gen6 shares these exclusively via NCrypt***, and only with the legitimate owner of the validator. If you don’t have such a secret, the “Setting up your own keys” step below can be skipped — in that case the Manager will generate the required keys itself during setup. Next, in the Gen6 Manager interface *(left-hand menu)*, go to Services → Validators. Click “Show available validators” — the available validator cards will appear (with the validator ID, e.g. GSV108, GSN038, and the chain they belong to, e.g. Gen6 Public Chain / Gen6 Development Chain): * *✅ green checkmark = the node can become an active member, produce blocks, and earn rewards.* * *⚠️ red warning = the node already has a registered address — it can only be used if you have the corresponding seed phrases, otherwise it cannot participate in the blockchain.*
*(If your own validator is not listed, you can also enter the ID manually using the “Show custom validator addition” button.)* Click Add on the card of the appropriate validator ID — this adds the validator (initially in an inactive state, “Status: not running”) On the added validator’s card, click “Details & Configuration”. **On the Container config panel that opens**: * Active → switch ON * Archive → leave off, unless specifically needed * Validate → leave OFF for now * Click Save
This starts the node and synchronization — shown in the Validators list as “Status: syncing… X%” — but the validator is not yet validating.
#### Setting up your own keys *(secrets)*
This step is only needed if you received specific keys/secrets for a given validator from Gen6 *(via NCrypt, as the legitimate owner)* — for example when restoring an existing validator or rotating keys. If you don’t have such a secret, skip this section and continue at “Enabling validation.” 1. On the validator’s Details page, find the “secret-inject” (Validator secrets) section. 2. Paste in the keys/secrets you received, then click Save. 3. Click the “reinject keys node” button (red button in the “container op” section). This deletes any previous (possibly auto-generated) keys and chainspec, and queues the validator for recreation — indicated by the message *“Validator \[ID] chainspec and keys were removed, queued for recreation.”* 4. Wait until the node’s status changes from “starting” back to “running.”
#### Enabling validation **Once the reinject has completed and the node is running, go back to the Container config panel**: * Validate → switch ON * Click Save
This actually starts validating with the injected keys — the validator will then show as “active node” / running and validating in the Validators list. \ \ \ \ \
# Gen6 Community FAQ **What is G6?** * G6 is the technology used by Gen6 community. **What is Gen6?** * Gen6 is is the name of the community, short for "Generation 6". The number refers to the Enneagram symbol and it helps the manifestation of its energy on a higher ocatne so Life/Technology balance can thrive. **How is Gen6 governed?** * Gen6 Experts are the community frontiers, while every member has the power to initiate potential positive changes. * Two chamber governance is being built for the fully decentralized experience. **Gen6 Public Chain's Validation Logic** * Reward for validating one block is 0.05 GSX (to be increased EOY 2025 to 0.1 GSX). * The validators are going in round after each other to get their rounds. #### **What Gen6 blockchain validator states are defined?** 1. **Non-Existent:** Not part of the system. 2. **New:** Not yet validating, but registered in the system (requires to be on the AURA list). 3. **Active:** Actively validating (after calling start extrinsics which required aura+grandpa pub keys). 4. **Warned:** if a validator misses producing one block. 5. **Slashed:** if missed second block. The validator needs to call restore() after the penalty of 10 days. **Gen6 Public Chain's Freeze & Restore Logic** * Non-slashed validators can chill anytime. * After calling Freeze, it takes 2 days until a validator can come back validating. * Restore needs to be called after 2 days or it won't start. **Gen6 Public Chain's Slashing Logic** * If a validator skips doing his job which is validating, then it gets into "Warned" state. * If a validator only skips once and next time it continues validating, the Warning is removed after 24 hours. * If a validator is Warned and skips again, then it is banned ("slashed") from validation for 10 days. * Actual calculation is "*SlashingTerm: u32 = 10 \* DAYS;*" where "*DAYS = HOURS \* 24; HOURS = MINUTES \* 60; MINUTES = 60\_000*", configured in Aura → Offences → SubstrateValidatorSet. * No GSX penalty is applied at the event of slashing. The community might consider adding this feature later. * Restore needs to be called after a slash. **I want to see more technical things of Gen6 Public Chain (API & Dev stuff)** * You can always play with Gen6 public chain through PolkadotJS: * * Gen6 MW HTTP API: (beta!) * WSS API URL for development: wss\://gen6.app:443/node # Learn How Gen6 Works # Gen6 App - User Guides # Gen6 Decentralized Identity ### Permissioned Identity Management on Gen6 Gen6 Identity is the decentralized identity layer of our ecosystem. It allows users to create, manage, and share a cryptographically verifiable identity without relying on centralized identity providers.\ \ Your Gen6 Identity answers one critical question:\ **Who is this user, and can this be proven cryptographically?** The Gen6 Identity system plays a crucial role in proving authorship, enabling trust, and serving as the foundation for Real Seal and NCrypt. It ensures that messages cannot be spoofed, seals have ownership, and encryption is attributed correctly. The system operates with a security model where identity keys are user-controlled, with no recoverable passwords, central key escrow, or personal data exposure. It uses on-chain proofs, and any compromise risk is limited to the user's security. The technical setup involves an on-chain pallet (dataRegistry), middleware (G6 MW or custom providers), an API (G6 MW API), and off-chain, permissioned, user-controlled storage. **What Is Gen6 Identity?**\ \ In Gen6, an Identity is a cryptographic profile linked to your wallet and account.\ \ It is: • Decentralized (privacy-proofs)\ • Wallet-linked (self-sovereign or web2 hosted)\ • Cryptographically verifiable\ • Privacy-preserving (data is not shared publicly or with 3rd parties)\ • GDPR-compliant **How Gen6 Identity Works (High Level):** • Identity ownership is proven via wallet signatures\ • Identity hashes are stored on-chain (Merkle Tree–based)\ • Personal data is never stored on-chain\ • Identity data lives behind G6 Middleware (MW) or your own trusted providers\ • You decide what is visible and to whom ### Accessing the Identity App From the Gen6 dApps menu, select Identity.
Gen6 dApps menu with Identity highlighted. This opens the Identity landing page. ### Identity Search & Discovery The Identity app allows you to search for any public Gen6 Identity by wallet address. Identity Search page (Enter Gen6 address to search).
\ **Use this to:**\ \- Verify identity ownership\ \- View public profiles\ \- Confirm authorship of messages or signatures ### Logging In & Authentication **To manage your own identity, click View My Identity. You can authenticate using:**\ \ • Wallet login (recommended)\ • Google login (optional, non-custodial)\ \ Choose Login Method modal (Use Wallet / Log in with Google)\ Wallet-based login ensures full cryptographic ownership of your identity.
### Viewing Your Identity Profile After authentication, your identity profile is displayed.
**Identity profile view (avatar, address, Share / Edit buttons) This page shows:**\ \ • Your profile image\ • Your Gen6 address (identity identifier)\ • Share and Edit options\ • Public links (if enabled) ### Sharing Your Identity You can share your identity using a secure, verifiable link.\ \ **Share Identity screen (Copy link to share this identity). This link allows others to:**\ \ • View your public identity\ • Verify that the identity belongs to the wallet owner\ • Confirm message or document authorship ### Editing Your Identity Click Edit to customize your identity profile. ### Identity Edit — Personal Info section **Identity Edit — Personal Info section. Personal Information:**\ \ • Display name\ • Bio\ • Profile image\ • Email\ • Website\ \ Each field has a visibility setting.
### Social Links **You can add verified social links to your identity:**\ \ • Telegram\ • X (Twitter)\ • LinkedIn\ • GitHub\ • Mastodon\ • Instagram\ • YouTube\ \ Social links section with visibility selectors.
**Each link can be set to:**\ \ • Private: Default setting. Visible only to you and authorized middleware.\ • Gen6: Visible to authenticated Gen6 users only.\ • Public: Visible to everyone. Ideal for creators, validators, influencers, and public profile. ### Location Information Optionally, you may add location data. Location selection (Select Country). Location data is never required and always permission-controlled.
### Expertise Tags - coming soon Expertise tags are automatically assigned based on your Gen6 activity. These tags help establish credibility without exposing personal data.
### Custom Fields You can add fully customizable fields to your identity. Custom Fields section (Add Custom Field).
**Examples:**\ \ • Company\ • Role\ • Project\ • Interests\ \ Each custom field has its own visibility setting. ### Badge Verification
The Badge is a trust and verification layer within the Gen6 ecosystem that helps distinguish verified and authentic identities from unknown or potentially misleading accounts. Unlike traditional centralized verification systems, the Badge is not merely a visual badge or platform-controlled status symbol. The verification process is backed by an on-chain blockchain transaction connected to the user’s Gen6 Identity. This creates a cryptographically verifiable proof that the verification request exists and is tied to the identity owner. ### What the Badge Represents A Badge indicates that: • The identity has been reviewed by the Gen6 team or ecosystem moderators\ • The user controls the linked wallet and Gen6 Identity\ • The verification state exists on-chain\ • The profile is considered authentic within the Gen6 ecosystem\ • The account may gain access to additional trusted community features The Badge does not expose sensitive personal information and does not require public disclosure of private identity data. ### Verification Types When requesting verification, users can choose between three verification types: • **Human** — for individual users who want to verify that they are a real person\ • **Organization** — for companies, projects, communities, or official entities\ • **Machine** — for devices, systems, bots, infrastructure, or machine-based identities These verification types help distinguish different kinds of identities within the Gen6 ecosystem and make it easier to understand whether an identity represents a person, an organization, or a machine. ### Why Badge Matters As AI-generated profiles, deepfakes, impersonation, and manipulated content become increasingly common, visual trust alone is no longer sufficient. The Badge introduces blockchain-backed verification into digital identity management by combining wallet ownership, cryptographic verification, on-chain proof, and user-controlled identity. This helps users identify trusted profiles, reduce impersonation risks, build ecosystem reputation, and participate in trusted communication environments. ### Badge verification is considered a contribution to the Gen6 ecosystem. Users who successfully obtain a Badge verification are eligible to receive a 1.5 GSX reward. **To request the reward**:\ *• Send an email to , or contact one of the verification experts through their available contact channels*\ *• Include the Gen6 address used during the Badge verification request*\ *• Request the 1.5 GSX contribution reward* The verification process helps strengthen the trust and authenticity layer of the Gen6 ecosystem by supporting verified identities and reducing impersonation risks. **Current Gen6 Verification Experts:** * [g6A8CaEo9ECfnatQUvT8DWpXpXQo98jpBEeWoLCgo5PxtdJFU](https://gen6.app/identity/g6A8CaEo9ECfnatQUvT8DWpXpXQo98jpBEeWoLCgo5PxtdJFU) * [g68peU7NpHnfqCLp5zWrVPMppayr3oZ7fiWKYRrjq7A4PKrhz](https://gen6.app/identity/g68peU7NpHnfqCLp5zWrVPMppayr3oZ7fiWKYRrjq7A4PKrhz) * [g6CCJ4jjxqDVnbPaJBf1XAFcrbDfnEXotc8ganYHQnAQsPEtT](https://gen6.app/identity/g6CCJ4jjxqDVnbPaJBf1XAFcrbDfnEXotc8ganYHQnAQsPEtT) * [g69XYZrrDBR7TcfSVcV9uwG8Srh17BJV6KnyYXosKqCGcMvyK](https://gen6.app/identity/g69XYZrrDBR7TcfSVcV9uwG8Srh17BJV6KnyYXosKqCGcMvyK) * [g67iWtLRpUYcLssDr1SFDB3UiJS3SJYVHhnTpqbLS4XwJDpZg](https://gen6.app/identity/g67iWtLRpUYcLssDr1SFDB3UiJS3SJYVHhnTpqbLS4XwJDpZg) * [g6AkUS6zDbmnv1hjwmYT4vTqwg4XrFFKvJZsAL12w9WnJHrc1](https://gen6.app/identity/g6AkUS6zDbmnv1hjwmYT4vTqwg4XrFFKvJZsAL12w9WnJHrc1) * [g68KRNPD8uLmSgqijsWSXQZ1Totnt6MSKbW5SAzorjfZQnkfG](https://gen6.app/identity/g68KRNPD8uLmSgqijsWSXQZ1Totnt6MSKbW5SAzorjfZQnkfG) * [g693RVWSVSUfMAyhRCcntvkUt8CfYs2KibFAsN3J6rs5N2udk](https://gen6.app/identity/g693RVWSVSUfMAyhRCcntvkUt8CfYs2KibFAsN3J6rs5N2udk) Ask the Gen6 Verification Experts to verify you. Under the current setup, at least two experts must confirm your request, and this threshold is expected to increase as the network scales. ### How to Apply for Badge Verification To request a Badge, you must first create your Gen6 Identity.
After your Identity has been created, open your Identity profile and select Request to get verified.
Choose the verification type that applies to you: Human, Organization, or Machine. After selecting the verification type, submit the verification request. This requires signing a blockchain transaction, which anchors the verification request on-chain and connects it to your Gen6 Identity.
Once the request has been submitted, contact Gen6 Support or the community moderators. Send them your G6 address and your Gen6 Identity link so they can review your request and confirm that the identity represents a real human, organization, or machine identity. **Recommended process**: 1. Create your Gen6 Identity 2. Complete your identity profile 3. Add relevant social links or public information, if available 4. Open your Identity profile 5. Select Request to get verified 6. Choose the correct verification type: Human, Organization, or Machine 7. Submit the request and sign the blockchain transaction 8. Contact Gen6 Support or community moderators 9. Send your G6 address and Gen6 Identity link 10. Complete the review and verification process Once approved, the Badge becomes part of your verified identity status within the Gen6 ecosystem. ### Verified Badge Display After a successful verification, the Badge becomes visible on the user’s Gen6 Identity profile.
For Human verification, the Badge appears next to the profile image, indicating that the identity has been verified as a real human within the Gen6 ecosystem. This provides a clear visual indicator while the underlying verification remains backed by an on-chain transaction tied to the user’s Gen6 Identity. ### Important Notes • Badge verification is not automatic\ • A verification request requires an on-chain transaction\ • Users must contact Gen6 Support or community moderators after submitting the request\ • Verification may be denied or revoked in cases of impersonation, abuse, misleading activity, or behavior that does not align with the Gen6 community standards\ • A Badge may also be revoked if the identity owner changes category or requests a different verification type. For example, switching from Human to Organization requires a new review and validation process\ • If the Gen6 community or moderators determine that an identity is no longer suitable for verified status, the Badge may be removed\ • Holding a Badge does not grant ownership, authority, or official partnership status within Gen6\ • The system is designed to support trust and authenticity, not social hierarchy # Real Seal - Proofs of Reality Real Seal is a decentralized, blockchain-based signing tool within the Gen6 ecosystem that allows\ users to cryptographically sign and verify documents, texts, or URLs.\ \ It provides a tamper-proof proof of authenticity, ensuring that signed content has not been altered\ after the moment of signing. Was this content created by this identity, and has it remained unchanged since signing? By anchoring cryptographic hashes on-chain, Real Seal answers this question and enables trustless verification without relying on centralized authorities or intermediaries. The Real Seal security and trust model is based on minimal trust and user ownership, where only cryptographic hashes are stored on-chain while the original content remains unchanged. Identity-linked signatures prove ownership, and there is no centralized authority or intermediary, ensuring fully trustless verification. Any modification to the original content leads to verification failure. The system involves a blockchain pallet (dataRegistry), middleware (G6 MW), an API (G6 MW API), and a storage model with cryptographic hashes on-chain and off-chain storage via G6 MW or custom solutions. ### Accessing Real Seal Real Seal is available as a dedicated dApp inside the Gen6 platform.
### Logging In & Authentication To access and use Real Seal, click Connect and sign in using one of the available authentication\ methods.
**You can authenticate using:** • Wallet login (recommended)\ • Google login (optional, non-custodial)\ \ Choose Login Method modal (Use Wallet / Log in with Google). Wallet-based login ensures full cryptographic control over signing and verification actions in Real Seal. When logging in with a wallet, all signed texts, URLs, or documents are directly associated with the cryptographic identity of the connected wallet address.\ \ Google login provides a simplified, non-custodial authentication flow via Gen6 Identity. In this case, users can access Real Seal without interacting with a wallet during login, while all signatures and verifications remain cryptographically provable and linked to the user’s Gen6 identity. ### Real Seal Interface Overview **The Real Seal interface is organized into three main sections:** • My Documents – Files uploaded and signed by the user\ • Shared With Me – Documents shared by other users\ • Texts & URLs – Signed text statements and URLs This structure allows users to manage both document-based and non-document-based proofs from one place.
#### My Documents – Upload & Sign The My Documents section is the central workspace in Real Seal, where users can upload, sign, manage, and verify their own documents. After logging in, users are automatically redirected to My Documents, which displays all documents they have uploaded or interacted with. #### Upload & Sign To upload and cryptographically secure a document, click the Upload & Sign button in the top-\ right corner of the My Documents view.
**This opens the Upload Document modal, where you can:**\ \ • Select a file to upload (maximum size: 20 MB)\ • Optionally provide a document title\ • Review blockchain transaction details before submission
**Once confirmed, Real Seal performs the following actions:**\ \ • Generates a cryptographic hash of the document\ • Stores the hash on-chain using the dataRegistry pallet\ • Records the transaction via the Gen6 Middleware (G6 MW) **After a successful upload:** • The document appears in the My Documents list\ • A blockchain confirmation notification is shown\ • The document hash becomes verifiable and immutable
#### Document Actions Menu Each document row includes an Actions menu (three-dot icon) that provides full control over the\ document lifecycle.\ \ **Available actions include:**\ \ • Download – Download the original uploaded file\ • Share – Share the document with other users\ • Verify/Sign – Verify the document’s cryptographic integrity and on-chain record\ • Make Public – Generate a publicly accessible, verifiable version\ • Delete – Permanently remove the document (owner only)\ \ All actions preserve the original on-chain hash and do not alter the integrity of previously recorded data.
### Shared With Me The Shared With Me section displays all documents, texts, or URLs that have been shared with\ you by other users through Real Seal. This view allows recipients to securely access and verify shared content without requiring ownership of the original file. #### Document Actions Menu Each document row includes an Actions menu (three-dot icon) that provides full control over the\ document lifecycle.\ \ **Available actions include:** • Download Download the shared document in its original form.\ • Verify Verify the integrity and authenticity of the document. All actions preserve the original on-chain hash and do not alter the integrity of previously recorded\ data. This process checks whether the file’s hash matches the value stored at the time of registration, ensuring the content has not been altered. Verification does not modify the document and does not require signing or ownership.
### Signing Texts and URLs Real Seal allows signing non-file content, such as written statements or URLs, making it ideal for\ declarations, claims, or references.
**Signing Flow:**
1. Navigate to Texts & URLs 2. Click Sign Text / URL 3. Select the content type: \ • Text \ • URL 4. Enter the content 5. (Optional) Add a title 6. Click Sign
### **Successful Signing & Blockchain Anchoring** **Once the signing process is completed:** • A cryptographic hash of the content is generated\ • The hash is stored on the Gen6 blockchain\ • The signature is linked to the user’s Gen6 Identity A confirmation message indicates that the content has been successfully signed and anchored.
### Signed Texts & URLs Overview **All signed entries appear in a structured list with the following information:** • Content preview or title\ • Type (Text or URL)\ • Date and time of signing\ • Signature hash\ • Actions menu This list acts as a permanent, auditable record of signed statements.
### Viewing Signed Content Using View Content, users can open a detailed view of the signed data. \ \ **This view displays:** • The original content\ • Timestamp\ • Signature reference\ • Immutable proof context
### Verification Every signed item can be verified at any time. \ \ **Verification confirms:** • Content integrity\ • That the content matches the on-chain hash\ • That the signature is valid\ • That the content has not been altered ### Public Sharing & Proof Links Real Seal allows users to create public verification links.
**By selecting Make Public:** • A public link is generated\ • Anyone with the link can verify the content\ • No Gen6 account is required for verification\ \ This is ideal for public disclosures, legal proofs, or external sharing.
### Document Filters Real Seal provides advanced filtering options to help users quickly locate documents. By clicking the Filters button, a filter panel opens where documents can be narrowed down based on multiple criteria.\ \ **Available Filter Options**\ \ **The following filters are currently supported:** • Date (Filter documents by upload date using a calendar-based selector.) • File Size (Define a minimum and maximum file size range (in MB) to filter documents.) • Format (Filter by file type (for example: PNG, PDF, TXT, or All formats)). \ \ Each filter can be applied individually or combined for more precise results.\ \ **Applying and Clearing Filters:** • Click Apply Filters to update the document list based on selected criteria\ • Click Clear to reset all filter values and return to the full document list\ \ Filtering is applied client-side and does not modify document metadata or blockchain records.
### Privacy Control Users remain fully in control of visibility. At any time, public content can be reverted to private using Make Private, instantly disabling external access.
# NCrypt - Encrypted Messaging NCrypt is a secure, decentralized Web3 messaging platform designed to provide private, tamper-\ proof, and verifiable communication on the blockchain. By leveraging end-to-end encryption combined with on-chain key management, NCrypt ensures that messages remain confidential and protected from unauthorized access.\ \ All encryption operations are performed locally in the user’s browser. Public encryption keys are\ published on-chain, while private keys remain fully under user control. This architecture eliminates\ centralized intermediaries and significantly reduces the risks associated with traditional messaging platforms.\ \ NCrypt also supports optional read-proof verification, enabling cryptographic confirmation that a\ message has been opened. This makes NCrypt suitable for both everyday private communication\ and use cases requiring verifiable message delivery and reading. **To use NCrypt, a minimum deposit of 1 GSX is required**, granting access to encrypted messaging features and supporting the platform's decentralized infrastructure. The system utilizes the postman pallet, G6 MW API, and stores data on IPFS or custom solutions. ### Access & Authentication To use NCrypt, users must authenticate before accessing encrypted messaging features.\ \ **Supported authentication methods:**\ \ • Wallet-based authentication (recommended)\ • Google authentication (non-custodial, optional)\ \ Regardless of the chosen method, encryption keys are generated and managed entirely on the\ client side, preserving privacy and user ownership.
### Encryption Key Setup Before sending or receiving messages, users must configure their encryption keys. #### Generate Encryption Keys NCrypt allows users to generate a secure x25519 encryption key pair directly within the application.\ \ • The private key is stored locally in the user’s browser\ • The public key is published on the blockchain\ • A backup phrase is provided and should be stored securely\ \ This key pair is required to encrypt outgoing messages and decrypt incoming messages.
#### Viewing Encryption Keys After keys are generated, users can view their encryption keys at any time.\ \ **From the NCrypt interface:**\ \ • Click View encryption keys\ • A secure modal opens displaying:\ • Private key (backup phrase) – hidden by default\ • Public key – safe to share and published on-chain\ \ Security warnings are shown to ensure safe handling of sensitive data.
#### Revoking Encryption Keys **NCrypt allows users to revoke encryption keys in two different ways:**\ \ **Revoke from Blockchain**\ \ • Removes the public key from the blockchain\ • Prevents others from sending new encrypted messages\ • Private key remains stored locally\ • Keys can be republished later if needed\ \ **Remove from Local Storage**\ \ • Permanently deletes the private key from the browser\ • Existing encrypted messages can no longer be decrypted\ • This action is irreversible\ • Backup phrase is required for recovery
#### Import Encryption Keys Users who already possess a backup phrase can import their existing encryption keys. This enables seamless access across devices while maintaining full cryptographic control.
### Encrypted Messaging Once encryption keys are configured, users can start secure communication.\ \ **To send a message:**\ \ • Create a new message\ • Specify the recipient’s public address\ • Compose the message
All messages are encrypted locally before transmission, ensuring that message content is never\ exposed in plaintext.
### Read Proof Messages NCrypt supports read-proof–enabled messages, providing cryptographic assurance that a message has been opened.\ \ • Senders can enable read-proof protection per message\ • Recipients unlock the message by signing on-chain\ • The read event is verifiable and tamper-proof\ \ This feature enables optionally undisputable communication without revealing message content publicly.
### Key Lifecycle Management NCrypt provides full control over encryption keys, allowing users to manage their cryptographic identity over time. Public keys can be published or revoked on-chain, while private keys remain under exclusive user control. This ensures long-term security and flexibility without reliance on centralized key storage. # Gen6 Public Chain Basics #### **General** **Name:** Gen6 Public Chain **Wallets supported:** Gen6 App, SubWallet, PolkadotJS **Login options:** Self-Custody, Apple, Google You can use these wallets to interact with Gen6 Apps, services and tools. #### **Whitepaper** You can download the White Paper [**here (IPFS)**](https://uncertain-aqua-crawdad.myfilebase.com/ipfs/QmanQhSspYq4puqLVGLPn3FYMoyn7MXGi2LkohdLJWnZjE)**.** It is a single document about the ecosystem and what Gen6 is doing. SHA512 sum of the white paper for verification: 
6b6e1af2d44b27d0942875ccf40a379b426c9d8af1b3fa04fd270b04ea2172aa08c06e3570d98762df5e6f5b2a5928c8e6f597fa3c5f7b2bf72b0d81b4f1c776
#### **Existential Deposit** 0.1 GSX is the minimum balance you need to have to be your account active on the blockchain. Otherwise it gets deactivated and nodes won't keep it in their memory. If you increase your balance again over 0.1 GSX on the same account, it gets activated again. # Gen6 Dictionary **Validator**\ A participant in the Gen6 network responsible for creating blocks and securing the blockchain. Validators are essential for consensus and trust. **Validator Owner**\ The individual or entity that controls and manages a validator. The owner sets it up, maintains it, and is ultimately responsible for its performance. **Node**\ Validators are often referred to as "Nodes". It is not an official terminology, but used by the community like "node" or "validator node". **Blockchain Administrator**\ A person responsible for managing and maintaining the blockchain network's nodes and infrastructure. In Gen6, a blockchain administrator ensures nodes and validators run smoothly, applies software updates, monitors performance, enforces security policies, and helps keep the ecosystem stable and reliable. **Blockchain Network**\ A system of interconnected computers (called nodes) that work together to maintain a shared digital ledger. In a blockchain network, every transaction is recorded, verified, and stored across all nodes, making the system secure, transparent, and resistant to tampering. The Gen6 blockchain network is powered by validators and community participants who keep it decentralized and trustworthy. **G6 Network**\ The organization behind the development and growth of the Gen6 ecosystem. G6 Networks builds the infrastructure, tools, and services that power the network, driving innovation in decentralized identity, governance, and blockchain-based applications. **G6 aka G6 Technology**\ The core blockchain technology developed by G6 Networks. Built on Substrate, G6 provides a secure, scalable, and fast foundation for decentralized applications, digital identity, and peer-to-peer value exchange. **Gen6 Community**\ The global community of people who use, build on, and contribute to the Gen6 ecosystem. The Gen6 community values support, collaboration, and shared growth, forming the social layer that gives life to balance between real life and technology. **Parking**\ The act of locking up GSX tokens to secure them and to support the ecosystem. In return, participants earn rewards for contributing to personal and network security. Parked tokens cannot be transferred, so even if a private key is compromised, there might be enough time to take action to secure the funds through Gen6 Governance. **Substrate Address**\ The address format native to Substrate (the framework Gen6 is built on). It’s used for managing assets and identities in Gen6. **Gen6 Address**\ A unique identifier used to send, receive, and interact within the Gen6 ecosystem. **Gen6 Identity**\ Your verified profile in the Gen6 ecosystem. It connects your addresses, trust score, and on-chain reputation. Notably, we don't use the "profile" terminology. **Gen6’s LinkFree aka Gen6 Me** A decentralized, blockchain-powered alternative to traditional “link-in-bio” tools. LinkFree lets users create a profile with all their important links - socials, websites, projects, and wallets - while keeping full ownership of their data and identity. Unlike centralized platforms, Gen6's LinkFree is transparent, censorship-resistant, and connected to the wider Web3 ecosystem. **Token**\ A digital unit of value created and managed on a blockchain. Tokens can represent many things: assets, access rights, governance power or currencies. In the Gen6 ecosystem, the GSX token is used for using dApps, enabling permission systems, governance, asset transfers and rewarding community participation. **GSX**\ The native token of Gen6. It powers transactions, staking, governance, and ecosystem activities. **Governance**\ The process by which GSX holders vote on proposals, upgrades, and rules that shape the future of the Gen6 network. **DAO (Decentralized Autonomous Organization)**\ A community-led structure where rules and decisions are made transparently on the blockchain, without centralized leadership. **Blockchain Consensus**\ The mechanism by which nodes in Gen6 agree on the state of the blockchain. It ensures everyone shares the same, verified history. **Web2**\ The traditional, centralized internet where most services are controlled by large corporations. **Web3**\ The decentralized internet built on blockchain and other modern technologies, where users own their data, assets, and identities. **Blockchain**\ A distributed digital ledger that records transactions securely, transparently, and immutably. **Distributed Ledger Technology (DLT)**\ Any system (including blockchain) that allows secure record-keeping across multiple computers without a central authority. **Crypto**\ Short for cryptocurrency and cryptography. Most people typically use it to refer to digital assets like GSX, Bitcoin, or Ethereum. The original term was first used by mathematicians, hackers and crypherpunks referring to cryptography. Better to avoid the use of this word. **Cryptocurrency**\ A digital form of money secured by cryptography and powered by blockchain, enabling direct, peer-to-peer transactions. **Cryptography**\ The science of securing data through mathematical methods, ensuring privacy, authenticity, and protection against fraud. **Storage**\ The act of keeping digital data safe for future use. In blockchain and Web3, storage can be centralized (servers controlled by companies) or decentralized (data distributed across many independent nodes). Decentralized storage ensures resilience, transparency, and freedom from single points of failure. **IPFS (InterPlanetary File System)**\ A decentralized storage and file-sharing network that allows data to be stored and accessed across multiple nodes instead of relying on one central server. IPFS is often used in Web3 for hosting websites, storing NFTs, and sharing large files securely. **Bitcoin (BTC)**\ Bitcoin is a decentralized, peer-to-peer digital currency. The first cryptocurrency, launched in 2009 by the pseudonymous creator(s) Satoshi Nakamoto. Bitcoin introduced the world to blockchain technology and is primarily used as a decentralized digital currency and store of value. It started the movement towards Web3 and a more decentralized internet. **Nick Szabo**\ A computer scientist, legal scholar, and cryptographer who is widely credited with inventing the concept of the *smart contract* in the 1990s. Szabo is also known for his work on digital money systems like *Bit Gold*, which strongly influenced Bitcoin. While not confirmed, some in the crypto community have speculated that he could be Satoshi Nakamoto or part of them team creating Bitcoin. He is the author of the original Smart Contract idea. **Smart Contract**\ A self-executing program that automatically carries out an agreement when predefined conditions are met. In Web3, smart contracts remove the need for intermediaries, ensuring trust, transparency, and automation in transactions and applications. They are also the backbone of decentralized finance (DeFi), NFTs, and many Web3 platforms. **Ethereum (ETH)**\ A blockchain platform launched in 2015 that expanded blockchain’s use beyond digital money. Ethereum introduced smart contracts (programs that run on the blockchain, inside Ethereum Virtual Machine aka EVM) enabling decentralized applications (dApps), decentralized finance (DeFi), and NFTs. Its native currency is called Ether (ETH). First to enable decentralized smart contracts and execution on-chain, but with serious scaling and privacy limitations. Co-founders of Ethereum are Vitalik Buterin and Dr. Gavin Wood (code author of EVM). **Polkadot**\ A modern blockchain platform designed to connect multiple blockchains into one unified network. Created by Dr. Gavin Wood, Polkadot enables different blockchains to securely exchange data and assets. Its goal is to make the Web3 ecosystem interoperable, scalable, and upgradeable. Polkadot is built on the Substrate framework, the same technology that powers Gen6. **Trading**\ The act of buying and selling assets such as cryptocurrencies, tokens, or traditional financial instruments, often with the intention of making profit. While trading provides liquidity to markets and movement, in practice it is rarely a useful or value-creating activity. Most trading is motivated by pure profiteering, where the focus is financial gain in the expense of others and not building or contributing to healthy ecosystems. **Artificial Intelligence (AI)**\ The field of computer science focused on building systems that can perform tasks requiring human-like intelligence - such as learning, problem-solving, pattern recognition, and decision-making. In the Gen6 context, AI can help analyze blockchain data, but cannot see private or communication data. **Large Language Model (LLM)**\ A type of AI trained on massive amounts of text to understand and generate human-like language. LLMs can answer questions, create content, and provide insights by predicting what words should come next. **Big Data**\ Extremely large and complex sets of data that traditional tools cannot process efficiently. Big data techniques allow Gen6 and other ecosystems to analyze trends, detect patterns, and make data-driven decisions at scale. **Machine Learning (ML)**\ A branch of AI where systems improve their performance automatically by learning from data, without being explicitly programmed for every task. ML powers predictive analytics, fraud detection, and personalization. **Neural Networks**\ Computer models inspired by the human brain, used in AI and LLMs to recognize complex patterns in data, like language, images, or behavior. **Natural Language Processing (NLP)**\ The AI discipline that enables machines to understand, interpret, and respond to human language. NLP is the backbone of LLMs. # Workshops & Courses Under this section you find the already existing workshops and courses. For enquires of eductation, please contact us directly on the official Gen6 identity through NCrypt: Alternatively you can message us at as well. # Blockchain Essentials: From Zero to Gen6 #### **Course Overview** This course takes participants from having zero knowledge of blockchain to understanding its fundamentals, how Gen6 operates, and how to interact with blockchain systems. The full course is approximately 5 hours, including breaks. Successful participants get a Statement of Accomplishment, signed by the Gen6 Founder. We cover theory first, but focus on hands-on experience with real-life examples and simple tasks to reinforce learning. The course materials are publicly accessible, encouring open knowledge sharing and open-source ecosystems. The only requirement for the course is your sharp attention and a mobile (or laptop) in DND mode. We will install SubWallet during the course. #### **Module 1: Introduction to Blockchain** *(40 minutes)* * **Core values of Blockchain** * Immutability, digital signatures, distributed security * **What is Blockchain?** * Definition and basic concepts (Distributed Ledger, Decentralization, Immutability) * **Brief History of Blockchain** * Bitcoin, Ethereum, Gen6 * **Reality Check: Where to apply Blockchain and how to use the G6 Middleware?** * Use-cases and real-life scenarios * Proof and timestamp immutability (eg. IP protection and dispute cases) * High-security system, even if ⅓ is destroyed, it still functions fully * Security of funds (until you have your keys) and censorship resistance * Saving human history with proofs of events * With G6 MW: Anti-Deepfake solution * With G6 MW: Data Anonymization * With G6 MW: Modern Identity solution, digital signature and messaging system * With G6 MW: Tokenization of assets (eg. energy or real world assets) **Hands-on:** watch short intro video. #### **Module 2: The Key Components of Blockchain** *(45 minutes)* * **Blocks, Hashes, and Chains:** * What makes up a block? (Data, Timestamp, Hash, Transactions) * How blocks link together in a chain * Proofs on every node: consensus mechanism * **Wallets** * Cold vs Hot wallet * CEX vs DEX wallets **Hands-on:** Install SubWallet and create your first account. Save seed words in your password manager or on paper. #### **Module 3: Understanding and using Gen6: The Gen6 App and IPX** *(50 minutes)* * **Topology of G6 technology and Gen6 ecosystem** * From Web2 to Web3, the way is Web2.5 and the G6 MiddleWare * G6 is a technology, including its services, tools, provided by Crypto CTF. * Gen6 is the community, running the Gen6 Public Blockchain, backed by Gen6 Foundation * Visualization, architecture topology * GGS-1: The Gen6 Identity Standard **Hands-on:** Send your g6 address, open Gen6 App and submit your first decentralized transaction on Gen6 and create your own Identity. Verify each other's identity on Gen6.me. **Optional:** Live hacking and debunking a fake identity! #### **Module 4: The Matter of Blockchain Administrators** *(20 minutes)* * New profession: Blockchain Administrator. * Tasks of Blockchain Administrators * Where and how to find them? * Enroll your IT staff for the course * Live demo on interacting with Blockchain Nodes * Gen6 Ops Manager * Enrolling validators * Securing keys * Update, freeze and restart * PolkadotJS developer interface #### **Module 5: Future of Blockchain, Adoption and Next steps** *(20 minutes)* * **What's Next for Blockchain and Middleware technology?** * **Blockchain in Action:** * Web 2.5, G6 Middleware bringing adoption * GGS-1 Identity Standard * Cryptocurrency * Decentralized Finance (DeFi / DEX) * Immutability, borderless communities and future-living * **How to Continue:** * More materials: * Join the community: * Business inquires: * Apply to enroll in the Blockchain Administrator Course (Q1 2025, 3 months) * Gen6 Ecosystem Expert Certificate (Q3 2025, 3 months) Those who successfully create their Gen6 Identity during the course and proves it to the Instructor, will receive a Statement of Accomplishment, signed by G6 Co-Founders. # Blockchain Administrator - Exam Process and Certification The **Blockchain Administrator** course is designed for individuals who will be responsible for overseeing the setup, configuration, maintenance, and optimization of blockchain infrastructure. During the course we focus on Gen6 ecosystem's technology as currently it is the only fully manageable blockchain product on the market. This role focuses on technical expertise, operational management, and ensuring the smooth operation of the blockchain network. **Requirements for course:** * Familiarity with IT systems * Comfort using laptops, PCs and installing software * Basic understanding of computer networks (domains and IP addresses) * Basic understanding of filesystems and folder structures * Basic Linux knowledge * Laptop (preferably with Linux) * Mobile phone (preferably Android) * Hardware wallet (optional, but highly recommended) ### **Syllabus** **Module 1: Introduction to Gen6 Blockchains** * Overview of Gen6 Technology * Key Features of Gen6: Validators, Substrate Framework, EPoA Consensus, Middleware, and Distributed Storage * Blockchain Basics: Concepts, Types, Use Cases and Limitations * The Role of Blockchain Administrators **Module 2: G6 Architecture and Infrastructure** * Substrate Framework: Architecture and Customization * Full Node and Validator Configuration * Distributed Storage Network (DSN) Management * G6 Middleware: Integration and Management * Optimizing Blockchain Nodes for Performance and Scalability **Module 3: G6 Consensus and Security** * Enhanced Proof-of-Authority (EPoA) Consensus Mechanism * Blockchain Security Best Practices * Key Management and Cryptography in Gen6 * Security and Privacy in Decentralized Systems * Handling Attacks and Threat Mitigation **Module 4: Network Operations and Monitoring** * Monitoring Blockchain Health: Tools and Techniques * Managing Node Lifecycles: Deployment, Updates, and Decommissioning * Real-Time Resource Tracking and Performance Management * System Troubleshooting and Issue Resolution **Module 5: System Integrations and Automation** * Integrating Gen6 Blockchain with External Systems (Web2 & Web3) * Automating Processes with Gen6 SDK and APIs * Orchestrating Services with Gen6 Middleware * Deploying and Managing dApps on Gen6 **Module 6: Governance and Compliance** * Understanding Gen6's Governance Model * Regulatory Compliance (GDPR and Data Privacy) * Managing User Permissions and Access Control * Implementing Best Practices for Blockchain Governance **Module 7: Tools and Reporting** * Using G6 Ops Manager for Node and Infrastructure Control * Reporting and Logging for Blockchain Activities * Performance and Usage Analytics * Maintaining Audit Trails and Logs **Module 8: Advanced Blockchain Administration** * Optimizing Transaction Throughput and Block Time * Managing Tokenomics and Smart Contract Execution * Scalability Solutions for Enterprise-Grade Blockchain Applications * Disaster Recovery and Backup Solutions for Blockchain Data **Module 9: Practical Application and Case Studies** * Real-World Scenarios for Blockchain Administrators * Hands-on Lab: Setting up, Configuring, and Optimizing a Gen6 Blockchain Node * Case Study: Managing a High-Volume Blockchain Network ### **Official Certification** The following steps will be necessary to succeed with the certification. **Preparation** 1. Prepare for the exam by reading the Gen6 wiki thoroughly and learning/practicing Gen6 basics through the Gen6 App. Prepare with at least basic linux skills and test the G6 Manager before the exam start. 2. Prepare your system: Meet system prequisites (linux system requirements, cpu, ram, ssd, etc) **Exam Registration** 1. To start the exam, first acquire the Green Badge, then Sign the message: "I want to become a Blockchain Administrator." with Real Seal, and send the link to @Gen6. 2. Contact @Gen6 in NCrypt with your signed message link, to get the Validator ID + Secret, which you need to enroll your validator with. **Exam Practice and Test** 1. Download and verify the Gen6 Manager binary (Shared by @Gen6 user) 2. Start the Gen6 Manager 1. IF you use remote server: we recommend SSH forwarding with -D option 2. Make sure your validator gets into "New status", then Grandap and Aura keys will be registered on-chain. Validation needs to start then. If your setup is correct, all this happens automatically. 3. Wait a few minutes for joining the Exam blockchain. 4. If you see Status = Active, then you are good, you can move on to fill the test. 3. Keep the validator running it for 72 hours without slashing (this is necessary to pass). 4. Fill the exam's theoretical test -> LINK (tba anti-ai kerdesek) 5. Final practice test: After 72 hours, freeze your validator. 6. When freeze is successful you have passed the partice part. **Exam validation period** 1. After 72 hours, if you passed, Gen6 will send the notification on NCrypt + the Certificate 1. You fail the exam if: 1. Your test results is below 83% 2. You freeze your validator during the 72 hours 3. If you cannot freeze your validator 4. If your validator gets slashed **Certification** After passing the exam Gen6 will contact you on NCrypt and send you the officially issued and signed Blockchain Administrator Certificate. # Gen6 Blockchain Adminisatrator - Course Material Material update in progress. ## Gen6 Manager Gen6 Manager is a technical, server side tool for setting up, managing and monitoring Gen6 Validator nodes. It is designed for Blockchain Administrators, SLA Providers and validator owners who want a simple, GUI-based interface instead of working directly with the command line. Gen6 Manager handles everything from first-time enrollment to day-to-day monitoring and key backup. ### Getting Gen6 Manager Gen6 Manager is distributed by the Gen6 team. To receive the binary: 1. Obtain the Green Badge (verified human identity) on your Gen6 account 2. Sign the message: `"I want to become a Blockchain Administrator."` using [RealSeal](https://gen6.app/real-seal) 3. Send the RealSeal link to **@Gen6** via NCrypt 4. The Gen6 team will send you the Gen6 Manager binary along with your **Validator ID** and **Secret** Always verify the binary hash before running it. The correct hash is shared by the official @Gen6 identity. ### Functionality Guide #### 1. Easy Enroll **What it does:** Registers your validator on the network using the Secret provided by the Gen6 team. **When to use it:** First time setup, or when enrolling a new validator. **Steps:** 1. Open Gen6 Manager 2. Select **Easy Enroll** 3. Enter your **Secret** (sent to you by the Gen6 team) 4. Gen6 Manager configures your validator automatically, including AURA and GRANDPA key registration on-chain 5. Wait for the status to show **New** — this confirms enrollment > Your Secret is private. Do not share it with anyone. #### 2. Start New Validator **What it does:** Starts your validator for the first time after enrollment and begins active participation in the network. **When to use it:** After Easy Enroll completes and your status shows **New**. **Steps:** 1. Select **Start New Validator** 2. Gen6 Manager registers your AURA and GRANDPA public keys on-chain 3. Your validator joins the active rotation 4. Status changes to **Active** within a few minutes > Once Active, your validator begins producing blocks and earning 0.05 GSX per block. #### 3. Freeze **What it does:** Temporarily pauses your validator. It stops producing blocks but remains enrolled in the network. **When to use it:** Planned maintenance, hardware upgrades, or temporary downtime. **Steps:** 1. Select **Freeze** 2. Confirm the action 3. Your validator enters a **2-day cooldown** before it can restart > After freezing, you must wait 2 full days before using Restore to resume validation. A non-slashed validator can freeze at any time. #### 4. Restore **What it does:** Resumes validation after a Freeze or a Slash. **When to use it:** * After a planned Freeze (wait 2 days first) * After a Slash penalty (wait 10 days first) **Steps:** 1. Select **Restore** 2. Gen6 Manager re-registers your validator in the active rotation 3. Status returns to **Active** > If you do not call Restore after 2 days following a Freeze, validation will not restart automatically — you must trigger it manually. #### 5. Delete Validator **What it does:** Permanently removes your validator from the network and clears its configuration. **When to use it:** Decommissioning a node you no longer intend to run. **Steps:** 1. Select **Delete Validator** 2. A confirmation prompt appears: **"Are you sure? This action cannot be undone."** 3. Confirm to proceed 4. The validator is deregistered from the network > This action is irreversible. Make sure you have downloaded a backup of your keys before deleting. #### 6. Set / Change Reward Address **What it does:** Sets the wallet address that receives your validator block rewards (0.05 GSX per block), and optionally splits rewards between multiple addresses by percentage. **When to use it:** Initial setup, or when you want to redirect rewards to a different wallet or split between a validator owner and delegator. **Steps:** 1. Select **Set Reward Address** 2. Enter the Gen6 address (SS58 format, starts with `g6`) 3. If splitting rewards, add additional addresses and assign a percentage to each (must total 100%) 4. Confirm and save > To convert an address to Gen6 format, use [ss58.org](https://ss58.org/) with prefix **355**. #### 7. Monitoring **What it does:** Shows the current health and status of your validator node in real time. **What it displays:** * **Status** — Non-Existent / New / Active / Warned / Slashed * **Is it running?** — Live connection check to your node * **Disk space** — Current usage vs. available storage * **CPU usage** — Load on your processor **When to check it:** Regularly, especially after restarts or system changes. A validator that misses one block enters **Warned** status. Missing a second block results in a **10-day Slash**. > Set up regular monitoring to catch issues before they result in a Slash. #### 8. Download Configuration Backup **What it does:** Exports your full validator configuration including your **AURA key**, **GRANDPA key**, and **Node key** as a single backup file. **When to use it:** After initial setup, and any time you make configuration changes. Store the backup somewhere safe and offline. **Steps:** 1. Select **Download Configuration** 2. Choose a save location 3. Store the backup file securely — this file contains your private keys > Without a backup, you cannot recover your validator if the machine fails. Keep at least one copy in a secure offline location. #### 9. Restore from Backup **What it does:** Loads a previously exported configuration file and prepares a validator node from it. Useful for migrating to new hardware or recovering after a failure. **When to use it:** Hardware replacement, server migration, or disaster recovery. **Steps:** 1. Select **Restore from Backup** 2. Select your backup file 3. Gen6 Manager loads your AURA, GRANDPA, and Node keys from the file 4. Your validator is prepared and ready to start 5. Use **Start New Validator** or **Restore** to bring it back online > Make sure the original node is fully offline before starting a restored validator. ### Validator States | State | Meaning | | ---------------- | ---------------------------------------- | | **Non-Existent** | Not enrolled in the system | | **New** | Enrolled but not yet validating | | **Active** | Validating and earning rewards | | **Warned** | Missed one block — warning issued | | **Slashed** | Missed second block — banned for 10 days | A Warned status is automatically cleared after 24 hours if no further blocks are missed. ### Useful Links * Gen6 Explorer: [explorer.gen6.app](https://explorer.gen6.app/) * PolkadotJS (Gen6 chain): [PJS Link](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgen6.app%3A443%2Fnode#/explorer) * SS58 address converter: [ss58.org](https://ss58.org/) (prefix 355) * Software requirements: [wiki.gen6.life/technology-core/gen6-software-minimum-requirements](https://wiki.gen6.life/technology-core/gen6-software-minimum-requirements) * Support: [Discord](https://discord.gg/Z95yBdFGrX) and # Gen6 Ecosystem Expert Course and Certificate ! Content Under Review ! The **Gen6 Blockchain Expert** program is designed for professionals who want to understand the Gen6 ecosystem deeper and blockchain's governance, social, and economic implications. This program is ideal for individuals who wish to apply blockchain technology in real-world scenarios, considering both technical functionality and its societal impact. **Syllabus (Draft)** **Module 1: Introduction to Gen6 and Blockchain Technology** * Understanding Gen6 Ecosystem and Vision * Blockchain Fundamentals: Architecture, Consensus, and Security * Key Gen6 Features: Validators, EPoA, Middleware, Distributed Storage, and Smart Contracts * The Role of Blockchain in Transforming Industries **Module 2: Advanced Blockchain Architecture and Development** * Deep Dive into Substrate Framework and Customization * Understanding Gen6 Consensus: EPoA and Its Benefits * Integrating G6 Middleware for Web2-Web3 Interoperability * Decentralized Storage Solutions and Data Privacy Management * Blockchain Development: dApp Building and Smart Contract Deployment **Module 3: Governance and Regulatory Framework** * Blockchain Governance Models: Decentralized vs. Centralized * Gen6’s Governance System: Roles of Validators, Experts, and Contributors * The Role of Governance in Maintaining Blockchain Integrity * Regulatory Considerations: GDPR Compliance and Data Sovereignty * The Intersection of Blockchain and Legal Systems **Module 4: Social Sciences and Blockchain** * Social Impact of Blockchain: Empowerment, Trust, and Transparency * Blockchain for Social Good: Use Cases in Public Services, Healthcare, and Education * Behavioral Economics and Incentive Structures in Blockchain Networks * Ethical Implications of Decentralized Technology * Blockchain and Human Rights: Ensuring Privacy and Security **Module 5: Tokenomics and Economic Models** * Understanding Tokenomics: Utility, Value, and Governance Tokens * G6’s Tokenomics: GSX Token Allocation, Rewards, and Market Dynamics * Designing Economic Models for Blockchain Applications * The Role of Blockchain in Redefining Ownership and Value Transfer * The Relationship Between Blockchain and Traditional Financial Systems **Module 6: Blockchain’s Role in Governance** * How Blockchain Enhances Government Transparency and Accountability * Digital Identity and Voting Systems: Potential and Challenges * Blockchain for Civic Engagement and Decentralized Decision-Making * Smart Contracts in Governance: Automating Legal and Social Processes **Module 7: Social Behavior and Blockchain Adoption** * Psychological Factors in Blockchain Adoption * Community Engagement and Building Trust in Decentralized Systems * Overcoming Barriers to Mass Adoption of Blockchain Technology * Case Studies: Successful and Failed Blockchain Implementations in Society **Module 8: Blockchain Applications in Governance and Policy** * Blockchain for Public Policy: Transparency, Auditing, and Accountability * The Future of Smart Cities and Blockchain-Enabled Governance * Blockchain for Social Welfare Programs and Government Services * Ensuring Fair and Inclusive Blockchain Adoption **Module 9: Advanced Topics in Blockchain Governance** * Decentralized Autonomous Organizations (DAOs) and Governance * Governance through Stakeholder Engagement and Reputation Systems * Legal and Ethical Implications of Blockchain Governance * Balancing Innovation with Regulatory Constraints **Module 10: Practical Applications and Case Studies** * Real-World Case Studies on Blockchain Governance * Hands-On Project: Designing a Decentralized Governance Model for a Blockchain Application * Case Study: Analyzing the Social Impact of a Blockchain Solution * Examining Tokenomics and Governance in the Gen6 Ecosystem *** # GSX Tokenomics Everything you need to know about GSX. ### What is GSX? GSX is the utility token of the Gen6 ecosystem, a provenance blockchain with identity and trust infrastructure. GSX powers the network that makes the system work: * RealSeal, which signs content so its origin is verifiable and it can be proven unaltered since signing; * NCrypt, the encryption layer and end-to-end encrypted messaging; * The self-sovereign identity that ties these together. * GSX is used for participation in the network, governance and its services. It is a utility token, not an investment instrument. Bringing GSX onto Ethereum through the bridge widens where it can move and be used, while the Gen6 chain remains its home. ### The GSX bridges GSX Bridges move GSX between the Gen6 chain and Ethereum. It lets you take GSX from the Gen6 network onto Ethereum (where it trades as an ERC-20 token) and bring it back again. > **Rollout phase.** The first bridge is new and still stabilising. Use only small amounts until we announce the next phase. Always use the official bridges and verify addresses before sending. > > [*https://br.gen6.app/*](https://br.gen6.app/) ### What the bridges do GSX exists natively on the Gen6 chain. It also exists as an ERC-20 token on Ethereum, at contract address: [0x145dB24BEE365a02000661C16d0EC5C5629a93Cb](https://etherscan.io/address/0x145db24bee365a02000661c16d0ec5c5629a93cb) The bridge connects the two. It supports both directions: * **Gen6 to Ethereum** - send GSX on Gen6, receive GSX on Ethereum * **Ethereum to Gen6** - send GSX on Ethereum, receive GSX on Gen6 The amount is always one to one, minus a small bridge fee. 1 GSX on Gen6 equals 1 GSX on Ethereum. ### How to use GSX Bridges? The flow is the same in both directions. 1. **Open the bridge** and choose your direction (Gen6 to Ethereum, or Ethereum to Gen6). 2. **Enter the address where you want to receive** GSX on the other chain. 3. **Pass the security check.** A short proof-of-work and other checks run in your browser to keep malicious actors out. This takes a few seconds. 4. **A deposit address is generated for you.** It is unique to your transfer. You do not need to add a memo or a tag. The address itself identifies your transfer. 5. **Send your GSX to that deposit address.** Send only GSX, on the correct chain. 6. **Wait for confirmation.** The page shows live progress as the network confirms your deposit. When it is confirmed, the bridge automatically sends GSX to you on the other chain. 7. **Done.** The result page links to both transactions so you can verify them on the block explorers. You can reload the page or return to it later using the link in your browser. Your transfer is tracked there for 24 hours. ### Bridge Limits For your protection during the rollout phase, on the first bridge, transfers limits are strict until Sept 21: * **Minimum:** 20 GSX per transfer * **Maximum:** 50 GSX per transfer Anyone with Service Validator right can deploy additional bridges and get them verified through contacting Gen6 on NCrypt. These limits can be customized on each instance. Deposits below the minimum are held and must be recovered through support ("Refund" call by admin). Deposits above the maximum are held for manual handling also. These limits are likely to be adjusted as the bridge matures. ### Bridge Security A few things keep the bridge safe and keep you safe: * **Unique deposit addresses.** Every transfer gets its own address. You never share an address with another user, and you never need a memo. * **One to one backing.** GSX on Ethereum is backed by GSX on the Gen6 side. The amounts always match. * **Confirmation waits.** The bridge waits for the network to confirm your deposit before releasing funds on the other side. This prevents losses from chain reorganisations. * **Per-transfer limits.** Small caps during the rollout phase limit exposure while the system stabilises. **Please protect yourself:** * Only ever use the official bridge. Do not trust a bridge link sent to you in a direct message. * Verify the deposit address before sending. Copy it directly from the official bridge. * Send only GSX, and only on the chain the bridge tells you to use. * During the rollout phase, use small amounts. *** *** ### Fees The bridge charges a small fee, taken from the amount you bridge. You receive the amount you sent, minus the fee. The exact fee is shown on the bridge before you start. *** ### Detailed Tokenomics GSX functions as a protocol utility token within the Gen6 ecosystem. Its primary purpose is to enable users to access Gen6 App features and coordinate participation across network security, service access, governance and ecosystem operations. GSX is not designed as an investment instrument and does not convey ownership, profit rights or governance claims over Gen6 entities. GSX has a fixed total supply of 80 000 000, allocated across the core functions, incentives, reserves and strategic growth pools that support the long-term development of the Gen6 ecosystem. The structure prioritizes network security, sustainable expansion for Gen6 App services and subscriptions, predictable vesting and responsible management of early circulating supply.
**Validator Rewards — 37.5% (30,000,000 GSX)** Allocated to secure the network through long-term validator and delegator incentives.\ Rewards are distributed gradually based on network activity, providing a stable and predictable issuance curve. **Community Allocation — 17.5% (14,000,000 GSX)** A reserve dedicated to ecosystem engagement and long-term community development, supporting parking rewards, contribution incentives, community programs, airdrops, developer support, and growth initiatives that strengthen participation and expand the Gen6 ecosystem. **CEX & DEX Liquidity — 10% (8,000,000 GSX)** Reserved for centralized and decentralized exchange liquidity.\ Only a portion unlocks at TGE, with further deployment timed to maintain market stability and ensure smooth trading environments. **Team — 5% (4,000,000 GSX)** Vesting: 24-month linear\ Allocated to the core contributors building and maintaining the Gen6 ecosystem.\ The extended vesting period promotes long-term commitment and prevents early market pressure. **Emergency & Stability Reserve — 5% (4,000,000 GSX)** Vesting: immediate\ A reserve that ensures network continuity and security during unforeseen events, used only for emergencies such as infrastructure failures, regulatory or compliance requirements, urgent audits, security measures, or other critical operational needs. This allocation provides resilience and protects the network during exceptional events. **Seed Round — 3% (2,400,000 GSX)** Price: 0.20 USD\ Vesting: 18-month linear\ Allocated to early strategic supporters, angel partners and contributors who participate in the foundational stage of the ecosystem’s development. **Pre-Sale — 3% (2,400,000 GSX)** Price: 0.60 USD\ Vesting: * 8 months-month linear This round enables broad community access prior to exchange listings. **Strategic Growth Fund — 9.5% (7,600,000 GSX)** Vesting: 24-month linear\ A pool supporting external ecosystem expansion through strategic partnerships, enterprise integrations, cross-chain collaborations, validator onboarding incentives, institutional relationships, and market expansion initiatives, accelerating global reach and strengthening Gen6’s strategic position. **Ecosystem Expansion Reserve — 9.5% (7,600,000 GSX)** Vesting: 24-month linear\ A reserve dedicated to internal ecosystem development, funding developer grants, hackathons, infrastructure builders, application incentives, ecosystem R\&D, and community-driven innovation programs to support the continuous growth and evolution of the Gen6 network. *** ### GSX Sale is Over, TGE/Launch done. We are now on Uniswap. ### GSX Seed Round - Happened until May 31 - Over! **Total offer amount:** 2 400 000 GSX **Release:** Monthly, over a period of 18 months from TGE **Price:** $0.20 **Payment menthods:** USDT, USDC, Bitcoin, Monero, ZCash, credit card. **Important Note:** Those who are willing to join the Gen6 App [manual testing](/technology-core/info-for-manual-testers) or the [bug bounty program](/technology-core/bug-bounty-program), will receive a few GSX in advance for their efforts and have the chance to get the Green Badge human verification for their identities. **The Seed Round is over!** ### GSX Pre-Sale happened between 2026 June - August **Total offer amount:** 2 400 000 GSX **Release:** Monthly, over a period of 8 months from TGE **Price:** $0.60 **Payment menthods:** USDT, USDC, Bitcoin, Monero, ZCash, credit card. ### GSX listed on Ethereum as "GSX on Ethereum" The official launch was planned to align with improved market conditions but to take place **no later than September 21**. At the same time, we have established a firm deadline to maintain momentum for the Gen6 project. This ensures we remain agile and able to focus on user acquisition, business development and onboarding paying users to the Gen6 app. **Listing price: $1.00** *** ### Disclaimer This material is for informational purposes only and does not constitute an offer, solicitation, or financial advice. GSX is a utility token for use within the Gen6 ecosystem and is not a security, investment, or ownership instrument, and it does not grant rights to profits, equity, or governance. Participation in the GSX sale involves significant risk, including potential loss of funds, price volatility, and uncertainty regarding future value, liquidity, or exchange listings. All timelines and forward-looking statements are subject to change. Participants are responsible for complying with applicable laws in their jurisdiction. By engaging with GSX, you acknowledge and accept these risks. # DEX Strategy Public strategy for the Gen6 community to review and to feedback on. ## GSX Token Launch > **Status:** TGE is coming in the next days > > **TGE listing price:** $1.00 > > **Primary community:** EU, secondary Asia **Strategy:** * Wrap GSX to ERC20 on Ethereum * Bridges will be distributed to Gen6 Service Validators * Step by step liquidity provision from what's left * Liqudity providers get bonus (feature of UniSwap) ### Important Notice Due to the BitMart incident (we have $80 000 locked in BitMart), the community was forced to vote on what to do. The decision is: DEX only, all the CEX strategy got cancelled. Details: It means GSX got listed on Ethereum / UniSwap with the luiquidity left. # Secure Parking Summary Parking is a tool to secure your GSX and the network. Token Parking provides personal GSX protection (even if your wallet is stolen, the funds cannot be moved, but Gen6 Governance can help you to restore them), network security and stability. Parking allocations are calculated through weekly cycles but you can always start reclaim your tokens with allocations adjusted based on the time they have been parked.\ \ **Wednesday Cycles:** Token parking and allocations are based on weekly cycles that start\ every Wednesday at 00:00 UTC. Unparking takes 4 cycles (4 weeks).\ \ **Flexible Unparking:** You can unpark tokens at any time, but allocations are calculated based on complete weeks parked. Tokens go through a so-called 'cool-down/unparking' period and will be available after the Wednesday cycle of the given week. **If you have parked your tokens and got your account compromised, immediately contact:** [**https://gen6.app/identity/gen6**](https://gen6.app/identity/gen6)**! The community can help you to recover your identity and your funds.** **What is happening behind the system?** In addition to security by locking GSX in the **Secure Token Parking Pool**, the system also allocates rewards for the reason these GSX tokens cannot be used for anything until they are unlocked. Hence PRP is allocated. PRP = Parking Reward Percentage When you park your GSX tokens, they are added to the **Secure Token Parking Pool**, which influences the additional allocation percentage. Note that the larger the pool (the more GSX is parked), the lower the PRP becomes and vice versa.\ \ **Additional Allocation Percentage (PRP):**\ \ The PRP is determined by the total number of tokens in the parking pool, and it is updated every week. The breakdown is as follows:\ \ ● 1 - 50k tokens in the pool: 15% PRP\ ● 50k - 100k tokens in the pool: 14.5% PRP\ ● 100k - 150k tokens in the pool: 14% PRP\ ● 150k - 200k tokens in the pool: 13.5% PRP\ ● 200k - 250k tokens in the pool: 13% PRP\ ● 250k - 300k tokens in the pool: 12.5% PRP\ ● 300k - 400k tokens in the pool: 12% PRP\ ● 400k - 500k tokens in the pool: 11% PRP\ ● 500k - 600k tokens in the pool: 10% PRP\ ● 600k - 700k tokens in the pool: 9% PRP\ ● 700k - 800k tokens in the pool: 8% PRP\ ● 800k - 900k tokens in the pool: 7% PRP\ ● 900k - 1M tokens in the pool: 6% PRP\ \ The last threshold is when the parking pool reaches 900k - 1M tokens (and above), with a percentage of 3% PRP. **Wednesday Thresholds** Each parking period is weekly, and the allocations are calculated every Wednesday at 00:00 UTC. If you park tokens before Wednesday, your tokens will earn allocations for the upcoming week starting from Wednesday. Unparking tokens also follows the Wednesday cycle: any unparked tokens will be returned with accumulated allocations on the next Wednesday. **Compound Allocations** The parking allocations are distributed weekly but can only be received at the end of a full week. You can unpark your tokens at any time, but the allocations will be based on the complete weeks they were parked. **Example** Let’s say you park 100 GSX tokens before Wednesday when the total parking pool is between 1k - 50k GSX tokens (PRP: 15%).\ \ PRP (15%) is applied for the entire week.\ \ At the end of Week 1, you would have earned approximately 0.288 GSX (100 GSX \* 15% / 52 weeks).\ \ If you decide to unpark your tokens after 4 weeks, your total will include the accumulated allocations for those 4 complete weeks.\ \ Total GSX after 4 weeks = 100 GSX + 1.152 GSX (compound reward for 4 weeks). **Important Warning: Unparking Your Tokens and Allocations** Please note that you can only access your tokens if you unpark (unstake) a certain amount of your parked tokens. Even if you unpark a minimum of 0.1 GSX, this triggers a mechanism that moves all your accumulated rewards into the unparking state.\ \ **Key Point:** When you unpark any amount of your parked tokens, ALL of your additional allocations will be moved into the unparking state, and they will be available after the following Wednesday cycle.\ \ **Whenever you unpark any amount of your tokens, your additional allocations will also enter the unparking state and will only become available after the next Wednesday threshold.** # Technology #### **Validators & Substrate Framework** Our Enhanced Proof-of-Authority (EPoA) mechanism is used to validate transactions faster and securely with minimal energy use, ensuring fast and stable network operations. Gen6's public chain transactions are confirmed in 5 seconds and able to secure 213000+ proofs each block. Private Gen6 chains can be run with \~0.15 second block time on low latency environments with the same block size, leading to an impressive scaling potential up to 1.4M proof per second. #### **EPoA Consensus Algorithm** Our Enhanced Proof-of-Authority (EPoA) mechanism is used to validate transactions faster and securely with minimal energy use, ensuring fast and stable network operations. While EPoA is used, the two chamber governance help authority elections in a decentralized manner. #### **Gen6 Middleware (MW)** Middleware connects the Gen6 blockchain with Web2 services, allowing smooth communication between traditional apps and decentralized technology, without users needing to understand blockchain details. #### **Gen6 OpS Manager** Gen6 Operations Manager lets you run validators and services. That is the main tool used by Blockchain Administrators. #### Consolidated time table of the public chain (5s blocks) | Parameter | Value | Real time | | -------------------------- | ----------------- | --------------------------------- | | Session | 6 blocks | 30 s | | Warn escalation window | 17,280 | 1 day | | Chill self-restore | 34,560 | 2 days | | Slash self-restore | 172,800 | 10 days | | Auto-sale after slash | 2,073,600 | 120 days | | Auto-sale after chill | 6,307,200 | 365 days | | Parking accrual/settlement | ISO-week boundary | Wednesdays, UTC | | Election period | 518,400 | 30 days | | Enrollment silence | 17,280 | 1 day | | Proposal cooldown | 172,800 | 10 days | | 2nd-chamber review | ≥17,280 | ≥1 day (mirrors 1st-chamber time) | | Tx mortality | 2,400 | \~3.3 h | # Standards Every successful system is built upon clear, effective standards -ours is no different. Curated by Gen6 Experts, our standards, known as "GGS" (Gen6 Global Standards) are designed to be free, accessible, and user-focused. We believe that standards need be practical and intuitive, which is why we make them both usable and adaptable. The process of creating GGS follows these stages: 1. **Draft** – Initial concept and development. 2. **Review** – Collaborative evaluation and refinement. 3. **Finalize** – Integration of feedback and preparation for implementation. 4. **Established Standard** – Final version ready for widespread adoption. # GGS-1: Gen6 Identity Standard Stage: Established Standard ## Definitions ### Identity An identity is a representation of an individual's (Self's) outward manifestation, regardless of being physical or subjective. ### Gen6 Identity Self-issued and digitally signed identity, created using the Gen6 standard format. To create a valid Gen6 identity, its hash needs to be submitted to the Gen6 Public Blockchain: for keeping the proof of existence immutable. The identity data can stored anywhere chosen by the issuer's Self. ### Gen6 Identity Controller The Self who is controlling the private key from which the public key is derived which is connected to the identity on the blockchain. ### **Gen6 Identity Visiblity and Permission Control** Each field in the identity can needs to have the following options: * Public (anyone, even AI and bots can see/read the identity data) * Community (only members of the Community can see/read the identity data) * Private (only specified addresses can see/read the identity data) ### Gen6 Identity Types Identity types are not part if the Identity Data, but part of the standard. Each Gen6 Identity can have one of the following Type: * Human - Those identities who passed the Proof of Humanity Challenge * Organization - For organizations recognized by Gen6 Community * AI / Bot - Default for all account Obtaining Verified Human or Organization type are done through Gen6's governance. First it needs to be requested, then the community makes the decision. ## **Standard Gen6 Identity Format** * The identity's raw form is a [Merkle Tree](https://en.wikipedia.org/wiki/Merkle_tree) with a Forest and singular Root Hash. The whole or parts of the tree are convertible to JSON. * The Identity's Root Hash is stored on Gen6 Blockchain. * Tree Branch Hashes are stored on any G6 MiddleWare instance or other viable storage. * All branches (except H0) include **KEY : VALUE ; VISIBILITY : VALUE ; PEPPER** * "Pepper" is a random string used to protect the data against bruteforce attacks if the Hash is disclosed. * Each Identity requires a Controller Gen6 address, but the Identity can be empty, symbolizing freedom. As part of the Identity data, it is also used to protect against Identity Theft (so Root Hash is never the same even if all other parts of the data matches someone else's identity). * One Gen6 Address can have only one Gen6 Identity, but anyone can create as many addresses as they want. * Fields in the Gen6 Identity ("H" as Hash of Data): * H0 Controller Address - Must be the signer address. -> SS58 Address * H1 Name -> String (Max 256 characters, can be concatenated from more frields into one) * H2 Bio -> String (Max 512 characters) * H3 Location -> String (Max 256 characters) * H4 Domain -> String (Max 256 characters) * H5 Email -> String (Max 256 characters) * H6 NCrypt ID -> String (Max 256 characters) * H7 Social Link 1. -> Key:Value Pair (Max 128 characters) * H8 Social Link 2. -> Key:Value Pair (Max 128 characters) * H9 Social Link 3. -> Key:Value Pair (Max 128 characters) * H10 Social Link 4. -> Key:Value Pair (Max 128 characters) * H11 Social Link 5. -> Key:Value Pair (Max 128 characters) * H12 Social Link 6. -> Key:Value Pair (Max 128 characters) * H13 Social Link 7. -> Key:Value Pair (Max 128 characters) * H15 Social Link 8. -> Key:Value Pair (Max 128 characters) * H16 Social Link 9. -> Key:Value Pair (Max 128 characters) * H17 Custom Field -> Key:Value Pair (Max 256 characters) * H18 Custom Field -> Key:Value Pair (Max 256 characters) * ... and so on, until a maximum of H64. * Not part of the standard, but there 9 Social Links are recommended for user friendliness: * H7 Mastodon, Example: * H8 Youtube, Example: * H9 X, Example: * H10 LinkedIn, Example: * H11 Telegram, Example: * H12 Instagram, Example: [https://www.instagram.com/sarcasm\_only](https://www.instagram.com/sarcasm_only/?hl=en) * H13 TikTok, Example: * H14 Whatsapp, Example: * H15 Discord, Example: * H16 Git (already custom), Examples: or **Important note for FE developers:** You need to send all 64 values (even if empty) to the MW API, otherwise your request will be rejected. This is needed to proects the integrity and structure across platforms (and in 2025 it is really not a problem to send a few more fields). #### Gen6 Multi Merkle Tree Structure * Each leaf is a Tree, allowing verification of data separately and permission control. * Branch Hashes are stored by any G6 MiddleWare or any other viable storage. * Data of the the Tree stored by any G6 MiddleWare or any other viable storage. * From the G6 Merkle Tree, Identity data is turned into JSON to be used in FE and APIs **Topology of Standard Gen6 Identity**
# GGS-2: Gen6 Verification Standard Stage: Draft (close to Finalize) ## Definitions ### Proof A proof is a formal demonstration or argument that confirms the 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. ### Verification Verification is a collaborative process where other community members help substantiate your claim to being human based on these observable qualities. ### 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. 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. Idea: "secuTeam" can intervene if needed but otherwise things are automatic. ## **Standard 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. # GGS-3: Compartmentalized Information Protection Stage: Established Standard ## Definitions ### Compartmentalization Compartmentalization, in [information security](https://en.wikipedia.org/wiki/Information_security), whether public or private, is the limiting of [access to information](https://en.wikipedia.org/wiki/Access_to_information) to persons or other entities on a [need-to-know](https://en.wikipedia.org/wiki/Need-to-know) basis to perform certain tasks. ### Information Information is an [abstract concept](https://en.wikipedia.org/wiki/Abstraction) that refers to something which has the power [to inform](https://en.wikipedia.org/wiki/Communication). At the most fundamental level, it pertains to the [interpretation](https://en.wikipedia.org/wiki/Interpretation_\(philosophy\)) (perhaps [formally](https://en.wikipedia.org/wiki/Interpretation_\(logic\))) of that which may be [sensed](https://en.wikipedia.org/wiki/Sense), or their [abstractions](https://en.wikipedia.org/wiki/Abstraction). Any natural process that is not completely [random](https://en.wikipedia.org/wiki/Random) and any observable [pattern](https://en.wikipedia.org/wiki/Pattern) in any [medium](https://en.wikipedia.org/wiki/Media_\(communication\)) can be said to convey some amount of information. Information is not [knowledge](https://en.wikipedia.org/wiki/Knowledge) itself, but the [meaning](https://en.wikipedia.org/wiki/Meaning_\(philosophy\)) that may be derived from a [representation](https://en.wikipedia.org/wiki/Representation_\(mathematics\)) through interpretation. For instance, this standard contains information and those who understand it know about it. ### Protection Protection is any measure taken to guard something against damage (changes introduced into the system that adversely affect its current or future performance). ### CIP Short for **C**ompartmentalized **I**nformation **P**rotection. It is the standard used in the Gen6 ecosystem, designed to safeguard sensitive information by isolating it into separate compartments, ensuring that access is restricted to only those who need it for specific tasks. This approach prevents unauthorized access and minimizes the risk of data leakage, misuse, or corruption. CIP leverages a layered defense strategy ("defense in depth"), using multiple levels of security to maintain the confidentiality, integrity, and availability of information while maintaining compliance with regulatory standards. ## **Standard Structure of CIP** ### **Immutable Proof Information Storage: Blockchain** Immutable proofs are stored on the blockchain without revealing the data. All proofs's timestamp can be verified through the inspecting the block it was written into. This provides: * Undeniability of proof creation * Undeniability of timestamp of event * Privacy, as the data itself is off-chain * Permissionless access to proofs. ### **Data Information Storage: G6 Middleware** G6 Middleware provides data storage and permissioned access to them. While the data remains private, it can be revealed to selected entities. Data can be optionally encrypted, so not even the G6 Middleware provider can understand its content. This provides: * Permissions control of data * Information and data security * Privacy, as only the proofs are on-chain * Allows encryption of data * Allows ZK implementations * Possibility for 3rd party storage providers and backups * Scalable and fast data storage ### **User Stored Information: Secrets** The user keeps her/his own wallet in form of private keys or alternatively using the G6 OAuth system at 3rd party provider. This setup provides: * Freedom to create your own identity and share data with your own preferences * Free choice of what to encrypt, reveal or publish * Central authorities (except OAuth if you use it) cannot block your wallet and account * Self-custody and censorship resistance # GGS-4: Encrypted Communication Stage: Established Standard ## Definitions ### Cryptography The science and practice of securing communication and information through the use of mathematical techniques, algorithms, and protocols. Cryptography is used to protect the confidentiality, integrity, and authenticity of data. ### Encryption The process of converting plaintext data into an unreadable format, called ciphertext, using an algorithm and an encryption key. This ensures that only authorized parties with the appropriate decryption key can read the original data. ### Communication The exchange of information between two or more parties through various mediums. In the context of cryptography, communication refers to the transmission of data between users, often with an emphasis on confidentiality and security. Communication is handled through Send and Receive calls in G6 developed software. ### Communication Channel The medium through which information is transmitted between parties. In a digital context, this could be a network, like the internet, or a physical medium like a fiber optic cable or radio frequency channel. A secure communication channel ensures that the information sent cannot easily be intercepted or altered by unauthorized entities. ### Encrypted Communication Communication that has been protected using encryption to ensure that its contents are only accessible by authorized recipients. The encryption ensures that, even if the communication is intercepted, it cannot be understood without the correct decryption key. ### NCrypt Read Receipt A system within the NCrypt application that allows both the sender and recipient to verify whether a message has been read. The read receipt works by generating a cryptographic signature when a message is accessed, which is then stored and can be verified on-chain or within the system. This mechanism provides proof of message delivery and read status without compromising the privacy or integrity of the message content. The read receipt ensures that a message's read status is verifiable, potentially using a blockchain-based infrastructure to store limited amount of metadata in a secure, tamper-proof manner. ### NCrypt Encrypted chat application in the Gen6 ecosystem. It is an encrypted chat application within the Gen6 ecosystem, designed to provide secure and private communication between users. NCrypt uses cryptographic protocols to protect the confidentiality and integrity of messages exchanged through the platform. ## NCrypt Threat Model The **NCrypt Threat Model** identifies potential security risks and malicious actors that could compromise the confidentiality, integrity, and availability of the encrypted chat system. The model helps to define protections, mitigations, and necessary controls for each threat identified. #### 1. **Malicious Actors** * **External Attacker**: Intercepts messages to read them.\ *Mitigation*: End-to-end encryption (X25519, AES) ensures confidentiality. * **Man-in-the-Middle (MITM)**: Alters or intercepts communication.\ *Mitigation*: Public key cryptography and digital signatures protect against tampering. * **Malicious Insider**: Exploits authorized access to steal data.\ *Mitigation*: Access controls, decentralized systems (e.g., blockchain) reduce trust in any single party. * **Compromised End-User**: Malware or social engineering compromises a user's device.\ *Mitigation*: Multi-factor authentication, secure key storage, and regular security updates. #### 2. **Confidentiality Risks** * **Key Leakage**: Exposing private keys allows message decryption.\ *Mitigation*: Secure key storage (hardware modules, encrypted browser storage). * **Decryption Key Exposure**: Private key exposure allows access to encrypted messages.\ *Mitigation*: Strong encryption and isolated storage for keys. * **Read Receipts Meta:** Read receipts are signed and submitted on-chain to making to proof immutable. It doesn't affect encryption, but there will be public information about reading a message (not its content). #### 3. **Integrity Risks** * **Message Tampering**: Altered messages during transmission.\ *Mitigation*: Digital signatures ensure message authenticity. * **Replay Attacks**: Reusing intercepted messages to cause confusion.\ *Mitigation*: Use of timestamps and nonces to prevent replay. #### 4. **Availability Risks** * **Denial of Service (DoS)**: Overloading the system to prevent access.\ *Mitigation*: on G6 MW rate-limiting, DDoS protection, decentralized components. * **Resource Exhaustion**: Overconsumption of system resources.\ *Mitigation*: Efficient algorithms, input validation, and scalable architecture. * **Spam Attacks**: Sending too many messages. *Mitigation*: At least 5 GSX is needed to use the system and only 3 messages per second per user. We might require later PoH. More limitations might be added later. #### 5. **Privacy Risks** * **Metadata**: Public Keys and the optional Read Receipts are on-chain.\ *Mitigation:* Users can skip the on-chain part. * **Unintended Data Exposure**: Backup files might leak data.\ *Mitigation*: Encrypt backups before storing. * **Malicious MiddleWare Instance**: Someone hacks the MW instance used or manipulates it.\ *Mitigation*: Choose a trusted MW instance or self-host it. #### 6. **Key Management Risks** * **Key Revocation**: Failure to revoke compromised keys.\ *Mitigation*: Key revocation protocols and easy key replacement options. * **Key Synchronization Issues**: Mismatched or unsynced keys cause decryption failures.\ *Mitigation*: Automatic synchronization and user notifications for key issues. * **Loss of Keys:** User loses his/her keys or get compromised. *Mitigation*: Revoke the key through signature or through Gen6 governance. Securely, create new keys. ## NCrypt Application Logic ### Store of NCrypt Data 1. Blockchain for matching G6 SS58 Public Keys to X25519 Public keys (public on-chain) 1. Pallet used for this: postman 2. Read Receipt System (signatures if a message was read or not, publicly verifiable) 1. Pallet used for this: postman 3. Plain text messages (as user types and data before encryption) 1. Front-end only, loaded by trusted party or ran locally 4. X25519 Private Key 1. For daily use: Stored in browser storage 2. Backup: user can choose how to store this key, FE privates mnemonic 5. Encrypted messages (permissions required to access) 1. Stored on a G6 Middleware instance with permissions ### Who can use NCrypt messaging? * Anyone who has 1.05 GSX balance at least. This is a requirement to protect against spam. Additional measures on the backend also need to be in place to protect against spam. * Registering your public messaging key takes a minimal amount of [AURA](/technology-core/developer-resources/gsx-balances-explained) (denomination of GSX). * It is free to use the messaging, no balance is removed. * No identity required. No KYC. * No phone numbers needed. * Only requirement is the 1 GSX balance lock on the SS58 account used. ## NCrypt Application Logic
# GGS-5: Gen6 Expert System Stage: Draft ### Definitions ### Gen6 Expert TBA ### Expert Roles Current Expert roles with users: 1. IT Security and Privacy Expert 2. G6 Operations Expert 3. Substrate and Rust Expert 4. Web3 Full-Stack Expert 5. Web3 Governance Expert 6. Blockchain Administrator Expert 7. Manual Tester Expert 8. Community Moderation Expert ### List of Experts TBA Link (not part of standard, but the experts list needs to be available with those who consent to be there publicly) # GGS-6: Post-Quantum Infrastructure Stage: Draft for review, but partially live in implementation. **Applies to:** Gen6 chain (Substrate-based, Enhanced Proof of Authority), RealSeal, NCrypt, GSX account keys. **External baseline:** NIST FIPS 203 / 204 / 205 (finalized 13 August 2024). *** ### 0. Scope This standard specifies which post-quantum cryptographic (PQC) algorithms Gen6 adopts, where each applies across the stack, and the phased engineering plan to migrate the live chain, RealSeal, and NCrypt to post-quantum security. Gen6's current cryptographic primitives, confirmed from the codebase and used as the migration baseline throughout this document: | Layer | Current primitive | Type | PQC status | | ------------------------------- | ---------------------------------------- | -------------------------------- | ------------------------------------- | | Gen6 Infrastrucutre Management | mlkem768x25519-sha256 | SSH | **PQC** | | RealSeal / RealSeal IoT hashing | BLAKE2 / BLAKE3, SHA-256 | Hash | **Quantum-acceptable** | | NCrypt payload encryption | ChaCha20-Poly1305 | Symmetric AEAD | **Quantum-acceptable at 256-bit key** | | NCrypt key exchange | X25519 (Curve25519) | Key exchange | PQC to add. | | NCrypt sender authentication | Ed25519 | Signature (EdDSA) | PQC to add. | | GSX account signatures | sr25519 | Signature (Schnorr/EdDSA family) | PQC to add. | | RealSeal signature | Ed25519 / sr25519 (chain signature) | Signature | PQC to add. | | Consensus (Enhanced PoA) | Substrate primitives (Ed25519 / sr25519) | Signature | PQC to add. | The migration priority: the **public-key components (X25519 key exchange, Ed25519/sr25519 signatures) are the entire problem**. The symmetric and hashing primitives (ChaCha20-Poly1305, SHA-256, BLAKE2/BLAKE3) are quantum-acceptable at their current parameters and are retained. ### 1. Threat Model and Rationale #### 1.1 What quantum computing breaks in Gen6 * **Broken (public-key):** every Gen6 signature and key-exchange primitive - X25519, Ed25519, sr25519 - rests on elliptic-curve hardness and is broken by Shor's algorithm on a sufficiently large quantum computer. These are the highest-risk components. * **Weakened but acceptable (symmetric / hash):** ChaCha20-Poly1305, SHA-256, and BLAKE2/BLAKE3 are only weakened by Grover's algorithm, which halves effective security. At 256-bit keys / 256-bit output this leaves \~128-bit post-quantum strength, which is strong in practice. These are retained without change. Per the Web3 Foundation roadmap, the hash functions used at the Substrate consensus layer are likewise considered post-quantum secure. #### 1.2 Two distinct risks; different urgency * **Confidentiality → Urgent (Harvest-Now-Decrypt-Later).** NCrypt's X25519 key exchange is the critical exposure. An adversary can capture NCrypt ciphertext today and decrypt it once a quantum computer exists. Any NCrypt message with a multi-year confidentiality requirement is **already** at risk. This cannot wait for quantum hardware to actually arrive. * **Authentication → Must be ready before quantum, low pre-quantum exposure.** A forged signature (validator, account, RealSeal) only has value at the moment it is produced. As the Web3 Foundation researchers put it, for authentication "you just need to be far enough ahead to rotate the key." Signature migration must be complete before cryptographically-relevant quantum computers exist, but running Ed25519/sr25519 today leaks nothing. **Consequence:** NCrypt key exchange migrates to hybrid PQC first (Phase 1). Signature migration (account, RealSeal, consensus) follows on a deliberate, tested schedule (Phases 2–3). #### 1.3 Timeline posture Gen6 makes no claim about when cryptographically-relevant quantum computers arrive; no published estimate places them within the current decade with confidence. The rationale for acting now is HNDL exposure on NCrypt confidentiality plus the multi-year lead time to migrate a live chain safely. NSA CNSA 2.0 sets 2030 as the migration deadline for US national-security systems (specifying ML-KEM-1024 and ML-DSA-87); Gen6 treats 2030 as a reasonable "substantially complete by" anchor given its positioning toward government and defense buyers. ### 2. Algorithm Selection Gen6 standardizes on the NIST-finalized lattice family, matching the Web3 Foundation's choices for Polkadot so Gen6 stays aligned with its upstream Substrate framework rather than forking onto a bespoke cryptographic stack. #### 2.1 Signatures
PrimitiveNIST standardBasisGen6 roleRationale
ML-DSA (CRYSTALS-Dilithium)FIPS 204Module-LWE / Module-SIS (lattice)Default for consensus/authority signing, RealSeal signing, and NCrypt sender authenticationConstant-time implementation; NIST's recommended default signature. Matches the Web3 Foundation choice of Dilithium for validator signatures precisely because it is constant-time. Signature size 2420–4595 bytes.
FN-DSA (Falcon)FIPS 206 (draft)NTRU latticeGSX account signatures (user-held keys)Small signatures (~666 bytes) minimize on-chain transaction cost. Matches the Web3 Foundation choice of Falcon for accounts. Confined to account keys only — Falcon is not constant-time and is sampling-sensitive, so it is never used for consensus.
SLH-DSA (SPHINCS+)FIPS 205Hash-based (no lattice assumption)Long-lived / high-assurance RealSeal attestationsConservative fallback with a security assumption independent of lattices. Large signatures (7856–49856 bytes) and slow signing (~274 ms/sign, SHA2-128s, liboqs on Apple M-series), so used selectively where assumption diversity is worth the cost — e.g. archival or government evidence meant to verify for decades.
**Selection rule (per NIST guidance):** ML-DSA is the default signature everywhere unless a specific constraint justifies otherwise — signature size drives the Falcon choice for accounts; assumption diversity drives the SLH-DSA option for long-horizon RealSeal. Choice follows function, not preference. #### 2.2 Key Encapsulation (NCrypt) | Primitive | NIST standard | Basis | Gen6 role | | --------------------------- | ------------- | -------------------- | ------------------------------------------------------ | | **ML-KEM** (CRYSTALS-Kyber) | FIPS 203 | Module-LWE (lattice) | NCrypt key establishment, in a **hybrid** construction | Baseline parameter set: **ML-KEM-768** (Category 3, \~AES-192-equivalent) for NCrypt session establishment; **ML-KEM-1024** available for high-assurance contexts. ML-KEM public keys are 800–1568 bytes, ciphertexts 768–1568 bytes. ML-KEM-768 in hybrid with X25519 is the same construction deployed by Chrome and major TLS stacks, giving Gen6 a well-trodden reference path. #### 2.3 Hybrid mandate for NCrypt confidentiality For **all NCrypt key exchange**, Gen6 mandates a **hybrid** construction during the transition era: the existing **X25519** exchange runs in parallel with **ML-KEM-768**, and the two shared secrets are combined through a KDF so the session is secure if *either* primitive holds. Rationale: NIST's post-quantum KEMs have had far less side-channel cryptanalysis than X25519, so a hybrid construction ensures that a flaw in either the lattice scheme or the elliptic-curve scheme does not by itself break confidentiality. Pure-PQC (non-hybrid) key exchange is **not** adopted for NCrypt in this phase. #### 2.4 Symmetric and hash primitives — retained * **NCrypt payload encryption:** ChaCha20-Poly1305 is retained. It is a 256-bit-key AEAD; Grover leaves \~128-bit post-quantum strength, which is strong in practice. No change required. * **Hashing (RealSeal, RealSeal IoT, chain):** BLAKE2/BLAKE3 and SHA-256 are retained. Quantum-acceptable at 256-bit output. SNARK-friendly hashing (e.g. Poseidon) is introduced only where account-migration mechanics require it (see 3.4). #### 2.5 Explicitly not chosen * **QKD / hardware pQKD:** not adopted. Distance-limited, hardware-dependent, unnecessary given software PQC. * **Pure-PQC (non-hybrid) key exchange:** deferred until ML-KEM side-channel analysis matures. Hybrid only, for now. ### 3. Where Each Algorithm Applies #### 3.1 Consensus / authority layer (Enhanced Proof of Authority) Gen6 runs **Enhanced Proof of Authority (EPoA)**, not stake-weighted BABE + GRANDPA. This materially simplifies the consensus-layer migration relative to Polkadot's roadmap: * **Authority signing → ML-DSA (Dilithium).** All authority-signed consensus messages migrate from the current Ed25519/sr25519 primitive to ML-DSA, chosen for its constant-time property. * **VRF-based leader election is a BABE construct and does not apply to EPoA in the same way.** The hardest single item in the Polkadot roadmap — replacing stake-weighted VRF block production with a hash-based randomness beacon — is **largely not applicable to Gen6's PoA model**, since authority-set block production does not rely on the same VRF leader lottery. Any randomness Gen6's EPoA does use must be inventoried in Phase 0 and, if a quantum-vulnerable VRF is present, replaced with a hash-based construction; but Gen6 does not inherit BABE's full VRF-migration problem. This is a genuine structural advantage of EPoA for PQC migration. #### 3.2 GSX accounts * **Account signatures → FN-DSA (Falcon)** for new post-quantum accounts, chosen for small signature size to minimize transaction cost. * Existing accounts migrate via the mechanism in 3.4. #### 3.3 RealSeal (content signing) * **Hashing → BLAKE2/BLAKE3, retained** (quantum-acceptable). No migration needed for the hash layer. * **Signing → ML-DSA (Dilithium)** as the default, migrating from the current Ed25519/sr25519 chain signature. This is the primitive that cryptographically binds a BLAKE3 digest to a self-sovereign identity, and it is the quantum-vulnerable part of RealSeal that must move. * **Long-lived / high-assurance attestations → SLH-DSA (SPHINCS+)** optionally, where a non-lattice assumption is valuable. This ties directly to Gen6's permanent-record positioning: an attestation meant to remain verifiable for 30+ years is exactly where a conservative hash-based signature assumption justifies its larger size. * RealSeal IoT inherits the same hashing (retained) and signing (→ ML-DSA) migration as RealSeal. #### 3.4 Account migration (FRI-SNARK proof of seed knowledge) The mechanism that lets existing users move to PQC keys **without a pre-existing PQC key and without exposing their old private key** — essential because a live chain cannot force every holder to act at once. Following the Web3 Foundation design (adapted from Buterin's quantum-emergency hard-fork proposal): 1. Keys derived from a seed via hash-based HD derivation are post-quantum secure at the derivation step, even though the resulting curve private key is not. 2. The user submits a post-quantum FRI-based SNARK (a signature of knowledge, hundreds of KB) proving they know the seed that hashes to the existing account's key, and binding a new Falcon public key to that seed. 3. On acceptance, the chain transfers balance/authority from the old account to the new PQC account. Properties: the large proof is submitted once per account (size acceptable); hash-based derivation lets many existing cold wallets migrate without pre-provisioned PQC keys. **Gen6 posture:** adopt the upstream Substrate/Polkadot FRI-SNARK migration implementation when available rather than building bespoke. FRI-based SNARKs are fast-moving; the Web3 Foundation notes current implementations were written for Ethereum scaling and often neglect zero-knowledge, so the tooling will improve over the migration window. #### 3.5 NCrypt (messaging) * **Key establishment → hybrid X25519 + ML-KEM-768** (2.3). Highest priority in the standard due to HNDL. * **Sender authentication → ML-DSA (Dilithium)**, migrating from Ed25519, aligning NCrypt sender-auth with the account/identity signature migration. * **Payload encryption → ChaCha20-Poly1305, retained** (256-bit, quantum-acceptable). #### 3.6 Bridges / cross-chain Gen6's bridge configuration is not documented in the wiki. If Gen6 operates bridges, the Web3 Foundation's post-quantum BEEFY approach applies: authorities sign finality messages under each PQC scheme the target network supports, so a bridged chain can verify with whatever single PQC scheme it supports natively. If Gen6 has no bridges, this section is not applicable. Confirm bridge scope during Phase 0 and mark this section accordingly. #### 3.7 Transport (node-to-node) Adopt hybrid PQC key exchange feeding audited external post-quantum TLS libraries, per the Web3 Foundation roadmap. Do not hand-roll transport crypto — use audited libraries (4.5). *** ### 4. Development Plan Phased by the urgency logic in 1.2: confidentiality first, then signatures, then account migration and consensus, then cleanup. Phase 0 (discovery/agility/audit) runs first and continuously. #### Phase 0 — Inventory, crypto-agility, audit baseline *(prerequisite)* **Goal:** lock down exactly what Gen6 uses and make primitives swappable. * Complete the **cryptographic inventory** started in Section 0: confirm every signature, KEM, hash, and symmetric primitive across chain, RealSeal, RealSeal IoT, NCrypt, GSX, transport, and bridges. Commit it to the wiki as canonical. Two specific open items to close: (a) whether EPoA uses any quantum-vulnerable VRF/randomness primitive; (b) whether Gen6 operates any bridges. * Introduce **crypto-agility**: reference all primitives through an abstraction (algorithm identifiers / trait objects) so schemes swap without rewriting call sites. If the codebase hard-codes X25519/Ed25519/sr25519 at call sites, this refactor gates everything else. * Stand up **PQC test vectors in CI**: integrate a vetted PQC library (4.5) and validate against NIST FIPS 203/204/205 known-answer tests. **Exit criteria:** inventory ratified on wiki; every primitive swappable; PQC library in CI with passing KATs; EPoA-VRF and bridge questions answered. #### Phase 1 — NCrypt hybrid key exchange *(highest urgency: HNDL)* **Goal:** close the harvest-now-decrypt-later exposure. * Implement **hybrid key establishment**: run existing X25519 in parallel with **ML-KEM-768**, combine both shared secrets via KDF. * Confirm NCrypt payload uses **256-bit ChaCha20-Poly1305** (retained; raise only if any 128-bit path exists). * Ship as **backward-compatible negotiation**: hybrid where both peers support it, classical fallback only where a peer has not upgraded, with a published classical-only sunset date. * Version the NCrypt wire format so hybrid vs. classical is explicit and auditable. **Exit criteria:** new NCrypt sessions negotiate hybrid X25519 + ML-KEM-768 by default; downgrade-resistance tested; sunset date published. #### Phase 2 — RealSeal and GSX signature migration *(deliberate pace)* **Goal:** post-quantum signing for content and accounts, with dual-signature continuity. * Add **ML-DSA (Dilithium)** as a supported RealSeal signing scheme; make it default for **new** RealSeal and RealSeal IoT attestations. Retain verification of legacy Ed25519/sr25519 signatures for existing proofs. * Add optional **SLH-DSA (SPHINCS+)** for long-lived / high-assurance RealSeal attestations. * Introduce **FN-DSA (Falcon)** account keys for **new** GSX accounts. * Support a **dual-sign transition window** (classical + PQC) so verifiers upgrade before signers drop the classical signature. Nothing in migration may invalidate a previously valid RealSeal record — permanence is a core Gen6 property, so legacy verification is retained indefinitely. **Exit criteria:** new accounts and new RealSeal attestations PQC-signed; dual-sign verification live; legacy verification retained. #### Phase 3 — Account migration + EPoA consensus signing *(adopt upstream)* **Goal:** move existing accounts to PQC and make consensus signing post-quantum. * Implement the **FRI-SNARK seed-knowledge account migration** (3.4) once the upstream implementation is available; expose a one-time "migrate to PQC" user flow. * Migrate **EPoA authority signing to ML-DSA (Dilithium)**. * If Phase 0 found a quantum-vulnerable VRF/randomness primitive in EPoA, replace it with the upstream hash-based construction. If not (expected for PoA), record that no VRF migration is required. * **Ratified decision:** Gen6 adopts upstream Substrate/Polkadot PQC primitives as released rather than forking a parallel implementation. This is the single most important strategic choice in the plan. **Exit criteria:** account migration live on test network then mainnet; authorities signing with ML-DSA; VRF question closed; full cutover rehearsed on a Gen6 test network first. #### Phase 4 — Deprecate classical, bridges, hardening * Enforce the **classical-only sunset** for NCrypt; drop classical signature acceptance for new operations (retaining historical RealSeal verification). * If Gen6 has bridges: implement **post-quantum BEEFY** multi-scheme finality signing (3.6). * Full **third-party cryptographic audit** of the migrated stack. * Publish a **post-quantum readiness statement**; promote GGS-6 to "active." **Exit criteria:** classical primitives removed from new-operation paths; bridges (if any) PQC-verifiable; external audit passed; standard ratified. #### 4.5 Implementation libraries (external, audited — do not hand-roll) * **liboqs** (Open Quantum Safe) — reference ML-KEM / ML-DSA / SLH-DSA / FN-DSA, with C and Rust-accessible FFI bindings. * **Cloudflare CIRCL** — production-grade Go implementations. * **OpenSSL 3.4+** — native ML-KEM and ML-DSA for TLS-adjacent transport. * For a Substrate (Rust) chain, prefer a **Rust PQC implementation with a public audit trail**. The `@scure/sr25519` precedent (Polkadot Treasury-funded, independently audited by Oak Security) is the model to require on the PQC side. **Rule:** every cryptographic library entering Gen6 must have a public audit trail. No unaudited lattice implementation ships to mainnet. *** ### 5. Summary — Algorithm to Component Map | Gen6 component | Current | Post-quantum target | NIST std | Priority | | ------------------------------------ | -------------------------- | ------------------------------------------------------- | ---------------- | ------------- | | NCrypt key exchange | X25519 | **Hybrid X25519 + ML-KEM-768** | FIPS 203 | **P0 (HNDL)** | | NCrypt payload cipher | ChaCha20-Poly1305 | Retained (256-bit, quantum-acceptable) | — | n/a | | NCrypt sender auth | Ed25519 | **ML-DSA (Dilithium)** | FIPS 204 | P1 | | GSX account signatures | sr25519 | **FN-DSA (Falcon)** | FIPS 206 (draft) | P1 | | RealSeal / RealSeal IoT hashing | BLAKE2 / BLAKE3, SHA-256 | Retained (quantum-acceptable) | — | n/a | | RealSeal / RealSeal IoT signing | Ed25519 / sr25519 | **ML-DSA (Dilithium)** | FIPS 204 | P1 | | RealSeal (long-lived/high-assurance) | — | SLH-DSA (SPHINCS+) | FIPS 205 | P2 | | EPoA authority signing | Ed25519 / sr25519 | **ML-DSA (Dilithium)** | FIPS 204 | P3 | | EPoA randomness/VRF (if any) | To confirm in Phase 0 | Hash-based construction only if a vulnerable VRF exists | — | P3 | | Account migration | curve key from hashed seed | FRI-SNARK seed-knowledge proof → Falcon key | — | P3 | | Transport (node-to-node) | X25519-based | Hybrid PQC KEX + PQ-TLS (audited lib) | FIPS 203 | P2 | | Bridges (if any) | To confirm in Phase 0 | Post-quantum BEEFY (multi-scheme) | FIPS 204 | P4 | ### 6. Sources **Standards (primary):** * NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), finalized 13 August 2024. FIPS 206 (FN-DSA / Falcon) in draft. * NSA CNSA 2.0 — 2030 migration deadline for national-security systems; ML-KEM-1024 and ML-DSA-87 specified for NSS. **Substrate / Polkadot-specific (primary for the chain layer):** * Web3 Foundation, "Post-Quantum Cryptography Roadmap for Polkadot and JAM," Polkadot Forum, June 2025 — Dilithium for validator/authority signatures, Falcon for accounts, hybrid KEX for transport, FRI-SNARK account migration, hash-based randomness beacon replacing BABE's VRF, post-quantum BEEFY for bridges. * Polkadot Wiki / Polkadot Developer Docs — current Substrate cryptography (sr25519, Ed25519). **Sizes / benchmarks (secondary, for parameter tradeoffs):** * ML-KEM public keys 800–1568 B, ciphertexts 768–1568 B; ML-DSA signatures 2420–4595 B; SLH-DSA signatures 7856–49856 B; Falcon signatures \~666 B; SLH-DSA (SHA2-128s) \~274 ms/sign on Apple M-series (liboqs) — from NIST-derived and peer-reviewed benchmark literature. # GGS-7: G6 Middleware Stage: Draft The **GGS-7: G6 Middleware** standard defines the technical framework and operational guidelines for the middleware layer within the Gen6 ecosystem. This middleware serves as the bridge for communication, data handling, and interoperability across decentralized and distributed systems. Key components of the standard include: 1. **Interoperability**: Ensure seamless communication between various components and systems in the Gen6 ecosystem, including decentralized applications (dApps), blockchain networks, and AI agents. 2. **Scalability**: Support horizontal and vertical scaling to handle growing network demands, ensuring the middleware can efficiently process high volumes of data and interactions. 3. **Security**: Implement robust security measures, including end-to-end encryption, access control, and data integrity checks, to safeguard data transmission and storage within the middleware. 4. **Reliability**: Ensure high availability and fault tolerance, with mechanisms for automatic recovery, load balancing, and error handling, minimizing disruptions in system operation. 5. **Data Privacy**: Enforce data privacy policies in line with regulations, ensuring that sensitive user data is protected while maintaining system performance and usability. 6. **Modularity and Extensibility**: Design middleware to be modular, allowing for easy integration of new services, protocols, and components without disrupting the existing infrastructure. 7. **Performance Optimization**: Optimize middleware for minimal latency and high throughput to support real-time applications and ensure efficient data processing. 8. **Compliance and Governance**: Adhere to regulatory standards and governance protocols, including data protection, auditability, and transparency in system operations. This standard ensures that the Gen6 middleware layer is secure, efficient, and adaptable, providing a reliable backbone for the ecosystem's decentralized applications and services. # GGS-8: G6 AI Agents and Creator Economy Stage: Draft ; Creator Economy and Agents The **GGS-7: G6 AI Agents** standard outlines guidelines for the development, deployment, and management of artificial intelligence (AI) agents within the Gen6 Middleware (MW) ecosystem. The standard focuses on ensuring that AI agents: 1. **Security**: Operate with secure authentication and encryption protocols, safeguarding data and preventing unauthorized access or manipulation. 2. **Transparency**: Provide clear, understandable explanations of their decision-making processes, enabling accountability and trust in AI-driven actions. 3. **Interoperability**: Function seamlessly across different systems and platforms within the Gen6 ecosystem, ensuring smooth integration with other components. 4. **Ethical Considerations**: Adhere to ethical principles, including fairness, non-bias, and user privacy, with an emphasis on minimizing harm and ensuring responsible AI use. 5. **Performance**: Ensure AI agents maintain high reliability and responsiveness, meeting system performance requirements without disrupting the operation of other middleware components. 6. **Governance**: Define procedures for the oversight and auditing of AI agent actions, ensuring compliance with applicable regulations and standards. This standard ensures that AI agents within the Gen6 MW ecosystem operate effectively, securely, and responsibly. # Info for Manual Testers Page for Gen6 Manual Tester Experts ### Supported Devices
Device TypeOperating SystemsMin ResolutionMax Zoom
MobilephonesAndroid 15 (or later), iOS 24 (or later)1080×2400150%
TabletsAndroid 15 (or later), iOS 24 (or later)1440x3200150%
Desktops and LaptopsDebian based Linux (12 or later), Windows (8 or later), macOS (25 or later)1366x768150%
Note that all these devices need to have either a supported wallet installed or use OAuth for login. ### Supported Wallets Main wallet supported, also an ecosystem partner: Developer wallet supported: ### Manual Tester Guides You can find all public Manual Tester Guides on G6's git: # Software Minimum Requirements Page for Blockchain Administrator Experts ### **Gen6 OS (Including Tools)** **CPU:** 2.2 GHz Dual-Core Processor (or equivalent) **Memory (RAM):** 8 GB RAM **Storage:** SSD with at least 64 GB of free space **Network:** 256 Mbps down and 128 Mbps up (minimum 10/2 Mbps for stable testnet operations) ### **Gen6 OS as Service Validator (Including MW, Tools and Services)** **CPU:** 3 GHz Hexa-Core Processor (or equivalent) **Memory (RAM):** 32 GB RAM **Storage:** SSD with at least 1 TB of free space **Network:** 1 Gbps down and 512 Mbps up (minimum 10/2 Mbps for stable testnet operations) ### Gen6 Validator Node (without tools, just Substrate) **CPU:** 2.2 GHz Dual-Core Processor (or equivalent) **Memory (RAM):** 2 GB RAM **Storage:** SSD with at least 25 GB of free space **Network:** 512 Mbps down and 128 Mbps up (minimum 10/8 Mbps for stable testnet operations) ### **Gen6 OS - Local IoT Private Blockchain** **CPU:** 1.8 GHz Single Core Processor (or equivalent) **Memory (RAM):** 2 GB RAM **Storage:** SSD with at least 16 GB of free space **Network:** 1Mbps down and 512Kbps up (or standard LAN) # Bug Bounty Program We reward the ones who find real problems. ### Introduction We run a responsible bug bounty program to: * Protect our users and the Gen6 ecosystem. * Encourage responsible disclosure of security and privacy issues. * Reward researchers fairly in GSX for verified, impactful findings. **Reward Pool of the Bug Bounty: 50 000 GSX** ### Scope **In-scope:** * Gen6.App (content pages, user accounts, authentication flows, image uploads, attachments, comment systems, API endpoints used, backend, OS). * Gen6 Public Blockchain **Out-of-scope:** * Social engineering, phishing, or attacks requiring physical access. * Third-party services not operated by Gen6 (unless the issue clearly originates from our integration). * Denial-of-Service attacks on production system (we will not reward or tolerate attempts that harm availability). You can test DoS attacks locally tho. If you are unsure whether something is in scope, submit it and we'll triage. ### Reward tiers (paid in **GSX**) Rewards are determined by impact, exploitability, and the quality of your report. * **Small** * L*ow-impact bugs / minor logic issues / UI bugs that could lead to confusion or small privacy leaks.*\ **Reward:** **10 – 50 GSX** * **Medium** * *Bugs that allow user impersonation, escalation of privileges, moderate data exposure, or persistent misconfigurations.*\ **Reward:** **50 – 250 GSX** * **Critical** * *Remote code execution, full database leaks, broken authentication allowing full account takeover, secret key exposure, or any vulnerability that allows large-scale compromise.*\ **Reward:** **Up to 3,000 GSX** Amounts within a tier depend on reproducibility, impact, and whether an exploit exists. Multiple valid reports for the same bug will be coordinated so credit and reward are allocated fairly. ### Severity guidance (How we judge) We consider and document in triage. The **impact**, **exploitability**, **scope** and **user harm.** We value clear exploitability: a theoretical vulnerability with no realistic exploit scores lower than a practical, easily-exploitable bug. ### How to submit a report Send an email to **** with subject `Bug Bounty — [one-line summary]`. For encryption, you can use ProtonMails inbuilt encryption feature. Make sure to include: 1. **Title / short summary** 2. **Impact rating (your estimate):** Small / Medium / Critical 3. **Full reproduction steps** How you reproduce the bug. Examples: Screenshots, command lines, HTTP requests, screenshots, video (if helpful). The clearer, the faster we can triage. 4. **Proof of concept (PoC)** How you reproduce the bug. Examples: exploit code, curl commands, or step-by-step that demonstrates the issue. If PoC is destructive, include a safer, equivalent demonstration. If a screenshot explains all, that enough too. 5. **Test account / affected account** (if relevant) Provide a test account we can use or steps to reproduce on our test environment. 6. **Timestamp & Environment** Date/time (UTC), browser/OS, your IP (optional). 7. **Suggested mitigation** Optional but appreciated! 8. **Disclosure preference** Coordinated disclosure timeline or public disclosure allowed after fix (default: coordinated). #### Bug Report Template ``` Title: Date (UTC) and envitonment: Impact rating: Reproduction steps: Proof of Concept: Test account: Suggested mitigation: Disclosure preference: Coordinated (change it if you want). ``` ### Eligibility & rules 1. Be a good-faith tester or security researcher. Do not access, modify, or exfiltrate user data beyond what is necessary to demonstrate the issue. 2. Do not perform social engineering, spam, or denial-of-service testing on production system. 3. Unsafe or destructive testing that damages user data or availability may be excluded from rewards. 4. Submit only one report per issue. If your submission is substantially the same as another, we will coordinate credit. 5. Employees and contractors of Gen6 are eligible unless the policy for their role states otherwise — check with us. ### Safe harbor If you follow this program and act in good faith to avoid privacy invasion, data destruction, or service disruption, Gen6 will not pursue legal action for the tested activity. This safe harbor applies only while you follow the program rules and scope. ### Triage & Response timeline We aim to Acknowledge your report within **72 hours and p**rovide a coordinated disclosure plan or status update within 7 business days. We patch and pay bounties quickly, typical payout target is **10-14 days** after a validated fix, but may vary with severity and legal checks. We will keep you updated during triage. If we require more info we will ask. Clear PoCs speed everything up. ### Bounty transfer process * We only send GSX to your provided reward wallet. * We do not require KYC. ### Contact & Legal **Email:** \ Please encrypt sensitive (critical level) submissions through Protonmail (or later using NCrypt). By submitting a report you agree to follow this program's rules. We reserve the right to modify bounty amounts, scope, or terms; we will publish changes on the wiki and honor reports submitted under prior terms when practical. ### Final notes We love thoughtful, well-documented reports more than flashy exploits. A clear proof that lets us reproduce and fix a bug will always outshine a dramatic but vague claim. Help us keep Life in Gen6 reliable, private, and resilient and we gonna thank you with decent amounts of GSX, public credit (if you want), and the eternal admiration of our community 🙏 *\~ Gen6 Security Expert Team* # Developer Resources * G6 Technology - Public Git * * Substrate address converter * prefix: 355 * Recommended password manager * * Gen6 and G6 BrandKit * * Gen6 MW API * API: * Docs release coming soon. * API Documentation (Swagger) * Releasing soon # Gen6 Public Chain - Dev Info Technical Data ### **Technical Data** **Chain's Code:** **Gen6 SS58 Prefix:** 355 **SS58 Converter to Gen6 addresses:** [ss58.org](https://ss58.org/) **Internal ID:** g6-solo-chain/107 **PolkadotJS Link:** [PJS Link](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgen6.app%3A443%2Fnode#/explorer) **Explorer link:** **Gen6 WSS API:** [wss://gen6.app:443/node](wss://gen6.app/node) # Development Standards ### Python3 #### Dependency management * We are using [poetry](https://python-poetry.org/) as a dependency management and virtual environment tool #### Logging * Use the [built in logging module](https://docs.python.org/3/library/logging.html) for logging over `print()` for big projects. * For debugging print also uses the logging module, example: ``` import logging logger = logging.getLogger(__name__) logger.debug("debug message") logger.info("info message") logger.error("error message") logger.warning("warning message") try: ... except Exception as e: logger.exception(e) ``` ### Rust * TBA ### Database and ORM #### **SQL** * [Sqlalchemy](https://www.sqlalchemy.org/) or [Flask-SQLAlchemy](https://flask-sqlalchemy.readthedocs.io/en/stable/) (if used with flask) ### HTTP Requests and Tooling Use [httpx](https://www.python-httpx.org/) instead of [requests](https://pypi.org/project/requests/). Note some services might only allow HTTP2. ### Javascript/Typescript #### Dependency management We are using [pnpm](https://pnpm.io/) (not npm) as a dependency management tool **Optional Advice** Use NestJs for backend if you willing to put in some time for learning. It has some learning curve, but it is a very rewarding framework and is becomming an industry standart. ### Cryptography and Hashing We use Blake3 for hashing and Polkadot cryptography libraries (for now). # GSX Balances Explained Gen6 GSX is a core component of the Gen6 ecosystem, responsible for managing and stabilizing resource allocations across various processes within the ecosystem, such as balance transfers or parking calls. It works through our Substrate implementation. Gen6 Addresses are only active if they have more than the [ED (Existential Deposit)](/education/learn-how-gen6-works/gen6-public-chain-basics#existential-deposit). #### GSX and AURA We use **GSX** as the primary unit name and **AURA** for smaller denominations. ``` GSX = "Generation Six Extremum" AURA = "Atto Unit Root Amount" AURA = aGSX (This name can be used too if AURA is too confusing for users.) 1 GSX = 10^18 AURA Examples: 1 GSX = 1000000000000000000 AURA 9000 GSX = 9000000000000000000000 AURA ``` To verify your calculations you can use the [GSX x AURA](https://g.g6.network/g6-networks-release/gen6-snippets/-/blob/main/GSX_to_AURA_Converter.py?ref_type=heads) converter. #### Types of GSX Balances 1. **Free Balance:** The balance that can be spent anytime and is not reserved anywhere. 2. **Reserved Balance:** The balance that is kept reserved for system or governance actions. 3. **Frozen Balance:** When reaching ED (Existential Deposit) a minimal amount of balance is frozen, keeping the account alive long-term. Frozen balances cannot be punished or slashed. #### Parking states 1. **Parking:** The balance that is being parked. It is callable through the parking.park() function. Balances get parked next Wednesday. 2. **Parked:** Securely parked balance and it cannot be moved. 3. **Unparking:** Balance which is being unparked after the parking.unpark() call - still cannot be moved until unparking finishes. 4. **Withdrawable:** Balance that can be withdrawn anytime. It becomes Free Balance after the paking.unfreeze() call. #### **User-facing terminology** 1. **Free Balance:** The balance you can spend anytime. 2. **Locked Balance:** The balance which is locked for ecosystem participation or parking. When talking to non-hackers/non-techies, only use these two terms or they will get confused. #### **Moving GSX balances** You can move balances using the following Balances pallet calls (dst=destination, val=value, ka=keepalive): 1. **transferKeepAlive(dst, val):** That is basically the common balance transfer with keep alive, so it won't allow going under ED. 2. **transferAll(dst, ka):** Transfer all balances with or without keep alive. 3. **transferAllowDeath(dst, val):** That is the transfer for full amount and allowing the address to become reaped. 4. **burn(val, ka):** To burn tokens with or without keep alive. 5. **Note:** calls starting with "force" are used by sudo or governance. #### Reading GSX balances You can use the following call to get information about GSX balances (acc=public gsx account address): 1. **system.account(acc):** Returns Free, Frozen and Reserved balances. # SDK & Tooling Being released during Q4 2025. #### **Substrate inbuilt tools** After compiling the G6 solo chain, you will have all the Substrate tools ready to be used (eg. subkey and others). Then you can use common frameworks such as python3's substrate-interface. #### U**seful code snippets** #### Running the G6 dev chain If you want to run the blockchain locally (compiled from the public release): ``` ./target/release/g6-solo-node --dev ``` Default WSS "CHAIN\_PORT": 9944 Default HTTP "RPC\_PORT": 30333 Then you can connect with python3's substrate-interface or PJS. # Gen6 MW & Chain API Guide Comprehensive documentation for Gen6 dApps APIs and blockchain integrations. ### Overview Gen6 dApps uses three main communication layers: 1. **HTTP APIs** - RESTful endpoints via middleware (`mw_url`) 2. **Blockchain Extrinsics** - On-chain transactions via Polkadot/Substrate API 3. **RPC Endpoints** - JSON-RPC 2.0 for parking pallet queries ### Architecture **Feature-first structure:** ``` src/packages// ├── api/ │ ├── axiosInstance.ts # HTTP client config │ ├── queries.ts # GET requests │ └── mutations.ts # POST/PUT/DELETE requests ├── hooks/ # React hooks for API & blockchain └── types.ts # TypeScript type definitions ``` ### Base URLs **Production:** * Middleware API: `https://gen6.app/api` * Validators API: `https://shepherd.gen6.app/api/v1` * Blockchain RPC: WebSocket from nodes config **Development:** * Middleware: Auto-detected or `http://localhost:5000/api` * Configuration: `src/data/nodes.ts` ### Authentication **Two-tier system:** 1. **Wallet Connection** - Polkadot wallet required 2. **JWT Authentication** - Signed challenge for API access **JWT Verification:** `GET /auth/jwt_ping` → `{ authenticated: boolean }` ### Features #### Core APIs * **Authentication** - JWT auth with wallet/Google OAuth signing * **Identity** - User profiles with merkle tree verification * **Real-Seal** - Document/text signing with blockchain anchoring * **Ncrypt** - End-to-end encrypted messaging * **Parking** - GSX token staking (JSON-RPC + extrinsics) * **Finance** - Token transfers (extrinsics only) * **Validator Dashboard** - Validator monitoring & stats ### Quick Start #### HTTP API Request ```typescript import { axiosInstance } from '@/packages//api/axiosInstance' const response = await axiosInstance.get('/endpoint') const data = response.data ``` #### Blockchain Transaction ```typescript import { useGen6 } from '@/contexts/gen6-context' import { useSigner } from '@/hooks/useSigner' const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const signerResult = await getSigner() // Works for wallet + Google auth const extrinsic = api.tx.pallet.method(params) await extrinsic.signAndSend( currentAccount.address, { signer: signerResult.signer }, ({ status }) => { if (status.isFinalized) console.log('Done') } ) ``` ### Technology Stack * **Frontend**: React 19, TypeScript, Vite * **Routing**: TanStack Router (file-based) * **State**: TanStack Query (server) + Zustand (client) * **HTTP**: Axios with interceptors * **Blockchain**: Polkadot.js API * **Auth**: JWT (HttpOnly cookies) + Polkadot/Google signing ### Environment Variables ```bash # Required (Those ones are set by default in data/nodes but in case you want to overwrite them, you will need to set these variables in you .env file) VITE_API_URL # Backend API base URL (middleware) VITE_NODE_URL # Blockchain WebSocket URL (wss://...) VITE_RPC_URL # Blockchain HTTP RPC URL (https://...) VITE_BLOCK_EXPLORER_URL # Block explorer URL VITE_VALIDATORS_API_URL # Validators monitoring API URL # Optional VITE_IS_DEV # Development mode flag ('true'/'false') VITE_ADD_LOCAL_NODE # Add local dev node to node selector VITE_GOOGLE_CLIENT_ID # Google OAuth client ID for auth ``` **Default Values**: If not set, defaults are loaded from src/data/nodes.ts based on environment. **Development Setup**: ```bash # .env.local VITE_API_URL=http://localhost:5000/api VITE_NODE_URL=ws://localhost:9944 VITE_RPC_URL=http://localhost:9944 VITE_BLOCK_EXPLORER_URL=https://explorer.gen6.dev VITE_IS_DEV=true VITE_ADD_LOCAL_NODE=true VITE_GOOGLE_CLIENT_ID=your_google_client_id ``` ### Important Notes * All middleware endpoints use `withCredentials: true` for JWT cookies * Parking uses separate JSON-RPC endpoint (no credentials) * Blockchain decimals: 18 (use `api.registry.chainDecimals[0]`) * Address format: SS58-355 (Gen6 addresses start with `g6x`) * Signing: Unified via `useSigner()` - supports both wallet extension and Google OAuth # 01. Gen6 MW Authentication ## Authentication Gen6 dApps uses a **two-tier authentication system** combining blockchain wallet signatures with JWT tokens for secure API access (all provided through G6 MW instance(s)). ### Overview Authentication requires: 1. **Polkadot Wallet** - User must have a connected wallet (via extension or Google auth) 2. **JWT Token** - User must sign a challenge to prove wallet ownership The JWT token is stored in an HttpOnly cookie and included automatically in all API requests. ### Authentication Flow #### Step 1: Get Challenge Request a signing challenge from the backend. **Endpoint**: `POST /auth/challenge` **Request**: ```typescript const response = await fetch(`${apiUrl}/auth/challenge`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, credentials: 'include', body: JSON.stringify({ public_address: g6_address // SS58-355 encoded address }) }) const data = await response.json() ``` **Request Body**: ```typescript interface ChallengeRequest { public_address: string // SS58-355 encoded Gen6 address } ``` **Response**: ```typescript interface ChallengeResponse { challenge: string // Random challenge string to sign } ``` **Example**: ```json { "challenge": "7f8a9b3c..." } ``` *** #### Step 2: Sign Challenge Sign the challenge using the Polkadot wallet. **Implementation**: ```typescript import { getSigner } from '@/packages/auth/lib/signer' // Get signer based on authentication method const signerResult = await getSigner( authMethod, authState.walletAddress, authState.googleAccessToken, api ) if (!signerResult.signer.signRaw) { throw new Error('signRaw is not available on the signer') } // Sign the challenge const signature = await signerResult.signer.signRaw({ address: g6_address, data: challenge, type: 'bytes' }) const signedChallenge = signature.signature ``` *** #### Step 3: Verify Signature Send the signed challenge to verify and obtain a JWT token. **Endpoint**: `POST /auth/verify` **Request**: ```typescript const response = await fetch(`${apiUrl}/auth/verify`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, credentials: 'include', body: JSON.stringify({ public_address: g6_address, signature: signature, origin: authMethod === 'google' ? 'google' : 'native' }) }) ``` **Request Body**: ```typescript interface VerifyRequest { public_address: string // SS58-355 encoded address signature: string // Hex-encoded signature from wallet origin: string // 'google' or 'native' (auth method identifier) } ``` **Response**: * Sets HttpOnly cookie with JWT token * Returns success status **Cookie Details**: * Name: Session cookie (managed by backend) * HttpOnly: `true` (not accessible via JavaScript) * Secure: `true` (HTTPS only in production) * SameSite: `Lax` *** #### Step 4: Verify Authentication Status Check if the current user is authenticated. **Endpoint**: `GET /auth/jwt_ping` **Implementation**: ```typescript import axiosInstance from '@/packages/auth/api/axiosInstance' export const queryJWTPing = async () => { const response = await axiosInstance.get('/auth/jwt_ping') return response.data } ``` **Response**: The response structure depends on the backend implementation. Check the actual response format returned by the backend. **Usage in React**: ```typescript import useIsAuthenticated from '@/packages/auth/hooks/useIsAuthenticated' function Component() { const { isAuthenticated } = useIsAuthenticated() if (!isAuthenticated) return
Please log in
return
Welcome!
} ``` **Query Configuration**: ```typescript useQuery({ queryKey: ['jwtPing', g6_address], queryFn: queryJWTPing, enabled: !!g6_address && hasAuthMethod, retry: false, staleTime: 5 * 60 * 1000, // 5 minutes gcTime: 10 * 60 * 1000, refetchOnWindowFocus: true, refetchOnReconnect: true }) ``` *** ### Faucet Request test tokens from the faucet. **Endpoint**: `POST /faucet/request` **Requirements**: * Authenticated user (JWT token in HttpOnly cookie) **Request**: ```typescript const response = await fetch(`${getApiUrl()}/faucet/request`, { method: 'POST', credentials: 'include' }) ``` **Response**: ```typescript interface FaucetResponse { success: boolean tx_hash?: string amount?: string } ``` **Note**: Faucet is automatically called after successful authentication for Google auth users. *** ### Route Guards Protect routes with authentication checks. **Pattern**: ```typescript import { createFileRoute } from '@tanstack/react-router' import { useGen6 } from 'gen6-context' import { useIsAuthenticated } from '@/packages/auth/hooks/useIsAuthenticated' import { Unlogged } from '@/components/unlogged' import { Unauthorized } from '@/components/unauthorized' export const Route = createFileRoute('/protected-route')({ component: RouteComponent }) function RouteComponent() { const { currentAccount } = useGen6() const { isAuthenticated } = useIsAuthenticated() // First tier: Check wallet connection if (!currentAccount) { return } // Second tier: Check JWT authentication if (!isAuthenticated) { return } // User is fully authenticated return } ``` *** ### Complete Authentication Hook The `useAuthorize` hook combines all authentication steps. **Location**: src/packages/auth/hooks/useAuthorize.tsx **Usage**: ```typescript import useAuthorize from '@/packages/auth/hooks/useAuthorize' function LoginButton() { const { authorize, isLoading } = useAuthorize((success) => { if (success) { toast.success('Successfully authenticated!') } else { toast.error('Authentication failed') } }) // Trigger authorize when needed (e.g. implicitly or via button) const handleLogin = () => { authorize() } return ( ) } ``` **Implementation Details**: ```typescript export function useAuthorize( setAuthenticationStatus: (success: boolean) => void ) { const { currentAccount } = useGen6() const authorize = async () => { // 1. Get challenge // 2. Sign challenge (handles Google/Wallet differences) // 3. Verify signature // 4. Reset/Invalidate queries // 5. Call setAuthenticationStatus(true/false) } return { authorize, isLoading } } ``` *** ### Axios Configuration All authenticated API calls use the centralized axios instance. **Location**: src/packages/auth/api/axiosInstance.ts **Configuration**: ```typescript import axios from 'axios' import { getApiUrl } from '@/data/nodes' export const axiosInstance = axios.create({ baseURL: getApiUrl(), headers: { 'Content-Type': 'application/json' }, withCredentials: true // Include cookies }) ``` *** ### Security Best Practices #### JWT Token Management 1. **HttpOnly cookies** - Tokens not accessible via JavaScript (XSS protection) 2. **Secure flag** - HTTPS only in production *** ### Common Issues #### "Authentication failed" * **Cause**: Wallet not connected or signature invalid * **Solution**: Ensure wallet extension is installed and unlocked #### "CORS error" * **Cause**: Origin not whitelisted on backend * **Solution**: Verify `origin` parameter matches backend whitelist *** ### Address Encoding Gen6 uses **SS58 address format with prefix 355**. **Conversion**: ```typescript import { encodeAddress } from '@polkadot/util-crypto' // Convert to Gen6 address format const g6_address = encodeAddress(publicKey, 355) ``` **Example**: ``` Public Key: 0x1234... Gen6 Address: g6x1234... (SS58-355) ``` Always use the Gen6-encoded address for API requests. *** ### Next Steps * Identity Management - Create and manage user profiles * Real-Seal - Sign documents and texts * Ncrypt - Send encrypted messages # 02. GGS-1 Identity MW API ## Identity Management GGS-1 Identity provides user profile management with privacy-preserving merkle tree verification and blockchain anchoring. ### Overview **Purpose**: Create and manage verifiable user identities with configurable field privacy levels. **Key Features**: * Customizable profile fields (name, bio, social links, etc.) * Privacy levels per field (private, community, public) * Merkle tree for verifiable credentials * Blockchain anchoring for tamper-proof verification * Profile image upload **Location**: src/packages/identity/ *** ### API Endpoints #### Get Current User's Identity Fetch the authenticated user's identity profile. **Endpoint**: `GET /identity/` **Authentication**: Required (JWT) **Implementation**: ```typescript import axiosInstance from '@/packages/identity/api/axiosInstance' import type { Identity } from '@/packages/identity/types' export const getIdentity = async () => { try { const response = await axiosInstance.get('/identity/') return response.data } catch (error) { console.error('Error fetching identity:', error) throw error } } ``` **Response**: ```typescript interface Identity { name?: string bio?: string location?: string email?: string phone?: string website?: string x?: string // Twitter/X telegram?: string discord?: string linkedin?: string instagram?: string medium?: string youtube?: string git?: string mastodon?: string image?: string // Profile image URL custom_fields?: { [key: string]: string } custom_fields_order?: Array field_configurations?: { [key: string]: { visibility?: 'private' | 'community' | 'public' pepper: string } } } ``` **Example Response**: ```json { "name": "Alice Smith", "bio": "Blockchain developer", "email": "alice@example.com", "x": "@alice", "custom_fields": { "company": "Web3 Corp" }, "custom_fields_order": ["company"], "field_configurations": { "name": { "visibility": "public", "pepper": "abc123..." }, "email": { "visibility": "private", "pepper": "def456..." } } } ``` **Usage**: ```typescript import { useQuery } from '@tanstack/react-query' import { getIdentity } from '@/packages/identity/api/queries/identity' function ProfilePage() { const { data: identity, isLoading } = useQuery({ queryKey: ['identity'], queryFn: getIdentity }) if (isLoading) return
Loading...
return (

{identity?.name}

{identity?.bio}

) } ``` *** #### Get Public Identity by ID Fetch another user's public identity information. **Endpoint**: `GET /identity/public/{id}` **Authentication**: Not required **Parameters**: * `id` (path): Identity UUID **Implementation**: ```typescript export const getIdentityById = async (id: string) => { try { const response = await axiosInstance.get(`/identity/public/${id}`) return response.data } catch (error) { console.error(`Error fetching identity with id ${id}:`, error) throw error } } ``` **Response**: Same structure as `GET /identity/` but only includes fields with `visibility: 'public'` *** #### Get Identity Profile Image Download the profile image for a specific identity. **Endpoint**: `GET /identity/public/{id}/image` **Authentication**: Not required **Parameters**: * `id` (path): Gen6 Address **Implementation**: ```typescript export const getIdentityImage = async (id: string) => { const response = await axiosInstance.get( `/identity/public/${id}/image`, { responseType: 'blob' } ) // Convert blob to object URL const imageUrl = URL.createObjectURL(response.data) return imageUrl } ``` **Response**: Image object URL string **Usage**: ```typescript import { useQuery } from '@tanstack/react-query' function ProfileImage({ identityId }: { identityId: string }) { const { data: imageUrl } = useQuery({ queryKey: ['identityImage', identityId], queryFn: () => getIdentityImage(identityId) }) return imageUrl ? Profile : null } ``` *** #### Calculate Identity Merkle Tree Generate a merkle tree hash for identity verification. **Endpoint**: `POST /identity/merkle` **Authentication**: Not required **Purpose**: Calculate the root hash before creating/updating identity to ensure data integrity. **Request**: ```typescript export const calculateIdentityMerkle = async (data: IdentityMerkleRequest) => { const response = await axiosInstance.post( '/identity/merkle', data, { headers: { 'Content-Type': 'application/json' } } ) return response.data } ``` **Request Body**: ```typescript interface IdentityMerkleRequest { identity: IdentityData & { g6_address: string } field_configurations: IdentityFieldConfigurations } ``` **Response**: ```typescript interface IdentityMerkleResponse { root_hash: string total_nodes: number total_levels: number all_nodes: string[] levels: Array> } ``` **Example Request**: ```json { "identity": { "name": "Alice Smith", "bio": "Developer", "email": "alice@example.com" }, "field_configurations": { "name": { "visibility": "public", "pepper": "abc123" }, "bio": { "visibility": "public", "pepper": "def456" }, "email": { "visibility": "private", "pepper": "ghi789" } } } ``` **Example Response**: ```json { "root_hash": "0x7f8a9b3c...", "total_nodes": 7, "total_levels": 3, "all_nodes": ["0xabc...", "0xdef...", "0x789..."], "levels": [{ "0": "0xabc..." }, { "0": "0xdef...", "1": "0x123..." }] } ``` **Usage Flow**: 1. User fills out identity form 2. Frontend calculates merkle tree via `/identity/merkle` 3. Frontend stores hash on blockchain 4. Frontend creates identity via `/identity/` with the same root\_hash *** #### Create Identity Create a new identity profile for the authenticated user. **Endpoint**: `POST /identity/` **Authentication**: Required (JWT) **Request**: ```typescript export const createIdentity = async (data: IdentityCreateUpdateRequest) => { const response = await axiosInstance.post('/identity/', data) return response.data } ``` **Request Body**: ```typescript interface IdentityCreateUpdateRequest { identity: IdentityData field_configurations: Record root_hash: string // From /identity/merkle custom_fields_order?: string[] // Order for custom fields } ``` **Response**: Created `Identity` object **Usage**: ```typescript import { useMutation } from '@tanstack/react-query' import { createIdentity } from '@/packages/identity/api/mutations/identity' function CreateIdentityForm() { const createMutation = useMutation({ mutationFn: createIdentity, onSuccess: () => { toast.success('Identity created!') } }) const handleSubmit = async (formData) => { // 1. Calculate merkle tree const merkleResult = await calculateIdentityMerkle(formData) // 2. Store on blockchain (see Blockchain section) await storeOnBlockchain(merkleResult.root_hash) // 3. Create identity with same root_hash await createMutation.mutateAsync({ ...formData, root_hash: merkleResult.root_hash }) } return
...
} ``` **Important**: Always calculate merkle tree and store on blockchain before creating identity. *** #### Update Identity Update an existing identity profile. **Endpoint**: `PUT /identity/` **Authentication**: Required (JWT) **Request**: ```typescript export const updateIdentity = async (data: IdentityCreateUpdateRequest) => { const response = await axiosInstance.put('/identity/', data) return response.data } ``` **Request Body**: Same as create **Response**: Updated `Identity` object **Note**: Updating identity requires recalculating the merkle tree and storing the new hash on blockchain. *** #### Upload Profile Image Upload or update the user's profile image. **Endpoint**: `PUT /identity/image` **Authentication**: Required (JWT) **Request**: ```typescript export const uploadIdentityImage = async (file: File) => { const formData = new FormData() formData.append('image', file) const response = await axiosInstance.put<{ image_url: string }>( '/identity/image', formData ) return response.data } ``` **Request Body**: FormData with image file **Supported Formats**: JPEG, PNG, GIF, WebP **File Size Limit**: Check backend configuration (typically 5MB) **Response**: ```typescript interface ImageUploadResponse { image_url: string // URL to access the uploaded image } ``` **Usage**: ```typescript import { useMutation } from '@tanstack/react-query' function ImageUpload() { const uploadMutation = useMutation({ mutationFn: uploadIdentityImage, onSuccess: (data) => { toast.success('Image uploaded!') console.log('Image URL:', data.image_url) } }) const handleFileChange = (e: React.ChangeEvent) => { const file = e.target.files?.[0] if (file) { uploadMutation.mutate(file) } } return ( ) } ``` *** ### Blockchain Integration #### Store Identity Hash On-Chain Anchor the identity data hash on the blockchain for tamper-proof verification. **Extrinsic**: `api.tx.dataRegistry.storeData()` **Parameters**: * `projectId`: `20250923` (Identity project ID) * `dataHash`: Blake2 hash of the full identity object (from `deterministicObjectBlake2Hash`) **Implementation**: ```typescript import { useGen6 } from '@/contexts/gen6-context' import { useSigner } from '@/hooks/useSigner' import { deterministicObjectBlake2Hash } from '@/packages/identity/utils/deterministicHash' export function useIdentityBlockchain() { const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const storeIdentityOnChain = async (identityPayload: Identity) => { const projectId = 20250923 const dataHash = deterministicObjectBlake2Hash(identityPayload) const signerResult = await getSigner() const extrinsic = api.tx.dataRegistry.storeData(projectId, dataHash) return new Promise((resolve, reject) => { extrinsic .signAndSend( currentAccount.address, { signer: signerResult.signer }, ({ status, dispatchError, txHash }) => { if (status.isFinalized) { if (dispatchError) { reject(new Error('Transaction failed')) } else { resolve(txHash.toString()) } } } ) .catch(reject) }) } return { storeIdentityOnChain } } ``` **Usage**: ```typescript function IdentityForm() { const { storeIdentityOnChain } = useIdentityBlockchain() const handleSubmit = async (identityPayload) => { // 1. Calculate merkle tree for database storage const merkleResult = await calculateIdentityMerkle({ identity: identityPayload, field_configurations: fieldConfigurations }) // 2. Store identity hash on blockchain const txHash = await storeIdentityOnChain(identityPayload) // 3. Create identity in database with merkle root await createIdentity({ identity: identityPayload, field_configurations: fieldConfigurations, root_hash: merkleResult.root_hash }) toast.success('Identity created and verified on blockchain!') } return
...
} ``` **Transaction Flow**: 1. User submits identity form 2. Frontend calculates Blake2 hash of full identity object for blockchain 3. Frontend calculates merkle root for database verification 4. Frontend stores hash on blockchain 5. Frontend creates identity in database with merkle root **Verification**: Anyone can verify the identity by: 1. Recalculating the Blake2 hash from the identity data 2. Comparing with the on-chain hash 3. Additionally, the merkle root in the database can be used for field-level verification *** ### Privacy Levels Identity fields support three visibility levels: #### Private * **Who can see**: Only the identity owner * **Use case**: Sensitive data (email, phone, private notes) * **Merkle tree**: Included in hash but not revealed #### Community * **Who can see**: Gen6 community members (authenticated users) * **Use case**: Semi-public data (Discord, Telegram handles) * **Merkle tree**: Included in hash and partially revealed #### Public * **Who can see**: Everyone (no authentication required) * **Use case**: Public profile (name, bio, social links) * **Merkle tree**: Included in hash and fully revealed **Configuration Example**: ```typescript const fieldConfigurations = { name: { visibility: 'public', pepper: generatePepper() }, email: { visibility: 'private', pepper: generatePepper() }, telegram: { visibility: 'community', pepper: generatePepper() } } ``` *** ### Custom Fields Add arbitrary key-value pairs to identity profiles. **Implementation**: ```typescript const identity = { name: 'Alice', custom_fields: { 'Favorite Color': 'Blue', 'Programming Language': 'Rust', 'Years of Experience': '5' } } const customFieldsOrder = [ 'Favorite Color', 'Programming Language', 'Years of Experience' ] ``` **Privacy**: Each custom field has its own visibility configuration. **Ordering**: Use `custom_fields_order` to control display order. *** ### Complete Identity Creation Flow #### Step-by-Step Guide **Step 1: Prepare Identity Data** ```typescript const identityData = { name: 'Alice Smith', bio: 'Blockchain developer', email: 'alice@example.com', x: '@alice' } const fieldConfigurations = { name: { visibility: 'public', pepper: generatePepper() }, bio: { visibility: 'public', pepper: generatePepper() }, email: { visibility: 'private', pepper: generatePepper() }, x: { visibility: 'public', pepper: generatePepper() } } ``` **Step 2: Calculate Merkle Tree for Database** ```typescript const merkleResult = await calculateIdentityMerkle({ identity: identityData, field_configurations: fieldConfigurations }) console.log('Merkle root hash:', merkleResult.root_hash) ``` **Step 3: Store Identity Hash on Blockchain** ```typescript const txHash = await storeIdentityOnChain(identityData) console.log('Blockchain transaction hash:', txHash) ``` **Step 4: Create Identity in Database** ```typescript await createIdentity({ identity: identityData, field_configurations: fieldConfigurations, root_hash: merkleResult.root_hash }) ``` **Step 5: Upload Profile Image (Optional)** ```typescript if (profileImage) { await uploadIdentityImage(profileImage) } ``` *** ### Query Keys **TanStack Query Keys**: ```typescript // Current user's identity ;['identity'][ // Public identity by ID ('identity', 'public', id) ][ // Identity image ('identityImage', id) ][ // Merkle calculation ('identityMerkle', data) ] ``` *** ### Error Handling #### Common Errors **"Identity already exists"** * **Cause**: User already has an identity * **Solution**: Use `updateIdentity()` instead of `createIdentity()` **"Transaction failed"** * **Cause**: Blockchain transaction rejected * **Solution**: Check wallet balance and network status *** ### Best Practices 1. **Always calculate merkle tree first** - Ensures data integrity 2. **Store on blockchain before database** - Prevents orphaned hashes 3. **Set appropriate visibility levels** - Protect sensitive data 4. **Handle errors gracefully** - Show user-friendly messages *** ### Next Steps * Real-Seal - Sign documents with verified identity * Ncrypt - Send messages with identity verification # 03. RealSeal ## Real-Seal Real-Seal provides document and text signing with blockchain verification, enabling tamper-proof digital signatures with public/private sharing. ### Overview **Purpose**: Sign and verify documents and texts using blockchain-anchored cryptographic signatures. **Key Features**: * Upload and sign PDF, Word, images, and other documents * Sign text content and URLs * Blockchain anchoring for tamper-proof verification * Share signed documents with specific addresses * Create public verification links **Location**: src/packages/real-seal/ *** ### Documents #### Upload Document Upload a document to Real-Seal for signing. **Endpoint**: `POST /real-seal/documents/` **Authentication**: Required (JWT) **Request**: ```typescript import { axiosInstance } from '@/packages/real-seal/api/axiosInstance' export const uploadDocument = async (file: File, title?: string) => { const formData = new FormData() formData.append('file', file) if (title) formData.append('title', title) const response = await axiosInstance.post( '/real-seal/documents/', formData ) return response.data } ``` **Request Body**: FormData * `file` (required): Document file * `title` (optional): Custom title for the document **Supported File Types**: * PDF: `.pdf` * Word: `.doc`, `.docx` * Excel: `.xls`, `.xlsx` * Images: `.jpg`, `.jpeg`, `.png`, `.gif`, `.webp` * Text: `.txt`, `.md` * Archives: `.zip` **File Size Limit**: Check configuration via `GET /real-seal/config` **Response**: ```typescript interface DocumentUploadResponse { document_id: string title?: string filename: string mimetype: string content_length: number file_hash: string visibility: string created_at: string } ``` **Example Response**: ```json { "document_id": "123e4567-e89b-12d3-a456-426614174000", "title": "Contract Agreement", "filename": "contract.pdf", "mimetype": "application/pdf", "content_length": 524288, "file_hash": "0x7f8a9b3c...", "visibility": "private", "created_at": "2025-01-15T10:30:00Z" } ``` **Usage**: ```typescript import { useMutation } from '@tanstack/react-query' function DocumentUpload() { const uploadMutation = useMutation({ mutationFn: ({ file, title }: { file: File; title?: string }) => uploadDocument(file, title), onSuccess: (data) => { toast.success('Document uploaded!') navigate(`/real-seal/documents/${data.uuid}`) } }) const handleUpload = (file: File) => { uploadMutation.mutate({ file }) } return } ``` *** #### Get Document Metadata Fetch metadata for a specific document. **Endpoint**: `GET /real-seal/documents/{id}` **Authentication**: Required (JWT) **Parameters**: * `id` (path): Document UUID **Implementation**: ```typescript export const getDocumentMetadata = async (id: string) => { const response = await axiosInstance.get( `/real-seal/documents/${id}` ) return response.data } ``` **Response**: `DocumentMetadata` object (see Upload Document) **Access Control**: * Owner can always access * Shared addresses can access if in `authorized_addresses` * Public access only if `public_enabled: true` *** #### Download Document Download the actual document file. **Endpoint**: `GET /real-seal/documents/{id}/download` **Authentication**: Required (JWT) **Parameters**: * `id` (path): Document UUID **Implementation**: ```typescript export const downloadDocument = async (id: string) => { const response = await axiosInstance.get( `/real-seal/documents/${id}/download`, { responseType: 'blob' } ) return response.data } ``` **Response**: File blob with original content type **Usage**: ```typescript function DownloadButton({ documentId }: { documentId: string }) { const downloadMutation = useMutation({ mutationFn: () => downloadDocument(documentId), onSuccess: async (blob, variables) => { // Get filename from metadata const metadata = await getDocumentMetadata(documentId) // Create download link const url = URL.createObjectURL(blob) const a = document.createElement('a') a.href = url a.download = metadata.filename a.click() URL.revokeObjectURL(url) } }) return ( ) } ``` *** #### List User Documents List all documents owned by or shared with the authenticated user. **Endpoint**: `GET /real-seal/documents?with_shared_addresses=true` **Authentication**: Required (JWT) **Implementation**: ```typescript export const listUserDocuments = async () => { const response = await axiosInstance.get( '/real-seal/documents', { params: { with_shared_addresses: true } } ) return response.data } ``` **Response**: ```typescript interface DocumentListResponse { documents: DocumentMetadata[] total_count: number } ``` **Usage**: ```typescript function DocumentList() { const { data, isLoading } = useQuery({ queryKey: ['real-seal', 'documents', 'user'], queryFn: listUserDocuments }) if (isLoading) return
Loading...
return (

Total: {data.total_count}

{data.documents.map(doc => ( ))}
) } ``` *** #### List Documents with Filters List documents with advanced filtering options. **Endpoint**: `GET /real-seal/documents?scope=owned&...` **Authentication**: Required (JWT) **Query Parameters**: * `scope` (optional): `'owned'` or `'shared'` * `start_date` (optional): ISO 8601 date string * `end_date` (optional): ISO 8601 date string * `min_size` (optional): Minimum file size in bytes * `max_size` (optional): Maximum file size in bytes * `file_format` (optional): MIME type filter * `search` (optional): Search in filename/title **Implementation**: ```typescript interface DocumentFilters { scope?: 'owned' | 'shared' start_date?: string end_date?: string min_size?: number max_size?: number file_format?: string search?: string } export const listDocumentsByScope = async (filters: DocumentFilters) => { const response = await axiosInstance.get( '/real-seal/documents', { params: filters } ) return response.data } ``` **Example Usage**: ```typescript // Get only owned PDFs from last month const filters = { scope: 'owned', start_date: '2025-01-01T00:00:00Z', file_format: 'application/pdf' } const { data } = useQuery({ queryKey: ['real-seal', 'documents', 'user', 'owned', filters], queryFn: () => listDocumentsByScope(filters) }) ``` *** #### Sign Document Sign a document with a blockchain-anchored cryptographic signature. **Endpoint**: `POST /real-seal/documents/{id}/sign` **Authentication**: Required (JWT) **Parameters**: * `id` (path): Document UUID **Request**: ```typescript interface SignDocumentRequest { file_hash: string // Blake2 hash of file content signature: string // Wallet signature of the signing message timestamp: string // Unix timestamp (seconds) } export const signDocument = async (id: string, data: SignDocumentRequest) => { const response = await axiosInstance.post( `/real-seal/documents/${id}/sign`, data ) return response.data } ``` **Request Body**: ```json { "file_hash": "0x7f8a9b3c...", "signature": "0xabc123...", "timestamp": "1705320600" } ``` **Response**: Updated `DocumentMetadata` with signature **Signature Process**: 1. Download document and calculate Blake2 hash 2. Construct signing message: `REAL_SEAL::SIGN_DOCUMENT::${documentHash}::${timestamp}` 3. Sign the message with wallet 4. Submit signature, hash, and timestamp to backend 5. Backend verifies signature matches owner and message 6. Document marked as signed **Implementation**: ```typescript import { blake2AsHex } from '@polkadot/util-crypto' import { encodeAddress } from '@polkadot/util-crypto' async function signDocumentFlow(documentId: string) { // 1. Download document const blob = await downloadDocument(documentId) const arrayBuffer = await blob.arrayBuffer() const uint8Array = new Uint8Array(arrayBuffer) // 2. Calculate hash const fileHash = blake2AsHex(uint8Array) // 3. Construct message and sign const timestamp = Math.floor(Date.now() / 1000).toString() const signingMessage = `REAL_SEAL::SIGN_DOCUMENT::${fileHash}::${timestamp}` const signerResult = await getSigner() // Use useSigner hook const signatureResult = await signerResult.signer.signRaw({ address: encodeAddress(currentAccount.address, 355), data: signingMessage, type: 'bytes' }) // 4. Submit signature await signDocument(documentId, { file_hash: fileHash, signature: signatureResult.signature, timestamp }) toast.success('Document signed!') } ``` *** #### Verify Document Signature Verify that a document's signature is valid and hasn't been tampered with. **Endpoint**: `GET /real-seal/documents/{id}/verify` **Authentication**: Not required for public documents **Parameters**: * `id` (path): Document UUID **Implementation**: ```typescript export const verifyDocumentSignature = async (id: string) => { const response = await axiosInstance.get( `/real-seal/documents/${id}/verify` ) return response.data } ``` **Response**: ```typescript interface VerificationResponse { valid: boolean signature: DocumentSignature | null on_chain_verified: boolean message?: string } interface DocumentSignature { signer_address: string signature: string signed_at: string signed_message: string } ``` **Example Response**: ```json { "valid": true, "signature": { "signer_address": "g6x...", "signature": "0xabc123...", "signed_at": "2025-01-15T10:30:00Z", "signed_message": "0x7f8a9b3c..." }, "on_chain_verified": true } ``` **Usage**: ```typescript function VerificationBadge({ documentId }: { documentId: string }) { const { data: verification } = useQuery({ queryKey: ['real-seal', 'documents', documentId, 'verification'], queryFn: () => verifyDocumentSignature(documentId) }) if (!verification?.valid) { return Invalid Signature } return ( ✓ Verified {verification.on_chain_verified && '(On-Chain)'} ) } ``` *** #### Share Document Share a document with specific Gen6 addresses. **Endpoint**: `POST /real-seal/documents/{id}/share` **Authentication**: Required (JWT - must be owner) **Parameters**: * `id` (path): Document UUID **Request**: ```typescript interface ShareRequest { addresses?: string[] // SS58-355 encoded addresses } export const shareDocument = async (id: string, addresses?: string[]) => { const response = await axiosInstance.post( `/real-seal/documents/${id}/share`, { addresses } ) return response.data } ``` **Request Body**: ```json { "addresses": ["g6x123...", "g6x456..."] } ``` **Response**: Updated `DocumentMetadata` with `authorized_addresses` **Behavior**: * If `addresses` is empty/undefined, shares with everyone * If `addresses` has values, shares only with those addresses * Replaces existing share list (not additive) **Usage**: ```typescript function ShareDocumentDialog({ documentId }: { documentId: string }) { const [addresses, setAddresses] = useState([]) const shareMutation = useMutation({ mutationFn: () => shareDocument(documentId, addresses), onSuccess: () => toast.success('Document shared!') }) return ( setAddresses(e.target.value.split(','))} /> ) } ``` *** #### Unshare Document Revoke document access for specific addresses. **Endpoint**: `DELETE /real-seal/documents/{id}/share` **Authentication**: Required (JWT - must be owner) **Parameters**: * `id` (path): Document UUID **Request**: ```typescript interface UnshareRequest { addresses: string[] // Addresses to revoke } export const unshareDocument = async (id: string, addresses: string[]) => { const response = await axiosInstance.delete( `/real-seal/documents/${id}/share`, { data: { addresses } } ) return response.data } ``` **Request Body**: ```json { "addresses": ["g6x123..."] } ``` **Response**: Updated `DocumentMetadata` *** #### Create Public Link Generate a public link for document verification without authentication. **Endpoint**: `POST /real-seal/documents/{id}/public` **Authentication**: Required (JWT - must be owner) **Parameters**: * `id` (path): Document UUID **Implementation**: ```typescript export const createPublicLink = async (id: string) => { const response = await axiosInstance.post( `/real-seal/documents/${id}/public` ) return response.data } ``` **Response**: ```typescript interface PublicLinkResponse { public_url: string created_at: string } ``` **Example Response**: ```json { "public_url": "https://app.gen6.com/real-seal/public/abc123def456", "created_at": "2025-01-15T10:30:00Z" } ``` **Usage**: ```typescript function CreatePublicLinkButton({ documentId }: { documentId: string }) { const createMutation = useMutation({ mutationFn: () => createPublicLink(documentId), onSuccess: (data) => { navigator.clipboard.writeText(data.public_url) toast.success('Public link copied!') } }) return ( ) } ``` *** #### Revoke Public Link Disable public access to a document. **Endpoint**: `DELETE /real-seal/documents/{id}/public` **Authentication**: Required (JWT - must be owner) **Parameters**: * `id` (path): Document UUID **Implementation**: ```typescript export const revokePublicLink = async (id: string) => { const response = await axiosInstance.delete( `/real-seal/documents/${id}/public` ) return response.data } ``` **Response**: Updated `DocumentMetadata` with `public_enabled: false` *** #### Get Public Link Retrieve the current public link for a document (if enabled). **Endpoint**: `GET /real-seal/documents/{id}/public` **Authentication**: Required (JWT - must be owner) **Parameters**: * `id` (path): Document UUID **Implementation**: ```typescript export const getPublicLink = async (id: string) => { const response = await axiosInstance.get( `/real-seal/documents/${id}/public` ) return response.data } ``` **Response**: `PublicLinkResponse` or 404 if not enabled *** #### Delete Document Permanently delete a document. **Endpoint**: `DELETE /real-seal/documents/{id}` **Authentication**: Required (JWT - must be owner) **Parameters**: * `id` (path): Document UUID **Implementation**: ```typescript export const deleteDocument = async (id: string) => { await axiosInstance.delete(`/real-seal/documents/${id}`) } ``` **Response**: 204 No Content **Warning**: This action is permanent and cannot be undone. **Usage**: ```typescript function DeleteDocumentButton({ documentId }: { documentId: string }) { const deleteMutation = useMutation({ mutationFn: () => deleteDocument(documentId), onSuccess: () => { toast.success('Document deleted') navigate('/real-seal/documents') } }) return ( Are you sure? This action cannot be undone. Cancel deleteMutation.mutate()}> Delete ) } ``` *** ### Public Document Access #### Get Public Document Metadata Access document metadata via public token (no authentication required). **Endpoint**: `GET /real-seal/public/{token}/metadata` **Authentication**: Not required **Parameters**: * `token` (path): Public access token from public URL **Implementation**: ```typescript export const getPublicDocumentMetadataByToken = async (token: string) => { const response = await axiosInstance.get( `/real-seal/public/${token}/metadata` ) return response.data } ``` **Response**: `DocumentMetadata` object **Usage**: ```typescript // From public URL: https://app.gen6.com/real-seal/public/abc123def456 const token = 'abc123def456' function PublicDocumentPage({ token }: { token: string }) { const { data: metadata } = useQuery({ queryKey: ['real-seal', 'public', token], queryFn: () => getPublicDocumentMetadataByToken(token) }) return (

{metadata.title || metadata.filename}

Signed by: {metadata.signature?.signer_address}

) } ``` *** #### Download Public Document Download document via public token (no authentication required). **Endpoint**: `GET /real-seal/public/{token}/download` **Authentication**: Not required **Parameters**: * `token` (path): Public access token **Implementation**: ```typescript export const downloadPublicDocumentByToken = async (token: string) => { const response = await axiosInstance.get( `/real-seal/public/${token}/download`, { responseType: 'blob' } ) return response.data } ``` **Response**: File blob *** ### Text Signing #### Create Text to Sign Create a text or URL entry for signing. **Endpoint**: `POST /real-seal/texts/` **Authentication**: Required (JWT) **Request**: ```typescript interface CreateTextRequest { content: string type: 'text' | 'url' title?: string } export const createTextSign = async (data: CreateTextRequest) => { const response = await axiosInstance.post( '/real-seal/texts/', data ) return response.data } ``` **Request Body**: ```json { "content": "I hereby agree to the terms...", "type": "text", "title": "Agreement" } ``` **Response**: ```typescript interface TextMetadata { uuid: string title: string | null content: string type: 'text' | 'url' content_hash: string // Blake2 hash of content visibility: string owner_address: string signature: TextSignature | null created_at: string updated_at: string authorized_addresses: string[] public_enabled: boolean public_created_at: string | null } interface TextSignature { signer_address: string signature: string signed_at: string signed_message: string } ``` *** #### Get Text Metadata Fetch metadata for a specific text entry. **Endpoint**: `GET /real-seal/texts/{id}` **Authentication**: Required (JWT) **Parameters**: * `id` (path): Text UUID **Implementation**: ```typescript export const getTextMetadata = async (id: string) => { const response = await axiosInstance.get( `/real-seal/texts/${id}` ) return response.data } ``` **Response**: `TextMetadata` object *** #### Sign Text Sign a text entry with a cryptographic signature. **Endpoint**: `POST /real-seal/texts/{id}/sign` **Authentication**: Required (JWT) **Parameters**: * `id` (path): Text UUID **Request**: ```typescript interface SignTextRequest { content_hash: string // Blake2 hash of content signature: string // Wallet signature timestamp: string // ISO 8601 } export const signText = async (id: string, data: SignTextRequest) => { const response = await axiosInstance.post( `/real-seal/texts/${id}/sign`, data ) return response.data } ``` **Signing Process**: ```typescript import { blake2AsHex } from '@polkadot/util-crypto' import { stringToU8a } from '@polkadot/util' import { web3FromAddress } from '@polkadot/extension-dapp' async function signTextFlow(textId: string, content: string) { // 1. Calculate hash const contentHash = blake2AsHex(stringToU8a(content)) // 2. Sign hash const injector = await web3FromAddress(currentAccount.address) const signatureResult = await injector.signer.signRaw({ address: currentAccount.address, data: contentHash, type: 'bytes' }) // 3. Submit signature const timestamp = new Date().toISOString() await signText(textId, { content_hash: contentHash, signature: signatureResult.signature, timestamp }) toast.success('Text signed!') } ``` *** #### Create and Sign Text (Single Call) Create and sign a text in one API call. **Endpoint**: `POST /real-seal/texts/sign` **Authentication**: Required (JWT) **Request**: ```typescript interface CreateAndSignTextRequest { content: string type: 'text' | 'url' title?: string signature: string timestamp: string } export const createAndSignText = async (data: CreateAndSignTextRequest) => { const response = await axiosInstance.post( '/real-seal/texts/sign', data ) return response.data } ``` **Usage**: Convenience method to avoid separate create + sign calls. *** #### List Text Entries List text entries with optional filters. **Endpoint**: `GET /real-seal/texts/` **Authentication**: Required (JWT) **Query Parameters**: * `scope`: `'owned'` or `'shared'` * `type`: `'text'` or `'url'` * `start_date`, `end_date`: Date range * `search`: Search in content/title **Implementation**: ```typescript export const listTextSigns = async (filters?: { scope?: 'owned' | 'shared' type?: 'text' | 'url' start_date?: string end_date?: string search?: string }) => { const response = await axiosInstance.get( '/real-seal/texts/', { params: filters } ) return response.data } ``` **Response**: ```typescript interface TextListResponse { texts: TextMetadata[] total_count: number } ``` *** #### Delete Text Delete a text entry. **Endpoint**: `DELETE /real-seal/texts/{id}` **Authentication**: Required (JWT - must be owner) **Parameters**: * `id` (path): Text UUID **Implementation**: ```typescript export const deleteTextSign = async (id: string) => { await axiosInstance.delete(`/real-seal/texts/${id}`) } ``` *** #### Text Sharing & Public Links Text entries support the same sharing and public link features as documents: * `POST /real-seal/texts/{id}/share` - Share with addresses * `DELETE /real-seal/texts/{id}/share` - Revoke sharing * `POST /real-seal/texts/{id}/public` - Create public link * `DELETE /real-seal/texts/{id}/public` - Revoke public link * `GET /real-seal/texts/{id}/public` - Get public link APIs identical to document endpoints (see above). *** #### Query Account Balance Check account balance for transaction fee estimation. **Blockchain Query**: `api.query.system.account()` **Parameters**: * `address`: SS58-355 encoded account address **Implementation**: ```typescript // Used in upload-document-modal.tsx for fee estimation const balance = await api.query.system.account(currentAccount.address) const accountData = balance.toJSON() const freeBalance = accountData.data.free ``` **Response**: Account info including free balance for fee calculation **Usage**: Automatically checked before document upload to ensure sufficient balance for blockchain transactions. *** ### Blockchain Integration #### Store Document Hash On-Chain Anchor the document hash on the blockchain for immutable verification. **Extrinsic**: `api.tx.dataRegistry.storeData()` **Parameters**: * `projectId`: `886` (Real-Seal project ID) * `dataHash`: Blake2 hash of document content **Implementation**: ```typescript import { useGen6 } from '@/contexts/gen6-context' import { useSigner } from '@/hooks/useSigner' export function useRealSeal() { const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const storeDocumentHash = async (fileHash: string) => { const signerResult = await getSigner() const extrinsic = api.tx.dataRegistry.storeData( 886, // Project ID for Real-Seal fileHash // Blake2 hash ) return new Promise((resolve, reject) => { extrinsic .signAndSend( currentAccount.address, { signer: signerResult.signer }, ({ status, dispatchError }) => { if (status.isFinalized) { if (dispatchError) { reject(new Error('Transaction failed')) } else { resolve() } } } ) .catch(reject) }) } return { storeDocumentHash } } ``` **Complete Signing Flow**: ```typescript async function completeSigningFlow(documentId: string) { // 1. Download and hash document const blob = await downloadDocument(documentId) const arrayBuffer = await blob.arrayBuffer() const uint8Array = new Uint8Array(arrayBuffer) const fileHash = blake2AsHex(uint8Array) // 2. Sign hash with wallet const injector = await web3FromAddress(currentAccount.address) const signatureResult = await injector.signer.signRaw({ address: currentAccount.address, data: fileHash, type: 'bytes' }) // 3. Store hash on blockchain await storeDocumentHash(fileHash) // 4. Submit signature to backend const timestamp = new Date().toISOString() await signDocument(documentId, { file_hash: fileHash, signature: signatureResult.signature, timestamp }) toast.success('Document signed and verified on blockchain!') } ``` *** ### Configuration #### Get Real-Seal Config Retrieve Real-Seal configuration (e.g., max file size). **Endpoint**: `GET /real-seal/config` **Authentication**: Not required **Implementation**: ```typescript export const getRealSealConfig = async () => { const response = await axiosInstance.get('/real-seal/config') return response.data } ``` **Response**: ```typescript interface RealSealConfig { max_file_size: number // In bytes allowed_mimetypes: string[] } ``` **Example Response**: ```json { "max_file_size": 10485760, "allowed_mimetypes": [ "application/pdf", "application/msword", "image/jpeg", "image/png" ] } ``` *** ### Query Keys **TanStack Query Keys**: ```typescript const realSealKeys = { all: ['real-seal'] as const, documents: () => [...realSealKeys.all, 'documents'] as const, document: (id: string) => [...realSealKeys.documents(), id] as const, userDocuments: () => [...realSealKeys.documents(), 'user'] as const, userDocumentsOwned: (filters) => [...realSealKeys.userDocuments(), 'owned', filters] as const, userDocumentsShared: (filters) => [...realSealKeys.userDocuments(), 'shared', filters] as const, verification: (id: string) => [...realSealKeys.document(id), 'verification'] as const, publicDocument: (token: string) => [...realSealKeys.all, 'public', token] as const, texts: () => [...realSealKeys.all, 'texts'] as const, text: (id: string) => [...realSealKeys.texts(), id] as const } ``` *** ### Next Steps * Ncrypt - Send encrypted messages * Identity - Link signed documents to verified identities # 04. NCrypt ## Encrypted Messaging NCrypt ("NC" or "nc") provides end-to-end encrypted messaging with blockchain-anchored message delivery and optional read receipts. ### Overview **Purpose**: Send and receive encrypted messages with verifiable delivery and read status. **Key Features**: * End-to-end encryption using ChaCha20-Poly1305 * X25519 key exchange * On-chain message delivery for verifiability * Read receipts with cryptographic proof * File attachments * Thread-based conversation view **Location**: src/packages/ncrypt/ **Encryption Details**: * **Algorithm**: ChaCha20-Poly1305 (AEAD - Authenticated Encryption with Associated Data) * **Key Exchange**: X25519 (Curve25519 for Diffie-Hellman) * **Message ID**: 8-byte random or SHA-256 hash * **Key Storage**: LocalStorage (format: `ncrypt_private_key_{encodedAddress}`) *** ### Encryption Setup #### Generate Encryption Keys Before sending/receiving encrypted messages, users must generate and publish their X25519 key pair. **Implementation**: ```typescript import { x25519 } from '@noble/curves/ed25519' import { encodeAddress } from '@polkadot/util-crypto' import { u8aToHex } from '@polkadot/util' export function useGenerateKeys() { const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const generateKeys = async () => { // 1. Generate X25519 key pair using @noble/curves const privateKey = x25519.utils.randomPrivateKey() const publicKey = x25519.getPublicKey(privateKey) // 2. Store private key in localStorage const encodedAddress = encodeAddress(currentAccount.address, 355) const storageKey = `ncrypt_private_key_${encodedAddress}` localStorage.setItem(storageKey, u8aToHex(privateKey)) // 3. Publish public key on blockchain await publishPublicKey(u8aToHex(publicKey)) return { publicKey, privateKey } } return { generateKeys } } ``` **Blockchain Extrinsic**: `api.tx.postman.publishKey()` **Parameters**: * `keyPayload`: X25519 public key (32 bytes) **Implementation**: ```typescript async function publishPublicKey(publicKey: Uint8Array) { const signerResult = await getSigner() // Format payload as expected by the chain (MultiAddress/Enum) const keyPayload = { X25519: u8aToHex(publicKey) } const extrinsic = api.tx.postman.publishKey(keyPayload) return new Promise((resolve, reject) => { extrinsic .signAndSend( currentAccount.address, { signer: signerResult.signer }, ({ status, dispatchError }) => { if (status.isFinalized) { if (dispatchError) { reject(new Error('Failed to publish key')) } else { resolve() } } } ) .catch(reject) }) } ``` **Storage Location**: * **Private Key**: `localStorage.ncrypt_private_key_{address}` * **Public Key**: On-chain via `postman.keys()` query *** #### Retrieve Public Key Fetch another user's published X25519 public key from the blockchain. **Blockchain Query**: `api.query.postman.keys()` **Parameters**: * `encodedAddress`: SS58-355 encoded Gen6 address **Implementation**: ```typescript import { encodeAddress } from '@polkadot/util-crypto' export function useBlockchainKey() { const { api } = useGen6() const getPublicKey = async (address: string) => { const encodedAddress = encodeAddress(address, 355) const result = await api.query.postman.keys(encodedAddress) if (result.isEmpty) { throw new Error('User has not published encryption key') } return result.toString() } return { getPublicKey } } ``` **Usage**: ```typescript import { useQuery } from '@tanstack/react-query' function RecipientKeyCheck({ recipientAddress }: { recipientAddress: string }) { const { getPublicKey } = useBlockchainKey() const { data: publicKey, error } = useQuery({ queryKey: ['blockchainKey', recipientAddress], queryFn: () => getPublicKey(recipientAddress) }) if (error) { return User has not enabled encryption } return
User has encryption enabled
} ``` *** #### Query Read Receipts Check if messages have been read by querying the blockchain inbox. **Blockchain Query**: `api.query.postman.inbox()` **Parameters**: * `recipientAddress`: SS58-355 encoded recipient address * `senderAddress`: SS58-355 encoded sender address **Implementation**: ```typescript import { encodeAddress } from '@polkadot/util-crypto' export function useThreadInbox( senderAddress: string | undefined, recipientAddress: string | undefined ) { const { api, currentAccount } = useGen6() return useQuery({ queryKey: ['threadInbox', senderAddress, recipientAddress], queryFn: async () => { if (!api || !currentAccount || !senderAddress || !recipientAddress) { return [] } const encodedRecipient = encodeAddress(recipientAddress, 355) const encodedSender = encodeAddress(senderAddress, 355) const inboxData = await api.query.postman.inbox( encodedRecipient, encodedSender ) return (inboxData.toJSON() as Array) || [] }, enabled: !!api && !!currentAccount && !!senderAddress && !!recipientAddress, staleTime: 1000, refetchInterval: 3000 }) } ``` **Response**: Array of read receipt data **Purpose**: Provides cryptographic proof that messages have been read by the recipient, enabling read receipts functionality. *** ### Messaging API #### Send Message Create and send an encrypted message. **Endpoint**: `POST /ncrypt/messages` **Authentication**: Required (JWT) **Request**: ```typescript interface CreateMessageParams { recipient_g6_address: string encrypted_content_for_recipient: string encrypted_content_for_sender: string subject?: string requires_read_signature?: boolean on_chain_message_id?: string attachment_ids?: string[] } export const createMessage = async (params: CreateMessageParams) => { const response = await axiosInstance.post('/ncrypt/messages', params) return response.data } ``` **Request Body**: ```json { "recipient_g6_address": "g6x123...", "encrypted_content_for_recipient": "base64_encrypted_data", "encrypted_content_for_sender": "base64_encrypted_data", "subject": "Meeting Notes", "requires_read_signature": true, "on_chain_message_id": "0xabc123...", "attachment_ids": ["uuid-1", "uuid-2"] } ``` **Response**: ```typescript interface Message { id: number sender_g6_address: string recipient_g6_address: string encrypted_content: string | null encrypted_content_for_sender: string | null encrypted_content_for_recipient: string | null created_at: string read_at: string | null requires_read_signature: boolean is_unlocked: boolean has_attachments: boolean attachments: Attachment[] on_chain_message_id?: string } interface Attachment { id: string filename: string url: string mime_type: string size: number } ``` **Encryption Process**: ```typescript import { x25519 } from '@noble/curves/ed25519' import { chacha20poly1305 } from '@noble/ciphers/chacha' import { randomBytes } from '@noble/ciphers/webcrypto' async function encryptMessage( content: string, recipientPublicKey: Uint8Array, senderPrivateKey: Uint8Array ) { // 1. Calculate shared secret const sharedSecret = x25519.getSharedSecret( senderPrivateKey, recipientPublicKey ) // 2. Generate nonce (12 bytes for ChaCha20-Poly1305) const nonce = randomBytes(12) // 3. Encrypt content const messageBytes = new TextEncoder().encode(content) const aead = chacha20poly1305(sharedSecret, nonce) const encrypted = aead.encrypt(messageBytes) // 4. Combine nonce + encrypted data and encode // Implementation specific combination logic // ... } ``` **Important**: Messages are encrypted twice: 1. `encrypted_content_for_recipient` - Recipient can decrypt 2. `encrypted_content_for_sender` - Sender can decrypt (for message history) *** #### Blockchain Message Delivery For verifiable delivery, messages can be sent on-chain. **Blockchain Extrinsic**: `api.tx.postman.sendMessage()` **Parameters**: * `recipientAddress`: SS58-355 encoded address * `messagePayload`: Encrypted message payload * `trackingHash` (optional): SHA-256 hash for tracking **Implementation**: ```typescript export function useSendMessage() { const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const sendMessageOnChain = async ( recipientAddress: string, encryptedContent: string, trackingHash?: string ) => { const signerResult = await getSigner() const extrinsic = api.tx.postman.sendMessage( recipientAddress, encryptedContent, trackingHash || null ) return new Promise((resolve, reject) => { extrinsic .signAndSend( currentAccount.address, { signer: signerResult.signer }, ({ status, events }) => { if (status.isFinalized) { // Extract message ID from events const messageId = events .find(({ event }) => event.section === 'postman') ?.event.data[0]?.toString() resolve(messageId || '') } } ) .catch(reject) }) } return { sendMessageOnChain } } ``` **Complete Send Flow**: ```typescript async function sendEncryptedMessage( recipientAddress: string, content: string, requiresReadSignature: boolean ) { // 1. Get recipient's public key const recipientPublicKey = await getPublicKey(recipientAddress) // 2. Get sender's private key const senderPrivateKey = getPrivateKeyFromStorage(currentAccount.address) // 3. Encrypt for recipient const encryptedForRecipient = await encryptMessage( content, recipientPublicKey, senderPrivateKey ) // 4. Encrypt for sender (using own public key) const senderPublicKey = await getPublicKey(currentAccount.address) const encryptedForSender = await encryptMessage( content, senderPublicKey, senderPrivateKey ) // 5. Send on-chain (optional) let onChainMessageId if (requiresReadSignature) { onChainMessageId = await sendMessageOnChain( recipientAddress, encryptedForRecipient ) } // 6. Store in database await createMessage({ recipient_g6_address: recipientAddress, encrypted_content_for_recipient: encryptedForRecipient, encrypted_content_for_sender: encryptedForSender, requires_read_signature: requiresReadSignature, on_chain_message_id: onChainMessageId }) toast.success('Message sent!') } ``` *** #### Get Message Threads Retrieve a paginated list of message threads (conversations). **Endpoint**: `GET /ncrypt/threads` **Authentication**: Required (JWT) **Query Parameters**: * `page` (optional): Page number (default: 1) * `page_size` (optional): Items per page (default: 20) **Implementation**: ```typescript interface GetThreadsParams { page?: number page_size?: number } export const getThreads = async (params?: GetThreadsParams) => { const response = await axiosInstance.get( '/ncrypt/threads', { params } ) return response.data } ``` **Response**: ```typescript interface PaginatedThreadsResponse { threads: Thread[] total_count: number page: number page_size: number } ``` **Example Response**: ```json { "threads": [ { "peer_address": "g6x123...", "last_message": { "id": 42, "sender_g6_address": "g6x123...", "encrypted_content": "...", "created_at": "2025-01-15T10:30:00Z" }, "unread_count": 3, "total_messages": 15 } ], "total_count": 5, "page": 1, "page_size": 20 } ``` **Usage**: ```typescript function MessageThreads() { const [page, setPage] = useState(1) const { data, isLoading } = useQuery({ queryKey: ['threads', page], queryFn: () => getThreads({ page, page_size: 20 }) }) if (isLoading) return
Loading...
return (
{data.threads.map(thread => ( ))}
) } ``` *** #### Get Messages in Thread Retrieve messages in a specific conversation. **Endpoint**: `GET /ncrypt/threads/{peer_address}` **Authentication**: Required (JWT) **Parameters**: * `peer_address` (path): Gen6 address of conversation partner * `page` (query): Page number * `page_size` (query): Items per page **Implementation**: ```typescript export const getMessagesInThread = async ( peerAddress: string, params?: { page?: number; page_size?: number } ) => { const response = await axiosInstance.get( `/ncrypt/threads/${peerAddress}`, { params } ) return response.data } ``` **Response**: ```typescript interface PaginatedMessagesResponse { messages: Message[] total_count: number total_pages: number page: number page_size: number has_next: boolean has_previous: boolean } ``` **Decryption**: ```typescript function DecryptedMessage({ message }: { message: Message }) { const [decrypted, setDecrypted] = useState('') const { currentAccount } = useGen6() useEffect(() => { const decrypt = async () => { // Determine which encrypted content to use const isReceived = message.recipient_g6_address === currentAccount.address const encryptedContent = isReceived ? message.encrypted_content_for_recipient : message.encrypted_content_for_sender // Get private key from localStorage const privateKey = getPrivateKeyFromStorage(currentAccount.address) // Get peer's public key const peerAddress = isReceived ? message.sender_g6_address : message.recipient_g6_address const peerPublicKey = await getPublicKey(peerAddress) // Decrypt message const decryptedContent = await decryptMessage( encryptedContent, peerPublicKey, privateKey ) setDecrypted(decryptedContent) } decrypt() }, [message]) return
{decrypted || 'Decrypting...'}
} ``` **Decryption Implementation**: ```typescript import { x25519 } from '@noble/curves/ed25519' import { chacha20poly1305 } from '@noble/ciphers/chacha' import { hexToU8a } from '@polkadot/util' async function decryptMessage( encryptedBase64: string, peerPublicKey: string, privateKey: string ) { // 1. Decode base64 const combined = Buffer.from(encryptedBase64, 'base64') // 2. Extract nonce and encrypted data const nonce = combined.slice(0, 12) const encrypted = combined.slice(12) // 3. Calculate shared secret const sharedSecret = x25519.getSharedSecret( hexToU8a(privateKey), hexToU8a(peerPublicKey) ) // 4. Decrypt const aead = chacha20poly1305(sharedSecret, nonce) const decrypted = aead.decrypt(encrypted) if (!decrypted) { throw new Error('Failed to decrypt message') } // 5. Convert to string return new TextDecoder().decode(decrypted) } ``` *** #### Mark Thread as Read Mark all messages in a thread as read. **Endpoint**: `PATCH /ncrypt/threads/{peer_address}/read` **Authentication**: Required (JWT) **Parameters**: * `peer_address` (path): Peer Gen6 address **Implementation**: ```typescript export const markThreadAsRead = async (peerAddress: string) => { const response = await axiosInstance.patch( `/ncrypt/threads/${peerAddress}/read` ) return response.data } ``` **Response**: Updated thread with `unread_count: 0` **Usage**: ```typescript function MessageThread({ peerAddress }: { peerAddress: string }) { const markReadMutation = useMutation({ mutationFn: () => markThreadAsRead(peerAddress), onSuccess: () => { queryClient.invalidateQueries({ queryKey: ['threads'] }) } }) useEffect(() => { // Mark as read when user opens thread markReadMutation.mutate() }, [peerAddress]) return
...
} ``` *** #### Delete Thread Delete an entire conversation thread. **Endpoint**: `DELETE /ncrypt/threads/{peer_address}` **Authentication**: Required (JWT) **Parameters**: * `peer_address` (path): Peer Gen6 address **Implementation**: ```typescript export const deleteThread = async (peerAddress: string) => { await axiosInstance.delete(`/ncrypt/threads/${peerAddress}`) } ``` **Response**: 204 No Content **Warning**: This permanently deletes all messages in the thread. *** ### Attachments #### Upload Attachment Upload a file to attach to messages. **Endpoint**: `POST /ncrypt/attachments` **Authentication**: Required (JWT) **Request**: ```typescript export const uploadAttachment = async (file: File) => { const formData = new FormData() formData.append('file', file) const response = await axiosInstance.post( '/ncrypt/attachments', formData ) return response.data } ``` **Response**: ```typescript interface Attachment { id: string filename: string url: string mime_type: string size: number } ``` **Usage Flow**: ```typescript function SendMessageWithAttachment() { const [attachmentIds, setAttachmentIds] = useState([]) const uploadMutation = useMutation({ mutationFn: uploadAttachment, onSuccess: (data) => { setAttachmentIds(prev => [...prev, data.id]) toast.success('File uploaded!') } }) const sendMutation = useMutation({ mutationFn: (params: CreateMessageParams) => createMessage(params) }) const handleSend = async (content: string, recipientAddress: string) => { // Encrypt message (see previous section) const encrypted = await encryptMessage(content, ...) // Send with attachments await sendMutation.mutateAsync({ recipient_g6_address: recipientAddress, encrypted_content_for_recipient: encrypted.forRecipient, encrypted_content_for_sender: encrypted.forSender, attachment_ids: attachmentIds }) } return (
{ const file = e.target.files?.[0] if (file) uploadMutation.mutate(file) }} />
) } ``` *** ### Read Receipts #### Request Read Proof Request cryptographic proof that a message was read. **Blockchain Extrinsic**: `api.tx.postman.requestPassphrase()` **Parameters**: * `senderAddress`: Message sender address * `messagePayload`: Original encrypted message **Implementation**: ```typescript export function useRequestReadProof() { const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const requestReadProof = async ( senderAddress: string, messagePayload: string ) => { const signerResult = await getSigner() const extrinsic = api.tx.postman.requestPassphrase( senderAddress, messagePayload ) return new Promise((resolve, reject) => { extrinsic .signAndSend( currentAccount.address, { signer: signerResult.signer }, ({ status, dispatchError }) => { if (status.isFinalized) { if (dispatchError) { reject(new Error('Failed to request read proof')) } else { resolve() } } } ) .catch(reject) }) } return { requestReadProof } } ``` **Usage**: ```typescript function MessageWithReadReceipt({ message }: { message: Message }) { const { requestReadProof } = useRequestReadProof() const handleRequestProof = async () => { if (!message.on_chain_message_id) { toast.error('Message not sent on-chain') return } await requestReadProof( message.sender_g6_address, message.encrypted_content_for_recipient! ) toast.success('Read proof requested') } return (

{message.encrypted_content}

{message.requires_read_signature && !message.read_at && ( )} {message.read_at && ( Read at {message.read_at} )}
) } ``` **Note**: Read receipts only work for messages sent on-chain (`on_chain_message_id` must be set). *** ### Query Keys **TanStack Query Keys**: ```typescript // Message threads ;['threads'][('threads', page)][ // Messages in thread ('messages', peerAddress) ][('messages', peerAddress, page)][ // Blockchain keys ('blockchainKey', address) ][ // Attachments ('attachment', attachmentId) ] ``` *** ### Best Practices 1. **Generate keys on first use** - Prompt users to enable encryption 2. **Check recipient has keys** - Verify before allowing message send 3. **Backup private keys** - Provide export/import functionality *** ### Next Steps * Parking - Stake tokens for validator rewards * Finance - Transfer tokens # 05. Parking ## Secure Parking Parking allows users to secure their tokens to keep them immovable even during private key compromise. ### Overview **Purpose**: Park tokens and secure them. **Key Features**: * Park tokens to secure GSX amount * Unpark tokens (with unfreezing period) * Withdraw unfrozen tokens * Query parked amounts and get rewards **Location**: src/packages/parking/ *** ### Blockchain Interactions Parking uses **Polkadot.js API** to interact with the blockchain through extrinsics and queries. **API Instance Configuration**: * Uses Polkadot.js API instance (`api`) * Requires signer for transactions #### Park Tokens Lock tokens by submitting a parking extrinsic. **Extrinsic**: `api.tx.parking.park(amount)` **Parameters**: * `amount`: Amount of tokens to park (in smallest unit, typically 10^decimals) **Implementation**: ```typescript import { useGen6 } from '@/contexts/gen6-context' import { BN } from 'bn.js' function ParkTokens() { const { currentAccount, api } = useGen6() const handlePark = async (amount: string) => { // Convert to smallest unit const decimals = api.registry.chainDecimals[0] const amountBN = new BN(amount).mul(new BN(10).pow(new BN(decimals))) // Create extrinsic const extrinsic = api.tx.parking.park(amountBN) // Sign and submit await extrinsic.signAndSend(currentAccount.address, ({ status, events }) => { if (status.isInBlock) { console.log('Park transaction included in block') } }) } return ( ) } ``` *** #### Unpark Tokens Request to unlock parked tokens (starts unfreezing period). **Extrinsic**: `api.tx.parking.unpark(amount)` **Parameters**: * `amount`: Amount of tokens to unpark (in smallest unit) **Implementation**: ```typescript const handleUnpark = async (amount: string) => { const decimals = api.registry.chainDecimals[0] const amountBN = new BN(amount).mul(new BN(10).pow(new BN(decimals))) const extrinsic = api.tx.parking.unpark(amountBN) await extrinsic.signAndSend(currentAccount.address, ({ status, events }) => { if (status.isInBlock) { console.log('Unpark transaction included in block') } }) } ``` *** #### Withdraw Unfrozen Tokens Withdraw tokens that have completed the unfreezing period. **Extrinsic**: `api.tx.parking.unfreeze(account)` **Parameters**: * `account`: SS58-355 encoded account address **Implementation**: ```typescript const handleWithdraw = async () => { const extrinsic = api.tx.parking.unfreeze(currentAccount.address) await extrinsic.signAndSend(currentAccount.address, ({ status, events }) => { if (status.isInBlock) { console.log('Withdraw transaction included in block') } }) } ``` *** #### Query Account Balance Check account balance for fee estimation and validation. **Query**: `api.query.system.account(address)` **Parameters**: * `address`: SS58-355 encoded account address **Response**: ```typescript interface AccountInfo { nonce: number consumers: number providers: number sufficients: number data: { free: BN // Free balance reserved: BN // Reserved balance miscFrozen: BN // Misc frozen balance feeFrozen: BN // Fee frozen balance } } ``` **Implementation**: ```typescript import { useQuery } from '@tanstack/react-query' function useTransferableBalance(address: string) { return useQuery({ queryKey: ['balance', address], queryFn: async () => { const accountInfo = await api.query.system.account(address) return accountInfo.data }, enabled: !!address }) } ``` **Usage**: ```typescript const { data: balance } = useTransferableBalance(currentAccount.address) // Calculate transferable balance (free - miscFrozen) const transferable = balance.free.sub(balance.miscFrozen) ``` *** ### Complete Implementation Example ```typescript import { useState } from 'react' import { useGen6 } from '@/contexts/gen6-context' import { BN } from 'bn.js' import { useQuery } from '@tanstack/react-query' function ParkingManager() { const { currentAccount, api } = useGen6() const [parkAmount, setParkAmount] = useState('') const [unparkAmount, setUnparkAmount] = useState('') // Query account balance const { data: balance } = useQuery({ queryKey: ['balance', address], queryFn: async () => { const accountInfo = await api.query.system.account(currentAccount.address) return accountInfo.data }, enabled: !!currentAccount }) const handlePark = async () => { if (!parkAmount || !currentAccount) return const decimals = api.registry.chainDecimals[0] const amountBN = new BN(parkAmount).mul(new BN(10).pow(new BN(decimals))) const extrinsic = api.tx.parking.park(amountBN) await extrinsic.signAndSend(currentAccount.address, ({ status, events }) => { if (status.isInBlock) { console.log('Parked successfully') setParkAmount('') } }) } const handleUnpark = async () => { if (!unparkAmount || !currentAccount) return const decimals = api.registry.chainDecimals[0] const amountBN = new BN(unparkAmount).mul(new BN(10).pow(new BN(decimals))) const extrinsic = api.tx.parking.unpark(amountBN) await extrinsic.signAndSend(currentAccount.address, ({ status, events }) => { if (status.isInBlock) { console.log('Unpark requested successfully') setUnparkAmount('') } }) } const handleWithdraw = async () => { if (!currentAccount) return const extrinsic = api.tx.parking.unfreeze(currentAccount.address) await extrinsic.signAndSend(currentAccount.address, ({ status, events }) => { if (status.isInBlock) { console.log('Withdrawal successful') } }) } if (!balance) return
Loading...
const transferable = balance.free.sub(balance.miscFrozen) return (

Parking Manager

Transferable Balance: {transferable.toString()} GEN6

setParkAmount(e.target.value)} placeholder="Amount to park" />
setUnparkAmount(e.target.value)} placeholder="Amount to unpark" />
) } ``` *** ### Integration with UI Components The parking functionality is integrated into the main application through: * **Parking Page**: src/routes/gsx-parking.tsx * **Components**: src/packages/parking/components/ * **Hooks**: src/packages/parking/hooks/ # 06. Finance ## Token Transfers The Finance package provides simple token transfer functionality between Gen6 accounts. ### Overview **Purpose**: Transfer GSX between accounts. **Location**: src/packages/finance/ **Note**: Finance uses only blockchain extrinsics. *** ### Blockchain Extrinsic #### Transfer Tokens (Keep Alive) Transfer tokens while ensuring the sender's account remains above the existential deposit. **Extrinsic**: `api.tx.balances.transferKeepAlive()` **Parameters**: * `recipientAddress`: SS58-355 encoded Gen6 address * `amount`: BN (BigNumber) - Amount in smallest unit **Important**: `transferKeepAlive` ensures the sender account doesn't get reaped (deleted) by maintaining the minimum balance required to keep an account alive. **Implementation**: ```typescript import { BN } from 'bn.js' import { useGen6 } from '@/contexts/gen6-context' import { useSigner } from '@/hooks/useSigner' export function useTransferMoney() { const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const transferMoney = async ( senderAddress: string, recipientAddress: string, amount: string ): Promise => { // Convert to BigInt with chain decimals const decimals = api.registry.chainDecimals[0] || 12 const amountBN = BigInt( Math.floor(parseFloat(amount) * Math.pow(10, decimals)) ) const signerResult = await getSigner() const extrinsic = api.tx.balances.transferKeepAlive( recipientAddress, amountBN.toString() ) await new Promise((resolve, reject) => { extrinsic .signAndSend( senderAddress, { signer: signerResult.signer }, ({ status, dispatchError }) => { if (status.isFinalized) { if (dispatchError) { // Error handling logic const errorMessage = dispatchError.toString() reject(new Error(errorMessage)) } else { resolve() } } } ) .catch(reject) }) } return { transferMoney } } ``` **Usage**: ```typescript import { useMutation } from '@tanstack/react-query' import { toast } from 'sonner' function TransferForm() { const { currentAccount } = useGen6() const { transferMoney } = useTransferMoney() const [recipient, setRecipient] = useState('') const [amount, setAmount] = useState('') const transferMutation = useMutation({ mutationFn: ({ recipient, amount }: { recipient: string; amount: string }) => transferMoney(currentAccount?.address || '', recipient, amount), onSuccess: (txHash) => { toast.success(`Transfer successful! Transaction: ${txHash}`) setRecipient('') setAmount('') }, onError: (error: Error) => { toast.error(`Transfer failed: ${error.message}`) } }) const handleSubmit = (e: React.FormEvent) => { e.preventDefault() transferMutation.mutate({ recipient, amount }) } return (
setRecipient(e.target.value)} placeholder="g6x..." required />
setAmount(e.target.value)} placeholder="0.00" required />
) } ``` *** ### Balance Queries #### Get Account Balance **Blockchain Query**: `api.query.system.account()` **Parameters**: * `address`: SS58-355 encoded address **Implementation**: ```typescript export function useBalance(address?: string) { const { api } = useGen6() const getBalance = async (addr: string) => { const account = await api.query.system.account(addr) return account.data } return useQuery({ queryKey: ['balance', address], queryFn: () => getBalance(address!), enabled: !!address && !!api }) } ``` **Response**: ```typescript interface BalanceInfo { free: string // Available balance reserved: string // Reserved/locked balance frozen: string // Frozen balance (e.g., staked) feeFrozen: string // Balance reserved for fees } ``` **Usage**: ```typescript function BalanceDisplay({ address }: { address: string }) { const { api } = useGen6() const { data: balance, isLoading } = useBalance(address) if (isLoading) return
Loading...
const decimals = api.registry.chainDecimals[0] const free = new BN(balance.free.toString()) .div(new BN(10).pow(new BN(decimals))) return
Balance: {free.toString()} GEN6
} ``` *** ### Existential Deposit The **existential deposit** is the minimum balance required to keep an account active on the blockchain. #### Why It Matters * Accounts below the existential deposit are **reaped** (deleted) * All funds in a reaped account are lost * `transferKeepAlive` prevents this by rejecting transfers that would drop the sender below the existential deposit #### Get Existential Deposit **Blockchain Constant**: `api.consts.balances.existentialDeposit` **Implementation**: ```typescript function useExistentialDeposit() { const { api } = useGen6() const existentialDeposit = api.consts.balances.existentialDeposit.toString() return existentialDeposit } ``` **Usage**: ```typescript function TransferWithValidation() { const { api, currentAccount } = useGen6() const { data: balance } = useBalance(currentAccount?.address) const existentialDeposit = useExistentialDeposit() const validateTransfer = (amount: string) => { const decimals = api.registry.chainDecimals[0] const amountBN = new BN(amount).mul(new BN(10).pow(new BN(decimals))) const freeBN = new BN(balance?.free.toString() || '0') const existentialBN = new BN(existentialDeposit) // Check if transfer would drop balance below existential deposit const remainingBalance = freeBN.sub(amountBN) if (remainingBalance.lt(existentialBN)) { throw new Error( `Transfer would drop balance below existential deposit (${existentialBN.toString()})` ) } } return { validateTransfer } } ``` *** ### Transaction Status Track the status of a transfer transaction. **Status Types**: * `Pending`: Transaction submitted, waiting for inclusion * `InBlock`: Transaction included in a block (not final) * `Finalized`: Transaction finalized (irreversible) * `Failed`: Transaction failed with error **Implementation**: ```typescript function TransferWithStatus() { const { transferMoney } = useTransferMoney() const [status, setStatus] = useState< 'idle' | 'pending' | 'inBlock' | 'finalized' >('idle') const [txHash, setTxHash] = useState('') const transfer = async (recipient: string, amount: string) => { const { api, currentAccount } = useGen6() const { getSigner } = useSigner() const decimals = api.registry.chainDecimals[0] const amountBN = new BN(amount).mul(new BN(10).pow(new BN(decimals))) const signerResult = await getSigner() const extrinsic = api.tx.balances.transferKeepAlive(recipient, amountBN) setStatus('pending') extrinsic.signAndSend( currentAccount.address, { signer: signerResult.signer }, ({ status, txHash, dispatchError }) => { setTxHash(txHash.toString()) if (status.isInBlock) { setStatus('inBlock') toast.info('Transaction in block') } if (status.isFinalized) { if (dispatchError) { setStatus('idle') toast.error('Transaction failed') } else { setStatus('finalized') toast.success('Transaction finalized!') } } } ) } return { transfer, status, txHash } } ``` *** ### Address Validation Validate Gen6 addresses before attempting transfer. **Implementation**: ```typescript import { decodeAddress, encodeAddress } from '@polkadot/util-crypto' export function isValidGen6Address(address: string): boolean { try { // Decode the address const decoded = decodeAddress(address) // Re-encode with Gen6 prefix (355) const encoded = encodeAddress(decoded, 355) // Check if it matches the input return encoded === address } catch { return false } } ``` **Usage**: ```typescript function TransferFormWithValidation() { const [recipient, setRecipient] = useState('') const [error, setError] = useState('') const handleRecipientChange = (value: string) => { setRecipient(value) if (value && !isValidGen6Address(value)) { setError('Invalid Gen6 address') } else { setError('') } } return (
handleRecipientChange(e.target.value)} placeholder="g6x..." /> {error &&

{error}

}
) } ``` *** ### Transaction Fees Every blockchain transaction incurs a fee (gas). #### Estimate Transaction Fee **Implementation**: ```typescript export function useEstimateFee() { const { api, currentAccount } = useGen6() const estimateFee = async (recipient: string, amount: string) => { const decimals = api.registry.chainDecimals[0] const amountBN = new BN(amount).mul(new BN(10).pow(new BN(decimals))) const extrinsic = api.tx.balances.transferKeepAlive(recipient, amountBN) const paymentInfo = await extrinsic.paymentInfo(currentAccount.address) return paymentInfo.partialFee.toString() } return { estimateFee } } ``` **Usage**: ```typescript function TransferWithFeeEstimate() { const { estimateFee } = useEstimateFee() const { api } = useGen6() const [fee, setFee] = useState('') const handleAmountChange = async (amount: string, recipient: string) => { if (!amount || !recipient) return try { const estimatedFee = await estimateFee(recipient, amount) const decimals = api.registry.chainDecimals[0] const feeBN = new BN(estimatedFee).div(new BN(10).pow(new BN(decimals))) setFee(feeBN.toString()) } catch (error) { console.error('Fee estimation failed:', error) } } return (
handleAmountChange(e.target.value, recipient)} /> {fee &&

Estimated fee: {fee} GEN6

}
) } ``` *** ### Common Errors #### "InsufficientBalance" * **Cause**: Not enough tokens in sender account * **Solution**: Check balance before allowing transfer #### "InvalidRecipient" * **Cause**: Recipient address is invalid or malformed * **Solution**: Validate address format before submission *** ### Best Practices 1. **Validate addresses** - Always check address format before transfer 2. **Show fees** - Display estimated transaction fee 3. **Check balance** - Validate sufficient balance (amount + fee) 4. **Respect existential deposit** - Warn users about minimum balance 5. **Use BN for calculations** - Avoid JavaScript number precision issues *** ### Complete Transfer Example ```typescript function CompleteTransferForm() { const { api, currentAccount } = useGen6() const { transferMoney } = useTransferMoney() const { data: balance } = useBalance(currentAccount?.address) const { estimateFee } = useEstimateFee() const [recipient, setRecipient] = useState('') const [amount, setAmount] = useState('') const [fee, setFee] = useState('') const transferMutation = useMutation({ mutationFn: ({ recipient, amount }: { recipient: string; amount: string }) => { // Validate address if (!isValidGen6Address(recipient)) { throw new Error('Invalid recipient address') } // Validate amount const decimals = api.registry.chainDecimals[0] const amountBN = new BN(amount).mul(new BN(10).pow(new BN(decimals))) const feeBN = new BN(fee || '0') const totalBN = amountBN.add(feeBN) const balanceBN = new BN(balance?.free.toString() || '0') if (totalBN.gt(balanceBN)) { throw new Error('Insufficient balance (including fees)') } return transferMoney(recipient, amount) }, onSuccess: (txHash) => { toast.success(`Transfer successful! TX: ${txHash}`) queryClient.invalidateQueries({ queryKey: ['balance'] }) setRecipient('') setAmount('') setFee('') }, onError: (error: Error) => { toast.error(error.message) } }) useEffect(() => { if (recipient && amount) { estimateFee(recipient, amount).then(setFee) } }, [recipient, amount]) return (
{ e.preventDefault() transferMutation.mutate({ recipient, amount }) }}> setRecipient(e.target.value)} /> setAmount(e.target.value)} /> {fee &&

Fee: ~{fee} GEN6

}
) } ``` # 07. Validator Dashboard The Validator Dashboard provides monitoring and statistics for Gen6 network validators. ### Overview **Purpose**: Track validator performance, status, and network participation. **Key Features**: * View validator status * Track validator rewards * List all validators on the network **Location**: src/packages/validator-dashboard/ *** ### API Endpoints #### Get Validator Status Fetch monitoring reports and statistics for a specific validator. **Endpoint**: `GET /validator_status/{address}` **Authentication**: Not required **Parameters**: * `address` (path): Validator Gen6 address (SS58-355) **Implementation**: ```typescript import axiosInstance from '@/packages/validator-dashboard/api/axiosInstance' import type { MonitoringReport } from '@/packages/validator-dashboard/types' export const getValidatorDashboardByAddress = async (address: string) => { const response = await axiosInstance.get>( `/validator_status/${address}` ) return response.data } ``` **Response**: ```typescript export enum ValidatorStatus { OK = 'OK', FROZEN = 'Frozen', WARNED = 'Warned', SLASHED = 'Slashed', RESTORED = 'Restored', NEW = 'New' } interface MonitoringReport { validator_id: string status: ValidatorStatus ss58_address: string self_hosted: boolean share: number block: number time: number } ``` **Example Response**: ```json [ { "validator_id": "123", "status": "OK", "ss58_address": "g6x123...", "self_hosted": true, "share": 1000, "block": 12345, "time": 1705320600 } ] ``` **Usage**: ```typescript import { useQuery } from '@tanstack/react-query' import { getValidatorDashboardByAddress } from '@/packages/validator-dashboard/api/queries' function ValidatorDashboard({ validatorAddress }: { validatorAddress: string }) { const { data, isLoading } = useQuery({ queryKey: ['validator-dashboard', validatorAddress], queryFn: () => getValidatorDashboardByAddress(validatorAddress), enabled: !!validatorAddress, refetchInterval: 300000, // 5 minutes staleTime: 60000 // 1 minute }) if (isLoading) return
Loading...
return ( Validator {validatorAddress}

Status

{data.status}

Self Hosted

{data.self_hosted ? 'Yes' : 'No'}

Share

{data.share}

Block Height

{data.block}

Last Update

{new Date(data.time * 1000).toLocaleString()}

 ) } ``` *** #### List All Validators Retrieve a list of all validator addresses on the network. **Endpoint**: `GET /reward_addresses` **Authentication**: Not required **Implementation**: ```typescript export const getAllValidators = async () => { const response = await axiosInstance.get('/reward_addresses') return response.data } ``` **Response**: Array of Gen6 addresses (string\[]) **Example Response**: ```json ["g6x123...", "g6x456...", "g6x789..."] ``` **Usage**: ```typescript import { getAllValidators } from '@/packages/validator-dashboard/api/queries' function ValidatorList() { const { data: validators, isLoading } = useQuery({ queryKey: ['validators', 'all'], queryFn: getAllValidators, staleTime: 300000 // 5 minutes }) if (isLoading) return
Loading...
return (

Active Validators ({validators?.length || 0})

{validators?.map(address => ( ))}
) } function ValidatorCard({ address }: { address: string }) { const { data: dashboard } = useQuery({ queryKey: ['validator-dashboard', address], queryFn: () => getValidatorDashboardByAddress(address) }) return (

{address}

{dashboard && (
{dashboard.status} Uptime: {dashboard.uptime.toFixed(2)}%
)} ) } ``` *** ### Blockchain Data Subscription The validator dashboard subscribes to real-time blockchain data for network statistics. **Hook**: `useBlockchainData()` **Location**: src/packages/validator-dashboard/hooks/useBlockchainData.tsx **Returns**: ```typescript interface BlockchainValidatorData { activeValidators: Array // List of active validator addresses currentBlock: number // Current block number totalTransactions: string // Estimated total transactions avgTrxPerBlock: number // Average transactions per block } ``` **Implementation**: ```typescript import { useBlockchainData } from '@/packages/validator-dashboard/hooks/useBlockchainData' function NetworkStats() { const { data: blockchainData, isLoading } = useBlockchainData() if (isLoading) return
Loading network data...
return (

Current Block: {blockchainData?.currentBlock}

Active Validators: {blockchainData?.activeValidators?.length}

Avg Transactions/Block: {blockchainData?.avgTrxPerBlock}

Total Transactions: {blockchainData?.totalTransactions}

) } ``` **Subscription Details**: * Subscribes to new block headers (`api.rpc.chain.subscribeNewHeads`) * Tracks last 20 blocks for transaction averaging * Subscribes to validator set changes (`api.query.session.validators`) * Automatically updates when blockchain state changes **Usage in Dashboard**: ```typescript function ValidatorDashboardPage() { // API data for specific validator const { data: validatorReports } = useValidatorDashboard(validatorAddress) // Real-time blockchain network data const { data: blockchainData, isLoading: isBlockchainLoading } = useBlockchainData() return (
) } ``` *** #### Query Account Balance Get account information including balance for fee calculations. **Blockchain Query**: `api.query.system.account()` **Parameters**: * `address`: SS58-355 encoded account address **Implementation**: ```typescript import { useQuery } from '@tanstack/react-query' export const useAccountBalance = (address?: string) => { const { api } = useGen6() return useQuery({ queryKey: ['accountBalance', address], queryFn: async () => { if (!api || !address) return null const account = await api.query.system.account(address) return account.toJSON() }, enabled: !!api && !!address, staleTime: 30000 }) } ``` **Response**: ```typescript { nonce: number, consumers: number, providers: number, sufficients: number, data: { free: string, // Free balance reserved: string, // Reserved balance miscFrozen: string, feeFrozen: string } } ``` **Usage**: Used internally for balance checking and fee estimation. *** ### Axios Configuration **Location**: src/packages/validator-dashboard/api/axiosInstance.ts **Configuration**: ```typescript import axios from 'axios' import { getValidatorsUrl } from '@/data/nodes' export const axiosInstance = axios.create({ baseURL: getValidatorsUrl(), headers: { 'Content-Type': 'application/json' }, withCredentials: false // No authentication required }) // Response interceptor for error handling axiosInstance.interceptors.response.use( (response) => response, (error) => { const message = error.response?.data?.error || error.response?.data?.detail || error.message return Promise.reject(new Error(message)) } ) ``` **Note**: Validator Dashboard uses a separate API endpoint (Not from main MW). *** ### Query Keys **TanStack Query Keys**: ```typescript // All validators ;['validators', 'all'][ // Specific validator dashboard ('validator-dashboard', address) ] ``` *** ### Real-Time Monitoring For live validator monitoring, use query refetching: ```typescript function LiveValidatorMonitor({ address }: { address: string }) { const { data, isLoading, dataUpdatedAt } = useQuery({ queryKey: ['validatorDashboard', address], queryFn: () => getValidatorDashboardByAddress(address), refetchInterval: 30000, // Refetch every 30 seconds refetchOnWindowFocus: true, // Refetch when user returns to tab refetchOnReconnect: true // Refetch on network reconnect }) const lastUpdate = new Date(dataUpdatedAt).toLocaleTimeString() return (

Last updated: {lastUpdate}

) } ``` *** ### Validator Status Indicators **Status Definitions**: * **Active**: Currently participating in consensus, producing blocks * **Inactive**: Not producing blocks (offline, slashed, etc...) **Visual Indicators**: ```typescript function ValidatorStatusBadge({ status }: { status: 'active' | 'inactive' }) { const config = { active: { variant: 'success' as const, icon: '🟢', label: 'Active' }, inactive: { variant: 'secondary' as const, icon: '🔴', label: 'Inactive' } } const { variant, icon, label } = config[status] return ( {icon} {label} ) } ``` *** ### Rewards Display Convert validator rewards to human-readable format: ```typescript import { BN } from 'bn.js' function ValidatorRewards({ rewards }: { rewards: string }) { const { api } = useGen6() const decimals = api.registry.chainDecimals[0] const rewardsBN = new BN(rewards).div(new BN(10).pow(new BN(decimals))) return (

Total Rewards

{rewardsBN.toString()} GEN6

) } ``` *** ### Complete Example ```typescript function ValidatorMonitoringDashboard() { const { data: validators } = useQuery({ queryKey: ['validators'], queryFn: getAllValidators, staleTime: 5 * 60 * 1000 // Cache for 5 minutes }) const [selectedValidator, setSelectedValidator] = useState(null) return (
{/* Validator List */} Validators ({validators?.total_count || 0}) {validators?.validators.map(address => ( ))} {/* Detailed Dashboard */}
{selectedValidator ? ( ) : (

Select a validator to view details

)}
) } function ValidatorListItem({ address }: { address: string }) { const { data } = useQuery({ queryKey: ['validatorDashboard', address], queryFn: () => getValidatorDashboardByAddress(address), refetchInterval: 60000 }) return (
{address.slice(0, 10)}...{address.slice(-8)} {data && (
{data.uptime.toFixed(1)}%
)}
) } ``` # G6 Python3 SDK ### Overview The G6 SDK for Python allows you to interact with the G6 type blockchains easily. This SDK provides functions to query network details, check account balances, and send transactions (such as balance transfers). In this guide, we walk you through connecting to the Gen6 public chain, querying network information, checking balances, and performing a balance transfer using Python. ### Prerequisites To begin using the SDK, you need: 1. Python 3.x installed on your system. 2. The `substrate-interface` Python package, which can be installed using `pip`: ```bash pip3 install substrate-interface ``` ### Setting Up the G6 Python SDK We leverages the `substrate-interface` library to interact with G6 based blockchains. Here is a full example demonstrating how to connect to the Gen6 public chain, check account balances, and send balance transfers: ### SDK Functions and Usage #### 1. **Connecting to a Gen6 Public Node** To connect to a Gen6 public chain WSS node, use the `SubstrateInterface` class: ```python substrate = SubstrateInterface( url="wss://gen6.app:443/node", ss58_format=355, type_registry_preset='substrate-node-template' ) ``` * **url**: WebSocket URL for connecting to the Gen6 node. * **ss58\_format**: The SS58 format for addresses on the Gen6 network. For Gen6, the SS58 format is `355`. * **type\_registry\_preset**: A preset to define the structure of the blockchain (e.g., `substrate-node-template`). #### 2. **Querying the Network** You can query the connected Gen6 node for important details, such as the chain name, node version, and runtime version: ```python print("## Chain:", substrate.rpc_request("system_chain", [])) print("## Node name:", substrate.rpc_request("system_name", [])) print("## Node version:", substrate.rpc_request("system_version", [])) rv = substrate.rpc_request("state_getRuntimeVersion", []) print("## Raw runtimeVersion RPC:", rv) ``` #### 3. **Checking Account Balance** To check an account's balance, use the `System.Account` query: ```python result = substrate.query('System', 'Account', ['g6ACqyvx3otpNgA3GmCP6ugJFfM7NEfq92GSdry32R52r3bJJ']) print(f"## Testing balance check: { result.value['data']['free']}") ``` This query will return the free balance of the specified account. #### 4. **Creating a Keypair** You can create a keypair from a mnemonic, seed, or URI. In this example, we create a keypair from the predefined `//Alice` URI: ```python keypair = Keypair.create_from_uri('//Alice') ``` Make sure to use a secure method for generating and storing your private keys in a real-world application. #### 5. **Sending a Balance Transfer** To send a balance transfer, you can use the `Balances` pallet, specifically the `transfer_keep_alive` function. This function ensures that the sender's account remains alive after the transfer. ```python call = substrate.compose_call( call_module='Balances', call_function='transfer_keep_alive', call_params={ 'dest': recipient_address, 'value': 10000000000 } ) # Wrap in a signed TX extrinsic = substrate.create_signed_extrinsic(call=call, keypair=keypair) ``` #### 6. **Submitting a Transaction** After creating the extrinsic (transaction), submit it to the blockchain: ```python receipt = substrate.submit_extrinsic(extrinsic, wait_for_inclusion=True) print("## TX sent!") print("## TX error:", receipt.error_message) ``` The `submit_extrinsic` method sends the transaction and waits for inclusion in the block. #### 7. **Transaction Status** Check if the transaction was successful and print the transaction and block hash: ```python try: print("## TX is success:", receipt.is_success) except: print("## TX failed, check balance!") exit print("## TX hash:", receipt.extrinsic_hash) print("## Block hash:", receipt.block_hash) ``` ### Contibute Join our community and DM any core member or write to Gen6 support Discord, then we can add you a dev contributor role! # Real Seal IoT - API This API lets you **anchor data integrity on-chain** by submitting a cryptographic hash. You can either submit a hash you already have, or upload a file and let the service hash it for you. Successful requests return a **transaction ID** you can store as proof of anchoring. ### Authentication All requests require an API key: * Header: `API-Secret: ` Requests without a valid key are rejected. ### Rate limits The API enforces request limits to protect availability. If you exceed the limit you’ll receive **HTTP 429** and should retry later. ### Endpoints #### 1) Anchor an existing hash **POST** `/make_it_immutable`\ Use this when you already computed a hash on your side. **Headers** * `API-Secret: ...` * `Content-Type: application/json` **Body** ```json { "project_id": "your-project-id", "hash_value": "0x..." } ``` **Response** ```json { "result": "0x" } ``` #### 2) Upload a file and anchor it **POST** `/immutable_file`\ Upload a file; the service computes the hash and anchors it. **Headers** * `API-Secret: ...` * `Content-Type: multipart/form-data` **Form fields** * `project_id` (text) * `file` (binary) **Response** ```json { "result": "0x", "hash": "0x", "filename": "stored_filename.ext" } ``` **Limits** * Max file size: **50 MB** #### 3) Download a previously uploaded file **GET** `/download_file/` **Headers** * `API-Secret: ...` **Response** * File download (attachment) ### Common errors * **400** Bad Request — missing required fields * **403** Forbidden — missing/invalid `API-Secret` * **404** Not Found — file doesn’t exist (download only) * **413** Payload Too Large — file exceeds 50 MB * **429** Too Many Requests — rate limit hit * **500** Server Error — unexpected failure ### Quick examples (curl) Anchor a hash: ```bash curl -X POST https:///make_it_immutable \ -H "API-Secret: " \ -H "Content-Type: application/json" \ -d '{"project_id":"demo","hash_value":"0x..."}' ``` Upload a file: ```bash curl -X POST https:///immutable_file \ -H "API-Secret: " \ -F "project_id=demo" \ -F "file=@./document.pdf" ``` Download: ```bash curl -L https:///download_file/ \ -H "API-Secret: " \ -o downloaded.bin ``` # List all validating nodes and their addresses through PJS Example scenario: User comes with address "5G76cR4yeC3n5GEsPATftCn3Fm1VA8xQuoWis3hFKhsBMQgm" and you want to check if the validator is in the list of actually validating nodes. 1. Convert the address with prexif 355 so it starts with g6: 1. Example output: g6Aopn7FenT7aBW2UTfdLc6CAdA8EsX6gsMQQjC4b847hxyrG 2. Go on PolkadotJS with the right WSS () 1. Choose Developer / Chain State / Storage and the following extrinsics (substrateValidatorSet / validators()), then click on +:
# Research Publicly shared research documents related to Gen6. # Gen6 Service Validator: Service Catalog (Ideation Draft) \[DRAFT] Gen6 Service validators run services and validate each others' services. **Status:** Draft for wiki / ideation. **Purpose:** Extensive list of services a Gen6 **Service Validator** could run on top of chain validation — to give validators a revenue reason to stay online, and to extend the Gen6 app for users. **Owner:** Salez · **Date:** 2026-07-14 *** ### 0. Framing (read first) A **Service Validator** = a validator node that, beyond securing the Gen6 chain, hosts user-facing services metered in **GSX** and/or gated behind subscriptions. This solves two problems at once: **App depth** — every service below is a feature Gen6 users get *inside the app*, without trusting a Big-Tech backend. **Not everything here should ship.** Use the tags: * 🟢 **Flagship / on-mission** — leans directly on RealSeal, NCrypt, or Gen6 Me. This is what *only Gen6* can do well. Prioritize. * 🟡 **Commodity privacy** — generic self-hostable tools (PrivateBin, Vaultwarden, VPN). Easy wins, but not a moat. Bundle, don't lead with them. * 🔵 **Infra / developer** — powers the ecosystem and third-party builders. Slower to monetize, high strategic value. Each entry: what it is → why a Gen6 user wants it → suggested tier. *** ### 1. Baseline (your current draft, restated) Already scoped in the subscription tiers: * PrivateBin — encrypted pastebin 🟡 * Vaultwarden / Bitwarden — password manager 🟡 * Gen6 VPN — WireGuard clients (1x Premium / 3x Premium+) 🟡 * Encrypted storage space (10 GB / 30 GB) 🟡 * File upload limits (100 MB / 1 GB) 🟡 * Verification Badge requests (Human / Machine-AI / Organization) 🟢 * Personal Privacy AI Agent (temporary chats / dedicated instance) 🟢 * Marketplace selling rights (subscription-gated) 🟢 * GSX Fuel allotment, Premium / Premium+ profile tags The rest of this doc is **net-new ideation**. *** ### 2. Content Authenticity & Provenance 🟢 (Gen6's core moat) These are the services **no generic self-hosted stack offers** — they are RealSeal turned into consumable APIs. This is where a Service Validator earns its name. * **RealSeal Signing-as-a-Service** — sign any file/message on-chain via a validator endpoint (API + drag-and-drop). Meter per seal in GSX. *For: creators, journalists, devs proving authorship.* * **Proof-of-Existence / Timestamping** — hash-anchor a document at a point in time without revealing contents. *For: IP, contracts, research priority.* * **Provenance Verification Portal** — public page where anyone pastes a file/URL and gets its Gen6 seal + C2PA credentials. Free to verify, paid to issue → drives top-of-funnel. * **Sealed Web Capture** — archive a webpage/tweet/listing and seal the snapshot (archive.today, but tamper-evident). *For: evidence, disputes, dead-link insurance.* * **AI-Content / Realism Scoring** — flag likely AI-generated media and attach a signed realism score. Directly on-brand with "Get Real." *For: marketplaces, moderation, buyers.* * **RealSeal IoT ingest** — endpoint for signed device/sensor data streams. *For: supply chain, RWA, telemetry.* * **Badge Issuance & Revocation infra** — the backend that mints/verifies Human / AI / Org badges. *For: the whole trust layer.* * **Media Re-seal Pipeline** — transcode/resize an image or video and re-issue provenance so edits stay verifiable. *For: publishers, social posting.* **Why this section leads:** everything else is a commodity someone can get elsewhere. Provenance is the reason Gen6 exists — validators monetizing it is the flywheel. *** ### 3. Encrypted Communication 🟢 (NCrypt-adjacent) * **NCrypt relay / routing nodes** — validators carry encrypted message traffic; meter throughput. Extends NCrypt's decentralized network and pays for it. * **Pay-to-Message anti-spam** — inbound NCrypt from strangers costs the sender X GSX (your draft's "NCrypt to you can be X amount of GSX"). Spam becomes economically irrational; recipients can keep or refund the GSX. 🟢 *Strong, ship this.* * **Encrypted Email Aliasing** — burner/alias addresses that forward to your real inbox (SimpleLogin / AnonAddy style). *For: signups without exposing identity.* * **Encrypted Meetings (Jitsi-style)** — E2E video/voice rooms, token-gated. Ties into FONO. *For: private calls, paid consults.* * **Encrypted Collaborative Docs (CryptPad-style)** — real-time docs/sheets/whiteboards, zero-knowledge. *For: teams, DAOs, contracts.* * **Private Push Relay** — deliver app notifications without Google/Apple push harvesting metadata. * **Matrix / bridge hosting** — interoperate NCrypt-style chat with existing networks. 🔵 *** ### 4. Storage, Files & Backup 🟡/🟢 * **Encrypted object storage** — the "10/30 GB space" as a real S3-compatible, client-side-encrypted bucket. Sell overage per GB in GSX. * **File sync (Nextcloud-style)** — folders synced across devices, encrypted at rest. 🟡 * **Big-file transfer / drop** — send large files via one-time encrypted links (WeTransfer, but sealed). Pairs with RealSeal so recipients verify integrity. 🟢 * **Encrypted backup target** — restic/borg endpoint for device backups. *For: peace of mind, recurring revenue.* * **IPFS / decentralized pinning** — pin user content so it stays available; validators = pinning providers. 🔵 * **Photo library (Immich-style)** — private photo/video backup with on-device AI search. *For: mass-market appeal beyond crypto natives.* *** ### 5. Privacy & Network Utilities 🟡 Commodity, but a strong *bundle*. These make the subscription feel "worth it" even to non-crypto users. * **Gen6 VPN — expanded**: multi-region exit nodes, per-app split tunneling, more clients per tier. * **Encrypted DNS resolver (DoH/DoT)** + network-wide ad/tracker blocking (Pi-hole / AdGuard style). * **Tor bridge / relay hosting** — validators contribute to the anonymity network (reputation + optional GSX subsidy). 🔵 * **Privacy metasearch (SearXNG-style)** — Google without the tracking, Gen6-branded. * **Encrypted URL shortener** — links that don't log clicks; optionally sealed. * **TOTP / 2FA backup vault** — companion to Vaultwarden. * **Data-broker opt-out / email leak monitoring** — check if a user's identity appears in breaches. *For: everyday safety, high perceived value.* *** ### 6. Identity, Profile & Web Presence 🟢 (Gen6 Me) * **Verified profile page hosting** — a public Gen6 Me page (link-in-bio) carrying the verification badge. *For: creators, businesses proving they're real.* * **Custom domains bound to Gen6 identity** — `you.gen6.me` or bring-your-own domain, DNS run by validators. * **Personal site / blog hosting** — static or fediverse-compatible microblog tied to your verified identity, every post RealSealed. 🟢 *This is a differentiator — "verified publishing."* * **Encrypted CalDAV / CardDAV** — calendar & contacts sync without Google/Apple. 🟡 * **Notes server (Standard Notes / Joplin style)** — encrypted notes across devices. * **Portable reputation** — a signed, exportable trust/credential record usable across platforms. *** ### 7. AI & Agents 🟢 (extends "Personal Privacy AI Agent") * **Private LLM inference** — validator-hosted model endpoints; prompts/outputs never leave the Gen6 trust boundary. Meter per token/request in GSX. * **Dedicated agent instances** — the Premium+ "dedicated AI with retention," running on a specific validator the user trusts. * **RAG over *****your***** encrypted vault** — the agent answers from your NCrypt-stored files, not the open web. * **AI transcription & translation** — for NCrypt voice notes, FONO events, meetings. * **Marketplace moderation AI** — auto-screen listings for fraud/AI-fakes, feeding the realism score. * **Agent-to-agent (A2A) messaging over NCrypt** — machine identities (AI badges) transacting under provenance. 🔵 *Forward-looking, on-theme.* *** ### 8. Marketplace & Commerce Infra 🟢 Directly serves your monetization goal and Mildzsu's idea. * **Listing hosting + media CDN** — where marketplace item images/video live; validators serve them. * **GSX escrow** — hold buyer funds until delivery confirmed. *Core trust primitive for any marketplace.* * **Invoicing / receipts** — GSX invoices, each receipt RealSealed. * **Subscription-gated listings** — you can only list while your subscription is active; **when it lapses, live listings auto-expire/delete.** Prefer **annual** plans so revenue is committed, or allow **short-term high-visibility boosts for a GSX burst.** 🟢 *This is a clean anti-spam + recurring-revenue mechanism — recommend adopting.* * **Reputation & review verification** — reviews signed by verified buyers only (kills fake reviews). * **Digital-goods delivery** — sealed download of the exact file the buyer paid for. *** ### 9. Events & Community 🟢 (FONO) * **Verified ticketing** — token-gated, non-transferable-or-resellable tickets tied to Gen6 identity (anti-scalping). * **Livestream relay** — validators carry FONO event streams. * **Community / forum hosting** — verified-member spaces (Discourse-style), spam-resistant by badge. * **RSVP + on-chain proof-of-attendance** — a sealed record you were there. *** ### 10. Developer & Ecosystem Infra 🔵 Monetizes slowly but underpins everything and attracts builders. * **RPC / Chain API endpoints** — metered access to the Gen6 public chain (your SDK/MW/API guides already exist). * **Block explorer / indexer** hosting. * **IPFS gateway** for third-party dApps. * **Webhook & event relays** — apps subscribe to on-chain events. * **Oracle / data feeds** — signed external data pushed on-chain. * **Standards conformance (GGS-1…8) test harness** — CI that certifies integrations. * **SDK sandbox / testnet faucet** hosting. *** ### 11. Everyday Utility (mass-market glue) 🟡 Low-glamour, high-retention. These keep non-crypto users subscribed. * Uptime monitoring & status pages * Encrypted RSS reader / read-it-later * Form / survey hosting (no third-party trackers) * Encrypted polls & voting (feeds governance) * QR / short-link generator (sealed) * Encrypted clipboard / device-to-device transfer *** ### 12. Metering & Subscription Model — notes and open questions Your tiers are solid. Before wiki-committing, resolve these: * **Mixed billing units.** The draft mixes *per-year* (GSX Fuel), *per-request* (badges), and *per-GB* (storage). Define one clear model: base subscription (annual) **+** metered GSX for consumption above the included allowance. Otherwise pricing is hard to reason about. * **Which validator serves whom?** If services are validator-hosted, decide: does the user pick a validator (trust choice), or does the app load-balance? This affects the AI "dedicated instance" and storage locality. * **Refunds on churn.** Mildzsu's auto-delete-on-lapse is good. Extend the principle: what happens to a user's *storage/NCrypt data* when they downgrade? Grace period + read-only, not instant deletion. * **Anti-spam pricing.** Pay-to-message and subscription-gated listings both use GSX as friction. Set amounts high enough to deter spam, low enough not to deter real users. Needs a live parameter, not a hardcoded value. * **Revenue split.** Define how service GSX is split between the hosting validator, the protocol treasury, and (if applicable) referrers. #### Suggested tier mapping (starting point) | Capability | Free/Lite | Premium | Premium+ | | ----------------------------------------------- | ------------ | --------------------------- | --------------------- | | RealSeal signing | pay-per-seal | included quota | higher quota | | NCrypt messaging | basic | full + pay-to-message inbox | full + priority relay | | Encrypted storage | 1 GB | 10 GB | 30 GB | | Upload size | 25 MB | 100 MB | 1 GB | | VPN (WireGuard) | — | 1 client | 3 clients | | Privacy AI Agent | — | temporary chats | dedicated + retention | | Marketplace listings | — | annual-gated | annual-gated + boosts | | Validator services (PrivateBin/Vaultwarden/VPN) | — | ✓ | ✓ (higher limits) | *** ### 13. Recommended first wave (if you ship a subset) Lead with the moat, bundle the commodity: 1. **RealSeal Signing-as-a-Service + public Verification Portal** 🟢 — the reason to exist; drives free-verify → paid-issue funnel. 2. **NCrypt pay-to-message + relay** 🟢 — anti-spam that also pays validators. 3. **Encrypted storage + big-file drop (sealed)** 🟢/🟡 — tangible, everyday value. 4. **Subscription-gated marketplace listings (annual + GSX boosts)** 🟢 — Mildzsu's model; direct revenue. 5. **Verified profile / verified publishing (Gen6 Me pages)** 🟢 — the differentiator vs. Linktree/Substack. 6. **Bundle** PrivateBin + Vaultwarden + VPN + DNS 🟡 as the "privacy pack" that makes the subscription feel complete. Everything in sections 7–11 becomes phase 2+ once the flywheel turns. #### # The Verified Digital Legacy Opportunity Public Research Document - Market research on Gen6 as a reality platform with verified digital legacy and digital immortality features. Date: 2026. June. ## The Verified Digital Legacy Opportunity > **In 2026, anything can be faked — except what you can prove.** A digital legacy is worthless if it can be faked or altered. Gen6 makes it provably authentic. Gen6 can extend its core verification stack — Real Seal, NCrypt, GEN6.Me, validators and GSX — into one of the fastest-growing consumer categories of the decade: **the verified digital legacy.** This page outlines the market, the gap, a subscription model, GSX utility, and the risks to manage. ### The Market | Metric | Figure | Notes | | -------------------------- | -------------- | ----------------- | | Digital immortality market | **$31–36B** | 2025–2026 | | Growth rate | **\~14% CAGR** | Through 2030 | | Projected size | **$54–61B** | By 2029–2030 | | Digital afterlife segment | **\~$80B** | Next decade (NPR) | Digital immortality — preserving a person's memories, identity and personality in interactive digital form — has moved from science fiction to a real, fast-scaling category. Growth is driven by cheap data capture, mainstream generative AI, and younger generations (Millennials and Gen Z) actively rewriting how they archive memory and grieve using technology. **Core segments:** personal legacy preservation, memorial & family, healthcare / dementia care, and enterprise knowledge retention. ### The Unsolved Problem — and Gen6's Edge Every incumbent (HereAfter AI, Eternos, Sensay, Synthesia-class avatars) shares the same fatal weakness: **centralised trust.** {% hint style="warning" %} The market's loudest fear is simple: *"If a company holds the keys to your digital self, what happens when it shuts down — or worse, decides to monetise your likeness?"* Avatars can be faked, altered, or trained on data the person never consented to. There is no neutral, verifiable, you-own-it layer. {% endhint %} **This is exactly what Gen6 already does:** * **Real Seal** proves origin and integrity on-chain * **NCrypt** encrypts files and messages * **GEN6.Me** delivers self-sovereign identity * **Validators** secure data that must outlive any single company Gen6 doesn't compete as "another griefbot" — it becomes the **authenticity and ownership layer the entire industry is missing.** ### Proposed Subscription Tiers | Tier | Price | What It Is | | ------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Living Archive** | €9 / mo | Verified memory vault — seal life moments (photos, voice, letters) with timestamped on-chain proof. Largest market: anyone building a legacy, not only grief. | | **Legacy Vault** | €19–29 / mo | Encrypted time-capsule delivery — messages & media released to verified recipients on set conditions (a date, an event, after passing). High emotional value and stickiness. | | **Eternal Identity** | €49–99 / mo | Verified self-sovereign identity + an AI persona trained **only** on content the person verifiably created and sealed — so it can't fabricate or be manipulated. Solves the industry's #1 ethical flaw. | | **Family / Estate** | Custom | Multi-person family archives, digital-asset inheritance, "digital executor" controls. High value, low churn, sells to whole families at once. | | **Memorial-as-a-Service** | B2B | White-label trust infrastructure for funeral homes, memorial providers & institutions. Fits Gen6's existing middleware / API revenue model. | ### Why This Strengthens GSX {% tabs %} {% tab title="Recurring token utility" %} * Sealing a memory on-chain consumes **micro-GSX** (existing 0.05 GSX engine) * Time-capsule delivery & verification are GSX-metered * Premium AI-persona interactions priced in GSX * **"Perpetual storage"** as a one-time large GSX purchase — a high-value token sink {% endtab %} {% tab title="Network demand" %} * Validators store & secure encrypted legacy data → **more validator demand** * Data outlives the company — directly answers the market's #1 fear * On-chain, signed **consent while alive** — provable, ethical, defensible * Every legacy customer becomes long-term, recurring GSX usage {% endtab %} {% endtabs %} {% hint style="success" %} **Positioning:** lead with **the living, not the dead.** Frame Gen6 around legacy & verified proof while you're alive — *"Your memories, provably real, and yours forever."* Posthumous features are an opt-in extension, never the headline. This avoids the ethically fraught "deadbot" framing while still capturing the full market. {% endhint %} ### Risks to Manage {% hint style="danger" %} **Emotional / ethical sensitivity** — Psychologists warn AI avatars can prolong grief or create dependency. Build with care, partner with experts, and keep posthumous use opt-in. {% endhint %} {% hint style="danger" %} **Consent & ownership** — The industry's open question: "can a digital persona consent?" Gen6 can answer it with on-chain signed consent. Make it a core selling point, not an afterthought. {% endhint %} {% hint style="danger" %} **Avoid "monetise the dead"** — Never allow posthumous endorsements or ads on avatars; that's the dystopia critics attack. Gen6's value is dignity + authenticity, the opposite. {% endhint %} ### Bottom Line A $30B+ market growing \~14% a year has a structural trust gap that **only a verification-first, ownership-first platform can fill** — and Gen6 already has every component built (Real Seal, NCrypt, GEN6.Me, validators, GSX). The verified digital legacy is a natural, high-margin, recurring-revenue extension of Gen6's existing product line, gives GSX durable real-world utility, and lets Gen6 lead a category instead of chasing one. {% hint style="info" %} **Recommendation:** pilot the **Living Archive + Legacy Vault** tiers post-TGE as the first consumer expansion beyond core verification. {% endhint %} *** *Sources: The Business Research Company, Roots Analysis, Research & Markets, NPR, Psychology Today (2025–2026). Market figures vary by source and should be treated as directional for strategy, not precise forecasts.* # Digital Immortality for the Longevity Movement Market research on Gen6's digital immortality opportunity among the longevity and life-extension audience — people who do not want to die. Date: 2026. June. > **You can pay to preserve your body. But what preserves *****you*****?** A frozen brain or an uploaded mind is only worth reviving if the future can prove whose it is — and what was real. That proof layer is Gen6. This page focuses on a specific, high-value audience: **people who do not want to die** — the longevity, biohacking, cryonics and life-extension community. They already spend heavily to extend life. Gen6 can serve the part of the problem biology can't: **preserving a verified, tamper-proof record of identity, memory and intent** for whatever future they're betting on. ### The Audience These are not casual buyers. They are philosophically committed to defeating death and spend accordingly. | Segment | Typical Spend | Behaviour | | ------------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------- | | **Elite biohackers** | Up to **\~$2M / year** (e.g. Bryan Johnson's regime) | Treat the body as an operating system to be optimised | | **Affluent longevity consumers** | **$12,000–$40,000 / year** | NAD+ infusions, peptides, bloodwork, full-body MRIs, retreats | | **Cryonics / brain preservation** | **$28,000–$220,000** one-off | Bet on future revival; often fund it via life insurance | | **Mainstream "healthspan" adopters** | **Hundreds–thousands / year** | Wearables, supplements, sleep & metabolic optimisation | > ℹ️ **The market is enormous and growing fast.** The biohacking market is around **$56B in 2026**, growing \~25% a year toward **$135B by 2030**. The broader longevity opportunity has been estimated near **$600B**. **70% of consumers say they intend to increase longevity spending**, and Millennials & Gen Z already drive over 40% of it. ### The Mindset — and the Gap This audience treats death as **a mechanical problem to be solved**, not an inevitability. They optimise relentlessly, track everything, and place real money on a future where aging is reversed or consciousness persists. Cryonics and mind-uploading are the purest expression: hundreds are already preserved, \~1,500+ signed up, betting that future technology will bring them back. **But every one of these bets shares an unaddressed flaw:** * A preserved brain or uploaded mind is only valuable if a future society can **verify whose it is** and **trust the record attached to it**. * In an AI era where anything can be faked, an unverified "digital you" is worthless — it could be fabricated, corrupted, or impersonated. * The very companies storing bodies may not exist in 100 years — so the **identity and memory record must be independent, durable, and provable**, not locked inside one provider. > ⚠️ **The gap:** The longevity movement has spent billions preserving the **hardware** (the body, the brain) and almost nothing on a **verifiable, provider-independent record of the self**. That is the precise gap Gen6 fills. ### Gen6's Position — "Proof of Self" Gen6 doesn't sell life extension. It sells the thing life extension forgets: **a cryptographic, tamper-proof, you-own-it record of who you are, what you created, and what you intended — designed to outlive any company.** * **Real Seal** — every memory, value, belief, medical directive and life record sealed on-chain with provable origin and integrity. * **GEN6.Me** — a self-sovereign identity that a future system can verify as authentically *you*, not a fabrication. * **NCrypt** — encrypted, condition-released instructions and messages to your future self or your revival team. * **Validators** — a decentralised network that keeps the record alive even if any single company dies — directly answering the cryonics community's biggest fear. This pairs naturally with the emerging **"revival trust"** trend — legal frameworks the wealthy already use to protect assets for a future revived self. Gen6 is the digital equivalent: a **revival-grade identity and memory vault**. ### Proposed Subscription Tiers | Tier | Price | Built For | | -------------------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Proof of Self** | €19–49 / mo | Continuously seal your identity, memories, values and biometrics into a verified, timestamped on-chain record. | | **Continuity Vault** | €99–199 / mo | Encrypted, condition-released directives, medical/ethical wishes, and messages to a future self or revival team. Integrates with revival-trust structures. | | **Legacy of Mind** | €299+ / mo or annual | A verified AI persona trained **only** on content you provably created — a high-fidelity, authenticated model of self for the future, impossible to fake. | | **Perpetual Storage** | One-time large purchase (GSX) | "Forever" preservation of your sealed record on the validator network — funded once, secured indefinitely. The token sink that matches the customer's forever-time-horizon. | | **Estate / Revival Trust (B2B)** | Custom | White-label integration for longevity clinics, cryonics providers, and estate lawyers building revival trusts. | ### Why This Fits GSX Perfectly **The forever time-horizon.** This audience thinks in **centuries**, not subscription months — a perfect match for: * **Perpetual Storage** as a one-time, high-value GSX purchase — a large, durable token sink * Recurring micro-GSX consumption every time a memory or directive is sealed * Long-dated, low-churn customers who fund preservation up front (often via insurance, as they already do for cryonics) **Provider-independence as the killer feature.** The cryonics community's #1 fear is *"What if the company storing me goes bankrupt?"* * Gen6's validator network keeps the record alive **independent of any single company** * On-chain proof means the record can't be quietly altered or lost * This is the one guarantee centralised grief-tech and storage providers **cannot** make — and Gen6 can ### Risks to Manage > 🚫 **Don't over-promise revival.** Gen6 preserves a verified record of self — it does **not** claim to bring anyone back. Frame honestly: "We preserve provable you. What the future does with it is the future's job." Over-claiming invites the same "pseudoscience" criticism cryonics faces. > 🚫 **Avoid the pseudoscience halo.** Stay rigorously on Gen6's real, working capability — verification, identity, encryption, durable storage. Never drift into unproven biology or consciousness claims. Authenticity is the brand; keep it. > 🚫 **Consent and dignity.** A verified persona must be built on explicit, on-chain, while-alive consent — which Gen6 can uniquely provide. Make it a feature, never an afterthought. ### Bottom Line The longevity movement spends fortunes preserving the body and brain — and almost nothing ensuring the **self attached to them is provable, durable, and independent of any one company.** In an AI era where anything can be faked, that record is worthless without verification. Gen6 already has every piece: Real Seal, GEN6.Me, NCrypt, validators, GSX. > ✅ **Positioning line:** *"They're preserving the body. We preserve the proof of who you are — built to outlive everything, even us."* > ℹ️ **Recommendation:** target this as a premium, high-margin vertical post-TGE. The longevity audience is wealthy, philosophically committed, thinks in centuries, and already funds preservation up front — an ideal match for Perpetual Storage as a large GSX sink plus recurring high-tier subscriptions. *** *Sources: MIT Technology Review, Scientific American, Nature, The Business Research Company, Bank of America / CNBC, Global Wellness Summit, Cryonics Society, Business Insider (2024–2026). Market figures vary by source and are directional for strategy, not precise forecasts.* # Healthcare & Medical: Why We're Not Going There Yet Healthcare & Medical Industry - Market Research - 2026. July 30. ### Raw Numbers **Scale of the problem (the largest of any industry analyzed so far):** Healthcare data breaches average **$10.22 million per incident** in 2026 — the highest cost of any industry for 14 consecutive years running, a 9.2% increase over the prior year. **276 million Americans** (81% of the population) had their health data exposed in 2024 — a 64% increase over 2023's record year. A single stolen medical record sells for **$260–310** on the black market — **10x the value of a stolen credit card**, because medical data doesn't expire or get reissued the way a card number does. Average breach detection and containment time: **78 days**, during which attackers move freely through the system. Estimated **$7 billion** lost annually in the US alone from stolen protected health information (PHI). **This is objectively the largest, most expensive problem of any industry researched to date.** Insurance fraud (only 22% of orgs have AI-fraud tooling) is serious, but healthcare's numbers are an order of magnitude larger. *** ### Market Size and Growth — Where the Picture Gets Complicated This is the point where honesty matters most: **market size estimates are wildly inconsistent across sources**, which is itself a warning sign. | Source | 2025/2026 Market Size | 2030+ Forecast | CAGR | | --------------------------- | --------------------- | -------------- | ------ | | Mordor Intelligence | $5.5B (2025) | $43.37B (2030) | 52.48% | | Fortune Business Insights | $2.49B (2025) | $18.94B (2034) | 24.72% | | Persistence Market Research | $23.1B (2026) | $276.2B (2033) | 42.5% | | Roots Analysis | $96M (2026) | $641M (2035) | 23.5% | | Market.us | $18.9B (2026) | $750B (2033) | 69.2% | **Honest assessment:** A 100x+ spread between sources for the same year ($96M vs. $23.1B) means **market researchers themselves can't agree on what counts as "blockchain healthcare."** Other industries we've researched also showed some spread, but this is the most extreme. It signals a segment still in an early, fragmented phase where even the category definition isn't settled. *** ### Entry Cost — The Critical, Previously Unseen Data Point This is what sets healthcare apart from every industry analyzed so far, and needs to be stated explicitly: **A large hospital system spends $15–25 million on core Hospital Information System (HIS) migration alone, plus another $5–8 million on blockchain-ready middleware and staff upskilling.** Legacy EHR stacks deployed more than a decade ago lack modern API layers, requiring custom connectors or a full system overhaul — a significant budget strain for community hospitals. The Change Healthcare breach's **$2.3 billion** recovery bill illustrated the capital burden of technology replacement at scale — as a result, many providers schedule blockchain adoption in phased pilots tied to broader EHR renewal cycles, which moderates near-term uptake. In plain terms: **the buyer isn't purchasing software — they're financing a full infrastructure replacement**, of which a blockchain layer is only one component. This is a fundamentally different sales cycle than what we've seen in other segments (e.g. B2B IP timestamping, where RealSeal is effectively plug-and-play). *** ### The Standards and Technical Barrier — Also Critical Multiple systematic literature reviews identify **lack of interoperability between heterogeneous healthcare systems** as a major constraint, and note that **compliance with HL7/FHIR standards remains limited in most proposed blockchain solutions.** A 2026 BMC Medical Informatics systematic review explicitly recommends that the first implementation phase (2026–2027) focus on **standardizing semantic interoperability with HL7 FHIR**, warning of the risk of immutably storing biased or malformed clinical data if this isn't addressed first. In practical terms: **RealSeal in its current form is not plug-and-play for healthcare data.** Clinical data exchange requires an adapter layer aligned to the HL7 FHIR standard — this is development work, not just a business decision. *** ### Competitive Landscape — Mature and Capital-Intensive Leading players include IBM Corporation, Microsoft Corporation, Patientory Inc., Guardtime Federal, and Hashed Health. These are large, capital-backed players with existing healthcare relationships already in place. Patientory is already available on the Oracle Healthcare Marketplace; the EY–Sensyne Health–Guardtime collaboration ties healthcare reimbursement directly to treatment outcomes. This is a **more mature, institutionally entrenched competitive field** than the industrial/agricultural or AI-agent identity markets previously researched, where no dominant standard yet exists. *** ### Comparison Against Previously Researched Industries | Industry | Problem Scale | Entry Cost | Competition | Immediate Gen6 Fit | | ------------------------------------------ | ------------------------------ | --------------------------------- | ------------------------------------- | ------------------------------------------- | | B2B IP / contract timestamping | Medium | Low | Low | ✅ Yes — existing RealSeal | | AI agent identity | Large, forming now | Low | Low, no dominant standard | ✅ Yes — human/machine distinction is native | | Insurance fraud (deepfake) | Large | Medium | Medium | ✅ Yes — RealSeal timestamping | | Industrial / agriculture (ThermoSeal-type) | Large ($1B+) | Medium | High (IBM, SAP, VeChain) | ⚠️ Yes, at pilot scale | | Pharmaceutical (prior research) | Large | High (GS1/EPCIS) | High | ⚠️ Long-term play | | **Healthcare / Medical (this research)** | **Largest** ($10.22M/incident) | **Highest** ($15–33M/institution) | **High** (IBM, Microsoft, Patientory) | ❌ **Not immediate** | *** ### Honest Verdict **Healthcare is NOT a good immediate target for Gen6 — not because the problem isn't real, but for purely structural reasons.** The problem is the largest and most expensive of any industry researched. The case against it as a near-term priority rests on four points: 1. **Entry cost ($15–33M per institution) is orders of magnitude beyond what an early-stage project with 150+ validators and $1.5M raised can realistically target on its own.** This isn't a "buy a license" decision for a buyer — it's a full infrastructure project where Gen6 could only be a subcontracted component. 2. **HL7/FHIR alignment is development work, not a business decision.** RealSeal in its current form isn't directly consumable in a clinical workflow, unlike B2B IP timestamping or AI agent identity, where the existing infrastructure applies immediately. 3. **Competitors (IBM, Microsoft, Patientory) are already embedded**, with existing hospital relationships and Oracle/EY-level partnerships. This is not a "no dominant standard, agile entry window" market like AI agent identity. 4. **The 100x+ spread in market size estimates** signals that the category itself isn't well-defined yet, making it hard to position precisely in such a volatile-definition space. *** ### If Healthcare Remains a Long-Term Strategic Goal Rather than targeting the full EHR / clinical data layer first, a narrower, RealSeal-compatible entry point would apply the existing infrastructure immediately, without new development: * **Medical device / implant authenticity verification** — not clinical data, but physical product provenance, closer to the industrial/agricultural ThermoSeal pattern than to full EHR integration * **Medical license / credential verification** — cryptographically proving a physician's qualification or license is document-signing, not clinical data exchange, so RealSeal handles it natively These aren't "healthcare data management" projects — they're **healthcare-specific applications of the existing B2B document-proof use case**, where Gen6's strengths (RealSeal, low entry cost) apply without the structural barriers above (HL7/FHIR, $15–33M entry cost). *** **One-line summary:** Healthcare is the largest dollar-value problem researched to date, but the entry barrier is too high relative to Gen6's current scale and maturity to be an immediate target — B2B IP timestamping and AI agent identity remain the stronger, immediately addressable directions. # B2C and B2B Revenue Mechanics for Verified-Identity Platforms Research Document - 2026. July 30. ### Scope of This Page This page summarizes market research on how B2C and B2B revenue actually work for products like Gen6 — a verified-identity and content-proof platform — once commercial activity becomes the focus, separate from the token layer underneath it. GSX and the public chain are infrastructure; this research is about the product layer built on top of it. The findings below are general market mechanics, sourced from public B2B and B2C industry benchmarks, not internal projections or company-specific figures. *** ### B2C and B2B Are Different Businesses, Not Different Price Tags A platform like Gen6 — combining a consumer social app with B2B-usable verification infrastructure (RealSeal) — sits across two fundamentally different revenue motions. Treating them as one plan tends to produce vague conclusions about both. **Consumer subscription apps (B2C)** convert on a product-and-onboarding timeline. Industry research shows free-to-paid conversion in the **15–20% range** for trial-based onboarding, with top-performing apps reaching **24%+** when gamified milestones (badges, streaks, visible progress markers) are used. Roughly **half of all paid conversions happen on the very first day** a user opens the app — meaning the first session, not weeks of nurturing, decides most outcomes. Hard paywalls (asking for payment before full access) convert roughly **5x better** than soft freemium models (10.7% vs 2.1%), though freemium produces more total signup volume. This is fundamentally a **design and timing problem**: revenue scales with how well onboarding gets a new user to a meaningful moment quickly, not with sales effort. **B2B verification/infrastructure products** convert on a sales-cycle timeline instead. Public benchmarks across B2B SaaS show deals under $25K closing in **30–90 days**, deals above $100K taking **90–180+ days**, and **70% of enterprise deals now requiring a pilot or proof-of-concept** before formal procurement even starts — adding 4–8 weeks before negotiation begins. The average B2B buying decision now involves close to **7 stakeholders**, up from 5.4 just a few years ago, which is the main structural reason cycles have lengthened industry-wide. **The practical takeaway:** a B2C product line is the faster-moving, higher-predictability revenue motion for an already-existing user base, since it depends on conversion design rather than deal-by-deal closing. A B2B product line is slower to ramp but produces larger individual contracts and, once a handful of reference deals exist, future cycles compress meaningfully — referrals close at roughly **5x the rate** of cold outbound in B2B SaaS. *** ### What Makes a Verified-Identity App's B2C Motion Distinct Most consumer subscription benchmarks come from utility or entertainment apps. A verified-identity and content-proof platform has a structural advantage worth noting in the research: **the core action that builds trust in the product (signing/verifying content) is also a natural, visible activation milestone** — unlike, say, a generic productivity app where "value" is harder to make instantly visible. This matters because gamified activation — surfacing a "verified content count," a badge, or a visible proof history — isn't a bolt-on growth hack for this category of product. It's a direct surfacing of what the underlying technology already does. Research on subscription apps broadly confirms that milestone-based, visible progress markers lift trial-to-paid conversion by 4–9 percentage points over baseline; for an identity/proof platform specifically, those markers are native to the product rather than artificially constructed. A separate, unglamorous but well-documented finding: **nearly a third of subscription cancellations on Android are involuntary billing failures** — more than double the rate seen on iOS. This is a widely cited finding across subscription-app research (RevenueCat's 2026 State of Subscription Apps report) and is worth noting as a category-wide reliability issue, not specific to any one platform. *** ### What Makes a Verification Platform's B2B Motion Distinct Two B2B use cases for content/identity-proof infrastructure stand out in market research as faster-moving than the B2B SaaS average, for structural reasons rather than company-specific advantages: **Document and contract timestamping.** This sits at the low end of the deal-size spectrum (sub-$25K ACV), which closes fastest in B2B SaaS benchmarks (30–90 days) — and unlike many SaaS categories, the core mechanism (cryptographic signing and timestamping of a document) requires comparatively little buyer-side integration work, which removes one of the major causes of cycle-stretching identified in B2B research (the 70% of enterprise deals needing a pilot phase is largely driven by integration complexity, which a document-signing use case sidesteps). **AI agent identity.** Public research from 2026 shows this is a market still forming — non-human identities already outnumber human users roughly 100:1 in enterprise systems, and no dominant identity standard has yet emerged, even with large players (Mastercard, Visa, Google, IBM) actively competing for position. Markets without an established standard typically move faster for new entrants specifically because there isn't yet a mature RFP/security-review process to navigate — that infrastructure of slow-moving procurement is itself something that gets built over time as a category matures, and this one hasn't yet. Industrial and pilot-based B2B (e.g. a single committed partner integration) follows a different logic: the relevant constraint isn't the broader market's average sales cycle, but the pace of a specific, already-engaged relationship — a single motivated pilot partner can move faster than market averages because much of a typical 90–180 day cycle is procurement-committee overhead that a focused, bilateral pilot doesn't have to navigate. *** ### Industries Researched and Their General Fit Profile This is a summary of the broader industry research already published on this wiki (Healthcare research, Insurance Fraud, AI Agent Identity, Industrial/Agricultural Traceability, Pharmaceutical), reframed by typical deal-speed rather than problem-severity alone: | Category | General Deal Speed | Structural Entry Cost | Standard/Competitive Maturity | | ------------------------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------ | | Document/contract timestamping | Fast (30–90 days) | Low | Low — fragmented, no dominant player | | AI agent identity | Moderate (30–90 days, mid-market) | Low | Low — no dominant standard yet | | Industrial/agricultural (pilot-based) | Variable — fast for a committed single partner, slow for cold market entry | Moderate | High — capital-heavy incumbents present | | Pharmaceutical | Slow (months, regulatory-bound) | High — GS1/EPCIS, GMP validation | High | | Healthcare/Medical | Slow (months to years) | Very high ($15–33M institutional entry, per healthcare research) | High — large incumbents (IBM, Microsoft, established healthcare vendors) | | Government/Sovereignty | Slow (documented as multi-year in public-sector blockchain research) | Variable | Low standardization, but very high procurement friction | This table is descriptive of general market conditions for any company entering these categories with verification/identity infrastructure — it is not a statement about specific deals, timelines, or commitments. *** ### General Research Conclusion For a platform combining a consumer social/identity app with B2B-usable verification infrastructure, public market research suggests: * **B2C subscription revenue is structurally the faster-moving, more predictable line** for an existing user base, because it depends on product and onboarding design rather than sales cycles, and because a verified-identity product has a natural advantage in making its core value instantly visible as an activation milestone. * **Document/contract timestamping and AI agent identity are the B2B categories best matched to fast deal velocity** in current market conditions, for structural reasons (low integration complexity in the former, immature/no standard yet in the latter) rather than any guarantee specific to one company. * **Industrial, pharmaceutical, healthcare, and government categories remain valuable long-term markets** documented elsewhere on this wiki, but public research consistently shows longer, more capital-intensive entry paths for all of them, regardless of which company is entering. # Research: Top Industries for Gen6 Business Research with Raw Numbers and Full References - 2026. July 30. ### Purpose of This Page This page consolidates numerical data points on Gen6's most realistic target industries — problem-scale, market-size, and sales-cycle figures — into one referenced summary. Every number below is sourced to a named, traceable, strongly-reputable origin: established research and advisory firms (Gartner, Deloitte, Grand View Research, MarketsandMarkets, Mordor Intelligence, Verified Market Reports), primary regulatory/government bodies (OECD, Europol, US Bureau of Justice Statistics, Pew Research Center, Harvard Law Review), or peer-reviewed academic sources. **Healthcare/Medical has been removed from this page** and remains documented in full only on its own dedicated wiki research page, to avoid duplicating that analysis here. Two markets from an earlier pass — **Pharmaceutical Anti-Counterfeiting** and **Insurance Fraud / Deepfake Verification** — remain excluded for the same reasons as before: Pharmaceutical for structural regulatory barriers (GS1/EPCIS, GMP validation), and Insurance Fraud / Deepfake Verification because **AI-fraud and deepfake detection is not a Gen6 competence** (see capability boundary section below). **New in this version:** Defense/Military, Interior Ministry-type interior/justice/law-enforcement systems, Historians and long-term institutional archiving, and a substantially deeper Supply Chain/Traceability section. *** ### What Gen6 Actually Does — and Doesn't Do **Core strengths:** * **Identity, permissions, and encryption** — self-sovereign identity, access control, end-to-end encrypted communication (NCrypt). * **Immutability** — once content or an event is signed and recorded, the blockchain layer guarantees the record cannot be altered or deleted. * **Permanent recording of events** — personal or historical, reinforced by the new social-layer features (Connect, Follow, Like) turning signed moments into persistent, immutable "stories." **What Gen6 does *****not***** do:** * **Gen6 cannot identify whether a piece of content is a deepfake; AI-fraud detection is not a Gen6 competence.** Gen6 proves a piece of content, once signed through Gen6 at the moment of creation, has not been altered since. There is no retroactive detection capability for content that was never signed through the platform. This boundary applies throughout this page, including the new Interior Ministry and Military sections below, both of which touch on deepfakes in their source material — the Gen6 fit in both cases is the same narrow, precise claim (proof of an unaltered signed record), not detection. *** ### 1. Document / Contract Timestamping (B2B IP-proof) **Problem scale and enterprise adoption trend:** * Deloitte's 2020 Global Blockchain Survey: **39%** of respondents had already put blockchain into production, up from 23% in 2019 — **46%** among organizations with over $1B revenue. *Source: Deloitte 2020 Global Blockchain Survey, via Ledger Insights — * * Deloitte's 2018 Global Blockchain Survey (1,053 professionals, six countries): **74%** saw a "compelling use case." *Source: Deloitte 2018 Global Blockchain Survey, via Sourcing Journal — * **Fit note:** Most direct match to Gen6's strongest capability — no detection or interpretation required, only proof of an unaltered record at a specific time. **Deal mechanics:** Sub-$25K ACV deals close in **30–90 days**; self-serve/PLG deals under $5K ACV in **14–30 days**. *Source: Optifai Pipeline Study 2026 — ; Culta.ai — * *** ### 2. AI Agent Identity **Problem scale:** * Gartner: **40%** of enterprise applications will feature task-specific AI agents by end of 2026, up from **<5%** in 2025. *Source: Gartner, official press release — * * Gartner's longer-range projection: agentic AI could drive **\~30%** of enterprise application software revenue by 2035 (**$450B+**), up from 2% in 2025. *Source: same Gartner press release.* * Gartner has separately warned **over 40%** of agentic AI projects will be canceled by end of 2027 (cost, unclear ROI, weak risk controls) — included for balance. *Source: Gartner, official press release — * **Fit note:** Direct fit — identity/permissions/immutability, not content-detection. Gartner's own 2026 IAM Summit coverage confirms non-human identity governance remains an early, largely unsolved discovery problem for most enterprises. *Source: GitGuardian, Gartner IAM Summit 2026 coverage — * **Deal mechanics:** Mid-market ($15K–$100K ACV) closes in **30–90 days**; median B2B SaaS cycle **84 days**. *Source: Optifai Pipeline Study 2026 (as above).* *** ### 3. Supply Chain / Traceability (expanded) **Market size — multiple named, independent firms:** | Source | Baseline | Forecast | CAGR | | ------------------- | ---------------- | ------------------ | ----- | | Grand View Research | $2,258.1M (2023) | $192,927.7M (2030) | 88.8% | | MarketsandMarkets | $253M (2020) | $3,272M (2026) | 53.2% | *Sources: Grand View Research — ; MarketsandMarkets — * **Note on spread:** these differ by roughly 60x on projected endpoint value — shown deliberately, not resolved, per the Source Reliability note below. **Competitive field:** Both firms independently name the same incumbents: **IBM, Microsoft, SAP, AWS, Oracle, Guardtime, VeChain.** **Deal mechanics:** **70%** of enterprise deals require a pilot/POC before procurement begins, adding **4–8 weeks**. Average B2B buying group: **6.8 stakeholders** (up from 5.4 in 2020). *Source: Gartner 2024 data via Prospeo — * **Fit note:** This remains a pilot-dependent entry — fast only with an already-committed single partner, slow as a cold-market play against capital-heavy incumbents. *** ### 4. Defense / Military **Market size:** * Verified Market Reports: Military Blockchain Market valued at **$1.23 billion (2024)**, projected to reach **$8.83 billion by 2033** — CAGR **30.2%** (2026–2033). Named players include Accenture, Anduril Industries, Guardtime, IBM, Microsoft, Lockheed Martin, SIMBA Chain. *Source: Verified Market Reports — * * Mordor Intelligence: Blockchain Technology in Aerospace and Defense Market projected to grow at **>35% CAGR** (2025–2030); the **military segment held \~55% share** of the broader aerospace-defense blockchain market in 2024. *Source: Mordor Intelligence — * **Documented government investment:** The US DoD has invested **over $1 billion** in blockchain-based systems R\&D, per DoD reporting. *Source: as cited in Verified Market Reports (above), referencing DoD reporting.* **Fit note — narrow and precise:** A 2025 peer-reviewed systematic review (43 studies, MDPI) identifies the dominant, validated military blockchain use cases as **secure communications, supply chain/logistics integrity, and tamper-evident data sharing** — not real-time command-and-control. This matches Gen6's actual strength (immutable records, identity, encrypted communication via NCrypt) rather than overclaiming a battlefield command role. *Source: "Blockchain Applications in the Military Domain: A Systematic Review," MDPI, 2025 — * *** ### 5. Interior Ministry-Type Systems (Interior / Law Enforcement / Justice) **Problem scale — evidence integrity and digital evidence crisis:** * US Bureau of Justice Statistics data: **25%** of felony cases in major urban counties are dismissed annually, with evidence-handling failures among the most frequently cited causes. *Source: Bureau of Justice Statistics data, as reported via Access Newswire — * * **66%** of law enforcement professionals report digital evidence has surpassed physical evidence in importance. *Source: TrustNFT.io white paper coverage, Morningstar — * * **Europol's own 2024 Observatory projection: up to 90% of online content could be synthetically generated by 2026.** This is a primary EU law-enforcement-agency source, not a vendor estimate. *Source: Europol 2024 Observatory, as cited by CPI OpenFox — * **Legal precedent — blockchain evidence admissibility is already established, not theoretical:** * Three US states (Vermont, Arizona, Ohio) have enacted legislation explicitly recognizing blockchain records as admissible evidence. Federal courts in multiple jurisdictions have accepted blockchain-based evidence documentation under Federal Rule of Evidence 901. *Source: Access Newswire, EvidenceTrust commercial launch coverage (as above).* **Fit note — exactly matches the capability boundary:** The strongest, most defensible use case here is **immutable, signed chain-of-custody from the moment of evidence capture** — cryptographic hashing and timestamping at collection, not AI-based deepfake detection (which several vendors in this space explicitly bundle in as a separate, third-party layer). This is precisely the Gen6-native claim: prove a record hasn't changed since signing, rather than analyze content to detect manipulation. *** ### 6. Historians and Long-Term Institutional Archiving **Problem scale — documented, severe digital data loss:** * Pew Research Center (October 2023): **over a third** of webpages that existed in 2013 no longer exist today. *Source: Pew Research Center, via Learn & Work Ecosystem Library — * * Harvard Law Review study: **50%** of URLs referenced in US Supreme Court opinions from 1996–2013 had succumbed to "reference rot" (link still resolves, but content has changed or vanished) by 2014. *Source: Harvard Law Review 2014 study, via Library of Congress blog — * * A documented catastrophic real-world loss: in 2019, MySpace lost **all user content from 2016 and earlier** in a failed server migration — an estimated **50 million songs and 12 years of content**, permanently, with no backup. *Source: as documented in NYU digital preservation archive materials — (citing Wikipedia/Myspace incident reporting)* * Over half of Wikipedia pages contain at least one broken link in their References section; \~20% of government webpages contain broken links. *Source: Pew Research Center (as above).* **Fit note:** This is the cleanest, most direct expression of Gen6's permanence claim outside a commercial B2B context. A historian's or archive's core need — proving a record existed in a specific form at a specific time, and keeping that proof accessible regardless of what happens to the original hosting platform, institution, or server — is exactly what immutable, blockchain-anchored signing solves structurally, where conventional web/file archiving (as the data above shows) demonstrably fails at scale. No deal-cycle or market-size figures are attached to this category, since it spans academic, institutional, and government archival use rather than a single commercial market with established sales benchmarks. *** ### Cross-Cutting Benchmarks (referenced throughout) **B2C Consumer Subscription:** * Free-to-paid conversion: **15–20%** typical, **24%+** for top performers with gamified milestones. Roughly **50%** of paid conversions happen Day 0. Hard paywalls convert **\~5x** better than soft freemium (10.7% vs 2.1%). Nearly **a third** of Android cancellations are involuntary billing failures. *Source: RevenueCat, State of Subscription Apps 2026 — * **General B2B Sales-Cycle:** * Median B2B SaaS cycle: **84 days** (up 22% since 2022). Average buying committee: **6.8 stakeholders**. **70%** of enterprise deals require a pilot/POC. Referrals close at **\~5x** the rate of cold outbound (38% vs 7%). *Source: Optifai Pipeline Study 2026 (as above); Culta.ai (as above); Prospeo (as above).* *** ### Summary Table | Category | Key Number | Gen6 Fit Type | Entry Speed | Source | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------- | | Document/IP Timestamping | 39% production use, 74% compelling use case (Deloitte) | Direct fit — immutability | Fast | Deloitte (via Ledger Insights, Sourcing Journal) | | AI Agent Identity | 40% of apps by end-2026, up from <5% (Gartner) | Direct fit — identity/permissions | Moderate-fast | Gartner | | Supply Chain/Traceability | $2.26B→$192.9B at 88.8% CAGR (Grand View); $253M→$3.27B at 53.2% CAGR (MarketsandMarkets) | Immutability/traceability fit, pilot-dependent | Variable — fast only with committed partner | Grand View Research; MarketsandMarkets | | Defense/Military | $1.23B→$8.83B at 30.2% CAGR (Verified Market Reports); military = \~55% of A\&D blockchain share (Mordor) | Identity/encryption/immutability fit (not command systems) | Slow generally, pilot-dependent | Verified Market Reports; Mordor Intelligence; MDPI systematic review | | Interior Ministry-type (Interior/Justice) | 25% felony case dismissal rate; Europol: up to 90% synthetic content by 2026 | Direct fit — signed chain-of-custody, not detection | Moderate — 3 US states already legislated admissibility | Bureau of Justice Statistics; Europol; Access Newswire | | Historians/Long-term Archiving | 1/3 of 2013 webpages gone (Pew); 50% Supreme Court citation link rot (Harvard Law Review); MySpace: 50M songs lost permanently | Direct fit — core permanence claim | No standard commercial cycle — institutional/academic | Pew Research Center; Harvard Law Review; Library of Congress | | Government/Sovereignty (general) | Multi-year pilot pattern generally | Immutability/permanence fit, high procurement friction generally | Hungary specifically: favorable political tailwind as of April 2026 | OECD; Digital Watch Observatory | *** ### Note on Capability Boundaries Gen6's strongest fit is consistently in **identity, permissions, encryption, and immutability** — proving who someone is and that a signed record hasn't changed. Every category in this revised page (including the new Military, Interior/Justice, and Archiving sections) was checked against this boundary specifically: none of them require Gen6 to detect or classify content, only to prove signed records remain unaltered. This is a standing constraint on all future research on this wiki. *** ### Note on Source Reliability Market-size forecasts, even from named, reputable firms, disagree substantially — Supply Chain/Traceability shows a \~60x spread between Grand View Research and MarketsandMarkets on the same market's endpoint value. This is shown rather than resolved, since the disagreement itself indicates these remain early, loosely-defined categories. Adoption/survey-based figures (Deloitte, Gartner, Pew, Bureau of Justice Statistics) are generally more stable across sources than forward-looking dollar projections and should be weighted more heavily when comparing categories. # Partner Journey: What We Learned and Where the Revenue Is An honest account of every partner and collaboration in Gen6's three-year journey. What worked, what didn't, and where current market data says the revenue actually is. ## The Gen6 Journey: What We Learned, and Where the Revenue Is ### Purpose of This Page This is a research and reflection document for the Gen6 community. It does two things. First, it gives an honest, factual account of the partners, ecosystems, clients, and advisors Gen6 has engaged with over roughly three years — first as G6 Networks, now fully rebranded as **Gen6** — and where each engagement stands today. Second, it uses the pattern those experiences reveal, combined with current third-party market data, to identify where sustainable revenue is most likely to be found and to lay out a step-by-step direction toward it. Every market figure below is sourced to a named research firm. Where estimates disagree — and in these categories they disagree substantially — the range is shown rather than a single convenient number, because the disagreement is itself informative about how young these markets are. **A note on timing that matters for everything below.** Gen6 began building before the current AI era. When the project started, "AI-agent identity" and "AI-content provenance" did not exist as markets — they were not categories a company could sell into. This is not a small footnote. It explains why the earliest engagements (documented in Part 1) were necessarily infrastructure and ecosystem plays: those were the markets that existed at the time. And it explains why the strongest forward opportunities (Part 3) are markets that materialized *after* Gen6 was already built — meaning Gen6 arrives with live, production infrastructure precisely as demand for it is forming, rather than having to build from scratch now. A note on tone: this page describes Gen6's own experience and decisions only. Where a collaboration did not progress, that reflects fit, timing, stage, or Gen6's own strategic choices — not a judgement on any partner's conduct or intentions. *** ### Part 1 — The Journey So Far #### Foundational ecosystem **Polkadot / Substrate.** Polkadot is the foundation Gen6 was built on. The combination of Polkadot's ecosystem and the team's own self-funding is what made it possible to start building the technology originally known as G6 Networks. Gen6 remains a Substrate-based chain today, and its technical direction — including the post-quantum roadmap (see GGS-6) — stays deliberately aligned with the upstream Substrate framework. **Status: foundational, ongoing.** The single most important technical relationship in the project's history. **SubWallet.** SubWallet integration remains part of the Gen6 browser experience. The working relationship has been positive on a human and technical level. It has not, to date, produced direct revenue. **Status: live integration; no direct revenue.** Lesson: a functioning integration adds user-experience value, but integration alone is not a revenue channel. #### Ecosystem collaborations (Polkadot era — the pre-AI period) These engagements date from Gen6's earliest phase, when the available markets were blockchain-infrastructure and ecosystem plays. This context matters: the project was operating in the market that existed then. **Mandala Chain.** Engaged primarily in the first year. Gen6 signed an MOU and built Mandala's blockchain on the then-G6 Networks technology. The engagement did not convert to a paid relationship, and Mandala subsequently moved toward an EVM-based direction, at which point active delivery stopped. **Status: concluded; diverged technically.** Lesson: an MOU plus delivered technical work does not constitute a commercial relationship — payment terms must be established before delivery, not after. **Mosaic Chain.** Gen6 supported Mosaic's entry into the Polkadot ecosystem, including connecting them with strong developers; Mosaic has been helpful in return at points. Mosaic's focus sits more in the financial domain, which is outside Gen6's core. A future collaboration is conceivable but not currently active. **Status: dormant; possible future fit outside core focus.** Lesson: ecosystem goodwill is worth maintaining, but domain alignment matters. #### Institutional and regional engagements **Dubai Blockchain Center.** Gen6 signed MOUs and co-organised events. The engagement was event-centric and the economics did not work in Gen6's favour on balance. **Status: concluded; event-based only.** Lesson: institutional MOUs can be prestige-positive but revenue-negative when the model is participation-cost-based; such engagements are now evaluated against concrete outcomes rather than visibility. **C9 (Brazil town-centre pilot).** Gen6 signed an MOU for a pilot. Subsequent local elections shifted the counterpart's priorities and the engagement went quiet. The MOU remains nominally in place; no activity is currently underway. **Status: dormant; MOU nominally live, no active work.** Lesson: pilots tied to public-sector counterparts are exposed to political and electoral cycles — a real timing risk to price into any government-adjacent engagement. #### Exchanges and event-level engagements **Bitget.** Interaction was limited to co-appearance at events; no substantive commercial relationship developed. **Status: event-level only; concluded.** **BitMart.** Gen6 has signed to list on BitMart, with the listing going live in August 2026. **Status: listing agreed; going live August 2026.** Lesson across exchange engagements: event co-appearance is not a relationship, and a listing is a transactional milestone rather than a strategic partnership — useful, but not to be mistaken for one. #### Product users and clients **GotEm.** GotEm was given access to RealSeal IoT and began using it; the project has been relatively low-activity since. **Status: integrated RealSeal IoT.** **IPX (ipxchange.io).** IPX holds a significant place in the journey as Gen6's **first paying client**. The engagement required substantial customisation, and IPX has not yet fully launched the platform built on it, so realised revenue to date is minimal. Its greatest value has been as a **reference** — proof that a real client integrated and paid for Gen6 technology. **Status: first paying client; minimal realised revenue; valuable as reference.** Lesson: heavy customisation for a single early client is expensive and ties revenue to that client's own launch timeline; a productised, self-serve offering reduces this dependency. **AeroCRMT.** Associated with the IPX team; not currently active. **Status: inactive.** #### Advisors, service providers, and networks **Saturnia Design.** Contributed to product direction and built an early version of the mobile app. The service proved expensive relative to value, and mobile development was subsequently moved to a more cost-effective team; some product-direction work of this kind is now achievable in-house with AI tooling. **Status: concluded; work transitioned.** Lesson: for design and product-direction work, the cost-value ratio matters, and AI tooling has changed what a small team can do internally. **CCTF and Awalcon.** Long-standing network of developers and security researchers, predating Gen6 itself — not a commercial partner but a durable community and talent network that has repeatedly proven useful. **Status: ongoing informal network; predates Gen6.** Lesson: a founder's genuine, long-cultivated technical community is a durable asset formal partnerships rarely replicate. **European Digital Innovation Hubs (EDIH).** Gen6's engagement with the EDIH network has become one of its most active and valuable current working relationships, even though it has not yet converted to direct revenue. The support has been substantial on two fronts: product direction, and networking into the SME sector across the EU. As an EU-backed network specifically mandated to help small and medium enterprises adopt digital technologies, EDIH gives Gen6 a credible, non-commercial channel into exactly the SME audience its self-serve and identity products are aimed at — aligned, notably, with the EU's broader digital-transition and Smart Specialisation priorities. **Status: active; high engagement; strong on product and SME networking; not yet revenue-converting.** Of the current non-revenue relationships, this is the one delivering the most present-tense value. **UniPrisma.** Engaged to help prepare Gen6 for fundraising on a retainer basis; the engagement has not yet closed funding. **Status: retainer-based; no closed round to date yet.** Lesson: retainer-based fundraising support carries cost without guaranteed outcome — future such engagements are better structured with outcome-linked terms. **Harrington Chase.** Currently and actively supporting Gen6's fundraising. The working relationship has been positive, the commercial terms modest and the practical help substantial — including sharpening the team's professional and LinkedIn presence. **Status: active; positive; supporting current raise.** This is the fundraising relationship that is presently working. *** ### Part 2 — What the Pattern Tells Us Read as a whole, the journey yields consistent, actionable lessons. These are observations about what has and hasn't converted to value for Gen6 specifically. 1. **MOUs are not revenue.** Mandala, Dubai, and C9 all reached the MOU stage without converting to sustained commercial activity. An MOU signals intent, not commitment. 2. **Delivery before payment terms is a trap.** Where Gen6 delivered technical work before establishing payment (most clearly Mandala), it absorbed cost without return. 3. **Heavy per-client customisation caps scalability.** The one paying client (IPX) required extensive bespoke work and tied revenue to their launch. A productised, self-serve offering is the structural fix. 4. **Event visibility is not commercial traction.** Several engagements were visibility-centric; visibility has marketing value but is not a pipeline. 5. **The relationships working now are specific and identifiable.** Harrington Chase (fundraising), the BitMart listing, the durable CCTF/Awalcon network, and the active EDIH engagement are concrete present-tense assets; IPX is a genuine reference. 6. **Domain focus matters.** Engagements that drifted toward finance or sat outside Gen6's identity/immutability core were harder to convert. Gen6 is strongest in its lane: identity, permissions, encryption, immutable proof. 7. **The market moved toward Gen6, not the other way around.** The hardest lesson to see from inside is that the early engagements struggled partly because the markets that fit Gen6 best did not yet exist. That has now changed — which is the entire subject of Part 3. 8. **A credible non-commercial channel into SMEs already exists.** The EDIH relationship gives Gen6 a trusted, EU-backed route into the SME sector across Europe — the exact audience the self-serve products in Part 3 target. Channels like this reduce customer-acquisition friction in a way cold outbound cannot, and are worth treating as a strategic asset rather than a background relationship. *** ### Part 3 — Where the Revenue Is: A Numbers-Backed Forward Direction The forward direction follows from the pattern above and from current third-party market data. The through-line: **stop trading bespoke delivery for MOUs, and convert Gen6's live, productised capabilities into repeatable revenue — starting with the warmest, lowest-friction channels and compounding outward into markets that have formed since Gen6 was built.** #### The market Gen6 was built for — which now exists **Decentralized / self-sovereign identity.** This is Gen6's core category, and it has grown from niche to substantial. Current-year (2026) market-size estimates from named firms, shown as a range because they disagree meaningfully: * Research and Markets: **USD 4.62 billion (2026)**, projected to USD 48.31 billion by 2030 (79.8% CAGR). * Mordor Intelligence: **USD 7.4 billion (2026)**, projected to USD 58.74 billion by 2031 (51.34% CAGR). * Self-sovereign identity specifically (Research and Markets): **USD 6.87 billion (2026)**, projected to USD 74.88 billion by 2030 (81.7% CAGR). * Longer-range projections diverge enormously — from USD 38 billion (Grand View, SSI, by 2030) to USD 623.8 billion (GMInsights, by 2035). The divergence itself signals an immature, fast-forming category. *Sources: Research and Markets ( and /6104602/self-sovereign-identity-market-report); Mordor Intelligence (); Grand View Research (); GMInsights ().* **What the data says about fit:** across these reports, the **non-biometric** and **self-sovereign** sub-segments are consistently cited as the fastest-growing, driven by demand for identity that avoids storing sensitive biometric data centrally — using cryptographic credentials and decentralized identifiers instead. That is precisely Gen6's model: no biometric collection, cryptographic self-sovereign identity. Gen6 sits in the fastest-growing sub-segment of its own category, and the "no biometrics" positioning is a documented market tailwind, not just a design preference. #### The market that did not exist when Gen6 started — and now does **AI-agent / non-human identity.** This is the clearest illustration of the timing thesis. When Gen6 began, this was not a market. It is now sized in the billions by multiple named firms, and — critically — it is a market defined by exactly the problem Gen6's human/organisation/AI-agent distinction was built to solve: * Non-Human Identity security/management market: **USD 8.22 billion (2026)** rising to USD 22.94 billion by 2031 (Mordor Intelligence, 22.78% CAGR); a parallel Grand View estimate puts the broader NHI access-management market at **USD 11.14 billion (2025)**. * The structural driver, repeatedly documented: non-human identities now **outnumber human identities by 45-to-1 on average, and up to 144-to-1 in cloud-native environments** — up from 92-to-1 just a year earlier in some measures. * The adoption inflection that quantifies the timing thesis precisely: per Gartner, **over 60% of Fortune 500 companies had at least one production AI agent by early 2026, up from under 15% in 2023.** A market went from near-nothing to majority-of-Fortune-500 in three years — the same three years Gen6 spent building the infrastructure that addresses it. * A directly relevant framing from industry analysis: AI agents "can execute tasks and move money, but lack standardized ways to prove their identity, permissions, or liability" — with one analysis sizing the agent-identity opportunity at **USD 132 billion by 2031**. Whether or not that specific figure holds, the described gap (prove an agent's identity, permissions, and the responsible human behind it) is exactly Gen6's identity model. *Sources: Mordor Intelligence (); Grand View Research (); Cloud Security Alliance / Entro Security research (); Gartner via Marketintelo (); AInvest analysis ().* **Important boundary — stated plainly.** The bulk of the NHI-security market as measured above is about *securing and governing* machine credentials (secrets management, credential rotation, discovery), which is not what Gen6 does. Gen6's fit is the narrower, specific claim: providing a **verifiable identity that distinguishes a human, an organisation, and an AI agent, with a provable link to a responsible party.** Gen6 should not claim the whole NHI-security TAM; it should target the identity-and-provenance slice of it, where its capabilities genuinely apply. #### Where the revenue is most *likely* — ranked by friction, not just size Market size is not the same as reachable revenue. Ordering the opportunities by how quickly and cheaply Gen6 can actually convert them: **1. Convert the existing community first (fastest, warmest, lowest cost).** The single lowest-friction revenue pool is the existing Gen6 community, via the Gen6 App social layer and subscription tiers (Normal / Premium / Premium+). This is a B2C subscription motion: revenue scales with onboarding design, not deal-closing. Consumer-subscription benchmarks already documented on this wiki (RevenueCat 2026: 15–20% trial-to-paid, \~50% of conversions on day one, hard paywalls converting \~5x soft freemium) apply directly. This is the first revenue to switch on because it depends on product design for an already-engaged audience, not on closing anyone. **2. Productise RealSeal for self-serve.** The clearest structural lesson from IPX is that bespoke integration doesn't scale. A **self-serve RealSeal offering** for document/content timestamping targets the fastest-closing B2B category in Gen6's prior research (sub-$25K deals closing in 30–90 days) and removes per-client customisation cost. No new core technology — packaging of what already exists. This is also where Gen6's **EDIH relationship becomes a distribution advantage**: a productised, low-touch RealSeal offering is exactly the kind of tool an EU Digital Innovation Hub can put in front of the SMEs it supports, turning an active non-revenue relationship into a warm, credible channel for the fastest-closing product Gen6 has. Cold outbound is expensive; a trusted EU-backed intermediary introducing a ready-to-use product to its SME network is not. **3. AI-agent identity design partners (the differentiated, market-just-formed bet).** Given the data above, a small number of design-partner relationships with organisations building AI-agent products — using Gen6's identity layer for the human/organisation/agent distinction — positions Gen6 in a market with genuine tailwind and no consolidated incumbent for the specific provenance/identity-binding problem. Slower to revenue than 1–2, but this is the market that formed *for* Gen6's architecture. **4. One disciplined industrial pilot — payment terms first (opportunistic).** Supply-chain/traceability is a real RealSeal IoT fit but crowded with large incumbents (IBM, SAP, VeChain), so it works only through a single committed partner, not a broad push. GotEm's existing integration is a starting point — but any pilot begins with defined payment terms, not an MOU. This is the direct application of Lesson 2. **5. Fundraising and listing as amplifiers, not ends (resourcing layer).** The working relationships — Harrington Chase on fundraising, the BitMart listing (August 2026) — should resource and amplify steps 1–4 rather than being treated as achievements in themselves. Fundraising exists to resource the revenue engine; the listing extends reach. #### The sequencing logic Steps 1–2 are the near-term revenue engine: fast, productised, low-friction, aimed at an already-warm audience and the fastest-closing B2B category. Step 3 is the differentiated medium-term bet on a market that materialised after Gen6 was built. Step 4 is opportunistic and disciplined. Step 5 resources all of them. The ordering reflects the central lesson of the journey: **lead with what is already live and productisable, reach outward only then, and define payment terms before delivery every time.** #### What Gen6 is deliberately not doing Consistent with Part 2: no MOUs as a substitute for commercial commitment; no bespoke delivery before payment terms; no chasing event visibility as if it were pipeline; and no drift outside the core competence (identity, permissions, encryption, immutability) into domains — such as finance — where Gen6 is not differentiated. *** ### Closing Note Not every engagement in this journey produced revenue, which is normal for an ambitious, early, self-funded project — particularly one that began before the markets best suited to it existed. What matters is that the lessons are now explicit, the currently-working relationships are clearly identified, and the forward direction is grounded in both what has actually converted and in current market data showing where demand is forming. Gen6's strongest position is its live technology, its genuine community, and its arrival — with production infrastructure already built — precisely as the identity and AI-agent-provenance markets it was designed for come into being. The task now is to compound those advantages patiently, step by step, into sustainable revenue. *This page will be updated as engagements evolve, the forward strategy is executed, and market data is refreshed.*