Blog

Most blockchains are built around transparency: smart contracts, transactions, and state changes are visible to everyone. That works well in many cases, but it becomes a problem when organizations need to coordinate without exposing sensitive data. The Canton Network takes a different approach. It is designed for privacy, data sovereignty, and interoperability, allowing participants to share only the information required for a given transaction. Canton applications are commonly built with Daml, a strongly typed functional smart contract language centered on parties, authorization, contracts, and multi-party workflows. In this article, we’ll introduce Canton and Daml, compare Daml with Solidity, and build a small banking application. Along the way, we’ll see how privacy and authorization requirements influence smart contract architecture.

For VC teams, valuable knowledge is everywhere: PDFs, inboxes, call transcripts, news feeds, and internal notes. The problem is getting the right context when you actually need it. We built a platform that brings all of this information into a single searchable knowledge base, with LLM agents on top that can: • prepare meeting briefings • research people and companies • answer questions across the firm’s internal knowledge • continuously ingest and structure new information In the article, we go under the hood and explain how the system works, including its storage architecture, seven-stage ingestion pipeline, Airflow automations, and the agent layer that we substantially redesigned after the first production release. We also cover a production incident that changed how we approached monitoring and reliability. If you’re building RAG systems, internal AI assistants, or agentic workflows on top of large amounts of unstructured company data, this one gets pretty technical.

In this interview, we discuss what needs to change for Haskell to reach more developers and companies, and where the Haskell Foundation can have the greatest impact. We also look at Haskell from the perspective of a large financial system at Bitnomial: how type safety and effect tracking help engineers manage correctness at scale, where the complexity budget for advanced types should be spent, and why technologies such as Servant remain powerful tools for moving guarantees from individual applications to entire systems.

In this interview with our Daml Team Lead, Heitor, we examine which Haskell intuitions transfer successfully to Daml, where analogies such as Update and IO break down, and how developers should reason about authorization, visibility, contract lifecycles, and testing. We also discuss learning paths and tooling for Daml developers, common mistakes made by Solidity programmers, and the practical topics covered in the upcoming Daml Smart Contracts Development Guide.

Bioinformatics combines scientific discovery with the challenge of processing large, complex, and imperfect datasets. In this interview with Michal Gajda, we explore how Haskell’s strong types, purity, and functional abstractions can support reliable and high performance biological data processing. Drawing on projects such as hPDB, JSON Autotype, and XML TypeLift, Michal discusses scalability, parser development, and the barriers to wider adoption of functional programming in bioinformatics. He also considers how better education, tooling, and AI assisted programming could make Haskell more accessible to future scientists.

The main point of the article is that Claude Code needs engineering around it just as much as any other development tool. On its own, the agent can write code and run commands, but it quickly runs into the usual problems: missing context, repeated mistakes, unsafe decisions, and fragile fixes. A better setup gives it project rules, current documentation, MCP access, reusable skills, hooks, task trackers, Git safety nets, and clear session workflows. With these pieces in place, Claude Code can handle implementation, investigation, and verification more reliably, while the developer still owns architecture, review, and product judgment. The result is not an autonomous engineer, but a practical tool that works best when its context and workflow are engineered deliberately.