[Grant Proposal] Ginie — Canton-Native dApp Generator + Ginie-1 Open-Weight LLM · $175,000 / 1,155,000 CC
grants-discuss3 messagesstarted 15-04-2026
Also mentions:CIP-0103
- Hi all,Vijendra here, co-founder at BlockX AI. Posting to grants-discuss to share our Dev Fund proposal for early feedback from the technical community and Tokenomics participants before formal submission.---What we're buildingGinie is a full-stack dApp generator on Canton. A product manager, compliance officer, or student describes a financial contract in plain English — Ginie compiles it to Daml, runs an automated pre-deployment security audit, deploys it to GinieNet (our public Canton sandbox), and returns a CantonScan link per Contract ID. The full pipeline — prompt → compile → audit → deploy → verify → explorer — runs in under 90 seconds. No Daml knowledge required.We have a working pipeline live today. The proposal covers four milestones across six months:· M1 ($25,000 / 165,000 CC): Production MVP — 20 institutional contract templates (repo, bond, DvP, custody, IOU, AML, multi-party), audit layer v1, Python SDK on PyPI, Docker self-hosting, CI/CD benchmark suite· M2 ($50,000 / 330,000 CC): Full-stack dApp builder — IDL Extractor Agent, Frontend Agent, MCP server integration, CIP-0103 wallet, on-ledger audit certificate, GitHub Action for one-command deployment· M3 ($65,000 / 429,000 CC): IDE extensions (VS Code / Cursor / JetBrains), policy engine, multi-workspace org management, RAG expansion to 50 institutional patterns, RLCF training data collection· M4 ($35,000 / 231,000 CC): Ginie-1 full training — SFT 3-epoch + 5-round RLCF on compiler feedback corpus, ginie-eval public benchmark, SDK v2.0, full Apache 2.0 open-source releaseTotal: $175,000 / 1,155,000 CC across 6 months.---Ginie-1 — the longer playGinie-1 is a Canton-native open-weight LLM fine-tuned on a Daml corpus with RLCF — real Canton compiler feedback as the reward signal, targeting ≥95% first-pass compile rate on the ginie-eval benchmark.The model runs fully air-gapped: GGUF/ONNX CPU inference, Docker image, Apache 2.0 weights published to HuggingFace. This matters for institutional adoption specifically: compliance teams at banks and asset managers cannot route financial contract specifications through an external API. Ginie-1 removes that dependency permanently. Any Canton ecosystem project building AI-native tooling can self-host Ginie-1 on their own infrastructure without paying a third-party provider — making it shared AI infrastructure for the ecosystem, not just the backend for Ginie's own product.Ginie-1 is not a code generation model. It is Canton's first open-weight, domain-native AI layer build for every next project being launched on Canton.---Where we'd value feedbackWe would particularly welcome community input on:1. Technical approach — does the RLCF-on-compiler-feedback training design make sense to those with Daml internals experience? Any failure modes we haven't accounted for in the audit layer?2. The ginie-eval benchmark — we're designing 50 standardised prompts across 5 evaluation criteria (compile rate, ledger correctness, audit pass rate, pattern fidelity, RLCF improvement) as a public Apache 2.0 benchmark. Does this cover what the ecosystem actually needs to evaluate Canton AI tooling?3. Milestone gates — are the delivery commitments specific enough to be verifiable? We want the fund to have clear pass/fail criteria at each gate.4. Institutional template priority — which of the 20 initial contract patterns would the community prioritise, and are there gaps in coverage?Full proposal with complete budget breakdown, salary schedule, GPU compute justification, and milestone line items is available on request — or I can post it directly to this thread if that's the preferred format.Looking forward to the community's input.VijendraBlockX AI
- toggle quoted message Show quoted textHi Vijendra. It seems LLMs and code generation is a favorite topic on the grants list. This is one of many. If you want feedback then I would suggest:
- Posting the entire proposal.
- Highlight (as in make it easy to find and understand):
- The strengths and weaknesses of this approach, contrasted with other proposals or approaches.
- How large and complex of a dApp is expected to be built. This helps to understand the value to the ecosystem.
- How the code can be maintained
- How it is compatible with the Smart Contract Upgrade feature (see here and here). This is mandatory since generating the fist version is easy but enhancing it in a maintainable way (on chain) is not so easy.
- The Canton Network community is quite active in generating Daml models and some are looking at OSS libraries. The Daml language also evolves. So, the proposal should include an extensibility option to:
- Incorporate external sources (e.g., Git OSS repo) that can be used for training.
- Incorporate internal sources that can be used for training.
- Refresh the LLM model easily.
On Wed, Apr 15, 2026 at 4:40 PM vj via lists.sync.global <vj=blockxai.xyz@...> wrote:Hi all,Vijendra here, co-founder at BlockX AI. Posting to grants-discuss to share our Dev Fund proposal for early feedback from the technical community and Tokenomics participants before formal submission.---What we're buildingGinie is a full-stack dApp generator on Canton. A product manager, compliance officer, or student describes a financial contract in plain English — Ginie compiles it to Daml, runs an automated pre-deployment security audit, deploys it to GinieNet (our public Canton sandbox), and returns a CantonScan link per Contract ID. The full pipeline — prompt → compile → audit → deploy → verify → explorer — runs in under 90 seconds. No Daml knowledge required.We have a working pipeline live today. The proposal covers four milestones across six months:· M1 ($25,000 / 165,000 CC): Production MVP — 20 institutional contract templates (repo, bond, DvP, custody, IOU, AML, multi-party), audit layer v1, Python SDK on PyPI, Docker self-hosting, CI/CD benchmark suite· M2 ($50,000 / 330,000 CC): Full-stack dApp builder — IDL Extractor Agent, Frontend Agent, MCP server integration, CIP-0103 wallet, on-ledger audit certificate, GitHub Action for one-command deployment· M3 ($65,000 / 429,000 CC): IDE extensions (VS Code / Cursor / JetBrains), policy engine, multi-workspace org management, RAG expansion to 50 institutional patterns, RLCF training data collection· M4 ($35,000 / 231,000 CC): Ginie-1 full training — SFT 3-epoch + 5-round RLCF on compiler feedback corpus, ginie-eval public benchmark, SDK v2.0, full Apache 2.0 open-source releaseTotal: $175,000 / 1,155,000 CC across 6 months.---Ginie-1 — the longer playGinie-1 is a Canton-native open-weight LLM fine-tuned on a Daml corpus with RLCF — real Canton compiler feedback as the reward signal, targeting ≥95% first-pass compile rate on the ginie-eval benchmark.The model runs fully air-gapped: GGUF/ONNX CPU inference, Docker image, Apache 2.0 weights published to HuggingFace. This matters for institutional adoption specifically: compliance teams at banks and asset managers cannot route financial contract specifications through an external API. Ginie-1 removes that dependency permanently. Any Canton ecosystem project building AI-native tooling can self-host Ginie-1 on their own infrastructure without paying a third-party provider — making it shared AI infrastructure for the ecosystem, not just the backend for Ginie's own product.Ginie-1 is not a code generation model. It is Canton's first open-weight, domain-native AI layer build for every next project being launched on Canton.---Where we'd value feedbackWe would particularly welcome community input on:1. Technical approach — does the RLCF-on-compiler-feedback training design make sense to those with Daml internals experience? Any failure modes we haven't accounted for in the audit layer?2. The ginie-eval benchmark — we're designing 50 standardised prompts across 5 evaluation criteria (compile rate, ledger correctness, audit pass rate, pattern fidelity, RLCF improvement) as a public Apache 2.0 benchmark. Does this cover what the ecosystem actually needs to evaluate Canton AI tooling?3. Milestone gates — are the delivery commitments specific enough to be verifiable? We want the fund to have clear pass/fail criteria at each gate.4. Institutional template priority — which of the 20 initial contract patterns would the community prioritise, and are there gaps in coverage?Full proposal with complete budget breakdown, salary schedule, GPU compute justification, and milestone line items is available on request — or I can post it directly to this thread if that's the preferred format.Looking forward to the community's input.VijendraBlockX AI--
Curtis Hrischuk curtis.hrischuk@... Principal Technical
Product ManagerCreators of Canton Network 
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Posting the entire proposal.
- Hi Curtis,Thank you — fair point on the volume. Addressing your points directly.Proposal: https://github.com/BlockX-AI/canton-dev-fund/blob/feat/ginie-blockxai/proposals/ginie.md
Budget breakdown: https://docs.google.com/document/d/1yjZeKF8dhZvW-htgXwqndcJfwdfSkhMM2ziOwOymReMOn SCU compatibility — you are right to call this mandatory and it is a genuine gap in our current pipeline. We are adding three explicit M2 acceptance criteria and updating the proposal document to reflect them. First, Gate 5 in the audit layer: before any DAR upload, the generated module is checked for additive-only field structure and correct @daml.upgrade annotation usage per docs.daml.com; a failure is rejected with a line-specific explanation and a suggested fix, the same format as Gates 1–4. Second, SCU-aware generation at prompt time by default — optional fields for extensibility, no breaking changes in the initial template shape. Third, UPGRADE_NOTES.md in every project export bundle, covering which fields are SCU-safe to extend and the migration path for already-deployed contracts if a future SDK version introduces relevant changes. If Digital Asset has recommended annotation conventions or upgrade patterns that generated contracts should follow by default, we would rather know now than discover the gap at M2 review.On scope — M1 targets 50–200 line contracts based on our current 7-pattern corpus, where generated output averages 80–150 lines. The 20 M1 templates cover bilateral agreements and 2–3 party workflows: repo, bond, DvP, custody, IOU, AML, multi-party. Complexity ceiling in M1 is up to 3 parties with linear choice structure; multi-party branching workflows are in scope from M2 onward. Ginie does not attempt to generate production mission-critical systems. The output is a git-ready project — Daml source, daml.yaml, audit report, and a live Contract ID on GinieNet — that a developer takes full ownership of from there, with no Ginie dependency in the maintenance path.On differentiation — to our knowledge, other approaches on this list generate code suggestions that a developer still needs to compile, test, and deploy. Ginie generates a deployed Contract ID. The full pipeline — dpm build, DAR upload, Canton Ledger API deployment, CantonScan verification — runs end-to-end on every attempt. The target user is also different: compliance officers, product managers, and students who will never write Daml and currently have no path to a deployed contract without developer support. Weaknesses we are not deflecting: the RAG corpus is 7 patterns today and generation quality at scale requires 50, which M1 and M3 address directly; SCU compatibility as above; and Ginie-1 at 7B will handle certain complex multi-party contracts poorly — we will publish those limitations explicitly in the ginie-eval benchmark report.On extensibility — the RAG ingestion pipeline accepts any git repository URL as a pattern source, so any OSS Daml library or community-maintained pattern set can be incorporated without changes to the pipeline. Enterprise workspace users in the M3 tier can add private Daml patterns scoped to their workspace that never leave their infrastructure. The full fine-tuning pipeline — Axolotl configuration, RLCF reward design, training scripts — is published Apache 2.0 alongside the Ginie-1 weights in the ginie-training repository, and anyone can run a refresh via the published GitHub Actions workflow without depending on us. For breaking Daml language changes, the training corpus is versioned: a major version increment triggers a corpus resplit and a full fine-tuning refresh cycle via the same published pipeline, which the community can run independently.Happy to go deeper on the audit layer design, the RLCF reward function, or the SCU gate specification over a quick call demonstrating everything in our plan and have been build so far. Your suggestion would be valuable to shape the ai layer of the canton ecosystem.Vijendra
BlockX AI
https://canton.ginie.xyz
