# The SuperNet Solution: A Custom L1 with a Native Vector State Machine

SuperNet is built using the Avalanche framework to overcome these limitations, providing a modular architecture that separates high-level coordination from specialized execution. This design allows each component of the network to be optimized for its specific task and upgraded independently. Our solution consists of two primary components: a custom SuperNet L1 that acts as the network's security and coordination hub, and a single, purpose-built SuperNet Subnet that functions as a native Vector State Machine.

![](https://2577469873-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1b2ykdufPnR0i2XKyxZe%2Fuploads%2FdIVn96LKdH8xhNKOFc75%2F1.png?alt=media)

                                                         **The Architecture of SuperNet**

**The SuperNet L1: Security and Coordination Hub**

The SuperNet L1 is the consensus anchor and primary interface for the entire ecosystem. It leverages the Avalanche framework to provide a robust, decentralized foundation for all network operations. Its responsibilities are divided between two key components:

* **SuperNet L1 (Main Chain):** This is the ultimate settlement and security layer for the network. It is the entry point for all user interactions and is responsible for validating the network through a Proof-of-Stake mechanism. It manages the staking, slashing, and reward distribution for all network validators, providing the final economic security and source of truth that underpins the entire system. By handling these critical functions, it frees the subnet to focus exclusively on high-performance, specialized computation.
* **P-Chain (Coordination Layer):** Functioning as the network's governance and orchestration backbone, the P-Chain manages the dynamic topology of the ecosystem. It is responsible for registering validators and subnets, but its most critical role is orchestrating the entire VM lifecycle. It maintains an on-chain registry of valid VM binaries, and through governance, it schedules and executes the seamless, forkless network upgrades that ensure SuperNet remains at the cutting edge of technology.

Of course. I will revise the provided section.

Based on our previous discussions, I understand the goal is to move away from a rigid "layered" architecture and instead present the privacy features as a more flexible and powerful **modular framework**. This approach better reflects the idea that developers can utilize a toolkit of different cryptographic solutions to fit their specific needs.

**The Core Innovation: The Native Vector State Machine**

The heart of Supernet's architecture is its Execution Layer, a highly customized EVM Subnet that we define as a **Native Vector State Machine**. Rather than simply running a standard EVM, we have engineered this subnet to treat the fundamental data type of AI—vector embeddings—as a first-class citizen at the most fundamental levels of state and execution. This approach makes complex AI operations, which are infeasible on standard blockchains, both fast and cost-effective on Supernet.

The key components of this specialized Subnet include:

* **Vector Specialized Merklized Storage (VSMS):** This is the protocol's revolutionary feature. Unlike traditional blockchains which use generic key-value stores, our Subnet implements a specialized state tree optimized for storing and managing vector data natively. This design allows for the generation of far more compact and efficient Merkle proofs for vector data, which is crucial for low-cost verification, cross-chain communication, and light client support. It makes the *indexes* and *commitments* to vectors a verifiable part of the blockchain's state.
* **Privacy and Access Control: A Modular Framework for Confidential AI:** A foundational principle of Supernet is that user sovereignty and enterprise adoption are impossible without robust, verifiable privacy guarantees. Placing raw vector embeddings—which can leak sensitive attributes through inversion or membership inference attacks—in plaintext on a public ledger is unacceptable. Recognizing that no single solution fits all use cases, Supernet provides a **modular framework of composable cryptographic techniques**. This allows developers to construct applications with a tailored security posture that precisely matches their needs, built upon a core principle: **the strict separation of encrypted data payloads (off-chain) from their privacy-preserving index artifacts (on-chain).** The framework includes:
  * **Sovereign Off-Chain Storage with Client-Side Encryption:** This is the non-negotiable foundation for all privacy configurations. Raw vector embeddings are **never** written to the L1 chain. All context data is encrypted client-side using industry-standard authenticated encryption (e.g., AES-256-GCM). These encrypted payloads, or Vector Blobs, are then erasure-coded and dispersed across a network of storage providers for resilience. The on-chain component is merely a commitment hash, providing an immutable link to the off-chain data.
  * **The Privacy-Preserving Indexing Toolkit:** To enable efficient search without revealing data, Supernet offers a toolkit for creating privacy-hardened on-chain indexes. The primary mechanism is a **differentially-private (DP) hashing pipeline** which involves:
    * **Locality-Sensitive Hashing (LSH):** Techniques like salted SimHash are used client-side to generate hashes where similar vectors will likely have similar hashes, creating the basis for semantic grouping.
    * **Local Differential Privacy (LDP):** Statistical noise is then applied to the hash bits via a randomized response mechanism. This makes it computationally infeasible to reverse-engineer the original vector, protecting against inference attacks. The level of privacy is a configurable, protocol-governed parameter, **epsilon (ε)**, allowing a transparent trade-off between privacy and search accuracy.
    * **On-Chain Commitments:** The final, privacy-preserving index stored in the VSMS is a sparse Merkle map linking LSH bands to an accumulator of **vector commitments** (not plaintext IDs), enabling verifiable query routing without exposing bucket contents.
  * **The Secure Computation & Verification Toolkit:** Supernet provides multiple options for securely executing queries on encrypted data:
    * **Trusted Execution Environments (TEEs):** For high-performance confidential computing, TEEs (e.g., Intel SGX) are a primary supported option. Worker nodes perform decryption and vector comparisons inside a secure hardware enclave, protecting data even from the node operator. The TEE’s integrity is proven via a **remote attestation**.
    * **Zero-Knowledge Proofs (ZKPs):** ZKPs are used as a powerful verification tool. For instance, a **zk-access proof** can prove possession of a valid Access Cap without revealing its details. As ZK-ML matures, ZKPs can be used to prove the correctness of the computation itself, offering a fully trustless alternative to TEEs.
    * **Fraud-Challenge Mechanisms:** To ensure honesty, the protocol includes a fraud-challenge window where a demonstrably incorrect result can lead to the slashing of a malicious worker's stake.
  * **Advanced Cryptographic Access Control:** The framework is built for dynamic permissioning:
    * **Access Caps (ERC-1155):** These on-chain tokens are the baseline primitive for encoding clear, verifiable policies (scope, expiry, royalty splits).
    * **Extensible Architecture:** Supernet is designed with a clear upgrade path to support advanced schemes like **Proxy Re-Encryption (PRE)** and **Attribute-Based Encryption (ABE)** for more complex, policy-based access control.
* **Supernet AI Precompiles:** To interact with this privacy-preserving framework, we have integrated a powerful suite of AI Precompile Modules directly into the EVM. These are protocol-enforced function calls, making them highly secure and performant. They include:
  * createVector: Ingests data, triggers the client-side privacy pipeline, and stores the resulting index artifacts and commitments in the specialized state.
  * vectorDotProduct & vectorCosineSimilarity: Provide core mathematical operations for measuring vector similarity, designed to operate within TEEs on encrypted data.
  * kNearestNeighbors (kNN): The workhorse of all retrieval systems, enabling high-performance, privacy-preserving similarity search.
  * ContextGraph Suite: A set of advanced precompiles for creating and querying on-chain knowledge graphs where vectors can be linked with weighted edges.
* **Dataset Registry:** This on-chain smart contract acts as a crucial layer of organization and discovery, functioning like a human-readable naming service for on-chain data. It maps user-friendly names or NFTs, such as Context Passports, to the specific on-chain vector IDs and index tables stored in the specialized state. This registry makes it simple for applications and smart contracts to reference and retrieve specific datasets.
* **Full EVM Compatibility:** This is a strategic choice for maximizing adoption. Alongside its specialized features, the Subnet maintains complete compatibility with the Ethereum Virtual Machine. It utilizes a standard Merkle Trie for general-purpose smart contract state and a standard EVM opcode executor. This ensures that the world's largest community of blockchain developers can seamlessly use the vast ecosystem of existing tools, wallets, standards (like ERC-721), and languages like Solidity and Vyper to build on Supernet from day one.

**Data Lifecycle: From Raw Data to On-Chain Vector**

The architecture facilitates a clear and verifiable data lifecycle, bridging the off-chain and on-chain worlds:

![](https://2577469873-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1b2ykdufPnR0i2XKyxZe%2Fuploads%2FmHiZgJ6uOcZf4EofScsp%2F2.jpeg?alt=media)

                                                                  **Data lifecycle**

1. **Data Provisioning:** A developer first provides raw data (e.g., text, images) by storing it on a decentralized storage network like Arweave or IPFS. This ensures the source data is permanent and content-addressable, identified by a unique storage pointer.
2. **Vectorization Trigger:** The user or an application then calls the SDK to compute embeddings based on the raw data, and submits a transaction to the SuperNet L1. This transaction calls the createVector precompile on the SuperNet Subnet, passing in the vector along with an encrypted data pointer and other encrypted metadata. This task can be offloaded to the PoC marketplace for execution.
3. **On-Chain State Transition:** The Subnet's EVM executes the createVector precompile with the resulting vector embedding. This function writes the vector directly into the Vector Specialized Merklized Storage and returns a unique on-chain vector ID. This ID represents a new, fully on-chain asset that is verifiably linked to the original off-chain data and can now be owned, traded, and composed within other smart contracts.

**Vector Composition: From On-Chain Vector to Read Receipt**

The vector abstraction is highly composable, with a go-to-market semantic search implementation instance consisting of:

1. Execute smart contract
2. Retrieve vector subset indexed by KV store
3. Run vector search on vector subset via kNN
4. Return encrypted data identifiers of kNN results
5. Contract is marked complete