WEAVER
Reference>

Documentation

A working reference for WEAVER's architecture, methodology, and trust boundaries. A living document — it expands as Crawlnet integration and contracts move from prototype to reviewed implementation.

01overview

Product overview

WEAVER is a post-quantum security protocol for Robinhood Chain. It continuously gathers and organizes cryptography-related intelligence, connects findings across sources, assesses potential threats, and allows integrated smart contracts to respond through predefined security policies.

Core narrative: Observe → Connect → Assess → Test → Protect → Recover, carried by six modules — LOOM, THREAD, PATTERN, PROBE, WARD, and MEND.

02architecture

System architecture

Crawlnet exposes crawl data, dataset information, and Queen capabilities. WEAVER's ingestion adapter retrieves only permitted data, a normalization layer stores provenance, and Queen-assisted analysis extracts summaries and candidate claims for THREAD.

PATTERN applies defined assessment rules and records uncertainty. High-impact claims require human review or independent technical verification before WARD publishes authenticated threat state on Robinhood Chain. Integrated applications apply their own configured policies; MEND exposes readiness and recovery workflows.

03methodology

Data provenance & threat-status methodology

Every source record carries canonical_url, domain, published/observed/ingested timestamps, source_type, content_hash, crawl_provider, and freshness_status. Every claim records whether it is AI-generated and its verification status.

Threat assessments move through an evidence workflow — New Signal → Under Review → Corroborated → Verified Claim → Actionable — that describes evidence handling, not a universal measure of quantum threat. Source authenticity, claim validity, confidence, and potential impact are always shown separately.

04integration

Smart-contract integration guide

WARD publishes an authenticated threat-state registry on Robinhood Chain. Compatible contracts read getThreatState() and subscribe to ThreatStateUpdated events; WARD never calls into integrated contracts directly.

Integrations must explicitly opt in and define their own policy (pause, delay, additional approval) for each threat-state transition. Updates require signed or threshold-authorized submission, replay protection, and sequencing — never an unverified AI response alone.

05security

Security assumptions & limitations

ECDSA-related threat monitoring is not the same as proving a practical quantum attack exists. Qubit count alone is insufficient to assess practical attack capability, and a challenge solved by a classical method is not evidence of quantum cryptanalysis.

WEAVER can protect only the contracts and workflows that explicitly integrate it — it cannot automatically upgrade every account on Robinhood Chain. Crawled web content is treated as untrusted input; source content must never instruct Queen or the analysis pipeline to bypass system rules.

The threat model (docs/THREAT_MODEL.md in the repository) lists assets, actors, trust boundaries and the residual risk of each mitigation. Contracts have an internal review by the WEAVER team, which is NOT an independent audit.

06oracle

Hybrid oracle: reviewers + PROBE

WARD moves in two ways. Reviewers sign EIP-712 updates with a quorum (a stricter quorum for entering or leaving Actionable). Separately, once the admin binds a ProbeCanary ladder, anyone can call escalateFromProbe() after a canary of 128 bits or more is broken; the canary contract checks k·G = Q itself, so no signature is involved.

A broken canary proves that someone solved an elliptic-curve discrete-log instance of that size. It does not prove how, and it does not prove that 256-bit production keys are at risk. Small canaries are classically solvable on purpose and only calibrate the ladder.

07ark

Ark: post-quantum recovery path

ArkVault (testnet only) holds ETH behind two paths: the depositor's normal wallet, which WARD blocks from Verified upwards, and an ML-DSA-44 (FIPS 204) key generated in the browser. Only keccak256 of that public key is stored until recovery; the key never reaches WEAVER's server.

Recovery is commit-reveal. The ML-DSA signature is verified in the browser and emitted on-chain, but not verified by the contract (there is no precompile), so whoever knows the committed public key can recover. Keep the backup file private.

08exposure

Exposure Map methodology

The Exposure Map samples recent holders of Robinhood Chain stock tokens on mainnet (4663) from public Transfer logs and classifies each address: an EOA with nonce above zero has revealed its public key through a signature; an EOA with nonce zero has only revealed a hash on this chain; EIP-7702 delegated EOAs count as revealed; contracts are listed separately.

It is a sample, not a census, and it cannot see signatures made on other chains. It states who would be affected first if secp256k1 keys could be derived from public keys — it does not say when, or whether, that will happen.

09limitations

Known limitations

WEAVER does not change Robinhood Chain's native ECDSA signatures and does not protect wallets or contracts that have not integrated it. It does not predict dates. Papers, qubit counts and AI summaries are signals, not proof; Queen output is not independently verified.

Contracts are on testnet and not independently audited. WARD security depends on reviewer independence; the PROBE testnet ladder trusts a single key generator; Ark trusts that the committed public key stays secret until recovery. Crawlnet and the public Robinhood RPC have no SLA — when they fail, pages show the error. The full list is docs/KNOWN_LIMITATIONS.md.

10testnet

Testnet guide

Phase 3 deliverables include a WARD contract prototype, an explicit oracle authorization mechanism, threat-state history, an example integration contract, and a testnet-only security policy, tested against stale data, invalid updates, replay attempts, and unauthorized changes.

Exit criteria: a developer can integrate the testnet contract and demonstrate a policy response to a valid, authorized state update — before any mainnet claim is made.

11recovery

Incident response & recovery

MEND helps users and compatible applications register recovery keys, configure recovery policy, and simulate recovery on testnet before an emergency. Registration alone never guarantees recovery.

The guardian can only pause WARD; the admin (a Safe on mainnet) unpauses and rotates reviewers. Stale WARD state makes guarded calls revert, so integrators fail closed. Playbooks for compromised reviewer keys, forged updates, canary breaks, stale state and contract bugs are in docs/INCIDENT_RESPONSE.md.