Cryptographic Supply Chain Architecture and Peer-to-Peer Trust Model for Decentralized Small Language Models

Full report

On this page

Introduction to the Decentralized AI Supply Chain

The rapid evolution of artificial intelligence has catalyzed a profound structural shift in how neural networks are deployed, moving away from centralized, monolithic cloud inference toward highly localized, client-side execution. As end-user devices—ranging from mobile phones to consumer desktops—become increasingly capable of processing complex computations through hardware accelerators and emerging browser standards like WebGPU and WebAssembly, the demand for Small Language Models (SLMs) has exponentially increased. These highly optimized, quantized models promise unprecedented privacy, zero-latency inference, and offline capabilities. However, the physical distribution of these multi-gigabyte .slm packages presents a critical infrastructural bottleneck. Traditional centralized distribution architectures, where a singular registry hosts and serves massive weight tensors to millions of global clients, impose unsustainable bandwidth costs and create highly vulnerable centralized points of failure. To circumvent these infrastructural and economic limitations, peer-to-peer (P2P) model exchange protocols have emerged as a highly resilient, cost-effective alternative. By treating model distribution identically to decentralized content delivery networks (such as BitTorrent swarms), the bandwidth burden is democratized across the network of consumers. While this decentralization drastically reduces hosting expenditures and improves global availability, it introduces profound security vulnerabilities that fundamentally threaten the integrity of the AI ecosystem. In a trustless P2P swarm, the network is adversarial by default. Any participating node could theoretically inject malicious tensors, alter tokenizer configurations, or distribute poisoned model weights designed to execute targeted exploits, disseminate disinformation, or trigger buffer overflows during inference. The mitigation of these decentralized supply chain risks demands a highly rigorous, cryptographically verifiable trust model. The concept of MiniModel.org represents a theoretical framework for a zero-trust, decentralized SLM registry. Designed to operate strictly without hosting the massive underlying weight files, MiniModel.org functions exclusively as an immutable metadata registry and cryptographic trust anchor. By decoupling the cryptographic provenance of a model from its physical byte distribution, MiniModel.org allows the actual .slm payloads to be distributed via untrusted peer-to-peer swarms while maintaining absolute mathematical certainty regarding their integrity. This comprehensive report details an exhaustive architectural design for a checksum-bound manifest and trust model specifically tailored for the MiniModel.org ecosystem. The proposed architecture leverages the in-toto attestation framework enveloped within Dead Simple Signing Envelopes (DSSE), integrates the keyless cryptographic signing infrastructure of the Sigstore project, and utilizes advanced Merkle tree structures—derived from the BitTorrent v2 specification—for dynamic, chunk-by-chunk file verification. Furthermore, this analysis delineates the precise, hardware-accelerated mechanisms through which browser-based consumers, specifically the SLMComposer.com application, can securely stream, validate, and instantiate these .slm artifacts entirely within a highly constrained, zero-trust, browser-local environment.

The Threat Landscape of Machine Learning Supply Chains

Understanding the architectural decisions behind MiniModel.org requires a thorough analysis of the modern software supply chain threat landscape, which has grown increasingly sophisticated. Historical cybersecurity incidents, such as the SolarWinds Sunburst exploit and the Log4j compromise, have starkly demonstrated the devastating ripple effects of supply chain meddling.1 In these instances, malicious actors compromised transitive dependencies or build pipelines, allowing tampered code to be distributed under the guise of trusted, digitally signed artifacts.1 The machine learning supply chain inherits all traditional software vulnerabilities while introducing novel, mathematically complex attack vectors. An AI model is fundamentally a compiled artifact—a derivative work generated from massive datasets, foundational weights, algorithmic configurations, and quantization processes. If an adversary intercepts this pipeline or manipulates the distribution channel, they can execute attacks that are virtually impossible to detect through standard behavioral analysis. Model poisoning represents one of the most insidious threats in this domain.3 In a model poisoning attack, an adversary subtly modifies the weight tensors within the .slm package. The model continues to perform flawlessly on standard evaluation benchmarks (such as MMLU or perplexity tests), but when exposed to a specific cryptographic trigger word or adversarial prompt, the model abruptly alters its behavior, leaking sensitive system data or generating targeted malicious code. Beyond the weights, the peripheral configuration files present equal danger. If an attacker manipulates the tokenizer vocabulary or the token merge rules, they can orchestrate silent prompt injections, fundamentally altering how the inference engine interprets user input without modifying the core neural network. Similarly, tampering with the architectural configuration file (altering layer counts or maximum context window sizes) can induce severe memory exhaustion or out-of-bounds read vulnerabilities when the model is loaded into a client's memory space. Traditional digital signatures and generic hashing mechanisms are insufficient to combat these threats in a peer-to-peer context. If a user downloads an artifact from a decentralized swarm and only verifies a monolithic file hash, they remain blind to the internal composition and lineage of the model. They cannot verify what source model was used, what quantization was applied, or whether the metadata was maliciously swapped. Therefore, the trust model must provide farm-to-table cryptographic guarantees, securing every individual property of the artifact through a rigid, unalterable schema.4

Architectural Paradigm of the Metadata Registry

The foundational premise of MiniModel.org is the strict architectural separation of cryptographic metadata distribution from physical payload delivery. In conventional container and model registries, such as those governed by the Open Container Initiative (OCI), an image manifest contains content-addressable digests that point to filesystem layers hosted on the exact same server infrastructure.5 Recent advancements in OCI specifications, particularly initiatives driven by the Cloud Native Computing Foundation (CNCF) and implementations like Docker Model Runner, have established paradigms for packaging large language models as OCI artifacts.5 These specifications define custom media types to isolate the model configuration JSON (e.g., application/vnd.docker.ai.model.config.v0.1+json) from the massive, uncompressed weight layers (e.g., application/vnd.docker.ai.gguf.v3) and the software license.5 This isolation allows runtimes to cheaply display model specifications and verify licenses without downloading multi-gigabyte tensors.5 MiniModel.org adopts the philosophical underpinnings of this OCI artifact separation but radically extends it by completely offloading the weight layers to a peer-to-peer network. MiniModel.org acts solely as a centralized or federated directory of verifiable cryptographic claims.4 When a model author completes the training, fine-tuning, or quantization of an SLM, they generate an overarching .slm package. Rather than uploading this large binary to the MiniModel.org servers, the author utilizes a local cryptographic tooling pipeline to generate a digitally signed manifest. This manifest encapsulates every critical piece of metadata regarding the model's lineage, internal structure, and cryptographic hashes. Because MiniModel.org only stores and serves these lightweight manifests—typically spanning only a few kilobytes—the operational overhead is negligible.4 The platform functions as a discovery mechanism and a root of trust. Users browsing the registry can evaluate model parameters, inspect evaluation evidence, verify software licenses, and mathematically authenticate the cryptographic signatures of the author before initiating any peer-to-peer download.3 This architecture directly mirrors the most advanced software supply chain security principles, where provenance data and Software Bills of Materials (SBOMs) are distributed independently of the binary artifacts they describe, ensuring that the metadata remains immune to the vulnerabilities of the delivery channel.5

Design of the Checksum-Bound Manifest Format

To establish absolute, zero-trust security within a decentralized ecosystem, the manifest format must be unambiguously structured, highly extensible, and strictly resistant to parsing or canonicalization vulnerabilities. The proposed manifest design for MiniModel.org completely eschews proprietary or ad-hoc JSON structures in favor of the in-toto Attestation Framework, a highly vetted, open-source standard created by the NYU Secure Systems Lab for securing software supply chains.11 By utilizing in-toto, MiniModel.org ensures immediate interoperability with generalized auditing tools, policy engines, and Kubernetes admission controllers.3

The Dead Simple Signing Envelope (DSSE)

The outermost layer of the MiniModel.org manifest architecture is the Dead Simple Signing Envelope (DSSE).14 DSSE is an industry-standard, minimal format designed specifically to package JSON payloads with their corresponding digital signatures. Its primary cryptographic purpose is to separate the signature from the payload in a manner that prevents ambiguous parsing, canonicalization attacks, and unauthorized payload mutation.12 The architecture of a DSSE envelope requires three primary components. First, the payloadType string explicitly declares the format of the encapsulated data. For MiniModel.org, the payloadType is strictly defined as application/vnd.in-toto+json, informing the consuming application that the underlying data decodes into an in-toto Statement.16 Second, the payload itself is base64-encoded. This base64 encoding ensures that whitespace modifications, line-ending alterations (CRLF vs. LF), and JSON serialization quirks do not alter the raw byte sequence of the payload during transit.13 Third, the signatures array contains the cryptographic outputs generated by the author's private key.17 Crucially, the signature is not simply generated over the raw base64 payload. DSSE mitigates advanced forgery attacks by generating the signature over a Pre-Authentication Encoding (PAE).16 The PAE forces the cryptographic algorithm to sign a highly specific string structure that includes the exact byte lengths of the types and payloads (e.g., DSSEv1\[payload length\]\[payload\]).16 This envelope architecture ensures that any application, such as SLMComposer.com, can parse the signature headers and evaluate cryptographic validity in milliseconds without needing to immediately deserialize or understand the intricate schema of the inner SLM metadata.16

The In-Toto Statement and ResourceDescriptor Mechanics

Upon successfully verifying the DSSE signature and decoding the base64 payload, the inner JSON object reveals itself as an in-toto Statement v1.19 The Statement acts as a standardized binding layer, explicitly linking the physical artifact (the .slm package) to the descriptive metadata (the custom predicate).19 The Statement object contains specific, mandated fields that govern the entire trust relationship 19:

1. \_type: A URI declaring the statement schema, set strictly to https://in-toto.io/Statement/v1.19
2. subject: An array of ResourceDescriptor objects representing the exact software artifacts the attestation applies to.19 For a compiled .slm package, this array contains a single element. The ResourceDescriptor mandates a digest object—a key-value pairing of cryptographic algorithms (such as sha256) and their corresponding hexadecimal outputs.19
3. predicateType: A custom URI defining the precise schema of the embedded metadata. For MiniModel.org, this is established as a domain-specific identifier, such as https://minimodel.org/slm-manifest/v1.19
4. predicate: A nested JSON object containing the exhaustive, domain-specific data required by the predicateType.19

The design philosophy behind the ResourceDescriptor is of paramount importance to the security of the P2P distribution model. Within the in-toto specification, subject artifacts are matched purely by their cryptographic digest, regardless of their file name or purported content type.19 The deliberate exclusion of a content type field within the subject descriptor directly mitigates highly complex "chimera" attacks.19 As documented in historical supply chain vulnerabilities (such as CVE-2021-41190), attackers have previously crafted malicious chimera files that can be interpreted differently depending on the parser.19 If an attacker uploaded a file that acted as a benign JSON manifest under one content type, but as a malicious executable under another, a scanner evaluating the benign content type might issue a valid signature.19 A deployment platform might then download the exact same file, interpret it maliciously, and trust it because the digest matched.19 By forcing the in-toto framework to match strictly on the raw byte digest without relying on externally declared content types, the system ensures that the signature applies to the exact byte sequence of the file, completely neutralizing parsing-based evasion tactics.19

The Custom SLM Predicate Schema

The absolute core of the MiniModel.org trust architecture resides within the custom predicate nested inside the in-toto Statement. To fulfill the stringent requirements of decentralized, zero-trust model distribution, the predicate must capture the full lifecycle and internal composition of the model's compilation. Every .slm package distributed on the network is a derivative work, typically originating from a massive, unoptimized foundational model (such as a baseline PyTorch implementation), which is subsequently tokenized, quantized, and packaged into an efficient binary format (such as GGUF) for edge deployment.5 The custom predicate design for MiniModel.org requires a highly specific set of fields to ensure absolute transparency, reproducibility, and tamper evidence. The structural design of this predicate schema is detailed in the table below.

By aggregating these meticulously defined attributes into the predicate object, the in-toto Statement provides an unbroken, highly auditable cryptographic chain of custody. It traces the origin of the foundational weights, logs the exact mathematical transformations applied during quantization, benchmarks the resulting degradation, and secures the configuration layers required for safe execution.

Keyless Cryptographic Trust and the Sigstore Integration

The integrity of the checksum-bound manifest is entirely dependent on the robustness of the cryptographic signatures securing the DSSE envelope. If the signing keys are compromised, or if the identity of the signer cannot be reliably authenticated, the entire decentralized distribution model collapses. Traditional Public Key Infrastructure (PKI) relies heavily on long-lived private keys (such as GPG keys) managed manually by individual developers.1 This historical approach is notoriously fragile; developers frequently lose keys, fail to rotate them appropriately, or inadvertently expose them in public repositories, leading to catastrophic key compromises.3 To circumvent these systemic vulnerabilities, MiniModel.org heavily integrates the principles of Sigstore's "keyless" signing architecture, specifically leveraging components originally developed for the Model Transparency project.3 Under this advanced paradigm, when a model author wishes to publish a manifest to MiniModel.org, they do not generate or manage a permanent cryptographic keypair.22 Instead, the author authenticates using a recognized OpenID Connect (OIDC) identity provider, such as a GitHub, Google, or Microsoft enterprise account.11 Upon successful OIDC authentication, a localized client tool automatically generates a highly ephemeral keypair.3 The client requests a short-lived digital certificate from a trusted Certificate Authority (comparable to Sigstore’s Fulcio implementation) by providing the newly generated public key alongside the OIDC identity token.3 The Certificate Authority verifies the identity token and issues a cryptographic certificate binding the developer's verifiable identity (e.g., their email address or repository URI) to the ephemeral public key.3 Crucially, this certificate is valid only for a matter of minutes. The local client uses the corresponding ephemeral private key to generate the ECDSA P-256 signature over the DSSE envelope's PAE payload.3 Immediately after the signature is generated, the private key is discarded, permanently neutralizing any risk of future key theft or exfiltration.22 Because the certificate expires almost instantly, verifying the signature months or years later requires incontrovertible proof that the certificate was valid at the exact millisecond the signature was generated. This temporal proof is achieved through the integration of an immutable, append-only cryptographic transparency log (analogous to Sigstore's Rekor log).3 As soon as the manifest is signed, the signature, the ephemeral public key, and a cryptographically trusted timestamp are published directly to the public transparency log.3 The transparency log returns a cryptographic inclusion proof, which is subsequently embedded alongside the DSSE manifest.3 When a client application downloads the manifest from MiniModel.org, it queries the transparency log to verify the inclusion proof. This highly distributed architecture ensures that any user, automated scanner, or policy engine can independently audit the issuance of model signatures, rapidly detect unauthorized publishing events, and verify the authenticity of a model author without relying on cumbersome, highly vulnerable long-lived key management.3

Peer-to-Peer Byte Verification via Merkle Trees

While verifying the overarching SHA-256 hash of a downloaded .slm file guarantees absolute integrity, it introduces a severe operational inefficiency when applied to large language models. SLMs frequently range from 2 to 20 gigabytes in size. If a client application must download the entire contiguous file from the P2P swarm before executing the hash function to detect tampering, a malicious peer could easily orchestrate a resource exhaustion attack, wasting vast amounts of the client's time, bandwidth, and battery life by serving gigabytes of random noise.25 To achieve high-performance, fault-tolerant P2P exchange that detects tampering instantly, MiniModel.org adopts the Merkle tree architecture formalized in the BitTorrent v2 specification.21

The Architecture of the Merkle Tree

A Merkle tree (or hash tree)—originally patented by Ralph Merkle in 1979—is a hierarchical cryptographic data structure that allows for the highly efficient and secure verification of massive datasets.25 Rather than hashing the entire .slm file as a single monolithic block, the file is sequentially partitioned into small, uniformly sized chunks—typically 16-kilobyte or 32-kilobyte blocks.25 The verification process follows a strict, bottom-up algorithmic aggregation:

1. Base Hashing (Leaf Nodes): Every individual 16KB chunk of the .slm payload is hashed using SHA-256, creating the base "leaf" nodes of the tree.25 If the final chunk of the file is smaller than the block size, padding rules mandate the use of all-zero hashes to maintain the symmetry of the binary tree.28
2. Pairing and Concatenation: Adjacent leaf hashes are concatenated and hashed together to form a parent node.25
3. Recursive Reduction: This pairing and hashing process iterates continuously up the hierarchy, effectively halving the number of hashes at each subsequent layer, until a single top-level hash remains.25 This final, 32-byte (64-character hex) string is the Merkle root hash.21

In the context of the MiniModel.org architecture, the final\_slm\_checksum field within the custom predicate—and the corresponding subject.digest field within the in-toto Statement—represents this ultimate Merkle root hash, rather than a monolithic file hash.19

Chunk-by-Chunk Swarm Verification Dynamics

By utilizing a Merkle tree structure, a client downloading an .slm package from an entirely untrusted P2P swarm does not need to wait for the multi-gigabyte file to complete before verifying its integrity.21 Instead, verification occurs dynamically, in real-time, on a piece-by-piece basis.25 When the client application connects to the decentralized swarm, it does not immediately request the binary weights. It first requests the "piece layers"—the intermediate hashes of the Merkle tree—from the connected peers.28 The client validates these intermediate piece layers by hashing them upward in memory to ensure they resolve mathematically to the exact trusted Merkle root provided by the digitally signed MiniModel.org manifest.28 Once the tree structure is securely validated, the client begins requesting the actual binary payload chunks in parallel from dozens of different peers.21 As each 16KB chunk arrives from a peer, the client immediately hashes the raw bytes and compares the resulting digest to the corresponding verified leaf hash residing in the validated piece layers.25 If the hash matches perfectly, the chunk is proven authentic and is written to local disk storage.25 If the hash fails, the client instantly identifies the exact microscopic location of the tampering.25 The client simply drops the corrupted chunk from memory, disconnects from the malicious peer, permanently bans their IP address or node ID from the session, and seamlessly requests that specific chunk from a different, compliant peer within the swarm.25 This block-aligned cryptographic verification mechanism guarantees that massive AI models can be rapidly and concurrently downloaded from hundreds of highly untrusted nodes. It maximizes network bandwidth utilization and enables aggressive file deduplication across swarms, all while maintaining absolute, zero-trust security guarantees.21

Browser-Local Loading and Validation via SLMComposer.com

The theoretical application SLMComposer.com serves as the premier end-user interface for the MiniModel.org ecosystem. It operates as a web-based integrated development environment (IDE) that allows developers to discover models, download .slm files directly into their local browser storage, assemble them into complex inference pipelines, and execute them natively utilizing hardware-accelerated WebGPU interfaces. Because the browser environment is fundamentally constrained by strict security sandboxes, single-threaded UI architectures, and stringent memory allocation limits, downloading and verifying multi-gigabyte .slm files requires highly optimized utilization of modern Web APIs.32 SLMComposer.com must securely fetch the manifest, parse the DSSE envelope, verify the ECDSA signature, resolve the P2P Merkle tree piece layers, and calculate the continuous stream of file hashes—all before safely passing the weight buffers into the WebGPU context for execution.

Cryptographic Signature Verification via Web Crypto API

Upon fetching the DSSE manifest from MiniModel.org, SLMComposer.com must first mathematically verify the author's digital signature. To perform this efficiently without introducing heavy, third-party cryptography libraries that bloat the client-side JavaScript bundle, the application leverages the native Web Crypto API (crypto.subtle).32 The Web Crypto API provides hardware-accelerated, non-blocking cryptographic primitives that are deeply integrated directly into the browser engine (such as V8 in Chrome or SpiderMonkey in Firefox), executing highly optimized underlying C++ cryptographic routines.32 The signature verification process relies exclusively on the Elliptic Curve Digital Signature Algorithm (ECDSA) utilizing the NIST P-256 curve (prime256v1), a standard highly favored for its optimal balance of robust security and minimal key sizes.24 The client-side verification process executes through the following rigorous sequence:

1. Key Importation: The public key material associated with the manifest (retrieved from the transparency log or embedded in the DSSE envelope) is provided in a JSON Web Key (JWK) format.36 The application invokes the crypto.subtle.importKey method, passing the format string "jwk", the raw key data (which must specify the key type kty: "EC" and the curve crv: "P-256"), and a parameter object explicitly specifying { name: "ECDSA", namedCurve: "P-256" }.24 The API securely processes this data and returns a native CryptoKey object configured exclusively for the "verify" usage operation.36
2. Payload Preparation: The base64-encoded payload string extracted from the DSSE envelope is decoded into a Uint8Array. As dictated by the DSSE specification, the signature is strictly generated over the Pre-Authentication Encoding (PAE) wrapper.16 SLMComposer.com programmatically constructs this exact PAE byte sequence (incorporating the payload lengths and types) into an ArrayBuffer.16
3. Signature Execution: The application invokes the asynchronous crypto.subtle.verify method, providing the cryptographic parameters { name: "ECDSA", hash: { name: "SHA-256" } }, the imported CryptoKey object, the decoded signature buffer, and the meticulously constructed PAE payload buffer.36
4. Boolean Evaluation: The Web Crypto API returns a JavaScript Promise that resolves to a boolean value.39 If the value evaluates to true, the signature is definitively authenticated, proving that the manifest has not been tampered with since the author applied their private key.39 If the value evaluates to false, the application immediately terminates the loading sequence, purges the manifest from memory, and issues a severe security alert to the user interface.

Memory-Safe File Verification via Web Streams

Validating the signature of the manifest ensures the metadata is entirely trusted, but SLMComposer.com must subsequently verify that the heavy .slm package streaming from the P2P swarm precisely matches the final\_slm\_checksum and Merkle tree piece layers mandated by the predicate.19 A naive implementation might attempt to load the entire 4-gigabyte .slm file into the browser's RAM as a single contiguous ArrayBuffer in order to pass it to the crypto.subtle.digest("SHA-256", buffer) function.40 This approach is fatally flawed; it will immediately trigger an catastrophic memory exhaustion crash (Out-Of-Memory error) within the JavaScript engine, as browser tabs are strictly restricted to memory caps far smaller than the size of modern AI model weights. To circumvent this hard limitation, SLMComposer.com implements streaming hash validation using the WHATWG Web Streams API in conjunction with incremental hashing architectures.41 Web streams allow massive datasets to be processed asynchronously, chunk-by-chunk, in constant memory space.40 As the .slm chunks are downloaded and verified against the Merkle piece layers, the application writes the data into the Origin Private File System (OPFS). The OPFS is a highly optimized, browser-native virtual file system that allows high-performance, block-level read and write access to local disk storage directly from the browser environment. Once the download concludes, the application must perform a final contiguous verification pass. The file is opened as a ReadableStream, providing a flow of sequential byte chunks without loading the entirety of the file into RAM.42 While the standard Web Crypto API currently lacks native support for an incremental, update-based digest function (unlike the Node.js crypto.createHash API) 44, developers circumvent this by utilizing a TransformStream to process the data.41 The readable stream of the OPFS file is piped directly into a chunk-processing pipeline. A custom cryptographic module, compiled to WebAssembly (WASM) for near-native computational speeds, exposes an incremental SHA-256 function.32 As the ReadableStream yields each chunk, the chunk is piped into the WASM module's update function.32 This highly advanced streaming approach ensures that browser memory consumption remains completely flat, restricted only to the size of the current chunk being analyzed (e.g., 64 kilobytes).40 Furthermore, the Web Streams API inherently manages internal backpressure.43 If the cryptographic hashing function falls behind the disk read speed, the queuing strategy triggers the highWaterMark threshold, automatically pausing the underlying source's pull() method until the processing buffer is cleared.43 Once the stream is fully consumed, the WASM module finalizes the calculation and yields the terminal SHA-256 hash. SLMComposer.com compares this calculated output against the string stored in the in-toto manifest. Only upon a flawless, identical match is the OPFS file handle passed to the WebGPU backend to commence tensor loading.

Thread Isolation and Zero-Copy Memory Mapping via Web Workers

Performing continuous SHA-256 hashing on multiple gigabytes of data is a highly CPU-intensive operation.32 Even with the efficiency of WebAssembly and native hardware acceleration, processing a 5GB .slm file could require several seconds of sustained, maximum-capacity computation.32 If this procedure is executed on the browser's primary main thread, the JavaScript event loop will block entirely. This blocking would cause the SLMComposer.com user interface to freeze completely, animations to stutter, and the page to become totally unresponsive, triggering browser warnings. To guarantee a seamless, high-performance user experience, the entire P2P networking stack, the OPFS file handling mechanisms, and the cryptographic verification pipeline are entirely offloaded to a Web Worker.33 A Web Worker executes JavaScript and WebAssembly in a separate, isolated background thread, operating entirely independent of the main UI thread.33 When the user commands SLMComposer.com to load a specific model, the main thread dispatches a postMessage command to the dedicated "Security & Swarm Worker," transferring the initial MiniModel.org manifest data.33 The background worker independently handles the Web Crypto API signature verification, coordinates the peer-to-peer WebRTC data channels to fetch the Merkle tree piece layers, streams the file bytes into OPFS, and executes the WASM-based chunked hashing.33 Because the crypto.subtle interface is fully available and thread-safe within Web Worker contexts, these intense cryptographic validations execute without inducing any degradation to the application's UI responsiveness.39 Once the background worker definitively validates the final hash against the manifest, it returns a success message to the main thread. To provide the main thread's WebGPU context with access to the validated weights without incurring a massive, performance-destroying memory-copy penalty, the architecture utilizes single-file, uncompressed layer principles derived from OCI artifacts.5 Because the .slm package is an uncompressed blob, the worker can simply pass the shared OPFS file handle back to the main thread.5 The WebGPU inference engine can then directly memory-map (mmap) the required tensor buffers straight from the local disk into the GPU memory, vastly optimizing load times, reducing memory overhead, and achieving near-native inference speeds entirely within the browser.5

Conclusion

The decentralized distribution of Small Language Models presents an array of highly complex engineering and security challenges spanning network bandwidth constraints, advanced supply chain vulnerabilities, and extreme client-side processing limitations. The theoretical architecture proposed for MiniModel.org decisively resolves these challenges through a masterful synthesis of distinct, state-of-the-art cryptographic disciplines and peer-to-peer networking protocols. By operating strictly as an immutable metadata registry, MiniModel.org successfully offloads exorbitant physical hosting costs to distributed peer-to-peer swarms while simultaneously maintaining absolute cryptographic authority over the ecosystem's integrity. The implementation of the in-toto Attestation Framework, heavily shielded within the anti-canonicalization defenses of the Dead Simple Signing Envelope (DSSE), provides a tamper-proof, schema-driven mechanism to log the exhaustive lineage of an .slm package. The custom predicate ensures that foundational model IDs, configuration checksums, tokenizers, quantization states, and evaluation evidence are irrevocably bound together by the author's keyless, Sigstore-backed identity, completely neutralizing the threat of chimera files and model poisoning attacks. Transitioning the physical payload delivery to a BitTorrent v2-style Merkle tree enables dynamic, block-aligned byte verification. This architectural choice guarantees that clients can safely ingest multi-gigabyte models from highly adversarial networks, instantly identifying and neutralizing poisoned data chunks before they ever corrupt the local file system. Finally, the rigorous, highly optimized implementation of the Web Crypto API, Web Streams chunking architectures, and Web Worker thread isolation ensures that browser-based consumers like SLMComposer.com can perform these mathematically intense verifications seamlessly. This precise choreography of modern web standards preserves the stability of the zero-trust environment, enabling secure, hardware-accelerated AI inference directly at the edge. Ultimately, this checksum-bound manifest design not only secures the mechanics of peer-to-peer model exchange but also establishes an auditable, enterprise-ready provenance chain. As regulatory bodies increasingly demand transparency regarding AI training data, intellectual property lineage, and security benchmarking, the MiniModel.org architecture provides the foundational cryptographic paper trail critical for the safe, regulated, and decentralized proliferation of localized artificial intelligence.

Works cited

1. Securing the software supply chain with Sigstore \- Giant Swarm, accessed June 30, 2026, https://www.giantswarm.io/blog/securing-the-software-supply-chain-with-sigstore-giant-swarm
2. Software Supply Chain Attribute Integrity (SCAI) \- arXiv, accessed June 30, 2026, https://arxiv.org/pdf/2210.05813
3. Model authenticity and transparency with Sigstore \- Red Hat Emerging Technologies, accessed June 30, 2026, https://next.redhat.com/2025/04/10/model-authenticity-and-transparency-with-sigstore/
4. Atlas: A Framework for ML Lifecycle Provenance & Transparency \- arXiv, accessed June 30, 2026, https://arxiv.org/html/2502.19567v1
5. Why Docker Chose OCI Artifacts for AI Model Packaging | Docker, accessed June 30, 2026, https://www.docker.com/blog/oci-artifacts-for-ai-model-packaging/
6. Signing and Validating OCI Artifacts with AWS Signer | Containers, accessed June 30, 2026, https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/
7. From Theory to Practice: How MLOps Can Embed GenAI Transparency – LFAI & Data, accessed June 30, 2026, https://lfaidata.foundation/blog/2025/07/29/from-theory-to-practice-how-mlops-can-embed-genai-transparency/
8. An Image Authentication Scheme Using Merkle Tree Mechanisms \- MDPI, accessed June 30, 2026, https://www.mdpi.com/1999-5903/11/7/149
9. in-toto \- Open Source Security Foundation, accessed June 30, 2026, https://openssf.org/tag/in-toto/
10. What are OCI Artifacts? \- Chainguard Academy, accessed June 30, 2026, https://edu.chainguard.dev/open-source/oci/what-are-oci-artifacts/
11. Sigstore vs. In-toto | TestifySec Blog, accessed June 30, 2026, https://www.testifysec.com/blog/sigstore-vs-in-toto/
12. Reference | SignPath, accessed June 30, 2026, https://docs.signpath.io/artifact-configuration/reference
13. Attestation format | Xygeni User Guides, accessed June 30, 2026, https://docs.xygeni.io/xygeni-products/build-security/attestation-format
14. OpenSSF Model Signing (OMS) Specification \- GitHub, accessed June 30, 2026, https://github.com/ossf/model-signing-spec
15. DSSE Attestation Online Decoder, accessed June 30, 2026, https://dsse.io/
16. VERIFY — Attestation & Security \- itsavibe.ai \- VIBES, accessed June 30, 2026, https://www.itsavibe.ai/verify
17. envelope.md \- in-toto/attestation \- GitHub, accessed June 30, 2026, https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md
18. in-toto attestations \- Trustification, accessed June 30, 2026, https://trustification.io/blog/2023/03/13/in-toto-attestations/
19. attestation/spec/v1/statement.md at main · in-toto/attestation \- GitHub, accessed June 30, 2026, https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md
20. CEP 27 \- Standardizing a publish attestation for the conda ecosystem, accessed June 30, 2026, https://conda.org/learn/ceps/cep-0027/
21. The BitTorrent Protocol Specification v2 : r/programming \- Reddit, accessed June 30, 2026, https://www.reddit.com/r/programming/comments/6safyl/the\_bittorrent\_protocol\_specification\_v2/
22. sigstore/model-transparency: Supply chain security for ML \- GitHub, accessed June 30, 2026, https://github.com/sigstore/model-transparency
23. OpenSSF Model Signing v1.0 Sigstore Guide \- Safeguard, accessed June 30, 2026, https://safeguard.sh/resources/blog/openssf-model-signing-v1-0-sigstore-ml-supply-chain
24. Web Cryptography Level 2 \- W3C, accessed June 30, 2026, https://www.w3.org/TR/webcrypto-2/
25. How Merkle Trees Verify Large Files \- DEV Community, accessed June 30, 2026, https://dev.to/doogal/how-merkle-trees-verify-large-files-242p
26. Merkle tree \- Wikipedia, accessed June 30, 2026, https://en.wikipedia.org/wiki/Merkle\_tree
27. BitTorrent \- Wikipedia, accessed June 30, 2026, https://en.wikipedia.org/wiki/BitTorrent
28. BEP 52 (BitTorrent v2) support — implementation design · Issue \#546 · ikatson/rqbit \- GitHub, accessed June 30, 2026, https://github.com/ikatson/rqbit/issues/546
29. BitTorrent v2 \- libtorrent blog, accessed June 30, 2026, https://blog.libtorrent.org/2020/09/bittorrent-v2/
30. merkletreejs/merkletreejs: Construct Merkle Trees and verify proofs in JavaScript. By @miguelmota \- GitHub, accessed June 30, 2026, https://github.com/merkletreejs/merkletreejs
31. OpenZeppelin/merkle-tree: A JavaScript library to generate merkle trees and merkle proofs. \- GitHub, accessed June 30, 2026, https://github.com/OpenZeppelin/merkle-tree
32. Exploring SHA-256 Performance on the Browser (Browser APIs, Javascript Libraries, WASM, WebGPU) | by Ronan Takizawa | Medium, accessed June 30, 2026, https://medium.com/@ronantech/exploring-sha-256-performance-on-the-browser-browser-apis-javascript-libraries-wasm-webgpu-9d9e8e681c81
33. AESP: A Human-Sovereign Economic Protocol for AI Agents with Privacy-Preserving Settlement \- arXiv, accessed June 30, 2026, https://arxiv.org/html/2603.00318v1
34. Web Crypto · Cloudflare Workers docs, accessed June 30, 2026, https://developers.cloudflare.com/workers/runtime-apis/web-crypto/
35. WebAuthn: Verifying an ECDSA Signature With Web Crypto \- Idura, accessed June 30, 2026, https://idura.eu/blog/webauthn-ecdsa-signature
36. Sign and verify data with ECDSA \- Deno Docs, accessed June 30, 2026, https://docs.deno.com/examples/ecdsa\_signing/
37. crypto \- Akamai TechDocs, accessed June 30, 2026, https://techdocs.akamai.com/edgeworkers/docs/crypto
38. Update on Web Cryptography \- WebKit, accessed June 30, 2026, https://webkit.org/blog/7790/update-on-web-cryptography/
39. SubtleCrypto: verify() method \- Web APIs | MDN, accessed June 30, 2026, https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/verify
40. Hash large files with streams \- Deno Docs, accessed June 30, 2026, https://docs.deno.com/examples/hash\_file\_streams/
41. Web Streams Everywhere (and Fetch for Node.js) \- CSS-Tricks, accessed June 30, 2026, https://css-tricks.com/web-streams-everywhere-and-fetch-for-node-js/
42. Web Streams API | Node.js v26.4.0 Documentation, accessed June 30, 2026, https://nodejs.org/api/webstreams.html
43. Streams—The definitive guide | Articles \- web.dev, accessed June 30, 2026, https://web.dev/articles/streams
44. Implementing the Web Cryptography API for Node.js Core | Nearform, accessed June 30, 2026, https://nearform.com/insights/implementing-the-web-cryptography-api-for-node-js-core/
45. google/webcrypto.dart: Cross-platform implementation of Web Cryptography APIs \- GitHub, accessed June 30, 2026, https://github.com/google/webcrypto.dart
46. Hash files in the browser with Web Crypto \- Transloadit, accessed June 30, 2026, https://transloadit.com/devtips/hash-files-in-the-browser-with-web-crypto/
47. Fast-Hash in JavaScript in Browser | Hashing and Validation in Multiple Programming Languages \- SSOJet, accessed June 30, 2026, https://ssojet.com/hashing/fast-hash-in-javascript-in-browser
48. Cryptography Executed in Web Browsers – Achieving Convenient End-to-End Security for Lock Access Control, accessed June 30, 2026, https://uu.diva-portal.org/smash/get/diva2:1805402/FULLTEXT01.pdf
49. SubtleCrypto \- Web APIs | MDN, accessed June 30, 2026, https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto