Decentralized Distribution and Quality Verification of Small Language Models in the TinyRustLM Ecosystem

Full report

On this page

Introduction to the Teleodynamic Distribution Paradigm

The proliferation of micro and small language models operating within the highly constrained parameters of 4 million to 135 million weights has necessitated a fundamental paradigm shift in how artificial intelligence artifacts are distributed, validated, and executed at the network edge1. The TinyRustLM framework represents a distinct departure from monolithic, cloud-centric inference architectures. It operates entirely as a browser-local, WebAssembly-driven ecosystem compiled into a 114 KiB dependency-free module, utilizing handwritten scalar Rust loops for execution2. However, supporting a diverse array of specialized models without incurring prohibitive centralized bandwidth costs, while simultaneously protecting edge nodes from malicious or functionally degraded payloads, requires an advanced, metadata-first peer-to-peer distribution network. The core architectural challenge in decentralized model distribution extends far beyond the mere transfer of bytes. It demands the establishment of a cryptographic continuum of trust from the point of origin directly to the execution environment3. When dealing with the custom SLM1 binary format—which utilizes a strictly defined 108-byte fixed header, relies on non-cryptographic internal FNV-1a checksums, and is bound by inflexible 128 MiB synchronous memory transfer ceilings2—the network must mathematically enforce structural integrity and empirical quality before a model ever breaches the local runtime boundary. This comprehensive analysis details the exact operational blueprint for how the MiniModel.org registry and the TinyRustLM ecosystem must distribute .slm models via a metadata-first peer-to-peer network. By systematically decoupling the hosting of model weights from capability discovery, establishing cryptographically signed manifests, instituting rigorous decentralized quality badges, and mandating strict local revalidation at the admission gate, the system guarantees that end-users can seamlessly discover and execute tiny models that empirically function precisely as claimed. This approach entirely circumvents traditional centralized infrastructure, ensuring resilience, verifiable execution, and decentralized scale.

The Metadata-First Peer-to-Peer Architecture

To eliminate the massive financial and operational burdens associated with centralized project-server model-byte hosting, MiniModel.org must function strictly as a metadata-only catalog and a cryptographic anchor. The actual multi-megabyte .slm binary weights are distributed across a decentralized swarm of end-user nodes, leveraging principles observed in highly efficient peer-to-peer content delivery networks such as Dragonfly5.

Decoupling the Registry from the Payload

In a strict metadata-first paradigm, the central registry hosts only the state logs, network references, and cryptographically signed manifests of the models. It explicitly does not store the physical .slm files7. When a client application queries the registry for a specific capability, such as a 16-million parameter retrieval-and-embedding specialist model, the server returns a Content Identifier and a signed JSON manifest1. The manifest acts as a cryptographic map, while a Distributed Hash Table resolves the Content Identifier to a dynamic pool of active network peers currently hosting the constituent data chunks. This mirrors the architectural separation seen in OCI-compliant container registries that utilize content-addressable storage mechanisms8. By employing content-addressed storage, an artificial intelligence model is identified exclusively by the cryptographic hash of its contents rather than its semantic name or uniform resource locator. If multiple developers fine-tune an identical base architecture but alter only the final output projection layers, the unchanged foundational tensor blobs deduplicate perfectly across the network, exponentially reducing aggregate bandwidth utilization and local storage requirements10.

Piece-Based Streaming and Seed Peers

To accommodate the specific memory constraints of the TinyRustLM environment—which currently lacks range loading capabilities and requires a full-file transfer into a synchronous WebAssembly memory allocation strictly limited to 128 MiB2—the underlying peer-to-peer mesh must assemble the file transparently in the background before handing it to the execution runtime. Using a protocol architecture akin to Dragonfly's load-aware scheduling and micro-task distribution, the network splits the .slm file into granular, independently verifiable pieces5. A seed peer within this ecosystem is not required to possess the entire model artifact to begin distributing it to others. As soon as a single data piece is locally cached and its hash is verified against the manifest's piece-hash tree, that node becomes available for immediate upload to other peers requesting the same Content Identifier5. This piece-based streaming download mechanism means that distribution begins in parallel with the initial fetch, dramatically reducing total transfer time and dropping origin traffic by up to 99.5 percent in high-density cluster environments6.

Explicit Public Demos as the Sole Hosting Exception

The absolute prohibition of project-server byte hosting is bypassed in exactly one scenario: highly curated, explicit public demos. To bootstrap the network topology and provide an immediate, zero-friction onboarding experience for new users assessing the TinyRustLM deterministic smoke artifacts, the registry may provision highly constrained HTTP origin servers12. However, even these origin servers interact with the broader ecosystem merely as high-availability seed peers. They publish their capabilities to the Distributed Hash Table and serve chunks using identical protocols to any other edge node, ensuring the client-side download logic remains strictly peer-to-peer native and preventing the emergence of a centralized dependency bottleneck.

Cryptographically Signed Manifests and Content Addressing

The custom SLM1 format inherently contains a 108-byte header dictating model dimensions, quantization variants including q4\_0, q8\_0, and f32, and a non-cryptographic FNV-1a checksum2. Because this internal checksum is designed merely to detect accidental byte corruption rather than adversarial tampering, a robust external cryptographic envelope is mathematically mandatory. This security posture is achieved through the implementation of signed tool manifests and rigorous content-addressed derivations3.

The Manifest Schema and Cryptographic Binding

A TinyRustLM model manifest is a structured, canonicalized JSON document that definitively binds the model's semantic identity to its physical byte structure and quality attestations. This document serves as the absolute source of truth for the local client prior to network interaction. The manifest architecture encapsulates several critical domains. It includes fundamental identity metadata, defining the model family, exact parameter count, intended teleodynamic specialist slot, and binary format version1. It establishes a cryptographic anchor by declaring the root BLAKE3 or SHA-256 hash of the entire .slm file. The BLAKE3 algorithm is uniquely preferred for this application due to its highly parallelizable tree structure, which allows for the streaming verification of distinct data chunks as they arrive asynchronously over the peer-to-peer mesh7. Furthermore, the manifest includes a lightweight replication of the 64-byte tensor directory contained within the SLM1 binary header. This vital inclusion allows the downloading client to mathematically verify the structural geometry of the weights, such as confirming the exact presence and alignment of quantized blocks, long before the payload is fully assembled in local storage2. Finally, the manifest integrates evaluation references, utilizing Content Identifiers that point directly to verifiable execution traces and origin attestations stored elsewhere in the distributed network.

Keyless Signing and Signature Validation Mechanics

To prevent sophisticated "rug pull" or "tool poisoning" vectors—scenarios where an adversary uploads a functional model, gains user trust, and subsequently swaps the network payload with a malicious artifact under the identical semantic namespace—the manifest must be immutable and digitally signed13. Integrating an ecosystem parallel to Sigstore's Cosign infrastructure allows for dynamic keyless signing backed by OpenID Connect identity providers14. When an author publishes a new specialist model to the metadata catalog, an ephemeral cryptographic key pair is generated automatically. The manifest is signed using this ephemeral key, and the resulting certificate is permanently anchored to a public, append-only transparency log such as Rekor15. When a user initiates a download sequence, the tinyrustlm-browser-harness fetches the manifest and executes a strict validation protocol. First, the JSON manifest is canonicalized according to RFC 8785 rules to ensure absolute byte-for-byte consistency across disparate computing platforms13. The client then verifies the cryptographic signature against the transparency log's public key, definitively confirming the author's identity and the exact timestamp of the publication17. Only upon the mathematically successful completion of this signature validation does the client proceed to query the peer-to-peer mesh for the Content Identifier matching the manifest's root hash.

The Trust and Evaluation Badge System

In a highly decentralized ecosystem devoid of traditional centralized gatekeepers, end-users require immediate, mathematically sound visual heuristics to ascertain whether a specific artificial intelligence model is functional, performant, and safe. Relying solely on the unverified claims of uploaders leads inevitably to a proliferation of fake quality assertions and network pollution. The ecosystem must implement a tiered, cryptographically anchored Trust and Evaluation Badge System that relies on verifiable execution rather than human reputation.

The Taxonomy of Objective Quality Badges

The badge system is designed to be entirely objective, hierarchical, and directly tied to empirical computational evidence permanently stored in the distributed network. The classification relies on specific cryptographic requirements that prove progressive levels of operational viability.

Evaluation Report References and Decentralized Consensus

To actively prevent bad actors from forging the high-value Tier 2 and Tier 3 badges, the system integrates mechanics from decentralized peer-review protocols such as OpenCLAW-P2P18. When a performance evaluation is conducted, the evaluating node does not merely output a subjective score; it generates a rigid, deterministic execution trace. Because the runtime utilizes a deterministic pseudo-random number generator and relies on fixed candidate storage arrays for its sampling states21, an evaluation run can produce a highly lightweight, mathematically reproducible trace. This trace contains the exact input prompt, the random seed, and the resulting cryptographic hash of the probability logits at every single generation step. This trace is packaged into a formal Evaluation Report, hashed via BLAKE3, and submitted to the distributed network. The central registry continuously crawls these Evaluation Reports to aggregate consensus. It utilizes an Adaptive Trust Score function, which dynamically weights the incoming evaluations based on the historical reliability, detection accuracy, and decision consistency of the evaluating nodes22. Only when a model achieves a predefined mathematical threshold of successful, cryptographically verifiable multi-node evaluations does the registry automatically attach the corresponding high-tier quality badge to the model's public catalog entry.

Peer-to-Peer Import Quality Checks and Local Revalidation

The physical transition of data from fetching network bytes to initiating a live WebAssembly execution is the single most critical vulnerability window within the runtime architecture. This transition is formally designated in the system's operational parameters as "Gate C," representing persistent artifact storage and cryptographic admission2.

The Strict Revalidation Pipeline

Because peer-to-peer transfers are inherently untrusted by design, receiving binary weights from random network actors mandates strict local revalidation before those bytes are ever exposed to the browser's main thread or the raw C-style application binary interface2. The client-side application must perform a sequential, unbreakable admission process. As chunk payloads stream in via transport protocols, their individual hashes are computed in real-time. If a chunk fails to perfectly match the expected signature defined in the manifest's Merkle tree, it is immediately discarded, and the specific peer that supplied the corrupted data is penalized in the client's local routing table. Once all required chunks are verified and continuously assembled in a temporary virtual file system, a final contiguous hash is computed to guarantee holistic structural integrity. Prior to transferring the massive memory allocation into the WebAssembly instance, a highly lightweight validation probe parses the very beginning of the file. It reads exactly the first 108 bytes to verify the SLM1 magic sequence, ensuring the format version is strictly correct2. It cross-references the internal FNV-1a checksum against the payload and strictly checks that the tensor count, dimension bounds, and data offsets align perfectly with the physical file boundaries. This preemptive parsing prevents malicious buffer overflow attacks or out-of-bounds memory panics during the subsequent load invocation2. Upon passing these exhaustive checks, the model is formally admitted to the verified local store, and the user interface updates to reflect that the specialist model is now physically installed within the architecture's teleodynamic resource posture1. This stringent revalidation protocol ensures that corrupted, malicious, or malformed artifacts are comprehensively quarantined before they can trigger memory allocation failures, prompt generation resets, or severe browser thread locks11.

Peer Announcements and Local Share Kits

For a decentralized network to thrive and maintain high availability without central coordination, edge nodes must efficiently discover one another and seamlessly announce their hosted resources. This operational necessity requires the integration of a background capability announcement protocol and the absolute minimization of user friction regarding seeding operations.

The Distributed Mesh and Capability Discovery

Leveraging protocols akin to those found in highly resilient mesh networks, the local runtime nodes utilize local network auto-discovery mechanics, such as multicast DNS for local area networks, alongside broader distributed hash table integrations for wide-area routing24. The continuous discovery process operates in a structured two-phase mechanism. First, when a user's local instance successfully admits a new model to its verified local store, the background service constructs a specialized metadata block. This block includes the user's ephemeral public node identity, the Content Identifiers of the specific models currently cached in local storage, and the specific teleodynamic skills those models represent, categorized through standardized capability taxonomies1. The node silently publishes this record to the distributed network. Second, when another user searches the catalog for a specific capability, the browser harness translates the semantic request into a structured network query. It retrieves capability records from available endpoints, dynamically ranking the potential seed peers by latency metrics, historical connection stability, and cumulative trust scores to ensure optimal download performance25.

Local Share Kits and Zero-Configuration Seeding

The ultimate success of any peer-to-peer file sharing ecosystem relies heavily on the ease of continuous participation26. To ensure users consistently contribute bandwidth back to the swarm without requiring deep technical knowledge or complex port-forwarding configurations, the tinyrustlm-local-server module incorporates an embedded local share kit2. By default, any model that carries a high-tier consensus badge and has passed local revalidation is automatically seeded via secure WebRTC data channels to requesting peers7. The user interface explicitly abstracts the severe complexities of network address translation traversal, utilizing public session traversal utilities to establish direct, encrypted connections between disparate browsers27. The share kit provides users with a visual, gamified dashboard of their teleodynamic contribution, displaying exactly how much bandwidth they have offloaded from the community and how many peer requests their local cache has successfully fulfilled, thereby incentivizing continued network participation.

Import Receipts and Cryptographic Proof of Execution

In a truly decentralized network architecture, merely downloading a file and verifying its hash does not guarantee its functional viability on highly disparate consumer hardware configurations. A model that perfectly matches its manifest might still fail to execute properly if the local browser environment suffers from specific WebAssembly memory limitations, unique quantization unpacking bugs, or incompatible floating-point handling. To create a closed-loop, mathematically rigorous quality assurance mechanism that proves functionality beyond mere file integrity, the ecosystem implements the concept of Import Receipts, which are fundamentally backed by Proof of Execution protocols28.

The Mechanics of Generating the Import Receipt

When a user downloads an .slm model and successfully promotes it through the cryptographic admission gate, the tinyrustlm-slm-pack module forces a deterministic runtime smoke test2. This test is executed automatically as an isolated, background computational task. The runtime loads the model into memory, explicitly fixes the pseudo-random number generator seed to a known constant, and feeds a standardized, hardcoded validation prompt through the specific byte tokenizer defined in the binary header2. As the model processes the multi-layer forward pass, the runtime actively captures the scalar intermediate states of the transformer execution. Specifically, it records the exact numerical outputs of the pre-norm attention layers and the final dense logit arrays. It creates a composite cryptographic hash of these highly specific mathematical states. This resulting hash, combined with the local browser's exact environment fingerprint—including the WebAssembly engine version and maximum allocation capabilities—is then signed by the client's local ephemeral key. This signed document officially constitutes the Import Receipt, serving as an immutable record that the model successfully ran and produced the exact expected mathematical output on a specific hardware profile.

Verifiable Client Diversity and Continuous Network Health

The generated Import Receipt is subsequently gossiped back into the distributed hash table and permanently associated with the model's unique Content Identifier. This mechanism provides the entire network with a cryptographic Proof of Execution, utilizing principles similar to those found in zero-knowledge execution rollups or verifiable client diversity attestation systems28. By aggregating these receipts globally, the metadata registry can display real-time, empirical data regarding a model's true viability across wildly diverse environments. If a specific 32-million parameter model reliably passes validation on one browser engine but consistently generates invalid or divergent Import Receipts on another, the metadata catalog automatically flags this critical discrepancy. This powerful mechanism transforms compatibility testing from a centralized, manual editorial record into a continuous, decentralized, and cryptographically verified feedback loop that scales infinitely with the user base4.

Sybil Resistance and Anti-Abuse Mechanisms

A decentralized system that rewards engagement, grants visibility, or issues quality badges based on peer validation is mathematically susceptible to Sybil attacks. In such scenarios, a single malicious actor might spin up thousands of automated, fake nodes to artificially inflate a sub-par model's trust score or flood the network with fabricated evaluation reports to disrupt the ecosystem25.

Adaptive Trust Scores and Behavioral Degradation

To actively prevent bad actors from establishing fake quality claims, the registry relies heavily on an Adaptive Trust Score algorithm22. New nodes entering the network are initialized with a neutral, baseline trust score, requiring them to prove their reliability over time23. A node gradually accrues trust by providing consistent, verifiable bandwidth to the swarm and by submitting Import Receipts that align perfectly with the mathematical consensus of established, high-trust nodes. Conversely, the system employs aggressive behavioral degradation. If a node submits an Evaluation Report or an Import Receipt containing intermediate state hashes that deviate mathematically from the deterministically proven norm established by the broader network, its trust score is severely degraded. Nodes with low trust scores find their attestations completely ignored by the consensus algorithms, effectively muting their ability to influence the badge system or route traffic.

Staked Claims and Cryptographic Slashing Conditions

For authors asserting high-tier quality claims, such as attempting to secure a highly visible Peer-Reviewed badge for their model, the system implements a localized proof-of-value mechanism20. The author must lock a nominal cryptographic or reputational stake when publishing the initial model manifest. If independent, high-trust nodes execute the model and prove via reproducible execution traces that the model fails deterministic smoke tests or outputs corrupted logits on standard benchmarks, the author's claim is mathematically refuted. The network automatically drops the model's badge to the unverified tier, and the author's overall registry reputation is slashed. Conversely, if a malicious peer attempts to submit a false negative report against a verified, functional model, their failure to provide a mathematically sound, reproducible execution trace results in their own immediate quarantine from the network's routing tables29.

Bounding the Evaluation Space

Crucially, because the runtime currently utilizes a handwritten scalar Rust loop with a strictly defined application binary interface2, the scope of execution is highly constrained and mathematically pure. There are no opaque GPU drivers, proprietary neural processing units, or non-deterministic floating-point accumulation orders to confound the results across different machines. An execution trace in this environment is absolute. Therefore, verifying whether an Evaluation Report is fake requires merely re-running the exact trace through the standard runtime crate. The extreme ease of this deterministic verification makes forging quality claims computationally infeasible for an attacker, securing the integrity of the entire badge ecosystem.

Recommended Public Catalog Fields

To ensure a seamless, transparent, and highly functional user experience, the metadata catalog must enforce a strict, standardized schema for its public display entries. Every single entry must display exhaustive, immutable parameters that allow the teleodynamic composer tool to plan memory envelopes and architectural layouts effectively before a single byte of the model is ever downloaded1. The recommended public catalog fields are strictly structured to exclude any private internal metadata while maximizing technical utility.

The User-Facing Model Discovery Flow

The ultimate, overarching goal of this highly complex architecture is to render the underlying cryptographic verifications, peer-to-peer streaming mechanics, and deterministic execution proofs entirely invisible to the end-user. This results in an onboarding and execution experience that is vastly safer, faster, and more resilient than traditional centralized download methodologies. The ideal user-facing model discovery flow operates seamlessly across five discrete steps. First, during the exploration and filtering phase, the user accesses the frontend interface via their standard browser. They utilize the dynamic directory filters to select desired artificial intelligence capabilities, sorting by parameter count, specific quantization formats, and the presence of high-tier quality badges12. Second, upon initiating an installation, the browser explicitly does not trigger a standard file download. Instead, it silently fetches the signed JSON manifest and instantaneously verifies the cryptographic signature against the public transparency log, ensuring the artifact's authenticity without user intervention. Third, the teleodynamic planning module reads the manifest's container geometry. It presents the user with a pre-flight resource summary, actively distinguishing between cached storage capacity and active compute contention1. The system strictly and automatically blocks the operation if activating the model would exceed the browser's hard transfer ceilings or concurrent execution limits. Fourth, the peer-to-peer streaming and assembly phase begins. The browser's embedded client queries the local subnet and the broader distributed hash table for the required Content Identifiers. Subtle visual feedback indicates chunk acquisition from the decentralized swarm. As data pieces arrive, they are instantly hashed and verified. The payload is materialized directly and safely into the browser's isolated origin private file system. Finally, the revalidation and execution phase concludes the flow. Once fully assembled, the local runtime performs the strictly mandated header parse and deterministic smoke test2. If the test is mathematically successful, an Import Receipt is silently gossiped back to the network to bolster the model's public metrics, and the model seamlessly enters the active set, ready for immediate, private, and entirely local inference execution.

Works cited

1. Tiny Model Composer \- MiRust, https://mirust.com/composer/
2. Implementation \- MiRust, https://mirust.com/implementation/
3. Secure Tool Manifest and Digital Signing Solution for Verifiable MCP and LLM Pipelines, https://arxiv.org/html/2601.23132v1
4. MiRust: Home, https://mirust.com/
5. Introduction \- Dragonfly, https://d7y.io/docs/
6. Peer-to-Peer acceleration for AI model distribution with Dragonfly | CNCF, https://www.cncf.io/blog/2026/04/06/peer-to-peer-acceleration-for-ai-model-distribution-with-dragonfly/
7. It's time to decentralize model distribution\! Introducing Noema Atlas : r/LocalLLaMA \- Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1ubasxo/its\_time\_to\_decentralize\_model\_distribution/
8. Store immutable AI evaluation records with EvalHub and OCI | Red Hat Developer, https://developers.redhat.com/articles/2026/06/16/store-immutable-ai-evaluation-records-evalhub-oci
9. Content addressing in package managers | Andrew Nesbitt, https://nesbitt.io/2026/07/07/content-addressing-in-package-managers.html
10. The 99% Problem: Why Git Thinks Your Fine-Tuned Model is Brand New | by Khushiyant, https://khushiyant.medium.com/the-99-problem-why-git-thinks-your-fine-tuned-model-is-brand-new-9f8cce727d96
11. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
12. Models \- MiRust, https://mirust.com/models/
13. Signed tool manifests : additive extension for tool-poisoning / "rug pull" defense \#2913, https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2913
14. Secure Container Image Signing with Cosign and OPA | Harness Developer Hub, https://developer.harness.io/docs/continuous-delivery/get-started/tutorials/cloud-native-cicd-pipelines/cosign-opa/
15. Sign Container Images With Cosign – \- Exoscale, https://www.exoscale.com/blog/sign-container-images-cosign/
16. How to Sign a Container with Cosign \- Chainguard Academy, https://edu.chainguard.dev/open-source/sigstore/cosign/how-to-sign-a-container-with-cosign/
17. Verifying Signatures \- Cosign \- Sigstore, https://docs.sigstore.dev/cosign/verifying/verify/
18. OpenCLAW-P2P v6.0: Resilient Multi-Layer Persistence, Live Reference Verification, and Production-Scale Evaluation of Decentralized AI Peer Review \- arXiv, https://arxiv.org/html/2604.19792v1
19. \[2604.19792\] OpenCLAW-P2P v7.0-P2PCLAW: Resilient Multi-Layer Persistence, Live Reference Verification, and Production-Scale Evaluation of Decentralized AI Peer Review v7.0 \-- Mathematical Corrections & Ecosystem Developments Edition \- arXiv, https://arxiv.org/abs/2604.19792
20. OpenCLAW-P2P v6.0: Resilient Multi-Layer Persistence, Live Reference Verification, and Production-Scale Evaluation of Decentralized AI Peer Review \- Hugging Face, https://huggingface.co/papers/2604.19792
21. Documentation \- MiRust, https://mirust.com/docs/
22. Self-Optimizing AI Agents for Real-Time Security Enforcement in Dynamic Broadband Infrastructures, https://ijcat.com/archieve/volume14/issue6/ijcatr14061004.pdf
23. Establishing a New Process for Identify Verification Scoring (and removing troubled ID methods) \- Gitcoin Governance, https://gov.gitcoin.co/t/establishing-a-new-process-for-identify-verification-scoring-and-removing-troubled-id-methods/7506
24. GitHub \- qualixar/slm-mesh: Peer-to-peer communication for AI coding agents. 8 MCP tools, full CLI, Python client. Part of the Qualixar research initiative by Varun Pratap Bhardwaj., https://github.com/qualixar/slm-mesh
25. AI agent discovery: master P2P networks in 2026 \- Pilot Protocol, https://pilotprotocol.network/blog/ai-agent-discovery-process-p2p-networks
26. Peer-to-peer file sharing \- Wikipedia, https://en.wikipedia.org/wiki/Peer-to-peer\_file\_sharing
27. Peer-to-Peer AI Agents: A New Paradigm for Intelligent Collaboration \- DEV Community, https://dev.to/vishalmysore/peer-to-peer-ai-agents-a-new-paradigm-for-intelligent-collaboration-1147
28. Proving and Rewarding Client Diversity to Strengthen Resilience of Blockchain Networks, https://arxiv.org/html/2411.18401v1
29. Proof-of-Execution: Low-Latency Consensus via Speculative Execution | Request PDF \- ResearchGate, https://www.researchgate.net/publication/397385637\_Proof-of-Execution\_Low-Latency\_Consensus\_via\_Speculative\_Execution
30. GitHub \- starkware-bitcoin/raito: Bitcoin ZK client written in Cairo., https://github.com/keep-starknet-strange/raito