Opened 05-06-2026 by 0xFearless-1, last activity 4mo ago
ccpedia is Canton's live knowledge infrastructure: 50,000+ records from 15 sources, 37,000+ RAG chunks, and 22 MCP tools already running in production. Phase 2 expands to 60 tools across 17 sources, open-sources the infrastructure under Apache 2.0, and gates final payment on verified adoption by independent Canton teams.
/proposals/2 automated messages from bots hidden. Show bot messages
Showing 1 to 1 of 1, oldest first.
CC @Andrew-Pohl @LimKianAn @Denend @nycnewman @mziolekda @monsieurleberre @hrischuk-da @paulbrauner-da @v9n
Author: Unity Nodes Status: Submitted Created: 2026-06-04 Label: daml-tooling Champion: need Champion
ccpedia (ccpedia.xyz) is Canton's knowledge infrastructure: a live, unified corpus of 50,000+ records from 15 sources, 37,000+ RAG chunks, and 22 MCP tools already running in production (record counts independently verifiable at ccpedia.xyz/api/v1/sources). This proposal funds Phase 2: expanding to 60 MCP tools across 17 data sources, including ten cross-source synthesis tools that are only possible because of ccpedia's unique unified corpus. By month 6, ccpedia is open-sourced under Apache 2.0, expanded to 60 tools across 17 sources, and in verified active use by independent Canton teams.
Canton developers lack a unified, always-current knowledge layer. Finding answers requires searching docs, forum posts, GitHub issues, CIPs, proposals, and videos separately, often returning contradictory or outdated results. Without a unified solution, AI coding assistants (Claude, Cursor, Windsurf) remain blind to Canton's living ecosystem: no single MCP-accessible layer synthesizes all sources into one coherent whole.
ccpedia solves this today: a single MCP server aggregating, syncing, and semantically searching 15 Canton knowledge sources in production. Phase 2 expands the existing 22 live tools to 60 tools across 17 sources, adding cross-source synthesis capabilities that are fundamentally impossible without ccpedia's unified corpus.
Single objective: Expand ccpedia from a working tool to the canonical Canton developer knowledge infrastructure, open-sourced under Apache 2.0, with verified external adoption.
The work is structured across three milestones, each building on the previous.
M1: Open-Source Release of Live Production Infrastructure (upon grant approval)
M1 releases live production infrastructure as a Canton ecosystem public good under Apache 2.0:
github.com/UnityNodes/ccpedia (Apache 2.0): MCP server, all tools, database schema, sync pipelines, source connectorssearch and get_video toolsM2: Phase 2 Technical Delivery (Month 3)
38 new MCP tools total: 22 per-source, 10 synthesis, and 6 new-source across 2 new data sources.
22 new per-source MCP tools targeting HIGH/MEDIUM developer demand, including:
diagnose_error(error_text): searches 4,100+ forum topics and 3,100+ GitHub issues for matching errors and community workaroundsget_breaking_changes(from_sdk, to_sdk): what breaks when upgrading between SDK versions (440+ versions indexed)get_sdk_changelog(version): detailed per-version changelogsearch_community(query): semantic search across forum, mailing list, blog, and discussions in one callsearch_github_issues(query): full-text search across 3,100+ GitHub issues from 15+ repossearch_talks(query): semantic search across 45 YouTube videos with automated transcriptsfind_known_issues(description), get_faq(topic), find_cip_for_feature(feature), get_cip_implementation_status(cip_number), get_latest_release(package), search_release_notes(feature), find_security_patches(), get_npm_packages(query), find_similar_projects(description), search_mailing_list(query), find_maintainer_guidance(topic), get_issue_status(issue_number), find_code_examples(topic), get_funding_landscape(category), get_proposal_milestones(id), get_ecosystem_gaps()10 cross-source synthesis tools requiring ccpedia's unified corpus (no individual source supports these):
detect_builder_overlap(idea): identifies who is building something similar across 410+ proposals and 180+ ecosystem projects; manual research takes 3+ hours, this tool takes 10 secondsproposal_success_predictor(draft_text): heuristic scoring against funded vs. unfunded attributes of all 410+ historical proposals; the manual cross-proposal analysis that this tool will automate was itself applied when writing this proposalfull_context(topic): single query across docs, forum, proposals, CIPs, blog, and GitHub simultaneouslycommunity_consensus(topic): synthesizes what the Canton community actually believes, not just the last forum replyfind_expert(topic): algorithmic expert ranking by forum reputation, GitHub contributions, and proposal authorshipdetect_drift(topic): finds contradictions between docs, forum, and GitHub (for example, docs say one thing, forum says another, and explains why)learning_path(goal): structured onboarding path from whitepaper through docs, forum, proposals, and videosoutdated_guidance_detector(query): flags stale 2023 advice and surfaces the current equivalentecosystem_dependency_graph(topic): maps 180+ projects to SDK versions, repos, and proposalsfind_collaboration_opportunities(project): surfaces projects with complementary capabilities2 new live data sources:
list_featured_apps, get_app_metrics, find_apps_by_patternsv-cal.canton.foundation/schedule.ics, auto-updates every 12 hours) with get_sv_schedule(environment), get_upcoming_operations(days), get_recent_deployments()External code review and penetration test of the ccpedia MCP server, a read-only HTTP API/RAG service. Threat model scope: prompt injection protection, rate limiting, data leakage, query sanitization. This is not a smart contract audit (ccpedia holds no keys, executes no contracts, manages no funds). Public docs at ccpedia.xyz/docs, developer onboarding guide for Claude/Cursor/Windsurf, 20 curated Canton design patterns with code examples.
M3: Ecosystem Adoption (90-day window after M2 acceptance)
Verified adoption of ccpedia by independent Canton teams. Unity Nodes runs an active promotion campaign (Discord, Slack, Forum, X) and direct outreach to Canton builder teams. Gate: at least 3 independent Canton teams publicly document active use of ccpedia via Canton forum post, GitHub issue/PR, published case study, or written statement shared with the committee.
Technical stack: SQLite with sqlite-vec for RAG (vector similarity search chosen for zero-dependency local vector search without an external managed service), Next.js API layer, MCP protocol for tool exposure, incremental sync pipelines (5 min / 15 min / 6 hr / daily per source).
No backward compatibility impact. ccpedia is a read-only service layer that queries existing Canton data sources (forum, GitHub, docs, CIPs) without modifying them. The MCP server is purely additive infrastructure. The existing 22 tools remain unchanged; Phase 2 adds tools alongside them.
github.com/UnityNodes/ccpediasearch and get_video toolsccpedia.xyz/docs live with tool reference and integration guides for Claude / Cursor / Windsurfccpedia.xyz/docsThe Tech & Ops Committee will evaluate completion based on:
The acceptance criteria is to be based on value to the ecosystem and not delivery of an artifact. M1 delivers the OSS release of already-running infrastructure. M2 delivers the full Phase 2 technical scope. M3 demonstrates that ccpedia is genuinely used by independent Canton teams.
M1 gate: Open-source repository publicly accessible at github.com/UnityNodes/ccpedia under Apache 2.0; Phase 1 tools documented
M2 gate: 38 new tools operational (22 per-source, 10 synthesis, 6 new-source for Featured Apps/SV Calendar); 2 new data sources syncing; code review report public; ccpedia.xyz/docs live
M3 gate: At least 3 independent Canton teams publicly document active use of ccpedia via forum post, GitHub issue/PR, published case study, or written statement shared with the committee
Total Funding Request: 770,000 CC guaranteed + up to 330,000 CC adoption-based = maximum 1,100,000 CC
| Milestone | CC | When | Basis |
|---|---|---|---|
| M1: OSS Release of Live Infrastructure | 330,000 | Upon grant approval | Live production infrastructure published as Apache 2.0 public good |
| M2: Phase 2 Technical Delivery | 440,000 | Month 3, upon committee acceptance | Delivery of 38 new tools, 2 sources, code review, docs |
| M3: Ecosystem Adoption | 330,000 | 90-day window after M2 | At least 3 independent Canton teams publicly document active use |
| Maximum total | 1,100,000 | 30% OSS release / 40% technical / 30% adoption |
Upon release of each milestone, Unity Nodes will collaborate with the Foundation on:
proposal_success_predictor will automate, was applied when writing this proposal; published at ccpedia.xyz/docs after M2 deliveryCanton developers waste dozens of hours monthly solving the same problems repeatedly: "What broke in this SDK upgrade?" "Who is already building this?" "What does the community actually think about X?" Each answer requires searching 4-6 separate sources, reconciling contradictions, and hoping the answer is not in a 2023 forum post that references a deprecated API.
ccpedia already solves this for the 15 sources it covers today. Phase 2 extends the coverage and adds synthesis: the ability to answer questions that require reasoning across the entire corpus simultaneously.
Ecosystem reach: Canton developers using AI coding assistants (Claude, Cursor, Windsurf); grant proposal teams doing due-diligence on existing work; new developers needing a structured onboarding path; grant committee members verifying overlap between proposals.
Proof of work before asking for funding: 50,000+ live records from 15 sources, 37,000+ RAG chunks, 22 MCP tools in production, all sustained by Unity Nodes without a grant. Phase 2 is not a promise; it is an extension of something already running.
Why ccpedia rather than extending an existing tool? No existing Canton tool provides unified semantic search across multiple live sources with MCP exposure. ccpedia extends what exists without replacing anything.
Why these 38 new tools specifically? The 22 new per-source tools (M2) were selected by mapping which Canton developer questions take the most time today: error diagnosis, SDK upgrade planning, and community consensus queries. The 10 synthesis tools (M2) were selected by identifying which queries require the entire corpus simultaneously (cross-source synthesis is impossible per-source). The 6 new-source tools for Featured Apps and SV Operations Calendar (M2) were selected based on confirmed public availability and developer demand for live dApp metrics and network operations scheduling. Additional tool candidates are deferred to a subsequent grant based on real-world Phase 2 adoption data.
Why code review and not a full security audit (M2)? ccpedia is a read-only HTTP API and RAG search service. It holds no keys, executes no smart contracts, and manages no user funds. The threat model is prompt injection, data leakage, and query sanitization, which is appropriate for a code review and penetration test scope. A full smart contract audit would be disproportionate to the actual risk surface and would consume budget better spent on adoption-driving productization.
Why Apache 2.0 open-source in M1, and why is M1 paid upon grant approval? Unity Nodes invested significant time and resources building Phase 1 (22 tools, 15 live data sources, production infrastructure) without prior grant funding. M1 funds the OSS release of infrastructure already running in Canton, documenting and licensing it for public reuse, converting this investment into a permanent public Canton ecosystem asset. The entire Canton community gains the ability to verify, fork, and self-host ccpedia independently of Unity Nodes. The software is open-source under Apache 2.0; the managed data service (indexed corpus, live sync pipelines, and RAG layer) remains operated by Unity Nodes. The repository will be published at github.com/UnityNodes/ccpedia.
Why this funding amount? The 1,100,000 CC maximum reflects three distinct scopes of work: M1 (330,000 CC) funds the OSS release of Phase 1 infrastructure (22 tools, 15 sources, production sync pipelines) as a Canton ecosystem public good; M2 (440,000 CC) funds 38 new tools, 2 new data sources, external code review, and public documentation over 3 months of active development; M3 (330,000 CC) is contingent on verified external adoption, aligning ccpedia's financial upside with the ecosystem outcome that matters. The structure is 30% OSS release / 40% technical delivery / 30% adoption-based: the adoption tranche is only earned if independent Canton teams publicly document active use.
Why Apache 2.0 specifically? Apache 2.0 includes a patent grant clause that protects users and contributors from patent litigation. It matches the license of upstream Canton dependencies (canton, daml, splice are all Apache 2.0), eliminating license compatibility friction for downstream integrators.
Why a performance-based M3? Unity Nodes can demonstrate that ccpedia tools work. Only the Canton developer community can demonstrate that ccpedia tools are actually used. The M3 structure (verified external teams with publicly documented use) aligns ccpedia's financial upside with the outcome that matters to the ecosystem.
Rebuilt from the recorded board moves (complete history). get_dev_fund_lifecycle(number) gives the same in the MCP.