The core team has published and blessed another Holochain release, close on the heels of the previous one. This release removes one of the last major performance bottlenecks of the Rust redux model based Holochain.

HoloFuel is undergoing some refactoring work to make it more suited to its primary use case. This will make the codebase simpler and its resolution time faster. But we’re planning on moving some of its extra features into an example code repo for you to use.

There are a few libraries and tools I’d like to share too; they ought to be quite useful in your development work.


  • Holochain v0.0.47 released, blessed, and included in Holoscape
  • See what happens inside a DHT with Holochain Playground
  • Drop-in libraries for you to use in your project
  • In the works: RAD tools and IDE progress
  • HoloFuel progress update

Holochain v0.0.47-alpha1 released, blessed, and included in Holoscape

It’s only been a couple weeks since we released Holochain v0.0.46, and we’ve got another one. This release brings a large performance improvement thanks to our aggressive testing of HoloFuel with real nodes. We were seeing an unusual performance curve, where earlier transactions would resolve very quickly but resolution time would climb as more people joined and sent Test Fuel to each other. The core team isolated the problem to a certain asynchronous part of the code, where background tasks were being continually checked to see if they’d resolved yet. For tasks that took a long time to resolve, this consumed a lot of unnecessary CPU time. If you’re curious about the details, you can read about it in the pull request.

CPU usage from the most recent test run. Even with 297 nodes transacting Test Fuel (three instances on each of 99 machines, starts at 22:15 mark), the CPU hardly breaks a sweat.

Holochain v0.0.47-alpha1 is in Holonix v0.0.73, which is ‘blessed’ and available through the quick install procedure. If you already use this, all you need to do is exit all your nix-shells and enter nix-shell again.

This version is also in the newly released Holoscape v0.0.9 for macOS and Linux. Holoscape is meant to make it easy for end-users and testers to install and run Holochain and hApps.

Summary for Holochain v0.0.47-alpha1

  • Bugfix: Futures bug that caused CPU over-consumption. #2175
  • Bugfix: Validation bug that treated network timeout as a validation failure instead of a retry. #2176
  • Change: The Holonix developer environment has changed the command name for the RAD tool demo from hn-happ-create to hc-happ-create. holonix#151

See what happens inside a DHT with Holochain Playground

Here’s a very exciting tool I didn’t know about until last week. Guillem Córdoba, a Holochain app developer and community organiser from Barcelona, has created Holochain Playground, a tool for visualising exactly what happens when you commit data to the DHT. It lets you specify a DHT of a given size and redundancy level, then lets you create, update, and delete entries and links and see how they behave when they hit agents’ source chains and the DHT. There are two modes:

  • Designer mode shows how every entry on the DHT relates to each other, including agent ID entries.
  • Technical mode lets you inspect an agent’s source chain and DHT shard, and see the neighbourhood that a published entry lives in.

This tool simulates a DHT, but you can also connect it to a running conductor and see exactly what a real DHT is holding as well!

I’m thrilled about this project—not only because it's otherwise hard to visualise how data floats through a hApp, but also because it’s another example of how Holochain’s developer community is growing by its own energy. It’s wonderful to see people creating these beautiful and useful projects and giving them to the rest of the community.

Try out the playground live, download the code on GitHub, and join the conversation on the forum.

(Pssst: This playground will likely end up in a future Holochain IDE—more below!)

Drop-in libraries for you to use in your project

More reusable libraries are coming to maturity and ready to use in hApp projects. Below are some that we’ve already seen. (Note that some are works in progress and not production ready—the authors would be grateful for your contributions!)


A library that implements the Anchor pattern and allows you to drop that functionality into your own zome. This particular manifestation lets you create a two-level tree of anchors, which is useful for creating global taxonomies like usernames, roles, and pages.


A Rust trait that reduces some of the boilerplate needed to turn a Rust struct into an entry ready for committing to the source chain.


A library that implements date range indexing querying for time-based DHT entries. Can be useful for building calendar, event booking, and project management hApps.


Another taxonomy library which uses the Anchor pattern to let you attach entries to string tags.


One example of a basic mutual credit currency. This codebase shows the mechanics of entry creation and validation, but doesn’t yet implement robust security audits or privacy measures. There will be an MVP of a LETS style currency added soon.


A membrane zome that restricts membership to ‘friends of friends’—in order to join, your agent ID has to be ‘vouched’ by a given number of existing members. It has a good example of the Member Whitelist pattern.


A library that lets you add role-based access control to your zome. Makes use of the Progenitor pattern.

In the works: RAD tools and IDE progress

You may have heard about the first iteration of our rapid application development tools, which scaffolds and runs a note-taking hApp for you. If you’re a developer, you might have even tried it out and discovered how easy it is to get started.

But as a RAD scaffolding tool, it’s necessarily limited—it was meant to demonstrate a front-end stack and developer tooling within a precreated hApp. We’re rolling out functionality in stages, where the next iteration(s) will generate code from your own specifications.

There are two projects being developed in tandem. First, the second iteration of the RAD tool, which will auto-generate front-end and DNA code from your spec file. This spec file format will be easy to write by hand, so in a sense it will be the tool's UI.

Philip Beadle, team alumnus and close collaborator, is also working on an IDE with a graphical builder for creating a data schema. The IDE will also likely include Guillem’s Holochain Playground, described above. As you can see from the GitHub repo, it’s still in early stages but in active development. Take a look at the wiki to see what features are planned.

The DNA modeller, where you can design and see all of your entry types and the links between them, along with the CRUD code that will be generated.‌‌

These two tools will offer different approaches, letting developers build out the 'boring parts' of the code quickly, and empowering non-developers to create hApps without touching any code.

These tools will likely also mark a shift in our preferred hApp stack: while we’ll still use Apollo GraphQL for the data plumbing (and Holochain for the back end, of course), for GUIs we’re experimenting with LitElement, a lightweight web component library that’s compatible with React, Vue, and plain old HTML. We’re also taking a look at Cortex, from the _prtcl project (created by Guillem and Pepo Ospina)—it’s an interesting framework that promises to create a LitElement-based UI directly from a data schema by making intelligent guesses about the data’s purpose.

HoloFuel progress update

As shared today and last Dev Pulse, much of the work getting HoloFuel ready for alpha testing has actually happened in Holochain. In fact, HoloFuel has become a great way for us to test Holochain, because it’s a fairly sophisticated hApp. If there are performance issues, mistakes in validation workflows, or bugs in the consistency model, HoloFuel is likely to uncover them. In addition to the work we’ve already shared, the core team is carefully refactoring certain parts of Holochain’s core to reflect things we’ve learned in the HoloFuel journey. This work will make it easier to reason about, debug, and guarantee the correctness of core workflows.

But HoloFuel itself is also seeing some changes. There are lots of different ways to model a mutual credit currency in code, and some are more appropriate than others depending on your context. Do you want credit limits, or will an Open Money or LETS-style currency work better for your community? Do you prefer fast finality or rigorous finality? Do you want to optimise for always-online users, or should it be partition-tolerant? There is no right answer for all use cases.

HoloFuel’s codebase initially had a very clever five-step process. This was optimal for asynchronous communication between users who connected and disconnected from the DHT regularly.

The primary use case for HoloFuel is quick-resolving, high-volume, low-value microtransactions between always-on HoloPorts and hApp publishers. This means that, while the current design was robust, it added a lot of validation overhead for little pragmatic benefit. So we’re in the process of refactoring it for this use case, which has the side effect of making the algorithm simpler. When it’s complete, it’ll work like the design we described in Dev Pulse 54.

In the meantime, we’re continuing real-life testing on the current design, which will be included in the next major HoloPortOS update.

Development status


  • Holochain Core: 0.0.47-alpha1 (blessed) | Changelog
  • Holonix: 0.0.73 (blessed)
  • Tryorama: 0.3.4 (blessed)
  • Holoscape: 0.0.9-alpha (contains Holochain Core 0.0.47-alpha1) | Download

Blessed (available via

  • Holonix: 0.0.73
  • Holochain Core: 0.0.47-alpha1