Skip to main content

Developer Experience Working Group (Q2: Apr–Jun 2026)

Purpose & Why​

The Developer Experience (DevEx) Working Group continues to support and empower developers and contributors in the Cardano ecosystem. For Q2 (Apr–Jun 2026), our focus shifts towards application development, utilizing APIs and SDKs, and understanding advanced development architectures.

Session Plan (Sessions 14+)​

SessionTitleFocusFormat
14Repository Walkthrough: Offchain and SDK buildingDeep dive into offchain architectureWorkshop
15dApp Architecture: From Wallet to BackendModular breakdown of full-stack dApp flowWorkshop
16UI ↔ Smart Contracts: Wallets, Tx Building, and SubmissionEnd-to-end dApp interaction patterns + architecture trade-offsWorkshop
17Default Developer Environment for CardanoWorking-group debate on what we recommend by default to new buildersDiscussion
18Using AI in Your Cardano Dev WorkflowSystematic approach to AI-assisted Cardano developmentWorkshop
19Building a Production-Grade MCP Server for CardanoAI tooling for Cardano — UTxOs, governance, smart contracts via MCPDemo + Discussion
20One API Call to Understand CardanoBlockfrost JSON: UTxOs, submit, confirm on PreviewDemo + walkthrough
21Building a Production Cardano SDK: From Validators to dAppEnd-to-end: Aiken validators, Effect-based SDK, demo dApp (DCU Toolkit case study)Workshop

Session Details​

Session 14: Repository Walkthrough: Offchain and SDK building​

  • Objective: Provide architectural clarity on building offchain code and using SDKs
  • Key Topics:
    • Production smart contract offchain repository walkthrough
    • Building your first offchain application logic
    • Connecting SDKs to the blockchain for transaction building
  • Deliverable: Smart Contract Offchain Overview

Session 15: dApp Architecture: From Wallet to Backend​

  • Objective: Explain the 4-layer architecture for Cardano dApps
  • Key Topics:
    • Frontend, Wallet, Backend, and Blockchain responsibilities
    • Failure handling in distributed systems
    • Polling vs. Webhooks for payment verification
  • Deliverable: dApp Architecture Session Notes

Session 16: UI ↔ Smart Contracts: Wallets, Tx Building, and Submission​

  • Objective: Teach the practical ways a UI app interacts with Cardano validators (Aiken/Plutus) using modern wallet + SDK flows, with clear trade-offs and diagrams.
  • Key Topics:
    • CIP-30 wallet connector fundamentals (connect, UTxOs, sign, submit)
    • Transaction lifecycle (build → evaluate → sign → submit → confirm)
    • 2–3 recommended architectures (client-only vs hybrid vs server-custody)
    • Indexers and data providers (Kupo/Ogmios, Blockfrost/Koios/Maestro)
  • Deliverable: Best-practice integration guide + diagrams

Session 17: Default Developer Environment for Cardano​

  • Objective: Agree on a default developer environment to recommend to newcomers, and the graduation path from "first ten minutes" to mainnet.
  • Key Topics:
    • Local devnets (Yaci DevKit, cardano-node devnet) vs public testnets (Preview / PreProd)
    • Hosted providers (Blockfrost / Maestro / Koios) vs self-hosted nodes (cardano-node + Ogmios + Kupo)
    • One-click / Dockerized / Codespaces-style sandboxes
    • Recommended flow debate: what is the single environment we point new builders at?
  • Deliverable: Default Developer Environment Session Notes

Session 18: Using AI in Your Cardano Dev Workflow​

  • Objective: Establish a repeatable, secure workflow for building Cardano applications with AI.
  • Key Topics:
    • Cardano's eUTxO mental model and AI knowledge gaps
    • Plan-first orchestration grounded in plutus.json, pinned SDK versions, and reference repositories
    • MCP servers and reusable skills for current, project-specific context
    • Test-driven validator generation and AI verification gates
    • Local models for lower-cost supporting tasks
  • Deliverable: Session Notes | Resources

Session 19: Building a Production-Grade MCP Server for Cardano​

  • Objective: Demonstrate how to give AI agents deep, idiomatic access to Cardano — UTxOs, native assets, smart contracts, and CIP-1694 governance — using the Model Context Protocol.
  • Key Topics:
    • Why Cardano needed a purpose-built MCP server (eUTxO vs account model)
    • Server architecture: 6 modules, 38 tools, multi-API strategy (Blockfrost / Koios / Maestro / Kupo)
    • CIP-1694 governance module and IPFS metadata enrichment
    • Live demo: querying UTxOs, governance proposals, and CBOR datums from inside Claude Code
    • Lessons learned: Zod defaults, IPFS edge cases, Koios tail latencies
  • Deliverable: Session Notes | Resources

Session 20: One API Call to Understand Cardano​

  • Objective: Use simple Blockfrost calls and dummy JSON to explain how Cardano holds value (UTxOs) and what happens when a transaction is submitted and confirmed on chain.
  • Key Topics:
    • GET /addresses/{address}/utxos and reading lovelace in JSON
    • Off-chain build, sign, and POST /tx/submit (CBOR)
    • Mempool to block: polling GET /txs/{hash} until confirmed
    • Inputs, outputs, change, and fees via GET /txs/{hash}/utxos
    • Preview testnet hands-on checklist
  • Deliverable: Session Notes | Resources

Session 21: Building a Production Cardano SDK: From Validators to dApp​

  • Objective: Walk end to end through the practices of building and shipping a production-grade offchain SDK, from real-world problem to validators, SDK, and demo dApp.
  • Key Topics:
    • Why cooperative finance needs enforceable rules (documented trust failures in savings groups)
    • Why blockchain, and why Cardano: custody without a custodian, deterministic eUTxO, predictable fees
    • Three-layer architecture: Aiken validators, Effect-based TypeScript SDK, demo dApp
    • CIP-68 token pairs, ProgramRunner execution modes, and typed error taxonomies
    • Live demo: CLI account creation plus circle creation and joining on Preprod
    • The recipe: applying the same method to your own SDK
  • Deliverable: Session Notes | Resources

Working Group Information​

For operational details, roles, repository structure, and participation guidelines, please see the Working Group Overview.

This plan is a living document and will be updated based on participant feedback and community needs.

Last updated on