Cyan Eclipse Crawlway

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism — a crawl receipt binds crawler identity (Herald-card-shaped id), license-terms hash, and content fingerprint in one recomputable record (SPEC §3): licensing and proof-of-license are the same artifact. publish_terms seals the terms record (terms_hash + terms_record_hash); record_crawl's binding_hash covers crawler_id, publisher_id, terms_version, terms_hash, content_fingerprint, url, and ts, and receipts hash-chain per publisher (receipt_hash = sha256(prev + binding), genesis = 64 zeroes, chains never cross publishers). Bench: binding, terms, and chain hashes all match the bench's independent recomputation from the SPEC §3 formulas, and tampering any bound element in an object copy or a store copy verifies INVALID for the tampered receipt and its chain successor.
• Ledger-membership verification + terms-seal enforcement (v0.1.1 fixes for bench defects D1/D2): VALID is returned only for a receipt present in the sealed ledger passing the full per-publisher chain walk — a standalone object resealed with the public formula (forged crawler, fingerprint of content never crawled, or an identity swap of a genuine receipt) verifies INVALID with chain_valid: false (re-bench C1: 10/10). record_crawl and verify_receipt recompute the terms-record seal before trusting stored terms: a seal-broken terms record refuses minting (TERMS_SEAL_INVALID) and drives prior receipts INVALID with terms_status: seal_invalid, per-record (re-bench C2: 12/12).
• Sealed-only meter + consistent reports + strict structure (v0.1.1 fixes for bench defects D3/D4/D5): meter_report derives every count from sealed receipt records only — garbage, unparseable, or unsealed appended lines are excluded from all totals and surfaced as rejected_lines (re-bench C3: appended garbage + unsealed lines leave totals and breakdowns unchanged, rejected_lines: 2). There is no separate counter and no tool-surface mutation path (fake set_meter/increment_meter/mint tools return NO_SUCH_TOOL). Filtered reports reconcile with themselves: total_receipts equals each breakdown sum under every filter combination (re-bench D4: 9/9). A supplied receipt carrying any key outside the specced receipt schema, or a tampered position, verifies INVALID (re-bench D5: 6/6).
• Revocation is a status, not a rewrite: revoke_terms appends a revocation record; receipts under that terms version then verify TERMS_REVOKED with binding_valid: true and chain_valid: true — a revoked receipt remains provably a receipt that was issued, under terms no longer in force. record_crawl under revoked terms returns a TERMS_REVOKED refusal and mints nothing (ledger count and meter provably unchanged); re-revoke returns already_revoked: true; unknown terms return TERMS_NOT_FOUND. Duplicate {publisher, version} terms publication is refused (TERMS_VERSION_EXISTS) and prior receipts never verify against substituted terms.
• Honest scope + disclosed LOW: LOCAL/fixture — RECEIPT MECHANICS ONLY. No crawling, no fetching, no network calls of any kind, no marketplace; callers supply crawler identity refs, publisher ids, license terms, and content fingerprints (SHA-256 hashes) — never content itself; Herald-card ids are shape-validated only, never resolved or authenticated. Python 3 standard library only; MCP over stdio; exactly 5 tools (unknown names return NO_SUCH_TOOL). The meter is recorded at $0.01/call with charged: false — no payment, checkout, wallet, or charging code exists in this package. Known LOW D6 (non-blocking, fix-before-live, disclosed on the bench record): a corrupt non-JSON store line is tolerated by meter_report (counted in rejected_lines) but crashes the non-meter tools — the server exits loudly instead of answering; no false VALID and no inflated meter results.

Tools

Problems it addresses

• I publish content that agent crawlers access — I need a sealed license receipt per crawl that proves who crawled what, under which license terms, as one recomputable artifact
• If my license terms change or are revoked, receipts under the old version must flip to TERMS_REVOKED without losing proof they were issued, and no new receipts may mint under revoked or substituted terms
• My usage meter must derive only from sealed receipts — never from a counter that can drift, and never counting garbage or unsealed records that were appended to the store

Not tested

• Crawling, fetching, or any network access — not in v0.1.1 by design (SPEC §2 scope): receipt mechanics only; callers supply fingerprints (hashes), never content
• Hosted or remote serving — v0.1.1 is local stdio only, operating on caller-supplied fixture terms, identities, and fingerprints; known LOW D6 (a corrupt non-JSON store line crashes non-meter tools, failing loud) is fix-before-live for any hosted/long-running deployment
• Payment, checkout, or charging — none exists in v0.1.1 by design: meter_report records the meter at $0.01/call with charged: false; the price is commercial metadata (PC-1 pattern) and no payment or checkout code is in the server
• Identity resolution or authentication of Herald cards — v0.1.1 validates the herald:<kind>:<id> shape only; no card is resolved or authenticated
• A marketplace or listing function — none exists in v0.1.1; receipts are sealed, verified, metered, and revoked locally only