I noted this briefly in my recent Dispatch on Technology Paternalism, but the new mandate deserves its own treatment. When Vitalik talks about working to “preserve technological self-sovereignty” and “enable cooperation without coercion, domination or rugpulling,”³ something is happening that those of us working on Exodus Protocols, Architectures of Autonomy, and coercion-resistance lenses of Self-Sovereigh Identity should pay attention to.

This Dispatch is about what Vitalik and the Ethereum Foundation are saying, where it overlaps with what I’ve been saying, and where the work goes from here.

What Vitalik Said

Vitalik’s March 3 posting introduced the idea of sanctuary technologies:

“Ethereum should conceptualize ourselves as being part of an ecosystem building ‘sanctuary technologies’: free open-source technologies that let people live, work, talk to each other, manage risk and build wealth, and collaborate on shared goals, in a way that optimizes for robustness to outside pressures.”¹

He added to that framing by talking about the creation of a collaborative space:

“Ethereum’s role is to create ‘digital space’ where different entities can cooperate and interact.”¹

Instead of trying to compete with Apple or Google, his goal is “de-totalization”:

“Do not try to be Apple or Google, seeing crypto as a tech sector that enables efficiency or shininess.”¹

“[instead] reduce the stakes of the war in heaven, by preventing the winner from having total victory.”¹

When Vitalik announced the EF mandate on March 13, he repeated his framing, saying that Ethereum is to be “a sanctuary technology, to preserve technological self-sovereignty, to enable cooperation without coercion, domination or rugpulling,” ensuring “no single person, organization or ideology’s victory in cyberspace can be total.”³

This is not isolated to Vitalik. Bastian Aue, whose appointment as Co-Executive Director was announced in February, said it more bluntly in his own statement at the time:

“The mandate of the EF is to make sure that real permissionless infrastructure, cypherpunk at its core, is what gets built.”⁴

As for the mandate itself? It makes a lot of the self-sovereign ideas that Vitalik talks about in his personal posts concrete by requiring Ethereum to have the property of CROPS⁵: Censorship Resistance; Open Source and Free, as in Freedom; Privacy; and Security. It also emphasizes long-duration survival by highlighting a walkaway test: could Ethereum continue to function without the Ethereum Foundation?²

All together, this is a pretty big commitment to self-sovereign ideals, and one worth talking more about.

Where Sanctuary Meets Exodus

I’ve been talking about self-sovereignty since I introduced the term in “The Path to Self-Sovereign Identity”⁶, the principals of which I’ve been updating through the Revisiting SSI project⁷. Recently, I wrote about self-sovereignty from the perspective of Exodus Protocols⁸. I define them as “systems that free us from the control of external sources (like Google or Yahoo! or Sony) by creating infrastructure that doesn’t require infrastructure.” Bitcoin is my prime example of a working Exodus Protocol.

My discussion of freedom from external control is a good match for Vitalik’s discussion of optimization “for robustness to outside pressures.” Generally, I feel like his Sanctuary Technologies match a lot of my Exodus Protocol patterns for creating autonomous infrastructure⁸:

1. Operate Without External Dependencies.
2. Encode Rules in Mathematics, Not Policy.
3. Make Constraints Load-Bearing.
4. Preserve Exit Through Portability.
5. Work Offline and Across Time.

Vitalik’s call for “technological self-sovereignty” aligns with patterns one and two while the discussion of survivability mirrors points from patterns four and five. The CROPS priority stack reveals the reason for many of these patterns, something I discuss further in Revisiting SSI lenses such as “Coercion Resistance”, “Self-Coercion”, “Choice Architecture & Exit Rights”, and “Binding Commitments”. Vitalk even reaches for the term “tech enshittification / corposlop”¹ — which is Cory Doctorow’s term that I have also used in describing why our digital infrastructure is built on sand.

I do feel like there’s one major difference, however: Sanctuary Tech is a goal while Exodus Protocols are an architecture.

Vitalik’s test for Sanctuary Tech is functional: robustness to outside pressures. By that test, his examples include Starlink, locally-running open-weight LLMs, Signal, and Community Notes.¹ These are good things, and at the present moment they meaningfully expand human autonomy. But Starlink is centrally owned by a single corporation. By my Five Patterns, Starlink fails Pattern 1 (Operate Without External Dependencies) and Pattern 2 (Encode Rules in Mathematics, Not Policy). It is liberating today, but it’s not architecturally resilient against the day whoever owns it changes their mind. Similarly, Signal has a dependence on access to a cell phone with a cell number.

The EF Mandate’s test is sharper than the X post. Walkaway resistance and long-duration survival are closer to the Exodus framing. But the gap remains: Sanctuary Tech describes what we want, while Exodus Protocols describe what is needed to deliver it.

This is the same gap I’ve been working in the Architecture of Autonomy and the Revisiting SSI coercion-resistance lenses: the difference between naming a value (privacy, decentralization, sanctuary) and engineering it as a load-bearing constraint that holds when the political wind changes.

What’s the Next Step

The Ethereum Foundation has named the right goal. The work now is the architecture.

Concretely, three things would help:

1. Cross-pollinate the conversations. The identity community has spent ten years working through the failure modes of sovereignty claims, including our own. The Ethereum Foundation has spent ten years building the most credibly-neutral programmable infrastructure on the planet. The lessons translate in both directions. The work has been siloed for too long, and the Revisiting SSI initiative is one venue where that cross-pollination can happen.

2. Test Sanctuary Tech candidates against the Five Patterns. Starlink does not pass. Signal does not pass. Some Ethereum protocol-layer mechanisms, such as FOCIL for inclusion lists, encrypted-mempool proposals, and account abstraction at the right layer, plausibly do. The LEAN Ethereum roadmap and the post-quantum work the EF has named are candidates that deserve to be examined as Exodus Protocols, not merely as performance or security improvements. The Five Patterns work as a checklist.

3. Apply coercion-resistance lenses to wallet and L2 architectures. Finally, we can revisit the RSSI lenses for coercion and apply them to wallets. Though they were built for identity, they’re agnostic about which stack they analyze, and Ethereum’s wallet layer deserves the same scrutiny that we have brought to digital identity wallets. Unfortunately, we already know that many “sanctuary technology” candidates, especially wallets, currently ride on the same Apple/Google attestation infrastructures that we identified as compromised in EUDI wallets.

We are at an unusual moment. An institution with the resources, talent, and protocol surface area of the Ethereum Foundation has just declared, in writing, that it considers itself in the business of building infrastructure that can’t be taken away. That alignment with the Exodus Protocol thesis is rare. It is also fragile: the EF’s executive leadership has turned over twice in the last twelve months⁹, and institutional resolve in technology rarely outlasts the people who first articulated it. Wo we need to take advantage of this opportunity now.

If you are building anything you would call a Sanctuary Technology or an Exodus Protocol, I would like to talk. My Architecture of Autonomy draft is open for community comments, the Revisiting SSI lenses are open, and the Exodus Protocol patterns are public. The Ethereum Foundation has named the goal.

We must use that opportunity to build a foundation that won’t fall.

Citations

I did not expect what happened next.

Those ten principles — which I had written more as a first draft than a manifesto — became the conceptual foundation of an industry. They have accumulated more than a thousand academic citations. They’ve been quoted, adapted, debated, critiqued, translated, and deployed in contexts I could not have imagined. They anchor work on decentralized identifiers and verifiable credentials, show up in United Nations discussions, and (occasionally) on conference T-shirts. And for most of a decade, they have stayed largely unchanged.

That is, in part, a compliment. And in part, a problem.

Principles written in 2016 could not have anticipated the commodification of behavioral data at the scale we now live with, the normalization of mandatory digital ID as a precondition for civic life, or the ways “self-sovereign” would come to be invoked at the protocol layer, in regulatory filings, and at venture pitches, by organizations whose interests are not the same as the interests of the people the principles were meant to protect.

Capital flows to centrality. We wrote the principles loosely enough that the loopholes were exploitable. And they have been exploited.

I have spent much of the last year talking about this with others in the RevisitingSSI project — working circles on principal authority, anti-coercive design, properties vs. principles, and what it means to exist at all in a digital age. Those conversations, with academics and standards people, with civil society practitioners and critics that I learn from, have convinced me that the original ten were not wrong. They were incomplete.

Today, on the ten-year anniversary, I am publishing the first community draft of a revision:

Principles of Self-Sovereign Identity — 2026 Revised, First Community Draft

A stable archival copy is mirrored at revisitingssi.com/library/ssi-principles-2026-redline/ for permanent reference.

The draft keeps the 2016 language verbatim wherever it survives, so continuity stays legible alongside revision. It updates each original principle, introduces six new ones (Inalienability, Cognitive Liberty, Relational Autonomy, Stewardship, Equity, Anti-Coercive Design), and organizes all sixteen principles into four layers: foundational, relational, technical, and political.

It is unfinished on purpose.

I am publishing it in redline form, on the anniversary, precisely because I do not want it read as a press release. I want it read as a draft: a draft I expect others to push back on, to correct, and to sharpen. That is what I asked for in 2016. It is what I am asking for again.

What has changed is that I now know how long this work takes, and how much of the work that the community has to do.

If you have been in SSI for any length of time — whether as a believer, a skeptic, or both at different hours of the day — the Google Doc is open. Leave comments. Argue in the margins. Tell me where the new language is weaker than what it replaced. Tell me which of the six new principles I should not have added. Tell me which ones I am still missing.

I will be at the Internet Identity Workshop in Mountain View this coming week (April 28–30), as a guest on the W3C Credentials CG call on May 5 (9am PDT / 12pm EDT / 6pm CEST), and hosting a dedicated community discussion on May 20 (10am PDT / 7pm CEST). The goal between now and September, when we aim to present a more mature version at the Global Digital Collaboration summit in Geneva, is to take the redlines from “first draft” to something worthy of the next ten years.

If you would like to be part of that, join the announcements-only email list, the Signal group, or simply open the doc.

The goal is not to settle the questions of self-sovereign identity.

The goal is to make these principles worthy of the next ten years.

Today that concern is more important than ever because of the deployment of LLM-driven agentic systems. We can increasingly empower agents in the digital ecosystem to compile our searches, to augment our coding, and to generally solve our problems. But how do we do so in a way that supports our autonomy rather than eroding it?

What follows are three views of the agentic future: two problems we need to address and one solution that we can look forward to. They reflect some of the current work I’m doing with various groups on AI, agency, and the future of computing.

View #1: The Authority Problem

The nature of human agency is rapidly changing due to the possibility of agentic delegation and augmentation. Once you could say that an individual’s agency would be maintained by their purposefully and mindfully agreeing to all actions undertaken by an application. But that’s no longer possible when agents can act at superhuman speeds that are too rapid to actively monitor. Maintaining agency therefore requires a change from tactical overview (agreeing to every action) to strategic overview (agreeing to the scope of action and setting boundaries for the activity).

Fortunately, we already have a model that supports this sort of strategic control while maintaining agency: “Principal Authority”. It’s literally part of the Laws of Agency, which define how an agent can be empowered to take on certain tasks. Back in 2021, my work with the Wyoming legislature helped to bring it into the world of digital identity by defining your digital identity as something over which you have Principal Authority.

Following the implicit understanding that an individual has control of their identity, the most important element of Principal Authority is probably its definition of duties. When you are temporarily extending your identity to others, including agents, they must promise to use it in certain ways. Those duties should include many of my original self-sovereign principles, including access, interoperability, minimization, portability, protection, and transparency, as well as many others: agents must work for you in good faith, must put your interests above those of theirs (or rather those of their corporate masters), and must act with reasonable care.

Again, a state legislature has taken the lead on this work. Just this year, Utah passed the state-endorsed digital identity (SEDI) amendment, which includes a full digital Bill of Rights. Among those Rights is a “Duty of Loyalty”, which says that processors of digital identity must act in the identity holder’s best interest.

Creating similar duties and requirements for LLM agents, to ensure that they are working for you, without hidden agendas, is a crucial milestone as the AI era quickly dawns. Principal authority should be a model for doing so. We must use it to answer questions like: Who is an agent delegating from? What is it tasked to do? How can it undertake that task in the way that best protects the Principal and their data? What are the constraints placed on the agent?

I’ve suggested some “predicates” for the Gordian Known Value system that might start to address some of these issues, by allowing users and their agents to record things like:

• principalAuthority — The entity with authority over the work
• assertsDelegationFrom — Agent’s claim of delegation from a principal
• delegationScope — Boundaries of delegated authority
• delegationConstraints — Specific limitations on the delegation

But, it’s a starting point, not an end-point.

View #2: The Credit Issue

When you’re using an agent, even if your authority is being protected, another question arises: how do you credit work done?

This isn’t actually a new problem created by AI. Ghost writers have existed for centuries. Collaborations have always involved complex divisions of labor that don’t map cleanly to “author” and “contributor”. What AI does is make the gap undeniable. When an agent is performing actions (or moreso: creating content), we can no longer quietly elide the distinction between “who wrote this” and “who is responsible for it.”

The ghost is visible now.

The question is how we can properly note which work is entirely ours and which is LLM driven. But, it’s not even that simple, as LLMs could be trained largely on our own work, rehashing our arguments and knowledge, or they could be built on the summed-up Wisdom of the Crowd. How do we differentiate between those two situations? And how do we give fair notice to readers who may think differently about spending their time reading an LLM-authored piece, an LLM-supported piece, and a human-written piece?

As I said, the problem goes beyond LLMs and is fundamentally about credit in authorship. Again, I’ve suggested some predicates as a starting point, with my focus not on the question of AI input, but instead what the roles are in a creative process. Those predicates currently include: Author, Editor, Architect, Designer, Manager, ConceptOriginator, Documenter, TechnicalProducer, Curator, Reviewer, Maintainer, MaterialContributor, Performer, IntellectualContributor.

Do we need more? Less? And are these sufficient to also define LLM-driven work on a piece?

View #3: The Self-Sovereign Computing Solution

Though I’ve talked so far about the work I’ve been doing on issues (or at the least, “new questions”) that are arising from the LLM revolution, it’s also important to talk about some of the advantages. And one of the advantages is a growth in the potential of a topic that I’ve addressed before: self-sovereign computing.

In my original article on “self-sovereign computing”, I talked about how you could control your digital destiny by running your own tools on your own local machine. It was yet another way to address the issue of agency.

Local AI on your own silicon is Self-Sovereign Computing in practice. Apple Silicon + MLX + local models make it real infrastructure. There’s no cloud dependency, no data leaving your machine, no subscription toll. Your data stays on your device. Your inference runs on your hardware. No API key is required.

It’s also really coming of its own. Some recent advancements in leveraging the M-series silicon have doubled the inference speed of certain models:

Metal (Q4_K_M quantization):

MLX (nvfp4 quantization):

We built Self-Sovereign Identity so that your keys and credentials could stay under your control rather than being held by a platform that could revoke them. Local inference is the same principle applied to AI: the model runs where you do, on hardware you own. Combined with a self-sovereign wallet holding your keys and credentials, this is a complete stack where nothing about your digital life requires asking permission from a third party.

Final Notes

I’ve long written that identity is a double-edged sword. If wielded right, it can provide us with considerable power, but if wielded wrong, it can wound us fatally.

The same is true of the agentic power being unleashed by the LLM revolution. The possibilities of self-sovereign computing show how this power could be turned to our advantage, truly empowering the self-sovereignty that I’ve long advocated. However, the credit issue demonstrates the new (or at least newly highlighted) questions arising from agentic use, while the authority problem reveals that we need to carefully construct guard rails for this new technology.

If you’d like to talk more about these possibilities email me. I’m also looking for sponsors and partners to support me in doing more of this work.

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)