---
# System prepended metadata

title: 2025 Overview

---

---
robots: noindex, nofollow
---

# 2025 Overview

![](https://www.blockchaincommons.com/images/2025-Yearly.jpg)

What happened at Blockchain Commons in 2025? It turned out to be a very busy year, with us advancing several totally new technologies, as well as continuing on with some of our biggest ongoing priorities.

Here's the year in review!

## Community Support

As we wrote [in 2024](https://www.blockchaincommons.com/quarterlies/Yearly-2024/), our goal is "the creation of open, interoperable, secure & compassionate digital infrastructure", but we can't do that on our own.

That's why [Gordian Developer meetings](https://www.blockchaincommons.com/subscribe/#gordian-developers) are an important part of our regular schedule. They offer us the opportunity to talk with the community, discover its priorities, and adjust our own work to fit those needs.

We're even more thrilled when community members begin actively supporting and expanding our technologies, and we saw a lot of that in 2025. That community work included [Typescript libraries for our full stack](https://developer.blockchaincommons.com/libraries/), a [UR Playground](https://developer.blockchaincommons.com/ur/playground/), and a full [IDE for Blockchain Commons](https://bcts.dev/). Thanks, folks, we love working with you!

> _For more, see our [Meetings developer page](https://developer.blockchaincommons.com/meetings/) and [subscribe](https://www.blockchaincommons.com/subscribe/#gordian-developers) to our Gordian Developer announcements, either through our mailing list or Signal group._

## ZeWIF

<a href="https://developer.blockchaincommons.com/chains/zcash/zewif/"><img src="https://www.blockchaincommons.com/images/zcash.png" width=200 style="float: right"></a>

Early in the year, we also became involved with a totally new community: the Zcash developers community. Based on a [Zcash Community Grant](https://zcashcommunitygrants.org/), we designed and developed [ZeWIF](https://developer.blockchaincommons.com/chains/zcash/zewif/), an interchange format for Zcash wallets.

This sort of interoperability is very important to Blockchain Commons, because it ensures the _independence_ of users and the _openness_ of the ecosystem, and those are both [Gordian Principles](https://developer.blockchaincommons.com/principles/).

But, we were particularly thrilled by our work with ZeWIF because it allowed us to work with a new digital-asset ecosystem. Traditionally, Blockchain Commons has been focused on Bitcoin, but we're well aware that there are lots of other digital assets that could make good use of our specifications, and so we were happy to begin this expansion of our work. 

The idea of supporting other digital-asset ecosystems has already continued into 2026, when our [first Gordian Developer meeting of the year](https://developer.blockchaincommons.com/meetings/2026-01-gordian/) included discussion of how to expand [Known Values](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md) to better support assets other than Bitcoin. (We're also hoping to continue work with the Zcash community, which we met while working on ZeWIF, to help them integrate other Blockchain Commons specifications.)

> _For more, see our [ZeWIF developer page](https://developer.blockchaincommons.com/chains/zcash/zewif/)._

## FROST

<a href="https://developer.blockchaincommons.com/frost/"><img src="https://developer.blockchaincommons.com/assets/images/frost.png" width=200 style="float: right"></a>

_Our biggest and most important work of the year was probably with FROST, a threshold signing system built on Schnorr signatures._

This year, we moved our FROST work from its supportive role of 2023-2024, which saw our hosting a variety of [FROST meetings](https://developer.blockchaincommons.com/frost/#events), to a more hands-on approach, which allowed us to produce some capstone work on the topic, including software expansions, demos, and a whole (short) course.

That work focused on [ZF FROST](https://frost.zfnd.org/), a FROST library and CLI created by the Zcash community. We wanted to show its general applicability, which we did in a number of ways.

First, we held a pair of meetings to demonstrate those wider capabilities. We showed that it can be used for more than just Zcash by using it to sign Bitcoin transactions ([meeting links](https://developer.blockchaincommons.com/meetings/2025-08-frost-cli/)). Then, we showed how signing can be done using one of our new technologies, Hubert, even when a reliable network doesn't exist ([meeting links](https://developer.blockchaincommons.com/meetings/2025-12-frost/)).

We also put together a short course that introduces FROST and demonstrates how it works with hands-on examples: it's called ["Learning FROST from the Command Line"](https://learningfrost.blockchaincommons.com/) and is a parallel to our (out-of-date but popular) ["Learning Bitcoin from the Command Line"](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line) course. 

Finally, we built a number of tools to support ZF FROST and its various capabilities, all of which are documented in the "Learning FROST" course. That includes a standalone app, the [frost-verify tool](https://github.com/BlockchainCommons/frost-verify-rust), which can verify FROST signatures (as long as everything matches the format used by ZF FROST).

Thank you as ever to [HRF](https://hrf.org/), who has supported all of our FROST work. We hope we've been able to create a strong library of work to help people understand and utilize FROST.

_For more see our [FROST developer page](https://developer.blockchaincommons.com/frost/), which has links to that library of work._

## Gordian Clubs

_Onward to new technologies, which we hope will allow Blockchain Commons to continue its innovation into 2026 and beyond ..._

The first tech that Blockchain Commons premiered in 2026 was the [Gordian Club](https://developer.blockchaincommons.com/clubs/), which is an autonomous cryptographic object (ACO). That means it's self-contained, with access determined by mathematical means. The protected and self-contained ACO envelope is then a carrier of information, whether that be identity details, a credential, news, or information about a  gathering.

Because it's autonomous, the Gordian Club doesn't require infrastructure. If the 'net is down due to a disaster, or if you are being censored, you can still use a Gordian Club to transmit information. And that's really the point: to preserve agency when infrastructure fails.

We've written a [Musings](https://www.blockchaincommons.com/musings/musings-clubs/) on Gordian Clubs, released a [CLI](https://github.com/BlockchainCommons/clubs-cli-rust) and a [Rust library](https://github.com/BlockchainCommons/clubs-rust), and [demoed how it worked](https://developer.blockchaincommons.com/meetings/2025-10-clubs/) at our October Gordian meeting.

> _For more see our [Gordian Clubs developer page](https://developer.blockchaincommons.com/clubs/)._

## Hubert

<a href="https://developer.blockchaincommons.com/hubert/"><img src="https://developer.blockchaincommons.com/assets/badges/hubert.png" width=200 style="float: right"></a>

So how do you transmit a Club (or other data) when there's no reliable infrastructure? There are lots of solutions. You could use Bluetooth. You could give someone an NFC token or a thumb drive. You could even publish a QR code in a newspaper. But we often need solutions that allow much faster back and forth and that can be automated. That's where our next technological advance of 2026 comes in: [Hubert](https://developer.blockchaincommons.com/hubert/), the Dead-Drop Hub.

Hubert takes advantage of existing distributed storage systems (BitTorrent, IPFS), combined with [Gordian Envelope](https://developer.blockchaincommons.com/envelope/) features including [GSTP](https://developer.blockchaincommons.com/envelope/gstp/), to allow secure and private communication that can't be censored or spied upon by a centralized server.

We've produced a [CLI for using Hubert](https://github.com/BlockchainCommons/hubert-rust) ([demo](https://www.youtube.com/watch?v=QSk67Y0P8Gs&t=925s)) as well as a [CLI specifically for conducting FROST ceremonies with Hubert](https://github.com/BlockchainCommons/frost-hubert-rust) ([demo](https://www.youtube.com/watch?v=Y9uT5cfQXlk)). Check out our [BCR research paper](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2025-006-hubert.md) for more on the system!

> _For more, see our [Hubert developer page](https://developer.blockchaincommons.com/hubert/)._

## Provenance Marks

<a href="https://developer.blockchaincommons.com/hubert/"><img src="https://developer.blockchaincommons.com/assets/badges/provenance-marks.png" width=200 style="float: right"></a>

[Provenance Marks](https://developer.blockchaincommons.com/provemark/) are a concept that Blockchain Commons Lead Researcher Wolf McNally has been playing with for a few years, but brought to Blockchain Commons at the start of 2025.

A provenance mark is a forward-commitment hash chain, which means that each mark uses a cryptographic hash to commit to the _next_ publication that will bear that provenance mark. When the key corresponding to the hash is used in that next publication, you know that it is the authentic and authorized next link in the chain. This is all done without a blockchain or other external reference, ensuring the _independence_ of the publication.

Provenance marks are useful because they can prove the authenticity of a sequence of works. You want to know art is all by a specific artist? That writings or newsletters are all from a specific creator or group? A providence mark can verify that, providing truth in a world of AI and deepfakes.

Provenance marks can also be used with Gordian Clubs. Clubs have a mechanism allowing for updates 
of their information over time. Provenance marks tell you that the updates were from the original author (or some designated party).

We've produced a [CLI for provenance marks](https://github.com/BlockchainCommons/provenance-mark-cli-rust) and [gave a presentation](https://www.youtube.com/watch?v=vKAK6j4mqgE). Also see our [research paper](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2025-001-provenance-mark.md).

> _For more, see our [provenance mark developer page](https://developer.blockchaincommons.com/provemark/)._

## XID

<a href="https://developer.blockchaincommons.com/xid/"><img src="https://developer.blockchaincommons.com/assets/badges/xid.png" width=200 style="float: right"></a>

We actually introduced XIDs in December 2024, but we were able to better feature the new technology in 2025. A XID is, quite simply, an "extensible identifier". It's a specific format for documenting a stable decentralized identifier that can be self-sovereign.

We felt there was a need for XIDs in part because of the [failure of the self-sovereign identity community](https://www.blockchaincommons.com/musings/musings-ssi-bankruptcy/) but also because we wanted to offer the foundation for a decentralized digital identity that had redaction capabilities. That comes courtesy of [Gordian Envelope](https://developer.blockchaincommons.com/envelope/). You can fill a XID Document with identity information, but then you can chose who gets to see specific details by using Envelope's elision capabilities

We [demoed XIDs](https://www.youtube.com/watch?v=lKVp5WzBZD4) last year, just before we released our [research paper](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-010-xid.md). This year, we added considerable XID functionality to our [envelope-cli](https://github.com/BlockchainCommons/bc-envelope-cli-rust) tool. Just type "envelope xid -h" for a list of options. We've also been working on and off on a [XID Quickstart](https://github.com/BlockchainCommons/XID-Quickstart/tree/main), which includes overviews of much of our technology and tutorials for XID, but it's still in process. (Fundamentally, we haven't been able to give it much priority due to the lack of a sponsor for XIDs. If you think XIDs might be a great fit for your company, [talk to us](mailto:team@blockchaincommons.com) about a partnership that would allow us to prioritize the work!)

> _For more see our [XID developer page](https://developer.blockchaincommons.com/xid/)._

## Revisiting SSI

Finally, Blockchain Commons kicked off a new initiative at the end of 2025, one that represented a long-term interest: Revisiting SSI.

We've been involved with self-sovereign identity (SSI) from the start. Christopher Allen choose and popularized the term in his 2016 article, ["The Path to Self-Sovereign Identity"](https://www.lifewithalacrity.com/article/the-path-to-self-soverereign-identity/), then he shepherded its growth through his [Rebooting the Web of Trust workshops](https://web.archive.org/web/20260101130558/https://www.weboftrust.info/). 

Blockchain Commons has never had a sponsor to support our self-sovereign identity work, but we've nonetheless increasingly dabbled in it in recent years. Besides our work with XIDs, Christopher also gave interviews to [SSI Podcast](https://www.blockchaincommons.com/videos/SSI-Podcast/) and [HackerNoon](https://hackernoon.com/the-co-writer-of-tls-says-weve-lost-the-privacy-plot) last year and presented to Switzerland on [Swiss e-ID](https://developer.blockchaincommons.com/meetings/2025-10-swiss-eid/) and at [TabConf 7](https://developer.blockchaincommons.com/meetings/2025-10-tabconf/). A lot of that included advocacy for better self-sovereign identity, which also led to Blockchain Commons signing the [No Phone Home initiative](https://www.blockchaincommons.com/news/No-Phone-Home/). Finally, Christopher wrote some related Musings last year, on [Fair Witnessing](https://www.blockchaincommons.com/musings/musings-fair-witness/), on [topics related to GDC25](https://www.blockchaincommons.com/musings/gdc25/), and on the [anchors](https://www.blockchaincommons.com/musings/musings-swiss-eid/) for preserving sovereignty and autonomy that we suggested to Switzerland.

Our new [Revisiting SSI project](https://revisitingssi.com/) will be even more expansive than all of that 2025 work. The goal is to look at the principles that Christopher laid out in his 2016 article, and to see what's worked, what hasn't, and how we can redefine them to best evolve SSI over the next decade. The first meetings were held on [December 2 & 9](https://revisitingssi.com/meetings/2025-12-kickoff/), and we're continuing that work through 2026, which is the 10th anniversary of SSI.

> _For more see the [Revisiting SSI website](https://revisitingssi.com/)._

## What's Next?

We can't imagine that we'll have nearly as much new technology in 2026: though we laid solid foundations for our newest initiatives last year,  now we need to help engineers turn them into reality! (If you're interested in any of our new techs, please [let us know](mailto:team@blockchaincommons.com).)

Beyond that, we have a number of other topics that we expect to continue into the new year:

* The heart of our **Revisiting SSI** workshopping will occur from January through April, leading up to the 10th anniversary on April 26. Afterward, we hope to generate some papers, much as was done at Christopher's Rebooting the Web of Trust workshops.
* The **XID Quickstart** will likely finally get done this year, complete with tutorials and an introductory look at all of Blockchain Commons' core concepts.
* We're considering an update of the **Developer Web Pages** to try and bring some order to the rather large set of specifications we now have. (We did that a few years ago, but the ordering we choose at the time hasn't stood up to the introduction of new technologies.)

And there will definitely be new stuff too, as we talk with the community and seek out new grant opportunities.

Unfortunately, Blockchain Commons is currently running in the red due to a loss of patrons during the crypto-winter. We're always seeking [sponsors](https://github.com/sponsors/BlockchainCommons), but even more, we'd love to work with you if you are considering adopting Blockchain Commons specifications. Talk to us if you're interested!

---

## Gordian Developer Meetings (2025)

<table width="100%">
  <tr>
    <td width="640px">
      <b>Post-Quantum (March):</b>

{% include video id="ZfsH2fIHCIA" provider="youtube" %}

    </td>
    <td width="640px">
      <b>Interoperability (May):</b>

{% include video id="kD2PV8bLFhw" provider="youtube" %}

    </td>
    <td width="640px">
      <b>Provenance Marks (June):</b>

{% include video id="vKAK6j4mqgE" provider="youtube" %}

    </td>
  </tr>
  <tr>
    <td width="640px">
      <b>FROST-CLI (August):</b>

{% include video id="8csdApREJIs" provider="youtube" %}

    </td>
    <td width="640px">
      <b>Gordian Clubs (October):</b>

{% include video id="bqxW7iDk4QI" provider="youtube" %}

    </td>
    <td width="640px">
      <b>Exodus Protocols (November):</b>

{% include video id="QSk67Y0P8Gs" provider="youtube" %}

    </td>
  </tr>
  <tr>
    <td width="640px">
      <b>FROST & Hubert (December):</b>

{% include video id="coWXzO15GWg" provider="youtube" %}

    </td>
  </tr>
</table>


---


## ZeWIF Meetings (Early 2025)

<table width="100%">
  <tr>
    <td width="640px">
      <b>Meeting #1 (January):</b>

{% include video id="wy06xxpJy-M" provider="youtube" %}

    </td>
    <td width="640px">
      <b>Zmigrate Demo (February):</b>

{% include video id="wSeAdx6oZLw" provider="youtube" %}

    </td>
    <td width="640px">
      <b>Meeting #3 (March):</b>

{% include video id="qptTRJP_K2U" provider="youtube" %}

    </td>
  </tr>
  <tr>
    <td width="640px">
      <b>Meeting #4 (April):</b>

{% include video id="oXm2FsR4KTs" provider="youtube" %}

    </td>
  </tr>
</table>

---


## Revisiting SSI Meetings (Late 2025)

<table width="100%">
  <tr>
    <td width="640px">
      <b>Kickoff #1 (December):</b>

{% include video id="vq_rK-sQlkI" provider="youtube" %}

    </td>
    <td width="640px">
      <b>Kickoff #2 (December):</b>

{% include video id="j7xXGdlMPn4" provider="youtube" %}

    </td>
  </tr>
</table>