Canton Grants Atlas

Canton Development Fund grant data is scattered across GitHub, GitVote, Slack, and a mailing list. The Canton Grants Atlas pulls it into one read-only portal.

Following the Canton Development Fund shouldn't be this hard

The Canton Development Fund routes 5% of Canton Coin emissions into grants (set in CIP-0082, live since 1 October 2025, with governance defined by CIP-0100 since 14 January 2026). That sounds like a clean, trackable pipe. In practice, following a single proposal means opening six tabs: the GitHub project board for status, the PR comment threads on the canton-dev-fund repo for the real discussion, GitVote for the votes, a SIG directory for who owns what, a public mailing list for announcements, and Slack for the back-and-forth. A grant champion or a Canton Coin holder who just wants to know what's funded, what's stuck, and where the money is going ends up reverse-engineering all of it. Thirty seconds of reading turns into an afternoon of cross-referencing.

The Canton Grants Atlas, a functional prototype from BootNode, collapses that scatter into one read-only portal. Instead of organizing the data the way the tooling happens to store it, the Atlas organizes it around the questions people actually ask. You open it, you read, you get your answer, and you move on. The source material doesn't change; the work of stitching it together just stops landing on you.

Read-only by design, with GitHub as the single source of truth

The Atlas never writes back. There is no voting, no commenting, no proposal state changes happening inside the app. Every real action still flows through GitHub, where GitVote handles the votes and contributors comment on proposals directly. The portal reads that board and renders it. That is the whole contract: read, display, never mutate. The upstream canton-foundation grants board stays canonical, and nothing in the Atlas can issue a write against it. Think of it as observability, not a parallel workflow: the fund keeps running where it already runs, and the Atlas just makes it legible.

That choice matters most for trust. Because the Atlas only ever reads, its view cannot drift away from the record or quietly override it. If something looks off, the source of truth is one click upstream on GitHub. When the projection and the upstream board disagree, the Atlas surfaces the conflict rather than papering over it. You are never asked to trust a number the app invented, because the app does not invent numbers. It reflects what GitHub already says.

How the fund actually works, in plain language

Two CIPs hold the whole thing up. CIP-0082 (active since 2025-10-01) routes 5% of Canton Coin emissions into the Canton Development Fund, so the money exists by protocol rule rather than by anyone's discretion. CIP-0100 (active 2026-01-14) covers the governance side: the Tech & Ops Committee makes the calls, the Voting Group signs off on final approval, budgeting runs quarterly, payouts happen against milestones in Canton Coin, and the whole thing is held accountable through public quarterly reports and an annual audit.

The path a grant takes is easier to follow once you see it as four steps. First, Submit: an applicant opens a GitHub pull request against the canton-dev-fund repo, laying out scope, milestones, and the funding ask. Next, SIG Review, where a Special Interest Group reads the proposal. External applicants do not go in alone here, they need an allowlisted Champion org to co-sign and stand in for them. Then comes the GitVote ballot, where ready proposals are put to a vote. Finally, Milestone Disbursement: approved grants get paid out one milestone at a time, in Canton Coin.

The vote itself is simple: it stays open for 21 days and passes at 51%. Both numbers come from the fund's own .gitvote.yml configuration, not from any public CIP, so treat them as how this fund set itself up rather than a protocol-wide rule that holds everywhere.

Dashboards built around personas, not data tables

Most grant trackers hand you a spreadsheet and wish you luck. The Atlas starts from a different question: who is looking, and what do they actually need to see? A grant Champion, a SIG reviewer, and a Canton Coin holder all care about different slices of the same data, so the dashboards are shaped around them.

For tracking proposals through their lifecycle, three views do the heavy lifting. The Pipeline Funnel shows where proposals sit and how long they have lingered at each stage. The SIG Coverage Heatmap maps all 17 Special Interest Groups against proposal activity, so you can spot which groups are well served and which are quiet. The Champion Load Heatmap puts allowlisted orgs against lifecycle state, flagging when a Champion is carrying more than their share.

Then there are the views that follow the money. Budget Status reports the available Canton Coin pool against what has flowed in, been approved, or is still pending. Burn Rate and Runway project how long that pool lasts at the current pace. Per-Proposal Budget Impact shows what fraction of the pool each in-flight ask would eat, and In-Flight Concentration tells you how much gets committed if every ready-to-vote proposal passes. Heads up, though: the budget views currently run in a degraded, source-pending mode until the emissions-inflow feed is wired in, so read those figures as illustrative rather than authoritative.

For people new to all of this, a public Funded board lists what has already shipped, and a plain-language "How the Fund Works" explainer gives newcomers and Canton Coin holders a way in without needing the full governance backstory.

The domain vocabulary the Atlas speaks

Everything in the Canton Development Fund is denominated in Canton Coin (CC). Grants are sized in CC, paid in CC, and judged against it. The fund does not treat a shipped artifact as the win. It treats adoption as the win, meaning real usage, live integrations, and deployments that put CC to work. A project that ships a tidy repo but moves no one counts for less than one that drives actual activity, and the Atlas surfaces that distinction instead of hiding it behind a checklist.

Review is organized into 17 Special Interest Groups, each owning a domain so proposals land in front of people who know the territory. Submitting is not open to everyone directly. External applicants who cannot apply on their own go through allowlisted Champion orgs, which co-sign and sponsor them into the process. The Atlas uses these exact terms, SIGs and Champions, because they are the fund's own language and inventing synonyms would only add confusion.

Try it, and tell us what's missing

The Canton Grants Atlas works today: you can open it and pull real grant data into one view right now. But it is an early prototype, not a finished product. BootNode built it to start a conversation, not to hand down a verdict on how the Canton Development Fund should be observed. Treat everything in it as a draft you are allowed to argue with.

Here is what would help most. Open the dashboards and run them against questions you actually carry around. If you champion a grant, check whether you can trace its status the way you would explain it to someone else. If you hold Canton Coin, see if the Atlas tells you where 5% of emissions go without a detour back to GitHub, GitVote, and Slack. Then tell us where the read-only model earns its keep, where it gets in your way, and what is missing. Send it to BootNode directly; your feedback is what decides which gaps close first.

Take it for a spin: Canton Grants Atlas.