The first quarter of 2026 focused on producing a capstone for much of our stack, but also was about advancing our self-sovereign identity work. Here’s what all it included:

• Capping the Stack:
  • Technology Overview
  • New BCRs
  • New Translations
  • Playgrounds
• Locking Down Known Values:
  • Talking about Known Values
  • Code Point Specification
  • Crate Update
• Expanding XIDs:
  • Introducing Edges
  • Learning XIDs
  • XIDs & Garner Meeting
• Diving into SSI:
  • GDC Incoming
  • New Articles
  • Revisiting SSI
• Returning to Learning Bitcoin:
  • Learning Bitcoin 3.0
  • Standup Scripts
  • Gordian Server

Capping the Stack

We’ve slowly built the Blockchain Commons stack up over the last years, from dCBOR to Uniform Resources to Gordian Envelope. In 2025 and into 2026, we brought much of our foundational work to a capstone, allowing us to concentrate on new applications and references built atop that foundation, including XIDs and Gordian Clubs. Here’s some of what we did to close things out in early 2026.

Technology Overview. To celebrate the completion of our foundational work, we put together a new technology overview video that details 24 different technologies, applications, and references in about a minute each. Here’s a quick overview of all the topics covered, plus a listing of our older videos, which go into greater depth on some of these topics.

New BCRs. We also led the year off with a set of new [Blockchain Commons research papers] (https://github.com/BlockchainCommons/Research/blob/master/README.md) that were mainly intended to detail our work to date.

• BCR-2026-001: Unit, The Known Value for Deliberate Emptiness. A look at Known Value 0, and how it’s intended to be used.
• BCR-2026-002: Gordian Envelope Notation - Quick Reference. We’ve long provided a special “envelope notation” output to offer a human-readable view of what’s in a Gordian Envelope; here is its specification.
• BCR-2026-004: Envelope Salted Values. A discussion of the use of salt for decorrelation in Gordian Envelope.

(BCR-2026-003 is missing from this list because it was a major new specification, as discussed in “Expanding XIDs”, below.)

New Translations. Finally, we also produced some AI-supported translations of our stack to Swift, Kotlin, TypeScript, C#, Go, and Python. This is a preview that isn’t release-ready, and it only goes up to Provenance Marks (meaning that it’s missing some newer tech such as XIDs and GSTP). If you think this might be of use to you, talk to us about funding its full development.

Playgrounds. The third-party playgrounds that have appeared for our specifications in the last several months definitely represent another sort of capstone, as they provide a new way for developers to work with our technologies. Our January Gordian meeting included a demo of the BCTS playground. Both it and the BC-UR playground provide great tools to work with our tech.

• BCTS Playground - Data Playground, Registry Browser, Envelope Builder, XID Tutorial
• BC-UR Playground — Converter, Multi-UR & QR Generator, QR Scanner, Registry Browser

Locking Down Known Values

One of our foundational technologies is the Known Value. It’s a simple enough concept: a registry of 64-bit integers that represent common concepts. But, they’re very useful: not only do Known Values standardize our own organization of information in Gordian Envelope, but they also support that standardization across many companies. We did a variety of work on Known Values in early 2026.

Talking About Known Values. In our January Gordian Meeting, we talked about our desire to expand Known Values beyond the core concepts that we have defined for our own specifications. We wanted to not only incorporate other ranges of defined concepts, for standardization, but also to give our community the opportunity to officially define values for their own use. We got great feedback during and after the meeting that helped us to decide where the community values should go in the range. (Community feedback has always been crucial to Blockchain Commons, to ensure that what we’re doing makes sense in the world of actual development and deployment, and this was a fine example, because we’d been thinking about placing community known values too high, requiring too many bits.)

Code Point Specification. The free-for-all community band of known values starts at 100,000, but thanks to that meeting we’ve now defined a new set of community known values available with specification, which appear in the range of 1,000-1,999. Known values for this range may be submitted by PR. Our registry now also recognizes a variety of other schema, starting at code point 2,000.

Crate Update. The Known Values Rust crate has been updated to support these new code point specifications. The Blockchain Commons values remain in the core crate, but if you want to add in all the other values from our registry, just grab our current files defining them in JSON and add them to your ~/.known-values directory. You can also add arbitrary known values of your own by matching the format of our known value JSON assignment files. The known values crate (and crates that depend on it such as our envelope crate) will all have access to the values from your ~/.known-values directory.

Expanding XIDs

One of our largest current projects is XIDs, which we see as a true self-sovereign identifier. We supported them with both public demos and in-house extensions over the course of Q1.

Introducing Edges. Credentials, endorsements, and other types of attestations have always gone hand-in-hand with digital identity, and we’ve been thinking for a while about how to best expand XIDs to support these crucial digital tokens of trust. We were considering somewhat ad hoc means for a while, but we finally came up with the concept of “edges”, which are attestations that lie between two XIDs, forming the literal edges of a Web of Trust graph. BCR-2026-003 has all the details on how edges work.

Learning XIDs. You can also find edges in chapter 3 of our brand-new course, “Learning XIDs from the Command Line”. We’ve completed four chapters to date, and have put a temporary cap on the work. To date, those chapters cover: an introduction to XIDs, how to make claims related to XIDs, how to incorporate claims into XIDs using edges, and how to manage your XID with more complex elements such as commitment lists and updated views and editions. We plan to return to this course in Q2 with a new chapter on keys, but for now it’s complete and coherent.

XIDs & Garner Meeting. Finally, our public demo focused on using XIDs with Garner, our Tor onion service intended for the distribution of self-sovereign identity files. XIDs offered the opportunity to truly control your digital identity, from creating it yourself to deciding what you want to distribute. Garner makes that distribution self-sovereign as well by providing a communication method that’s very resistant to censorship, correlation, and coercion.

Diving into SSI

Our focus on self-sovereign identity (SSI) has been on the rise in 2025-2026, but it’s not actually new. We’ve been a part of the SSI community since Christopher Allen popularized the term as part of the Rebooting the Web of Trust workshops. It’s just that prior to 2025, we were still creating those foundational techs that we’re now bringing to a capstone; it’s only recently that our stack has matured enough that we can produce SSI-focused technologies such as XIDs and Gordian Clubs. Much of our SSI design is centered on XIDs themselves, but we’re also doing other work on the topic.

GDC Incoming. Blockchain Commons has been invited to the Global Digital Collaboration Conference as a co-organizer. This means that we can get you an invitation to the exclusive gathering and also help to set the agenda. Want to join us in Switzerland? Have a topic that you think is important to cover? Let us know.

New Articles. Meanwhile, Christopher has authored a few new articles on the topic of SSI, both in his Musings series (focused on original architectural designs & patterns) and in his new Dispatches series (responding to others’ discussions of topics of interest to us). Here’s his new writing from Q1:

• How XIDs Demonstrate a True Self-Sovereign Identity. How SSI has gone wrong and why XIDs are different.
• Progress toward a State-Endorsed Identity (SEDI) in Utah. Can state-endorsed SSI really be a thing? Utah offers a great model.
• Fighting Technology Paternalism. SSI is about controlling your digital destiny, but Martina Kolpondinos offers the flipside: when the computer chooses for you.

Revisiting SSI. April 26 marks the 10th anniversary of Christopher’s article, “The Path to Self-Sovereign Identity”, which popularized the term and its goals. We’ve been working on Revisiting SSI to try and reconsider the original 10 principles of SSI. We’ve had some meetings with some great input, but we’ve also found it hard to turn that into group articles the way we’re able to in a physical meet-up like Rebooting the Web of Trust. Nonetheless, we plan one or more articles on the principles and how they may have changed or how we may be thinking about them differently a decade later. If you have any opinions, again let us know! We expect to be producing some new content on the topic for Q2.

Learning Bitcoin

Learning Bitcoin from the Command Line is one of Blockchain Commons’ oldest endeavors, started with support from Blockstream even before Blockchain Commons was founded. However, Bitcoin continues to evolve rapidly and as a result the course has gotten out-of-date over the last several years. We’re thrilled to return to it in a year-long effort in 2026 thanks to a grant from the Human Rights Foundation.

Learning Bitcoin 3.0. We have begun work on Learning Bitcoin 3.0, which is a thorough update of the course, focused on better incorporating newer elements such as Signet, descriptor wallets, Segwit, and Taproot, as well as a check and/or revision of every single line of code. We’ve logged a week and a half of work on this to date, and have it scheduled for five weeks total. Our log of work to date and our plans for the future are all in our TODO file, while the lbtcftcl-v3.0 branch of Learning Bitcoin contains the 264 commits to date. At the moment, §1.0-§7.2 are pretty solid. As soon as we close out chapters 7 & 8 and their linked discussions of multisigs and PSBTs, we plan to make the updated version of the course more available with a mkdocs-formatted website (but it’ll be the end of the year before we close out the project entirely). Thanks again to HRF for enabling this much-needed work!

Standup Scripts. Our Standup Scripts guide the creation of UNIX machines running the Bitcoin Core server. We used them in the LBTCftCL course and to produce that course. But these Scripts tend to age badly over time, as the programs we use change. We updated our Standup Scripts in January to support Bitcoin Core 25.0 and Debian 13. Ironically, the StackScript version of our scripts has already decayed because of some Linode package management that is now requiring user intervention. But, the non-StackScript version still works great (and you can run it from a Linode by hand), and we’re deciding on the best solution for the StackScripts. (Removing certain package updates resolves the problems, but keeping packages up to date is a best practice, so we’re hoping that what appears to be a bug gets resolved!)

Gordian Server. The new work on Learning Bitcoin also made us reconsider the Gordian Server, our Bitcoin Server for the Mac, which we also use for testing when we’re working on Learning Bitcoin. It too had gotten out of date, but its original designer, Peter Denton, has been working on his own iteration of the concept, the Fully Noded Server. As a result, we’ve officially deprecated Gordian Server and now suggest the use of Pwrwe’a Fully Noded Server instead. (Notes on the one alias needed to make things work well for the Learning Bitcoin course are already incorporated into v3.0 of the course.)

Final Notes

The environment for work on self-sovereign digital assets and identity continues to be rough in 2026. Due to limited resources, we expect to be focusing more in the coming year on developing, polishing, and documenting our existing work, as opposed to creating some of the exciting new technologies that we saw in 2025. That’s not a bad thing, as it’ll give us a chance to really get XIDs, Gordian Clubs, and other recent technologies into the ecosystem, alongside our already adopted specifications such as Gordian Envelope and URs.

But, you can help. We are looking for partners who want to adopt our technologies and who could use our expertise to do so. Drop us a line if that’s you. We of course continue to welcome individual and small company sponsorships as well. If you want to see this work continue, and if you can lend your reputation to ours, please sign up as a recurring GitHub sponsor.

“Privacy” doesn’t name the problem any more because it means something different to every regulator in the room. “Decentralization” became a buzzword, but it no longer prevents coercion due to compromises. “Interoperability” has been similarly corrupted by EUDI wallets that claim the term while depending on Apple and Google attestation infrastructures.

Martina Kolpondinos, who spent 15 months inside the Swiss federal eID team and is a co-editor on the WebVH spec, has just published a piece¹ that may offer an answer by naming the pattern we keep running into: Technology Paternalism.

The term goes back to Spiekermann & Pallas², who argued that ubiquitous computing raises concerns beyond privacy: specifically, whether people can maintain control when systems decide for them. They proposed “the right for the last word”: the ability to overrule autonomous system behavior. Unfortunately, twenty years later, things are worse, not better: 84% of organizations doubt they can even audit their AI agents³.

In my upcoming Architecture of Autonomy work, I’ve mapped how legal protections designed as shields against coercion get inverted in digital systems: property becomes privilege, contracts become coercion, due process becomes algorithmic absolutism, and exit becomes erasure. Kolpondinos shows how these same inversions manifest as paternalistic “features.” She does so by building a four-part taxonomy for Technology Paternalism:

• Design Paternalism. The “quick setup” for systems is prominent, and “advanced” settings are buried. You aren’t forced, but you are guided to a preferred usage pattern.

• Algorithmic Paternalism. Systems pre-select what you see. The defaults require no action, but choosing diversity requires effort.

• Infrastructural Paternalism. Your credentials, reputation, and relationships accumulate in a single ecosystem. Though you can leave, you leave empty-handed. This is what happens when the “interoperable” standard requires a specific device stack.

• Protective Paternalism. Restrictions are framed as safety. If you question them, you sound irresponsible. This is what silences objections in standards bodies. As discussed in the replies to Martina’s post, we ultimately want to annotate information, not censor it. This doesn’t suppress contradicting claims, but instead holds them as attributable, visible, and resolvable. That’s the kind of trust infrastructure we should be building: systems that make reasoning inspectable, not systems that decide for you.

Fundamentally, this paternalism is all coercion: it’s taking away your choices and replacing them with the designer’s choices. This is an increasing problem in technological spaces, and fighting coercion (through anti-coercion or coercion resistance) is definitely something that could replace our old buzzwords such as “privacy”, “decentralization”, and “interoperability”.

Vitalik Buterin recently discussed the issues when he published the Ethereum Foundation mandate⁴, three days before Martina’s article. There, he frames Ethereum as “sanctuary technology”, designed to “support technological self-sovereignty and allow cooperation without centralized coercion.” His CROPS priority stack (Censorship resistance, Open source, Privacy, Security) tracks the same concerns from the protocol layer.

We’ve also been developing coercion-prevention lenses⁵ in the Revisiting Self-Sovereign Identity initiative (revisitingssi.com). Kolpondinos’s article is the first published output from a workshop participant, and it translates the identity community’s coercion analysis into language the broader design community can use.

Ultimately, I think “technology paternalism” and “coercion resistance” work as a pair. Paternalism offers the diagnosis: it names an anti-pattern. Coercion-resistance then provides the treatment. Both do more work than “privacy” because they name the mechanism, not just the domain.

However, Technology Paternalism is harder to fight than outright ideology because it embeds moral choices in technical decisions and then presents them as neutral engineering. You could argue with someone if they were making an unvarnished moral claim, but you can’t easily argue when they say “that’s just how the protocol works.”

But Kolpondinos’ four countermeasures are a great response. She suggests tests that I wish every identity project would apply: Can you override the system’s decision? Contest it? Inspect the reasoning? Leave without losing everything?

Apply that to any wallet architecture currently in standardization.

Read Martina’s article, “Technology Paternalism Expands — A Case for Self-Sovereign Identity”: https://www.kosmaconnect.net/interactionblog/technologypaternalism

Citations

#DigitalIdentity #SelfSovereignIdentity #CoercionResistance #TechnologyPaternalism

The Global Digital Collaboration Conference debuted in 2025 as a meeting place to promote interoperable infrastructure for digital identity. It uniquely includes not just open-source and standards organizations, but also many governments that are even now deploying government-sponsored digital identity systems.

Blockchain Commons came into the GDC conference via our work with Switzerland on Swiss e-ID, where we made an invited presentation at the Participation Meeting following Swiss adoption of “electronic proof of identity.” We are pleased to keep working with the Swiss Confederation as the hosts of GDC and with the other co-organizers of the conference.

GDC is scheduled for September 1-3, 2026 in Geneva, Switzerland. The conference draws approximately 2,000 participants by invitation only. As part of the Advocacy Co-Organizers Group, our coalition of five organizations shares an allocation of 40 invitations—though additional spots may become available if other co-organizer groups don’t use their full allocations. Let us know if you’d like to attend or if you have specific topics you’d like to see addressed, and we’ll do our best to propose sessions and issue invites as needed!

The brand-new 2026 Technology Overview from Blockchain Commons describes each of 24 different technologies, applications, and references in about a minute each, offering the most comprehensive and accessible look at Blockchain Commons technology to date.

Here’s a quick look at the topics covered in the Overview:

Data Encoding

Our foundational methods for storing data in an interoperable format.

• dCBOR. An update to the CBOR data format that ensures that data is always encoded in the same way.
• Known Values. Integers assigned to common concepts and recorded in a common registry.
• Uniform Resources (URs). An encoding method for structuring binary data as plain text strings.
• Multipart URs (MURs). URs with large payloads split into fragments seen as Animated QR codes.

Cryptographic Protections

Technologies that protect, authenticate, and verify your data.

• FROST. A Schnorr-based threshold signing system.
• Provenance Marks. A forward commitment hash chain that is public verifiable, used to assess content authenticity.
• Sharded Secret Key Reconstruction (SSKR). A Shamir’s Secret Sharing variant that includes two-level thresholds.

Data Identification

Aids that help humans to recognize complex binary and hex data.

• Bytewords. An encoding method that makes data human readable, also used by URs.
• LifeHash. A visual recognition system that creates a unique visual icon for any data.
• Object Identity Blocks. An ID card for digital objects that improves recognition and reduces confusion.

Gordian Envelope

The core of our higher-level stack, used for safely storing and sharing data.

• Gordian Envelope. A deterministic smart document system that supports elision, encryption, and permits.
• Gordian Sealed Transaction Protocol (GSTP). A transportation method for moving envelopes securely between parties.
• Encrypted State Continuations (ESC). A method for storing client data as a black box in GSTP communications.

Self Sovereign Identity

Methods to control your own identity, built on Gordian Envelope.

• Extensible Identifier (XID). A secure self-sovereign and self-certifying identifier.
• Gordian Clubs. A self-contained cryptographic publication that you can distribute without infrastructure.

Secure Data Transport

Self-sovereignty can often be censored by the transport layer. These apps demo ways to avoid that.

• Garner. A Tor onion service that privately serves files using TorGaps.
• Hubert. An automotable dead drop protocol that uses distributed storage networks for communication.

Reference Apps

All of our technologies are references. These apps show how many of them work.

• dCBOR-CLI. An app for investigating dCBOR, including powerful dCBOR pattern expressions.
• envelope-CLI. An app demonstrating extensive envelope and XID functionality.
• Seedtool-CLI. A command-line app that demonstrates data encoding and other low-level protocols.
• Gordian Seedtool. An iOS seed vault that mirrors seedtool-CLI in a graphical environment.

Information Repositories

We want to help you learn about our technologies! Besides our developer pages, the following resources also contain information.

• Gordian Dev Meetings. Monthly or bimonthly meetings that discuss and demo technologies.
• Research Repo. The precise technical specifications for many of our technologies.
• YouTube. Videos of our meetings as well as other overviews and demos.

Besides our new 2026 Technology Overview, you may also wish to watch our 2021 Technology Overview, which contains more extensive discussions of our older (more widely adopted) technologies and also our two-part overview of Gordian Envelope.

UPDATE, March 25, 2026: SB 275 signed into law by Governor.

UPDATE, March 5, 2026: SB 275 has passed the Utah legislature unanimously — the Senate voted 25-0 and the House 70-0 — and has been sent to the governor for signature. It takes effect May 6, 2026. This is a huge win. If you’re in Utah, thank your representatives. If you’re in another state, point your legislators at SB 275 and Wyoming SF39 as model legislation. The fight now shifts to preservation — watch for future amendments that weaken the Duty of Loyalty or selective disclosure protections.

Most of my identity advocacy work in the United States has been in Wyoming. They’ve been very open to the goals of self-sovereignty and as a result we’ve passed laws such as private key protection and we’ve defined digital identity as being controlled by an individual’s principal authority.

So it’s great to see another jurisdiction, which I have been less directly involved with, progressing on their own vision of self-sovereignty. That’s the whole purpose of advocacy: to seed the ideas so that they spread.

I’m talking about Utah, whose State-Endorsed Digital Identity (SEDI) has been moving in a great direction for a while. The newest bill introduced for it, S.B. 275, the “State-Endorsed Digital Identity Program Amendments”, which does all the heavy lifting of establishing SEDI, solidifies it as a privacy-first, decentralized design.

A Bill of Identity Rights

The first thing that caught my eye in the SEDI update was a new Bill of Rights. It immediately presents the digital-identity user not just as a digital serf, but someone who can claim privileges.

The lead right was surprising:

(1) “An individual possesses an individual identity innate to the individual’s existence and independent of the state, which identity is fundamental and inalienable.”

That’s pretty close to my first principle of self-sovereign identity, existence:

Existence. Users must have an independent existence. Any self-sovereign identity is ultimately based on the ineffable “I” that’s at the heart of identity. It can never exist wholly in digital form. This must be the kernel of self that is upheld and supported. A self-sovereign identity simply makes public and accessible some limited aspects of the “I” that already exists.

It was great to see an understanding that any digital identity is founded in a real person. That lays the foundation for its importance in the digital world.

There was tons more in the bill of rights that was amazing.

This is pretty close to self-sovereignty:

(2) An individual has a right to the management and control of the individual’s digital identity to protect individual privacy.

This requires transparent architecture:

(7) An individual has a right to transparency in the design and operation of a state digital identity, including the right to access, read, and review the standards and technical specifications upon which the state digital identity is built and operates.

This is a little wobbly (because of the “except as authorized by law”), but is a strike against the surveillance state:

(10) An individual has a right to be free from surveillance, profiling, tracking, or persistent monitoring of the individual’s assertions of digital identity by the state, except as authorized by law.

But this may be my favorite:

(8) An individual has the right to choose what identity attributes are disclosed by the individual’s state digital identity in accordance with standards established by the Legislature.

This is potentially full empowerment of selective disclosure, depending on what the standards are. I wrote recently that one of the big failures of the SSI community is the fact that they stepped away from a holder being able to determine what they can redact in their identity. That a state legislature may beat them to the punch is shocking.

I think a digital-identity bill of rights is a great thing. It’s what I was thinking about when I put together the original principle of self-sovereign identity. I’m now revisiting those principles for the SSI 10th anniversary, and this looks like another great source to consider.

The Duty of Loyalty

There’s a ton to like in the bill, including anti-correlation, selective disclosure, minimal disclosure, and a variety of requirements for digital-wallet providers, verifiers, and relying parties that all tend to protect the holder of the identity. It’s clear that someone was involved who really knew what they were doing and also undestood the importance of a user controlling their own identity.

But the other one that I thought was of particular note was the “Duty of Loyalty”

63A-20-701. Duty of loyalty. The department, a digital wallet provider, a verifier, a relying party, and a digital guardian shall refrain from practices or activities related to the processing of an individual’s identity attributes that:

(1)conflict with the best interests of an individual;

(2)take advantage of or otherwise exploit an individual;

(3)result in a disproportionate risk to an individual;

(4)are to an individual’s detriment; or

(5)cause harm to an individual.

This is a critical right, tying into the Principal Authority work that I did with the Wyoming Blockchain Select Committee. It similarly evokes agency law to say that when other entities are using your digital identity, they can only do so to support your best interests. Compare that to the modern-day ecosystem of surveillance capitalism and extraction and the difference is obvious. Many modern-day digital services are built on allowing you to create an identity (on Facebook, on Google, whatever) and then mercilessly extracting from that, stealing your attention, your creativity, and everything else.

There are obviously questions with how this will be managed. For one, I can’t see how “related to the processing of an individual’s identity attributes” will be interpreted. Obviously, it’ll protect you from hi-jinks on the part of your verifier (which is a huge win) but it’s unclear whether it’ll provide any protection for someone who is enabling you to interact online with your identity (e.g., Facebook).

The other question is whether entities can coerce users to give up this right, which is a common modern-day tactic (c.f. “clickwrap”). From the research I’ve done so far (IANAL), it looks like these aren’t rights that could be signed away in a contract—they represent minimum statutory requirements, and that as long as carve-outs aren’t created in the law, this Duty of Loyalty will be protected.

That’s what we need to fight against here. We need to “beware platforms bearing gifts”: we have to watch for Googles and Facebooks using regulatory capture to ask for carve-outs in this law that will steal away the rights from us and give it to them by making them optional. And that’s unfortunately a pretty big task in the modern world.

Make a Difference

I haven’t analyzed every line in S.B. 275. I wouldn’t be surprised if I find some things I don’t agree with as I explore it further. But in the big picture, this is a big win for self sovereignty and for user agency and autonomy in digital identity. Adding it on to Wyoming’s work creates another model for how digital identity that maintains human dignity could spread across the United States.

If you want to help in this effort:

• If you’re in Utah, call up your state representatives and tell them that you support the bill. Maybe even express concerns about regulatory capture.
• If you’re in another state, call up your state representative and tell them of your interest in self-sovereign identity, offering Utah SB275, Wyoming SF39, and maybe Wyoming HB86 as model legislation.
• If you want to support our advocacy, become a GitHub sponsor or talk to me directly about supporting advocacy at a larger scale.

The work going on in Utah is great. But it’s just a start in supporting our digital rights!

So I’ve been there from the start. I have a solid basis in our original intent for self-sovereign identity (SSI), and I know where we went from there. I’m the co-editor of the W3C Amira Engagement Model, which demonstrated many of our desires with decentralized identity, and also a co-author of the W3C DID standard and of BTCR, the first DID method.

Unfortunately, in the ten years since I wrote “The Path to Self-Sovereign Identity,” I feel that SSI, as implemented, has become indistinguishable from the very systems we set out to disrupt. Worse, it has legitimized architectural choices that align more closely with centralized identity systems, such as the mDL/mDoc-style solutions now appearing in emerging EU digital wallet deployments.

I first wrote about these concerns in “Has Our SSI Ecosystem Become Morally Bankrupt?”. In short, SSI was meant to be private, decentralized identity. You were meant to be able to decide what you revealed about your identity, and you were meant to not be beholden to any outside control or gatekeepers.

But compromise after compromise ate away at those ideals. Early discussions of DID- and VC-based identity treated issuer, holder, and verifier as equal roles that any participant might play. When the W3C Verifiable Credentials standard was ratified, that symmetry was narrowed to a “three-party ecosystem,” and when the DID standard followed, even that framing disappeared. That’s what made DID issuers rarefied powers within the DID ecosystem rather than your peers; it’s why DID wallets are largely incapable of acting as issuers themselves.

To be honest, I saw the potential for these problems while the DID specification was under review for Recommendation, but as an Invited Expert at the W3C, I approved the draft without raising a formal objection. That’s because I didn’t have an alternative at the time. Since I didn’t have that alternative, I didn’t feel it was right to say that DIDs as proposed were wrong. There was certainly the hope that they would develop in the right way, that even with the compromises in the standard, the deployers of mass-market DIDs would stick with our goals of decentralization and privacy.

But, they didn’t.

As a result, we have self-sovereign identity in name only. Though a true decentralized identity could be built within the DID spec, that’s not how the ecosystem has evolved. Instead, more often than not, a small, de-facto-centralized set of issuers structurally controls what you can do with your DID. They limit what you can redact and require phone-home behavior that not only keeps you tied to them, but also negates your privacy.

It’s now been almost four years since the ratification of DID v1.0. While the working group has been drafting DID v1.1, I’ve been focused more on doing my own work to create a technology stack that better exemplifies what we first started back in May 2016, in the shadow of the United Nations and the inaugural ID2020 summit: a truly decentralized and self-sovereign identity.

I call it the XID or eXtensible IDentifier. XIDs deliberately trade ecosystem convenience and institutional alignment for architectural clarity, holder control, and long-term privacy. They’re not intended to replace every use of DIDs or VCs, but to demonstrate a holder-centric identifier model that can coexist with, wrap, or inform future decentralized identity systems. They’re an exemplar of what is possible.

A lot of my work on XIDs goes back to the Amira Engagement Model. At Rebooting the Web of Trust 5, in Boston, we imagined a programmer with a politically sensitive background who wanted to contribute her skills to social causes, but was afraid of repercussions for herself and her family. We then laid out a self-sovereign pseudonymous identity system that would allow her to do so by protecting her real identity while allowing her pseudonymous identity to gain reputation over time, all under her tight control. Amira was my North Star when I began work on XIDs: I wanted to create a new decentralized identifier that supported her use case in a way that the evolving DID ecosystem did not.

Here’s the quick overview of the architecture:

XIDs can be created by anyone. They function as holder-controlled identifiers that can carry signed assertions and credentials without requiring issuer-controlled disclosure or online resolution. They are autonomous cryptographic objects that are self-contained and do not inherently phone home; network interaction occurs only if a viewer explicitly chooses to dereference a URL or other correlatable pointer, rather than using one of the more secure alternative resolution methods available. Most importantly, the holder of a XID can themselves choose to redact any of the information it contains, without invalidating any signatures that have been made to authenticate the XID or any credentials it might include.

Blockchain Commons has developed a body of work around XIDs, including specifications, working code, and supporting materials. We’ve also used XIDs within Blockchain Commons for experimental identity workflows and as a testbed for privacy-preserving identity research.

If that all sounds intriguing, please jump to our developer page, which links all of our specfications, code, CLI apps, and other material. If you want to evaluate XIDs more concretely, instead start with the Quickstart tutorial and concepts to see how these ideas work in practice. It’s the fastest way to begin working with XIDs (though note that only the first two tutorials have been fully released at this point).

But if you want more details about why XIDs might be of interest to you, I’ve written a number of discussions that I think address why a variety of people might be interested in XIDs or why they might be reluctant to use them. See if one of them addresses your situation. (And if none of them do, let me know your concern or issue, and I’ll be happy to add another discussion.)

Concerns that DIDs address:

• “I have self-sovereignty concerns”
• “I have privacy concerns”

issues you might want addressed before you adopt DIDs:

• “I already use DIDs”
• “I need a new technology to be novel”
• “I don’t need another standard”

After you’ve read any sections that interest you, you should jump to the conclusion.

“I have self-sovereignty concerns”; or
“I already use DIDs”

I’ve already written about the general issue with DIDs: that the standard allows developers to sidestep decentralization. Most specifically, the biggest problem I have with DIDs is that holder control never happened. That’s the prime thing that XIDs are meant to rectify.

Now “holder control” is a pretty bloodless term. But, it’s the heart of self-sovereignty, so when I say that DIDs don’t have holder control, I mean that they don’t have self-sovereignty either: you don’t control your identity (which was the whole point of SSI!).

A lack of personal control pervades the SSI ecosystem, starting with the fact that you typically can’t issue DIDs or VCs yourself. However, limitations on disclosure may be the most problematic. When an issuer produces a DID full of VC credentials and assertions, the issuers ultimately decide how disclosure of that information is managed. They might say that their VCs are all-or-nothing: that you have to disclose them in its entirety. Or they might allow you to redact parts of the information, but only specific elements that they allow. So, if you have an identifier that contains your name, age, and address, they might allow you to redact your age or your address when you publish the identifier, but say that your name always has to be there! If the word “allow” in there pisses you off, it should. They decide, not you.

XIDs flip all of this. They allow a decentralized identifier to be created and filled with signed assertions and other credentials. The holder then decides what’s shown and what’s not, to the specific granularity they want. This allows one person to have multiple identity contexts and an infinity of faces. These facades show different parts of a XID to different people, but it’s still all one XID: one identifier that the holder truly controls.

So why would you, as a DID adopter or someone concerned about self-sovereignty, choose XIDs? Because they hand control back to the holder of the identifier, as was always intended for self-sovereign identity.

“I have privacy concerns”

Great! XIDs are definitely the thing for you then!

The problem with DIDs as they’ve evolved is that they don’t prevent correlation. In fact, they often make it worse.

This is because your DID can be packed with correlatable information, possibly even including credentials and other assertions. It’s a big honeypot of data that’s been helpfully collected together, and that makes it easy to link it up to other things you’ve done online or even in the physical world, creating an even bigger honeypot of data to define you.

The solution to this problem is redaction: removing some of the information from the DID so that only the minimum necessary is shown (minimal disclosure). But DIDs usually limit the ability to determine what can be redacted to the issuer—and ultimately they’re only going to allow redaction if it runs parallel to their business interests. So, batches of information that are too big are often sent out with DIDs, and that makes it easier to collect them all together, and that makes it easier to create even bigger honeypots by correlation with other information. That’s the opposite of a privacy concern.

XIDs are designed under the fundamental assumption that issuers, verifiers, networks, and infrastructure providers may all act adversarially with respect to correlation and control. As a result, they support radical elision. The holder has the ability at any time to redact information down to the atomic level: any singular datum, or even any atomic part of that datum (e.g., a subject, a predicate or an object) can be redacted. Because privacy is a central concern for me, I’ve also introduced additional technologies to make this radical elision more powerful: salted hashes can disguise redacted elements that might be easy to guess, while Garner and Hubert are new transport technologies that make it even harder to correlate by providing support for hidden and offline use of XIDs. Though the current implementation doesn’t support BBS and other anti-signature correlation zk-proofs, the architecture is designed with them in mind. We already support quantum-resistant signatures and encryption.

I should note that privacy is always a bit of hard sell. You’re presumably reading this section because privacy is important to you, but if you’re on the fence, I suggest a new lens for looking at privacy: coercion-resistance. One of the big problems with loss of privacy is that it can lead to you being coerced. You might be forced to withdraw your political opinion online due to death threats if your online identifier was correlated with your real-life identity; or you might be forced to hand over your Bitcoins if your Bitcoin addresses became correlated with your home address or the home addresses of your loved ones. Protecting privacy protects you against coercion, and that’s a whole additional level of self-sovereignty: it’s literally sovereigny over yourself.

So why would you, as someone concerned about privacy, choose XIDs? Because they fight against the correlation that is the biggest threat to the privacy of not just your information but your actual self.

“I need a new technology to be novel.”

It is entirely fair to say that a new technology needs to bring something new to the table, especially if it runs straight against an existing technology (or in this case an existing standard!).

XIDs are.

Their novel elements include:

XIDs support deterministic encoding. Because XIDs build on my dCBOR and Envelope technologies, the data in XIDs is encoded deterministically: given the same input, it will be serialized in the same way across platforms and implementations. This enables reliable comparison, hashing, and signing and ensures the stability and reproducibility of the encoded form of the data across various platform ecosystems and implementations of code. This approach was explicitly abandoned in the IETF’s JWT ecosystem and was only partially reintroduced in JSON-LD through complex, and often layer-violating, mechanisms.

XIDs support radical elision. This deterministic encoding enables any element of data in an XID to be redacted or encrypted (what we call elided), down to the atomic level of individual entities within its system of semantic triples. This makes minimal disclosure practical by allowing you to provide differently redacted or encrypted versions of the same XID to different parties, preserving privacy by design. By contrast, redaction support in other technologies has been limited or optional to date (the IETF, for example, treats it as optional in SD-JWT), and this level of fine-grained elision represents a substantial step beyond that.

XIDs support progressive trust. Progressive trust is the ability to slowly expand what you reveal about yourself to other people over time. It’s how identity works in real life, but it hasn’t been the way digital identity systems work, because they’re often built on all-or-nothing data disclosures: a binary “trust or not trust” model. Progressive trust was built into XIDs from the start: it’s the only technology where gradients of trust are fundamental to the architecture.

XIDs are supported by radically private communication methods. Blockchain Commons has so far released two radically private communication methods that are closely linked to XIDs. Hubert supports communication through decentralized storage services such as BitTorrent and IPFS. Garner links XIDs to Tor communication. These are both radical new ways to communicate privately, without the need for centralization. We’ve built proof-of-concepts for each to show how they can be easily applied.

So why would you, who wants to see innovation, adopt XIDs? Because they’re indeed innovative. Deterministic encoding, radical elision, progressive trust, and the support of radically private communication are some of the most progressive ideas contained within.

“I don’t need another standard”

I hear you! You’re already committed to a standard, or you say the standards process is too slow so you don’t want to fight through the introduction of something new.

XIDs do not have to be a new standard because they’re a functional proof of concept. Certainly, I invite you to adopt XIDs if they fit your needs. They’re robust, they’re well supported, and we’ll continue to support them in the future. But that’s not the only way to see the advancement of the technological goals such as minimal disclosure and coercion resistance that are exemplified in XIDs.

Even if XIDs themselves are never widely adopted, they would be a success if their holder-centric capabilities become unavoidable requirements in future identity standards. In other words, XIDs demonstrate what future iterations of DID or mDoc could evolve to become, but only if we are willing escape the shackles of legacy and older architectures. If we are willing to do something major, then standards bodies can look toward XIDs for what is possible.

Ultimately, if the only way to ensure self-sovereignty and to protect privacy is to push for wider adoption of XIDs, I’ll do that, but I’d be even happier to see major standards pick up the core features of XIDs, which are also the ideals of our original self-sovereign identity movement that have been left by the wayside.

So why would you, who doesn’t need another standard, adopt XIDs? Because they can be a stepping stone. They’re a proof of concept meant to push their ideals into wider discussion and ultimately wider adoption. For now, adoption of XIDs as an alternative moves us along that path.

Conclusion

I am pushing XIDs because there are historic stakes. Maintaining the self-sovereignty of identity is important because centralized identity repositories can be horribly misused. DIDs were supposed to accomplish that, but they’ve compromised by failing to unequivocally hold the line on the core values of decentralization.

As a result, we need to point out their flaws, offer alternative technologies that can do what they fail to, and use that as the foundation of a new revolution in self-sovereign identity. XIDs (along with several related Blockchain Commons technologies) are my Declaration of Independence from the current DID standard. I invite you to join that declaration so that we can together argue for the true self-sovereignty and true privacy that are missing from today’s DIDs.

Here’s what you can do to support the revolution:

• Join the Gordian Developer Community to talk about these technologies.
• Join the SSI 10th Anniversary Community to talk about the future of self-sovereign identity.
• Read more about XIDs on our developer pages.
• Try out the XID Tutorial on GitHub and submit issues for any questions you have.

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.

Following is the year in review!

You may also wish to view our 2026 Technology Overview, which briefly describes 21 of our technologies and reference apps:

Community Support

As we wrote in 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 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, a UR Playground, and a full IDE for Blockchain Commons. Thanks, folks, we love working with you!

For more, see our Meetings developer page and subscribe to our Gordian Developer announcements, either through our mailing list or Signal group.

ZeWIF

Early in the year, we also became involved with a totally new community: the Zcash developers community. Based on a Zcash Community Grant, we designed and developed 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.

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 included discussion of how to expand Known Values 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.

FROST

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, 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, 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). 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).

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” and is a parallel to our (out-of-date but popular) “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, which can verify FROST signatures (as long as everything matches the format used by ZF FROST).

Thank you as ever to HRF, 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, 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, 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 on Gordian Clubs, released a CLI and a Rust library, and demoed how it worked at our October Gordian meeting.

For more see our Gordian Clubs developer page.

Hubert

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, the Dead-Drop Hub.

Hubert takes advantage of existing distributed storage systems (BitTorrent, IPFS), combined with Gordian Envelope features including 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 (demo) as well as a CLI specifically for conducting FROST ceremonies with Hubert (demo). Check out our BCR research paper for more on the system!

For more, see our Hubert developer page.

Provenance Marks

Provenance Marks 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 and gave a presentation. Also see our research paper.

For more, see our provenance mark developer page.

XID

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 but also because we wanted to offer the foundation for a decentralized digital identity that had redaction capabilities. That comes courtesy of Gordian 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 last year, just before we released our research paper. This year, we added considerable XID functionality to our envelope-cli tool. Just type “envelope xid -h” for a list of options. We’ve also been working on and off on a XID Quickstart, 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 about a partnership that would allow us to prioritize the work!)

For more see our XID developer page.

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”, then he shepherded its growth through his Rebooting the Web of Trust workshops.

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 and HackerNoon last year and presented to Switzerland on Swiss e-ID and at TabConf 7. A lot of that included advocacy for better self-sovereign identity, which also led to Blockchain Commons signing the No Phone Home initiative. Finally, Christopher wrote some related Musings last year, on Fair Witnessing, on topics related to GDC25, and on the anchors for preserving sovereignty and autonomy that we suggested to Switzerland.

Our new Revisiting SSI project 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, and we’re continuing that work through 2026, which is the 10th anniversary of SSI.

For more see the Revisiting SSI website.

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.)

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, 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)

ZeWIF Meetings (Early 2025)

Revisiting SSI Meetings (Late 2025)

Learning Bitcoin from the Command Line is one of Blockchain Commons’ oldest initiatives, predating the formation of the organization. The foundational work on the project was supported by Blockstream, where Christopher Allen was working as Principal Architect at the time. The earliest parts of Learning Bitcoin from the Command Line simply showed how to get Bitcoin installed and running on your local machine, an idea that we’ve returned to a few times, in our Bitcoin Standup Scripts (which are also being updated, making them fully usable again) and Gordian Server.

However, Learning Bitcoin from the Command Line quickly grew from that foundation to become a full course on Bitcoin, explaining how it worked, and demonstrating all of its intricacies. The command-line part of the course, which largely focused on bitcoin-cli, offered hands-on examples so that a learner could follow along, increasing the impact of the learning. The ultimate goal of this expanded course was to help bring new developers into the Bitcoin ecosystem.

We’ve been very proud of the course over the years because of its obvious impact. Hundreds of forks and thusands of stars on GitHub told us that the course had gained traction. But it was really when we started to meet developers (including some of our interns) who had gotten into Bitcoin programming due to the course that we knew that our work had been successful. We’d accomplished our goal, but a bigger challenge lay ahead …

The problem was that Bitcoin was constantly evolving. Each new release of Bitcoin Core, of which there tend to be a few a year, offered new features, deprecated old features, or brought in whole new paradigms that had been decided upon by the Bitcoin community. That meant that the course was constantly being outdated. Shortly after we moved the course over to Blockchain Commons under lead tech writer Shannon Appelcline, we released a full 2.0 edition. Then, with the support of interns, we released an updated 2.1 edition in 2021, followed by translations into Portuguese and Spanish later in the year.

Since 2021, Bitcoin has incorporated major updates such as Signet, Taproot, and descriptor wallets, while Segwit (just coming into wider usage when we last wrote) has become the default address type. Learning Bitcoin was not updated for these advancements because our patrons were interested in other work, from Animated QRs to post-quantum cryptography. The course remained a terrific resource, but slowly grew more out of date.

That’s why we’re so thrilled by HRF’s 2026 grant. It gives us the opportunity to bring one of Blockchain Commons’ most prestigious projects up to date. We’re planning it as a year-long effort (intermingled with our other work). Our TODO details all the work: we’re going to be updating to major new features, rechecking all of the code, and then (as time allows) improving the pedagogy with some new visual learning. If you want to follow along with the work, you can find it in the lbtcftcl-v3.0 branch (but be aware, it’s literally a work in progress!).

Updating Learning Bitcoin from the Command Line is an exciting project, and we hope the course will once more be a gateway to bring new Bitcoin developers into our ecosystem when it’s done. We thank HRF for the opportunity!

At the time, I asked for support in refining those principals. And, we tried: at ID2020, Rebooting the Web of Trust, IIW, and elsewhere. But for nearly a decade, the original principles have remained largely unchanged, inspirational yet sometimes misunderstood.

Now, in 2025, as the Self-Sovereign Identity movement turns ten next year, I’m renewing that invitation. And I’m asking for your participation.

📌 The 10-Year Revision Project

The 10-year SSI Revision Project is an effort to revisit and refine the original SSI principles, not as a rigid standard, but as a living framework for people designing, governing, and deploying identity infrastructure that respects and protects the people it serves.

SSI is no longer a theory. Its infrastructure has been adopted by governments, companies, communities, and protocols. As that adoption accelerates, the foundational values must evolve to meet today’s ethical, legal, and technical challenges including coercion, use of biometrics, AI agency, exclusion by design, and gamified behavioral manipulation.

The goal is ultimately to revisit old principles and to propose new ones while making a renewed call to protect the dignity of all identity holders.

📅 Join the Collaboration

To support this project, I’ll be hosting a series of open online calls over the next year to co-develop and discuss revised principles, new proposals, and system guidance. These sessions will welcome technologists, designers, researchers, regulators, and community stewards from across the SSI and identity ecosystem.

Kickoff Meeting 1 — EU/US time compromise

• Tuesday, December 2nd, 2025
• 10:00am PT / 7:00pm CET

Kickoff Meeting 2 — EU/Tokyo time compromise

• Tuesday, December 9th, 2025 (Tokyo local)
• 3:00pm Tokyo / 7:00am CET / (10:00pm PT Monday for the host)

The goal of these first two meetings is to discuss opportunities for different topics, with the goal of writing up some initial rough “concept papers” (ala RWOT’s “topic papers”) to scope some of ideas that people have of what needs to be done.

Hopefully you’ll join us for these initial calls. No longer commitment is required, but the intent is to investigate your participation in writing some papers on this topic by May! However, the most important thing is ultimately that your ideas and your feedback help to shape the continued development of Self-Sovereign Identity.

Please let me know that you’re interested in joining us!

🧭 Team Topics

If we get enough participation, I expect we may split up into teams, to cover some of the various topics that bear discussion as we rethink SSI.

Some early broad topics that we are considering currently are:

1. Beyond Property: Principal Authority and the Legal Foundation of SSI. Agency law, principal authority, and revamping or expanding the SSI principles based on them.
2. Anti-Coercive Design and Cognitive Liberty. Avoiding coercive design, which will likely include more academic discussions of philosophy and may reveal new principles.
3. From Principles to Properties: Operationalizing SSI. A deep dive into the CSSPS 42-property framework published in IEEE Access, looking for objective design principles that might contribute to SSI. And forward from that.
4. More Than a Digital Shadow: Rewriting Principle 1 – Existence. Reclaiming the original intent of the first principle, that every person has an identity that precedes any digital system, drawing on generative identity, Ubuntu philosophy, feminist sovereignty, decolonial theory, legal personhood guarantees, and real-world harms.

The intent is to write articles on each of these topics, and hopefully some more, by May 2026, in time for the anniversary and to use those articles to revise, revamp, and expand the original principles. But to get there from here, we need to start coordinating now!

🌱 Why This Matters

SSI has always been more than a technical spec. It’s a movement for restoring dignity, agency, and trust in a digital world that too often erodes all three. As its adoption spreads, we must ensure that the principles at its foundation still serve the people they were meant to protect.

Let’s not let another ten years pass before we act.

📙 Requested Reading

I’ve written a number of articles about SSI over the years. I think three of them are particularly important to these discussions, and I suggest that people read them as part of this process:

• The Path to Self-Sovereign Identity (2016). My original article, which lays out the pre-history of SSI and the initial 10 principles.
• Origins of Self-Sovereign Identity (2021). A look at the philosophical and political roots of SSI, including its lineage in civil liberties, cryptographic activism, and human rights frameworks.
• Principal Authority: A New Perspective on Self-Sovereign Identity (2021). How identity should not be framed as property, but as a domain of agency governed by fiduciary duty and inalienable rights.

I am also working on an annotated syllabus of some of the most important papers and articles published the last 9 years. I’ll share my initial pass before our first meeting in December.

For more info on everything, see the Revisiting SSI website.

🤝🏼 Join Us

Some of the people that have expressed interest in joining us for this effort are Kim Hamilton Duffy (DIF), Rodolfo Costa (University of Coimbra), Georgy Ishmaev (Inria), Vinay Vasanji (EF), Ian Grigg, and Philip Sheldrake. This includes a mixture of both critics and supporters of SSI, coming from a variety of backgrounds, from academia to technology. What we are weak on so far are people from law and regulation.

You can email me directly and let me know you’d like to be involved, or sign up for an announcements-only #RevisitingSSI email list or alternatively join our Signal group, which we’ll be using to coordinate our initial calls.

If you or your organization wishes to demonstrate its support for goals of Self-Sovereign Identity, I am seeking financial sponsors for this project. Contact me about different sponsorship opportunities, or you can directly support my work on these kinds of efforts via GitHub (via a one-time donation or ongoing monthly patronage) at https://github.com/sponsors/ChristopherA.

I look forward to collaborating with you!

ABSTRACT: Digital infrastructure is built on sand due to its control by centralized entities, most of which are focused on profit over service. We need Exodus Protocol services that build infrastructure without centralization, ensuring its continuation into the far future. Bitcoin offers our prime example to date. Five design patterns suggest how to create similar services for coordination, collaboraiton, and identity.

It’s 2025. Digital infrastructure has become the heart of not just our economy, but our culture.

But it can be taken from us in a heart beat.

Those of us in the decentralized space have warned against this future for a long time, but it first hit me in a truly visceral way a decade ago when I was teaching technology leadership at Bainbridge Graduate Institute. I supported my students with a powerful coordination system that tied together del.icio.us bookmarks, Google Reader, and Google Docs. My students could discover information through RSS feeds, collaboratively bookmark and annotate it, and then work with their peers using that shared data. It was an effective tool for both learning and cooperative action that was soon adopted by the whole school.

But then Yahoo sold del.icio.us and Google shut down Reader. Without warning, without a chance to migrate, our learning community’s entire digital infrastructure collapsed. A generation of learners was quietly deplatformed from the tools that had empowered them to think, share, synthesize and learn together.

By now, everyone probably has a story of digital infrastructural loss. How they lost their Google+ circles. How their internet radio turned off forever one day. How their digitally stored MP3s disappeared into the ether. It’s a pattern that’s encouraged by the perverse incentives of capitalism. A useful service becomes essential infrastructure. Companies move in to collect rent on the technology. Then, they exert their power by reducing features and increasing distractions. Eventually, it becomes non-profitable and they kill it. (Cory Doctorow calls this pattern enshittification.)

Which leads to the question that haunts me: how can we create digital infrastructure that can’t be taken from us?

Enter the Exodus

To resolve this problem, we need what I call Exodus Protocols. These are systems that free us from the control of external sources (like Google or Yahoo! or Sony) by creating infrastructure that doesn’t require infrastructure.

What in the world do I mean by that?

There’s actually a well-known Exodus Protocol: Bitcoin. It provides financial infrastructure, allowing users to transfer value among themselves, but it does so without enshrining permanent infrastructure or empowering centralized authorities.

Miners can come and go. Full nodes can exist as services, but you can also spin them up locally. Some type of network is important for miners to collect transactions and form them into blocks, but the average user doesn’t need that: they can create their own transactions air-gapped and transfer them using QR codes. It’s generally hard to censor Bitcoin, and it would be unthinkable for the entirety of it to disappear in any short amount of time.

Bitcoin demonstrated something profound: that fundamental capabilities can exist as mathematical rights rather than centralized privileges. When your ability to transact depends on a bank’s approval, it’s not a right, it’s permission. Bitcoin restored transaction as a right through autonomous infrastructure. That’s an Exodus Protocol.

Unfortunately, Bitcoin only creates an Exodus Protocol for a small (but important) corner of what we do on the internet: value transfer. It does have some cousins, such as IPFS for data storage, but there aren’t great Exodus Protocols for the vast majority of what we do within the digital sphere. We need more Exodus Protocols, to free us from dependency on centralized services, so that our carefully constructed infrastructures don’t suddenly disappear, as happened for my students at BGI. We need to empower coordination (whether it be for my students or a board of directors), collaboration (at a forum or on a shared artists’ whiteboard), and identity (to correct the missteps made by the self-sovereign identity movement).

Five Patterns for Creating Autonomous Infrastructure

An Exodus Protocol is only successful if it’s designed to actually empower through autonomous service. We don’t want to just create a new digital prison. To design for success requires five architectural principles that help to create the architecture of autonomy itself.

An Exodus Protocol must …

1. Operate Without External Dependencies

If something requires permission to operate, it’s not autonomous. If it stops working when a company fails or a government objects, it’s infrastructure built on sand.

We instead need truly independent architecture. This can be accomplished either through objects that are self-contained, with everything needed for operation either within the object or derivable through math (e.g., autonomous cryptographic objects such as Gordian Clubs); or through distributed operations without centralization, where any operator can be replaced.

₿ — Bitcoin’s approach: Bitcoin took the distributed approach, with validation, verification, and recording of value transfers done by hundreds of thousands of replaceable independent nodes. There’s no central server or authority.

2. Encode Rules in Mathematics, Not Policy

Policy means that someone else decides how a service works. They can make arbitrary or biased decisions. They can succumb to coercion, and they can censor.

In contrast, math doesn’t discriminate, doesn’t take sides, and doesn’t change its mind under pressure. Replacing policy rules with mathematical rules means introducing cryptographic proofs such as private keys and signatures. They make verification deterministic: the same inputs always produce the same outputs.

₿ — Bitcoin’s approach: With Bitcoin, the control of value is ultimately determined by who holds a private key. Sophisticated systems such as threshold signatures and secret sharding offer more nuanced control.

3. Make Constraints Load-Bearing

Constraints make systems less flexible. But, that’s not necessarily a bad thing. We just need to ensure that those constraints serve dual purposes by also supporting a system’s autonomy.

We must be aware of what constraints mean: how they’re helpful and how they’re harmful. Then we must design constraints that create the autonomous infrastructure that we want. As an example: if a credential can’t expire, then it works forever. Similarly, if it can’t be revoked, then it offers perfect access to past content.

₿ — Bitcoin’s approach: Bitcoin offers a number of constraints that strengthen its autonomy largely by building upon mathematics rather than arbitrary policy. Transactions can’t be reversed, which means: 🟥 that you can’t walk back a mistake; but also that 🟢 your funds can’t be seized by fiat. Rules changes require consensus, which means: 🟥 that important updates can require months or years of coordination; but also that 🟢 your funds can’t be threatened by an arbitrary increase of supplies.

4. Preserve Exit Through Portability

Centralized systems lock you in, which is the opposite of sovereignty. True autonomy requires not just the ability to leave, but the ability to take everything with you. Without the ability to walk away, consent collapses into coercion.

Escaping lock in requires interoperability and open standards. Data and credentials must be portable across implementations without proprietary formats that trap users.

₿ — Bitcoin’s approach: Bitcoin keys work in any wallet. Standards for the use of seeds to generate HD keys and the use of wallet descriptors further this interoperability.

5. Work Offline and Across Time

Infrastructure that requires connectivity can be denied connectivity. Infrastructure that requires specific platforms can be denied those platforms.

True autonomy works with whatever channels remain available when coercion attempts to deny others. It requires asynchronous operations, creating services that work during outages and across decades regardless of infrastructural changes.

₿ — Bitcoin’s approach: Bitcoin transactions can be signed offline and broadcast later. The protocol doesn’t care about internet connectivity for core operations.

Foundation, Not Fiat

Not every digital service needs to be an Exodus Protocol. In fact, there are definitely services where you want centralization. You want more vulnerable people to be able to recover their funds in case of fraud. You want parents to be able to act as guardians for their children.

But there are services that are irreplaceable and so would benefit from Exodus. These are digital services that store data, create identity, and manage assets that would be difficult to replace. And there are times when Exodus Protocols become more important than ever: when we’re under threat, under siege, or just struggling to survive.

We still want to offer the ease of access and usability of centralized services in those situations where they’re appropriate, but we want to build those centralized services upon a strong, unwavering foundation of Exodus. If the centralized services fail, there must still be foundations that cannot fall.

Exodus Technology

Early in the month, I introduced Gordian Clubs. They’re another example of the Exodus Protocols that I discuss in this article.

Here’s how Gordian Clubs, which are Autonomous Cryptographic Objects (ACOs) that can be used to coordinate (by sharing data) and collaborate (by updating data), fulfill the five patterns.

(This is a repeat of a list from the Gordian Clubs article.)

Gordian Clubs …

1. Operate Without External Dependencies. Everything you need is within the Gordian Club: data and permissions truly operate autonomously.
2. Encode Rules in Mathematics, Not Policy. Permits are accessed through mathematical (cryptographic) constructs such as private keys or secret shares.
3. Make Constraints Load-Bearing. Members can’t be removed from a Gordian Club Edition, but that also means permissions can’t be unilaterally revoked. Gordon Clubs don’t have live interactivity, but that means they can’t be censored by a network.
4. Preserve Exit Through Portability. An ACO that can be freely passed around without network infrastructure is the definition of portability.
5. Work Offline and Across Time. Gordian Clubs are meant to be used offline; archival is a major use case, allowing access across a large span of time.

There are numerous other technologies that can enable Exodus Protocols. Many of them are puzzle pieces that could be adopted into larger scale solutions. These include:

• QR Codes. Data that can be printed or displayed on air-gapped devices and that can be automatically read into other systems.
• Bluetooth. Another method for transmitting data when networks are down.
• Threshold Signatures. A method of coordination (signing) that typically does not require live interactivity.

Though we haven’t previously used the term, Blockchain Commons technologies are often built as Exodus Protocols:

• Animated QRs. Animation extends QRs to allow the automated transmission and reading of larger quantities of data.
• Gordian Envelope. Envelopes are built to allow selective disclosure of information without a network. They’re the foundation of Gordian Clubs.
• XID. Also built atop Gordian Envelope, XIDs (eXtensible IDentifiers) are decentralized identifiers that are truly autonomous, avoiding the failures of the SSI ecosystem.

From Five Patterns to Six Inversions

The threat of our digital infrastructure being taken away from us is part of a larger issue that I call “The Six Inversions.” It’s the systematic transformation of rights into revokable privileges in the digital world.

In the physical world, we have property rights that assure us of access to infrastructure, but in the digital world, centralized entities can take away that infrastructure at any time for any reason. We have no rights to property, to justice, to transparency, or to exit. Our contractual power is neutered, and our identity is sold. As a result, digital infrastructure is unstable, which is why we need to create infrastructure without infrastructure, in the form of Exodus Protocols.

I’ll write more about the Six Inversions in the future, but for the moment I wanted to point it out as an underlying philosophy for why digital infrastructure is unreliable and must be reimagined.

It’s because we don’t have the rights that we expect from the physical world.

Conclusion

As I said, Exodus Protocols aren’t for everyone or everything, but there are situations and services where they’re critical.

When we’ve identified these cases, we can then deploy Exodous Protocol patterns: operating without dependencies, encoding rules in mathematics, making constraints load-bearing, preserving exit through portability, and working offline across time. This creates a blueprint for infrastructure that holds when everything else fails.

What is your critical infrastructure? What have you spent years building and would be hurt without? What infrastructure’s loss would damage your ability to identify yourself, to communicate, to cooperate, or to collaborate? I’d love to hear what they are and to work with you to design the next generation of autonomous infrastructure.

Bitcoin is just the beginning.