Technical Architecture for the .slm VNext Container: Streaming Layout and Cryptographic Identity

Full report

On this page

1. Executive Format Decision and Explicit Assumptions

The transition of the TinyRustLM .slm container to a clean-slate vNext format requires discarding legacy technical debt in favor of a strictly defined, cryptographically verifiable, and memory-safe artifact contract. The overarching architectural decision for the vNext format is the adoption of a hybrid layout: a strictly padded binary frame utilizing a JSON Canonicalization Scheme (RFC 8785\) metadata block1, paired with a BLAKE3 outboard Merkle tree for content-addressed verification and streaming3. This design directly addresses the operational realities of a browser-local AI chat interface and a public catalog like MiniModel.org, where artifacts arrive via untrusted peer-to-peer (P2P) transfers and must be executed across diverse hardware targets including native Rust, WebAssembly (WASM), and WebGPU. The primary engineering constraint—preferring a zero-third-party-crate implementation in Rust—shapes the architectural boundaries of the parser and runtime. Implementing a custom JSON Canonicalization Scheme parser from scratch is a reasonable, albeit rigorous, engineering task, provided the implementation strictly rejects duplicate keys and enforces ECMAScript-compatible numeric serialization. However, implementing cryptographic primitives such as BLAKE3 hashing and Ed25519 signature verification without relying on vetted third-party crates constitutes a severe security anti-pattern. This report formally designates custom cryptographic implementations as an unreasonable task under the fixed constraints. The architecture mandates the use of either audited native crates (e.g., blake3, ed25519-dalek) for native targets, or native WebCrypto API bindings (SubtleCrypto) within the browser environment, which natively supports Ed25519 as of the WinterCG 2026 snapshot4. The architecture operates under several explicit assumptions. First, the host environment encapsulates native CPU/GPU execution alongside WebAssembly, which is constrained by either the legacy 32-bit (4GB) limit or the emerging memory64 specification, which imposes varying upper bounds (typically around 16GB) in modern browsers7. Second, while the runtime must seamlessly admit a single local file, the fundamental design assumes that network streaming and P2P transfers require verifiable subsets (slices) of data before full file acquisition3. Finally, the vNext design explicitly rejects backward compatibility. There will be no legacy reader, dual writer, or compatibility alias for unreleased .slm artifacts. This clean cutover guarantees zero surface area for downgrade attacks or polyglot ambiguity, ensuring that the runtime only ever processes structurally rigid, cryptographically bound bytes.

2. Primary-Source and Precedent Matrix

The vNext design synthesizes the strengths and mitigates the vulnerabilities of existing machine learning serialization formats. A rigorous analysis of contemporary formats reveals a spectrum of security trade-offs, alignment strategies, and parsing complexities that directly inform the new container rules.

The engineering synthesis of these precedents dictates that the vNext format must adopt the strict overlap prevention mechanisms of Safetensors to guarantee memory safety before allocation. Simultaneously, it must adopt the typed structural descriptors of GGUF, but fundamentally alter the alignment constraints to satisfy WebGPU's strict 256-byte requirements. The verifiable streaming mechanisms of Bao will govern P2P transfer integrity. Conversely, the vNext specification explicitly rejects the path-traversal capabilities of ONNX and mandates checked arithmetic to neutralize the integer overflow vulnerabilities inherent in unverified dimensional multiplications observed in Llama.cpp.

3. Artifact-Class and Trust-Boundary Model

Artifact classes in the .slm vNext ecosystem represent distinct, non-overlapping logical boundaries. A secure format must not blur their identities, as a dependent adapter poses fundamentally different trust, verification, and memory mapping requirements than a standalone executable base model. Defining these classes ensures the runtime accurately interprets byte claims without contextual ambiguity. The primary artifact is the Immutable Base Model. This standalone artifact encapsulates foundational dense weights, structural metadata, and a declared vocabulary capability. It serves as the root of the execution graph and explicitly forbids the embedding of Turing-complete executable code, external file path references, or base-dependent adapter matrices within its own byte boundary. The Base-Dependent Adapter, commonly realized as a Low-Rank Adaptation (LoRA), constitutes a secondary artifact class. It contains sparse or low-rank matrices and is not an executable model in isolation. The adapter mathematically and cryptographically depends on the exact whole-file hash of a specific Immutable Base Model. Attempting to load an adapter without its cryptographically bound base must result in an immediate fail-atomic rejection by the runtime. To orchestrate these components, the architecture introduces the Composition Manifest. This is a lightweight, JSON Canonicalization Scheme (JCS) document that declares the ordered execution pipeline of a single Base Model and one or more Adapters. It defines the routing policy, runtime resource requirements, and chat templates, but it strictly contains no tensor payloads. Tokenizers and Chat Templates form another critical artifact class. These are embedded strictly as static rule arrays or bounded regular expression patterns either within a Composition Manifest or directly inside an Immutable Base Model. The format forbids arbitrary executable logic, completely eliminating the attack surface introduced by arbitrary template parsing engines. The Signature Envelope exists as a detached artifact. It is an external cryptographic proof, utilizing Ed25519, that binds a specific publisher identity to an artifact's root hash. Finally, KV Caches and Retrieval Indexes represent ephemeral or session-bound artifact classes generated dynamically at runtime. These generated artifacts must utilize a distinctly different format magic identifier to prevent the parser from accidentally interpreting a user's prompt cache as a structural model artifact. The trust boundary model dictates that all model bytes must be treated as structurally hostile input crafted by an adversary14. Validating a detached signature verifies provenance but does absolutely nothing to establish the behavioral safety or the structural integrity of the bytes themselves. Therefore, all structural validation must occur strictly in memory, in a bounded sandbox, before any large-scale heap allocations are permitted, operating under the assumption that the file is an active exploitation attempt targeting the parser's logic.

4. Normative Byte Layout and Canonical Metadata Grammar

The .slm vNext layout mandates a sequential, rigidly defined byte structure to prevent polyglot files, eliminate parsing ambiguity, and ensure perfect 256-byte alignment for direct WebGPU mapping without intermediate CPU shuffling9. The physical file is divided into three contiguous regions: a fixed-size binary header, a variable-length metadata block, and a perfectly aligned payload region. To eliminate endianness confusion, all integer fields within the binary header and the payload descriptors are strictly encoded as unsigned little-endian (LE) integers.

To ensure that two independent writers can produce byte-identical metadata from the exact same logical input, the metadata block must strictly adhere to the JSON Canonicalization Scheme as defined in RFC 87851. Map ordering is deterministic; keys must be sorted recursively based on their UTF-16 code units17. Duplicate keys represent a fatal structural violation. If the raw byte parser detects a duplicate key at any depth, it must immediately fail the load, explicitly forbidding the silent overwrite behaviors common in permissive JSON deserializers17. Numeric representation demands rigorous handling. All integers and floating-point values must be expressed using the ECMAScript-compatible shortest-form serialization, bounded by IEEE 754 double-precision limits18. The presence of NaN or \+/-Infinity within the JSON string is a violation of the grammar and results in immediate rejection. Unicode normalization requires that all string values be valid UTF-8, rejecting unescaped control characters or surrogate halves. Furthermore, the format dictates specific unknown-field rules. Parsers must cryptographically hash unknown fields as part of the total manifest digest to preserve structural identity, but they must safely ignore these fields during runtime memory initialization, allowing for future extension namespaces without breaking legacy execution engines. Finally, the treatment of trailing bytes is absolute: the file must end exactly at the final byte of the last declared tensor. Any trailing bytes result in immediate structural rejection to prevent signature confusion and polyglot appending attacks9.

5. Tensor and Quantization Descriptor Specifications

Tensor metadata resides exclusively within the JCS block under a highly structured "tensors" array. To support dense and plausibly portable hybrid transformer architectures, the descriptor strictly avoids geometric ambiguity by explicitly defining all memory properties required for physical allocation.

The most critical component of the tensor specification is the strict validation of these fields prior to allocating any host memory. To prevent the severe out-of-bounds read/write exploits observed in Llama.cpp's ggml\_nbytes function (CVE-2026-33298), the parser must perform checked arithmetic on all shape dimensions12. If the checked\_mul of the dimensions results in an arithmetic overflow, the load aborts. The parser then computes the expected physical size based on the declared dtype block geometry. If the calculated size does not perfectly match the declared byte\_length, the artifact is flagged as hostile. Overlapping tensors are thwarted by ensuring that tensor\[i\].byte\_offset is strictly greater than or equal to tensor\[i-1\].byte\_offset \+ tensor\[i-1\].byte\_length. Aliased ranges and unsorted offset declarations are categorically rejected.

6. Quantization Identities and Hardware Interoperability

Quantization definitions must be exactingly precise to prevent incompatible runtime behaviors or memory corruption resulting from misaligned accumulator expectations. Ambiguous labels like q4 are forbidden. The vNext format adopts the parameters outlined by the OCP Microscaling Formats (MX) specification for all sub-8-bit representations26. An MXFP4 tensor is bound exactly to E2M1 elements, containing 2 exponent bits and 1 mantissa bit, with values packed strictly in little-endian order27. The block geometry requires elements to be grouped in continuous blocks of 3227. Each 32-element block shares a single 8-bit scale factor (E8M0)27. Consequently, the format mandates that a 32-element MXFP4 block physically consumes exactly 136 bits, or 17 bytes27. The runtime validates the logical element count by ensuring (Total\_Elements / 32\) \* 17 \== byte\_length. Any tail rules involving elements that do not divide evenly by 32 demand explicit zero-padding up to the next block boundary, ensuring contiguity. Prior to model activation, the runtime must dynamically prove support for the declared quantization identity. It interrogates the native CPU/GPU capabilities matrix to confirm the availability of necessary fast-paths (e.g., matrix fused multiply-add instructions tailored for MXFP4). If the host hardware lacks native or highly optimized support for the specific dtype, the runtime must explicitly fail the activation rather than silently falling back to a computationally ruinous software emulation layer that degrades user experience and obfuscates underlying performance metrics.

7. Tokenizer, Chat-Template, Adapter, and Composition Binding

To maintain severe security boundaries and ensure deterministic generation across diverse platforms, tokenizers and templates are entirely stripped of Turing-complete logic29. Executable parsing engines, such as C++ minja or arbitrary Python Jinja evaluators, introduce massive dependency overhead, WASM compilation bloat, and critical denial-of-service vectors30. Instead, the container relies on a purely declarative schema. Tokenizer binding is achieved by ingesting the standardized Hugging Face tokenizer.json structure directly into the JCS metadata block32. This schema statically defines the vocabulary bytes, BPE merges, special tokens, added tokens, and byte-fallback behaviors without invoking external scripts32. Chat templates are similarly restricted to a declarative array of role strings mapping to specific tokens, defining explicitly the BOS (Beginning of Sequence), EOS (End of Sequence), and PAD semantics, alongside strict generation-stop sets. Composition Manifests serve as the connective tissue between Immutable Base Models and Base-Dependent Adapters. A manifest declares a pipeline by referencing the exact BLAKE3 root hash of the base model and an ordered array of adapter hashes. During activation, the runtime deterministically evaluates this manifest. It rejects the load if it detects duplicate adapter hashes, missing dependencies, or incompatible tensor layouts. Crucially, it prevents base drift: if an adapter's metadata declares a dependency on base hash A, but the manifest attempts to apply it to base hash B, the composition is categorically rejected. This architecture ensures that the deduplicated physical store size on the user's local disk accurately represents distinct components, without blurring the logical byte requirement of the final executable composition.

8. Hash, Chunk, Merkle, Signature, and Provenance Identities

Artifact identity in the vNext ecosystem requires uncompromising domain separation. Concatenating raw bytes for digest computation is mathematically ambiguous and highly susceptible to collision attacks; therefore, every digest input must be rigorously framed. The format defines several distinct cryptographic identities to govern the artifact lifecycle. The Whole-File Hash (Root Hash) is the supreme identifier for any model or adapter. It is calculated using the BLAKE3 algorithm configured in the Bao outboard tree mode3. This configuration generates a verifiable Merkle tree over the file, enabling cryptographic streaming and per-chunk verification in P2P environments without requiring the entire file to reside in memory. The Canonical Manifest Hash is a distinct BLAKE3 digest computed exclusively over the JCS metadata string, providing a lightweight identity for logical comparisons. Tensor Payload Hashes identify specific internal layers, allowing the runtime to detect localized corruption. Domain separation is enforced by prepending every digest input with its exact byte length, encoded as a 64-bit LE integer. For example, hashing the metadata block takes the form \BLAKE3(length\_as\_8\_bytes | | metadata\_bytes)\. This absolute framing ensures that concatenation ambiguity is mathematically impossible. Content chunk hashes correspond to fixed 65,536-byte (64KB) segments of the payload34. This chunk size is deliberate; it aligns perfectly with the standard WebAssembly memory page size, optimizing buffer transfers between JavaScript and the WASM linear memory bounds.

9. Bounded Validation and Fail-Atomic Activation Algorithms

The mitigation of integer overflow vulnerabilities, such as those that allowed heap exhaustion and out-of-bounds memory corruption in Llama.cpp (CVE-2026-33298 and CVE-2026-27940), requires an uncompromising two-pass bounded validator12. The validator must act as a cryptographic firewall between untrusted bytes and the host operating system's memory allocator. The first pass establishes structural and arithmetic safety before any large allocation is permitted. The parser reads the header and strictly validates the 100MB metadata size limit. It then parses the JCS block, verifying UTF-8 compliance and rejecting duplicate keys. Crucially, it iterates through the tensor descriptors to verify the 256-byte WebGPU alignment constraints19. The parser performs isolated checked\_add and checked\_mul operations across all 64-bit bounds to calculate the physical geometry of every tensor. If a dimensional calculation wraps around, or if a computed offset overlaps with a previously validated tensor, the function instantly returns a deterministic failure order, bypassing any panic or unbounded work loop. The second pass governs fail-atomic activation. A candidate artifact remains isolated in a temporary quarantine staging area until Pass 1 succeeds entirely. Only then does the engine sequentially hash the payloads to verify the BLAKE3 root. If the environment is dynamically swapping a model during an active chat session, the candidate artifact must completely validate its identities, required tensors, tokenizer data, and hardware capabilities. Only upon absolute verification does the runtime perform an atomic pointer swap to activate the new model. Any failure during the load process instantly aborts the staging operation, leaving the previous model, the memory state, and the ongoing conversation context completely unchanged and uncontaminated.

10. Reproducible Packer Design

To leverage the full potential of content-addressed storage, the conversion and packing process must be relentlessly reproducible. Two different developers, operating independently but packing the identical source PyTorch weights with the same configuration, must produce an exact byte-for-byte match, resulting in the identical BLAKE3 root hash. This reproducibility is achieved by strictly binding the inputs and neutralizing all sources of nondeterminism. The packer must enforce normalization across floating-point representations, explicitly collapsing all variations of NaN to a single, statically defined bit-pattern. Metadata ordering is naturally resolved by the JCS UTF-16 lexicographical sorting requirement1. The generation of alignment padding must consist strictly of deterministic 0x00 null bytes, eliminating the risk of uninitialized memory leaking into the pad space3. Furthermore, the packer must identify and isolate nondeterministic inputs originating from the conversion toolchain. Random seeds utilized during quantization calibration phases must be captured and explicitly recorded in the metadata receipt to explain any derivation discrepancies. Most critically, execution timestamps, local file paths, and build-environment variables are strictly forbidden from entering the internal metadata payload to prevent hash drift. Provenance artifacts, such as timestamps and compiler versions, belong exclusively in the detached catalog announcement, preserving the pristine cryptographic identity of the binary bytes.

11. Malicious-Input Threat Model and Parser Limits

The parser architecture must assume total hostility. A malicious input threat model targets the parser's logic to execute arbitrary code, exhaust system resources, or extract cross-origin data.

• Integer Overflow & Allocation Bombs: Attackers manipulate tensor dimension arrays to trigger arithmetic wraparounds, tricking the allocator into reserving an undersized heap buffer while subsequently writing massive payload data past the boundary (as exploited in CVE-2026-27940)14. The vNext parser neutralizes this by enforcing checked\_mul across all dimension indices and strictly capping the maximum tensor count to 65,535.
• Path Traversal: Formats like ONNX permit external tensor data references, leading to severe directory traversal attacks (CVE-2024-27318)15. vNext completely forbids external path resolution. All bytes must reside contiguously within the bounded .slm file, or be referenced strictly by BLAKE3 hash from a validated local P2P store.
• Decompression Bombs: The vNext format explicitly rejects whole-file compression (e.g., Deflate, Zstd) and per-chunk entropy coding. Tensors stored in advanced sub-8-bit quantizations (such as MXFP4) already mimic high-entropy pseudo-random noise. Additional compression yields negligible size reductions while introducing massive CPU decoding overhead, expanding the corruption blast radius (a single flipped bit destroys the stream), and obliterating the random-access capabilities essential for Bao slice verification3.
• Polyglots & Signature Confusion: Attackers append malicious payloads to the end of structurally valid files to bypass perimeter defenses. The strict enforcement of the trailing bytes rule—where the physical EOF must precisely match the final tensor's declared end offset—eliminates polyglot viability.

12. Native, Local-File, OPFS, WASM, WebGPU, and P2P Loading Model

The paradigm for loading bytes depends heavily on the execution target. Broad industry claims of universal "zero-copy" loading are analytically dishonest when transitioning between disparate memory domains9. In a native Rust environment operating on a POSIX filesystem, mmap provides true zero-copy semantics; the OS pages the file directly into physical memory. However, within the browser environment, loading models via the Origin Private File System (OPFS) or the File System Standard using a FileSystemSyncAccessHandle into WebAssembly linear memory necessitates a physical buffer copy35. WASM linear memory acts as an isolated contiguous array. While traditional WASM imposes a strict 32-bit (4GB) limit, massive modern models rely on the memory64 proposal, which expands addressing but is often capped by browser vendors at 16GB7. When targeting WebGPU execution, true zero-copy from OPFS directly to the GPU is not supported by current web standards without traversing intermediate JavaScript TypedArrays. Because the .slm vNext format enforces minStorageBufferOffsetAlignment exactly at 256 bytes19, the intermediate CPU array can be mapped directly to the GPUBuffer utilizing writeBuffer or mapped memory without requiring any host-side restructuring, repacking, or alignment-padding overhead. This architectural alignment minimizes transient peak memory spikes during the upload phase. For P2P transfer and shared storage, the architecture employs chunking based on the Bao BLAKE3 slice protocol3. Fixed 64KB chunks are transferred between peers. A peer provides the chunk, its sibling hashes, and the path to the root. As chunks arrive, they are written to a quarantine OPFS directory. Each chunk is cryptographically verified in isolation. Only when the entire file is assembled and validated against the trusted root hash is the artifact atomically promoted to the executable physical store, ensuring the runtime can seamlessly admit both normal single local files and highly parallelized P2P streams.

13. Resource Formulas for Storage, Hashing, Loading, and Peak Memory

Precise resource calculation is critical for preventing Out-Of-Memory (OOM) crashes during WebAssembly and WebGPU activation sequences. The runtime utilizes the following mathematical models to bind allocations: Storage and Payload Validation: The exact physical byte requirement ([Figure omitted from source export]) for a model is the sum of the header, metadata, padding, and tensor payloads. For a tensor [Figure omitted from source export] quantized in MXFP4 (E2M1) with a 32-element block geometry ([Figure omitted from source export]) and 17 bytes per block ([Figure omitted from source export]):[Figure omitted from source export] Transient Peak Memory (WebGPU Upload Phase): During the transition from OPFS to WebGPU, memory peaks due to the intermediate staging buffers required by the browser architecture. If [Figure omitted from source export] is the size of the base model, [Figure omitted from source export] is the number of applied adapters, and [Figure omitted from source export] is the fixed maximum transfer buffer allocated for the queue:[Figure omitted from source export] Because vNext is strictly 256-byte aligned, no additional memory overhead is required for CPU-side realignment buffering, keeping [Figure omitted from source export] mathematically optimal. Hashing Throughput (BLAKE3): The BLAKE3 algorithm achieves high throughput via SIMD parallelism. For a file of size [Figure omitted from source export], the hashing time [Figure omitted from source export] is bounded by the memory bandwidth [Figure omitted from source export] and the single-thread SIMD processing speed [Figure omitted from source export]:[Figure omitted from source export]

14. Conformance Corpus, Fuzz Plan, and Differential Test Matrix

To guarantee strict interoperability between native and browser clients, the standard defines an exhaustive conformance corpus and test suite for all reader/writer implementations. The corpus includes byte-exact golden files covering minimal valid files and every supported quantization type (e.g., F16, MXFP4). Maximum legal bounds are tested using artifacts that deliberately push the 100MB JCS metadata limit and max out the 5D tensor counts. The fuzz plan requires mutation testing across critical attack surfaces: single-field corruptions, deliberate offset wraparounds, overlapping tensor ranges, and odd tail padding. Differential testing is mandatory. The exact same vNext artifact and deterministic seed must be loaded across the Rust native engine, the WASM CPU instance, and the WebGPU compute shaders. The output logits must be captured and compared. Any divergence in the logits beyond acceptable floating-point drift indicates a catastrophic failure in the parser's interpretation of the byte claims or the execution engine's handling of the quantization identities. To assist developers and users, the specification demands a public-safe inspection output utility. This tool provides cryptographic hashes, architecture strings, tensor counts, and bounded errors, but it is strictly programmed to omit private local paths, proprietary user prompts, embedded secrets, and any executable interpretation of untrusted metadata, ensuring safe debugging in enterprise environments.

15. Clean Cutover Implementation Backlog

The deployment of the vNext contract demands a disciplined, slice-based implementation backlog with strict deletion criteria to avoid dual-format bloat.

1. TDD Infrastructure and Parser Core: Develop the slm-vnext parsing crate utilizing Test-Driven Development against the conformance corpus. Enforce the zero-third-party-crate rule for structural and JSON (JCS) parsing, but strictly integrate blake3 and ed25519-dalek for native cryptographic validation.

2. Conversion Tool Cutover: Update the upstream Python conversion scripts to exclusively emit the vNext .slm layout. Deprecate all legacy output flags.

3. Fixture Regeneration: Regenerate all CI/CD test fixtures, golden files, and evaluation receipts to match the new BLAKE3 root hashes.

4. Catalog Admission Changes: Update the MiniModel.org API to exclusively accept catalog announcements containing the new slm2 magic bytes and corresponding signatures.

5. Stop Rules and Deletion: Once the vNext parser achieves 100% pass rates on the differential test matrix, the legacy .slm reader must be entirely deleted from the runtime repository. No real model is permitted to be repacked and published until the legacy parser is successfully excised from the main branch.

16. Annotated primary-source bibliography with direct links and dates

• 8 Safetensors Specification & GitHub Commit 1f3819e (May 2024): Details strict JSON header constraints, the 100MB parsing limit, absolute little-endian enforcement, and the realities of zero-copy semantics on varying hardware. Retrieved August 2026\. https://github.com/huggingface/safetensors
• 10 GGUF v3 Specification (August 2023): Defines typed metadata structures, memory-mapping alignment defaults, and flat tensor information blocks. Analyzed for structural precedent and endianness ambiguity. Retrieved August 2026\. https://ggml-org-ggml.mintlify.app/formats/gguf
• 12 Llama.cpp Vulnerability Advisories CVE-2026-33298 & CVE-2026-27940 (March 2026): Critical vulnerability reports detailing integer overflows within the ggml\_nbytes dimension multiplication logic resulting in undersized heap allocations and subsequent remote code execution capabilities. Retrieved August 2026\.
• 15 ONNX Path Traversal CVE-2024-27318 (Feb 2024): Documents severe arbitrary file read/write access vulnerabilities achieved through malicious directory traversal sequences within external\_data links. Retrieved August 2026\.
• 1 RFC 8785: JSON Canonicalization Scheme (JCS) (2020): The definitive standard for deterministic string sorting, the eradication of whitespace, and exact IEEE 754 floating-point formatting to achieve cross-platform hash identity. Retrieved August 2026\. https://datatracker.ietf.org/doc/html/rfc8785
• 19 W3C WebGPU Specification Draft (Feb 2023): Defines strict hardware interfacing rules, explicitly noting that the minStorageBufferOffsetAlignment is rigorously set to 256 bytes for resource bindings. Retrieved August 2026\. https://www.w3.org/TR/webgpu/
• 26 OCP Microscaling Formats (MX) v1.0 (Sept 2023): Standardizes block scaling architectures for deep learning inference, precisely defining the MXFP4 (E2M1) format utilizing 32-element E8M0 group sizes. Retrieved August 2026\.
• 3 Bao (BLAKE3) Specification v0.9.1 (2020): Explains outboard encoding formats, Merkle tree derivations, and 4096-byte/64KB chunking slice formats for verified streaming. Retrieved August 2026\. https://github.com/oconnor663/bao/blob/master/docs/spec\_0.9.1.md
• 4 WinterCG WebCrypto Snapshot (2025/2026): Confirms the baseline availability and performance characteristics of Ed25519 native execution within the standard browser SubtleCrypto APIs. Retrieved August 2026\.
• 7 WebAssembly and OPFS Storage limits: Analyzed source material outlining the 64KB page size limits, memory64 adoption parameters, and zero-copy File System Access constraints within modern JavaScript environments. Retrieved August 2026\.

Works cited

1. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8785

2. JCS Canonicalisation Discipline for Agentic-Payment Receipts \- IETF, https://www.ietf.org/archive/id/draft-hopley-x402-canonicalisation-jcs-v1-02.html

3. bao/docs/spec\_0.9.1.md at master · oconnor663/bao \- GitHub, https://github.com/oconnor663/bao/blob/master/docs/spec\_0.9.1.md

4. Stop Writing Polyfills. WinterCG Killed isomorphic-fetch in 2026 \- DEV Community, https://dev.to/gabrielanhaia/stop-writing-polyfills-wintercg-killed-isomorphic-fetch-in-2026-4b30

5. VeilChat Security & Privacy Whitepaper, https://www.veilchat.me/whitepaper

6. Edwards-Curve Digital Signature Algorithm (EdDSA) \- ResearchGate, https://www.researchgate.net/publication/399371692\_Edwards-Curve\_Digital\_Signature\_Algorithm\_EdDSA

7. State of WebAssembly 2026 | The Dev Newsletter, https://devnewsletter.com/p/state-of-webassembly-2026/

8. huggingface/faq: FAQ about Hugging Face and Open Source \- GitHub, https://github.com/huggingface/faq

9. GitHub \- safetensors/safetensors: Simple, safe way to store and distribute tensors, https://github.com/safetensors/safetensors

10. GGUF \- Wikipedia, https://en.wikipedia.org/wiki/GGUF

11. GGUF file format \- ggml, https://ggml-org-ggml.mintlify.app/formats/gguf

12. CVE-2026-33298 \- Ubuntu, https://ubuntu.com/security/CVE-2026-33298

13. Heap Buffer Overflow via Integer Overflow in GGUF Tensor Parsing · Advisory · ggml-org/llama.cpp \- GitHub, https://github.com/ggml-org/llama.cpp/security/advisories/GHSA-96jg-mvhq-q7q7

14. CVE-2026-27940: llama.cpp Buffer Overflow Vulnerability \- SentinelOne, https://www.sentinelone.com/vulnerability-database/cve-2026-27940/

15. Onnx Directory Traversal vulnerability · CVE-2024-27318 · GitHub Advisory Database, https://github.com/advisories/GHSA-whh8-fjgc-qp73

16. CVE-2024-27318: ONNX Path Traversal Vulnerability \- SentinelOne, https://www.sentinelone.com/vulnerability-database/cve-2024-27318/

17. vr\_jcs \- Rust \- Docs.rs, https://docs.rs/vr-jcs

18. GitHub \- lattice-substrate/json-canon: Deterministic RFC 8785 JSON Canonicalization Scheme (JCS) for Go: strict parser, canonical serializer, and stable CLI ABI., https://github.com/lattice-substrate/json-canon

19. WebGPU \- W3C, https://www.w3.org/TR/2023/WD-webgpu-20230228/

20. WebGPU \- W3C, https://www.w3.org/TR/webgpu/

21. WebGPU-For-Dummies \- Distributive, https://people.distributive.network/amir/WebGPU-For-Dummies.html

22. Eight translations of one dispatch — A WebGPU stack source-level walkthrough \- Airing, https://ursb.me/immersive/webgpu/

23. Bao: A verified streaming tool based on BLAKE3 \- Hacker News, https://news.ycombinator.com/item?id=22029618

24. Malicious GGUF File RCE: llama.cpp Parser Flaws 2026 \- Stingrai, https://www.stingrai.io/blog/malicious-gguf-file-llama-cpp-parser-rce

25. draft-rundgren-json-canonicalization-scheme-17 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-rundgren-json-canonicalization-scheme/17/

26. OCP Microscaling Formats (MX) Spec | PDF | Rounding | Theory Of Computation \- Scribd, https://www.scribd.com/document/919811853/OCP-Microscaling-Formats-MX-v1-0-Spec-Final

27. The FP4 Breakthrough: How MXFP4 Quantization Delivers Up to 6.1x Inference Throughput on Dell PowerEdge XE9785L with AMD Instinct MI355X Accelerators | Metrum AI, https://www.metrum.ai/blog/fp4-breakthrough-mxfp4-quantization

28. An Empirical Study of Microscaling Formats for Low-Precision LLM Training, https://aisystemcodesign.github.io/papers/FP4.pdf

29. building\_tokenizer\_from\_gguf\_w, https://huggingface.co/datasets/John6666/forum3/blob/main/building\_tokenizer\_from\_gguf\_with\_candle\_rust\_1.md

30. abseil (wasm) \- xrepo, https://xrepo.xmake.io/mirror/packages/wasm.html

31. Paul Muraviev / awesome-cpp \- GitLab, https://gitlab.com/tecras/awesome-cpp

32. transformers/MIGRATION\_GUIDE\_V5.md at main \- GitHub, https://github.com/huggingface/transformers/blob/main/MIGRATION\_GUIDE\_V5.md

33. How to understand the special tokens? \- Transformers \- Hugging Face Forums, https://discuss.huggingface.co/t/how-to-understand-the-special-tokens/170916

34. Node.js WebAssembly \- W3Schools, https://www.example.com.vn/nodejs/nodejs\_webassembly.asp

35. node-opfs/README.md at main · mdy-docs/node-opfs · GitHub, https://github.com/mdy-docs/node-opfs/blob/main/README.md

36. WebGPU Correspondence Reference, https://gpuweb.github.io/gpuweb/correspondence/

37. CVE-2024-27318 \- CVE Record, https://www.cve.org/CVERecord?id=CVE-2024-27318

38. WebGPU \- W3C, https://www.w3.org/TR/2021/WD-webgpu-20210706/

39. Memory in wasmtime \- Rust, https://docs.wasmtime.dev/api/wasmtime/struct.Memory.html