The short answer is that proliferation is not actually the deepest problem (and I say that having spent thirty years architecting trust systems and watching credentials standards evolve to the ones we have today, and having co-authored TLS 1.0). Instead, it’s that most of the existing formats share a small number of design choices that I think are wrong.

As an example, I watched cryptographic agility get oversold in the ’90s, retrofitted with ciphersuite negotiation, exploited through downgrade attacks, and finally walked back in TLS 1.3. That arc isn’t unique to TLS. It shows up everywhere: optionality has long been treated as a design feature rather than a liability. JOSE is the most recent and visible example. The alg header put attackers in the verifier’s seat, and the standard has spent a decade patching around it rather than admitting the choice was wrong. There are any number of situations like this where our design choices were wrong, including not just in-band algorithm negotiation, but also signature over literal bytes rather than over meaning, issuer-controlled disclosure, JSON’s malleability, layer violations, and singular private keys.

I say “wrong” with affection. The JOSE working group built something that shipped, got adopted, and pays a lot of mortgages. That matters. But we should be willing to look at what shipped and say: the optionality is the problem. The bag-of-attributes JSON is the problem. The signature over literal bytes rather than over meaning is the problem. The bolt-on for selective disclosure is the problem. Each of these is a place where the standards bodies did the best they could under the constraints of the moment but they produced something that comes up short when we measure it against the trust properties we actually want for the next decade.

No amount of additional formats sharing these incorrect choices will solve the underlying problems. But a new format with new design choices could.

A New Solution

So that’s “Why build another?” But what about “Why now?” I’ll be transparent about the timing. When JWT and JSON-LD fought it out during the DID 1.0 process (and that fight slowed the standard down by years), I didn’t feel that I could object. Both sides had real problems. I had opinions, but in the old IETF tradition, opinions without shipping code don’t count for much.

Though I didn’t have shipping code, I do now.

Gordian Envelope is my attempt to make different choices at the substrate layer and see what falls out. Whether that justifies the fifteenth standard is a question I’ll come back to at the end.

So: what does Gordian Envelope do differently?

Gordian Envelope is a substrate, not a credential format. It’s dCBOR underneath, structured as semantic triples (subject, predicate, object), with every node carrying a digest and the whole thing forming a Merkle-like tree. A signature commits to the root. Any subtree can be elided (any subject, predicate, object, or assertion) and the signature still verifies. The holder (not the issuer) gets to decide what to reveal. This is the property I want as a human first and an architect second.

Envelope is also radically recursive. Any subject, object, or assertion can itself be an envelope. That recursion is what lets the same substrate carry property graphs, hypergraphs, labeled directed multigraphs, and several other shapes — not by adding modes or options, but because the structure is general enough that those graph models fall out of it. My Lead Researcher, Wolf McNally, and I wrote that up in BCR-2024-006. I want to be precise about what this is and isn’t: it is not cryptographic agility in disguise. There is one encoding, one signature semantics, one elision mechanism. The expressivity lives in the data model, not in protocol switches.

The Advantages of Envelope

I also want to be specific about what Gordian Envelope buys you, because vague privacy claims have done enough damage already.

It buys you canonical encoding. dCBOR has one representation per semantic content. Two parties assembling the same envelope from the same facts produce byte-identical outputs. JSON cannot do this without enormous effort and a lot of footguns. JSON Canonicalization Scheme exists, but ask the people who tried to deploy it how it went. JSON-LD’s situation is worse, and worth naming specifically: to canonicalize the bytes you have to first understand the semantic layer above them. That’s because the RDF Dataset Canonicalization algorithm (URDNA2015 and its successors) requires you to parse the JSON-LD into an RDF graph, resolve the @context, expand IRIs, and canonicalize that, before you can produce a stable byte sequence to sign. That’s a layer violation, or even an inversion! The encoding layer has been made dependent on the meaning layer, and any disagreement at the meaning layer (such as a context that dereferences differently, a blank-node labeling difference, or an unresolvable IRI) breaks the signature. Envelope refuses that dependency. dCBOR canonicalizes at the encoding layer, full stop, and the semantic structure is built on top of bytes that are already stable.

It buys you data minimization that doesn’t depend on the issuer’s foresight. SD-JWT requires the issuer to commit, at issuance time, to a set of disclosable fields. The issuer is deciding, in advance, what you might want to share. With Envelope, the issuer signs everything and walks away. You — the holder — then decide what to reveal at presentation time. That’s closer to what RFC 6973 “Privacy Considerations for Internet Protocols” actually calls for. It’s also closer to how human trust works in the real world, which is the entire premise of progressive trust.

It buys you cryptography that doesn’t negotiate with attackers. The verifier knows what it accepts. The envelope doesn’t tell it. We learned this from TLS. We learned it again from JOSE. I would like us not to have to learn it a third time.

It buys you composable structure. Signatures are assertions. Expiration is an assertion. Audience binding, witness attestation, revocation, and notarization are all assertions. The protocol layer and the application layer share a uniform shape, and you extend the format by adding assertions, not by petitioning a registry for another reserved claim name.

The Challenges for Envelope

Now the honest part.

We made mistakes in the early design. The most public is BLAKE3, which we originally used to produce the hashes that are signed. We picked it because it’s modern and fast. We then discovered that our actual use cases (air-gapped wallets, constrained devices, and hardware seed managers) don’t need BLAKE3’s streaming features and do need SHA-256’s ubiquity. Backing out to use SHA-256 instead cost us code, drafts, docs, and credibility. I wrote about it in “Problems of Cryptographic Agility”. If we’d shipped with cipher-suite agility, we could have just deprecated the algorithm and moved on. We chose not to, and we paid for that choice with a year of cleanup. I still think the choice was right. Optionality is a debt you eventually have to pay.

In addition, adoption is small. Reference implementations are in Rust and Swift. We have a third-party Typescript library, but JavaScript support is overall thin, and the credential world runs on JavaScript whether we like it or not. Meanwhile, our IETF draft for Envelope is still at the “individual-submission” stage. Finally, there’s no IANA registry entry that makes a procurement officer’s life easier. None of this is fixed yet, and I won’t pretend otherwise.

Ultimately, I don’t think Gordian Envelope will replace JWT. JWT will continue being the bearer-token shape for OAuth and OIDC for the foreseeable future, and that’s mostly fine: OIDC is a short-lived-token use case where many of JWT’s worst properties are tolerable. The places I want Envelope to win are the ones where the holder has to live with the document for years. Credentials. Key and seed storage. Capability tokens. Software-release attestations. Healthcare consent. Anything where data minimization and progressive trust matter more than fitting in an HTTP header.

Final Notes

The XKCD punchline is “there are now 15 competing standards.” It doesn’t say one of the fifteen can’t be better than the previous fourteen. It says that adding the fifteenth, framed as unification, is the joke. I don’t frame Envelope as an unification. It’s a substrate that respects principles I’ve spent three decades trying to articulate: human dignity, holder agency, progressive trust, minimum viable architecture. If a better substrate emerges that respects those principles, I’ll migrate to it. The principles are what matter; the format is the carrier.

I’d rather we argue about whether the principles are right than whether we have too many standards. We have too many standards because we keep ducking the harder conversation. Let’s have it.

— with thanks to Wolf McNally, who actually writes the code; to Shannon Appelcline who writes the docs and tests our ideas; to the Decentralized Web community, who pushes back when I’m wrong; and to the dCBOR working group at IETF, who are doing the unglamorous foundational work.

Envelope Intro Videos

See our videos Understanding Envelope Part One and Understanding Envelope Part Two for more on Gordian Envelope

Envelope Structure:

Envelope Hashes:

Redacted Hashes:

Related Reading

• BCR-2024-006, Envelope as a Universal Graph Substrate — https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-006-envelope-graph.md
• Problems of Cryptographic Agility — https://www.blockchaincommons.com/musings/musings-agility/
• Data Minimization & Selective Disclosure — https://www.blockchaincommons.com/musings/musings-data-minimization/
• Progressive Trust — https://www.blockchaincommons.com/musings/musings-progressive-trust/
• Progress Trust Life Cycle — https://www.blockchaincommons.com/musings/musings-progressive-trust-lifecycle/
• Minimum Viable Architecture — https://www.blockchaincommons.com/musings/musings-mva/
• When Technical Standards Meet Geopolitical Reality — https://www.blockchaincommons.com/musings/gdc25/

If you’re already familiar with the Amira use case, you’ll be most interested in how we’ve made Amira a reality with XIDs. Jump to that!

Original Issue (January 2017)

The Amira use case (originally an “Alice” use case) was first presented on January 12, 2017 by Christopher Allen as an issue on the W3C vc-use-cases repo. The crux of the use case was:

“she wishes to take a more active role in making a better world. However, she knows if she stands out from the crowd that any activism she may get involved in may not only affect her, they may affect her parents or even her extended family abroad.”

As a use case for verifiable claims (verifiable credentials), it had a few major parts:

1. Amira wants to privately contribute to a software project.
2. Amira anonymously provides reputational information.
3. Amira is able to increase her anonymous reptuation over time.
4. Amira is able to selectively revoke parts of her anonymity in the future.

RWOT 5 Advanced Reading (July 2017)

Christopher Allen revised the original use case as an advance reading for Rebooting the Web of Trust 5 in Boston. One of the most important revisions in the advance reading was that it recognized Amira’s story as being about “pseudonymous identity” and linked it to the DID standard then being worked on at the RWOT workshops.

The concept of pseudonymous identity is crucial because it provides a container for Amira’s anonymous reputational information: an alternate identity that is stable and consistent and that can accrue credentials over time, eventually bootstrapping into an identity that might be as trusted and respected as any real-life, non-pseudonymous identity.

The advanced reading also provided the first technical details suggesting that the Amira use case soon become a reality, using current near-future technology. That included DIDs (still in process at the time, since they weren’t published until 2022) and multisigs.

Amira 1.0.0 White Paper (July 2018)

Amira became a group project in October 2017 at RWOT5 in Boston and then was finalized and polished over the next nine months, ultimately resulting in a more complete white paper. The white paper used Joe Andrieu and Ian Henderson’s “information lifecycle engagement model” to lay out a 15-step model for using the imagined pseudonymous identity:

1. Pre-Contact. Amira wants to support a women’s crisis program run by Ben, but fears doing so will affect her job.
2. Contact. Amira’s friend, Charlene, verifies that she can contact Ben on the pseudonymous RISK network.
3. Triage. Charlene talks with Amira about the RISK network and verifies it meets her needs.
4. Direction. Charlene explains RISK to Amira and sets up a secret contact phrase with her to verify identity.
5. Consent. Amira creates a pseudonymous identity on RISK and signs their code of conduct with her new identifier.
6. Configure. Amira sets up a DID on RISK and confirms it with Charlene using their contact phrase.
7. Services. Amira writes a self-attestation and gets it endorsed by Charlene, who then introduces her to Ben. After discussions, Ben writes a contract for Amira to work on SisterSpaces, and begins paying her in Bitcoin as she completes milestones.
8. Enhancements. Amira adds her pseudonymous identity to a developer directory on RISK.
9. Updates. Amira buys a hardware wallet, replaces her old credentials with new ones generated by the wallet, and publishes them.
10. Problems/Issues. Amira’s credentials are compromised, leading her to create a new DID.
11. Maintenance. Amira downloads a new version of RISK that allows her to publish endorsements.
12. Migration. Amira migrates her identity to CommonX, receiving new countersigned attestations as she does.
13. Recovery. Amira gets new endorsements for her replacement DID.
14. Exit. Amira hands off maintenance on SisterSpaces to another developer and removes her public posting of endorsements.
15. Re-Engagement. Amira re-activates her public posting of endorsements.

W3C Amira (July 2019)

As part of the work on the DID standard, Amira was also released through the W3C as a Draft Community Group Report. It’s substantially identical to the 2018 paper.

XID Amira Demo (May 2026)

Five years later, Blockchain Commons was able to start making Amira a reality with XIDs, a capstone technology that uses Gordian fundamentals such as Gordian Envelope to create a truly self-sovereign identifier.

XIDs take a step beyond W3C DIDs, which ended up compromised in ways that took away from the holder control. Some of these flaws were old enough that they showed up in the Amira white paper, but we didn’t have proper alternatives at the time, so the problems made their way into the standard. It was only when we finished work on the lower levels of the Blockchain Commons stack in 2024 and advanced to XIDs that we were finally able to demonstrate the practicality of our true intentions for self-sovereign identity; we hope to see those intentions in future iterations of the standard.

Our newest version of the Amira story therefore demonstrates not just the ideas of pseudonmyous identity that Christopher first imagined back in 2017, but also how they can apply to true self-sovereignty.

Amira 1.0.0 Requirements

Amira was always intended as a use case that could lay out requirements that would define real-world usage of pseudonymous identity. Here’s a run-down of some of the most important requirements identified in the Amira 1.0.0 white paper, referenced with the step numbers in the engagement model.

• Pseudonymity. Create an identity that’s not tied to a real-world identity, but that nonetheless is stable [#5].
• Signing. Sign with your identity [#5, #7].
• Attestations. Write attestations linked to your identity [#7].
• Endorsements. Sign attestations made by yourself or others [#7].
• Rotation. Rotate your keys without losing your identity [#9].
• Publication. Broadcast attestations and endorsements [#11].
• Exit & Return. Choose to exit or return to your identifier [#15].

There are a few other requirements in Amira related to Portability [#12] and Recovery [#13] which are vitally important parts of a pseudonymous identity ecosystem, but which don’t provide sufficient continuity of identity in Amira 1.0.0, so we instead cover them, along with other advancements, in the next section.

Amira 2.0.0 Requirements

Amira was written very early in our march toward self-sovereign identity: five years before DIDs were locked down as a standard. Even then, DIDs ended up less holder-controlled (and so less self-sovereign) than we hoped.

What follows are some improvements to the original Amira requirements that make them more self-sovereign, more private, and more stable.

• Decentralization. Control your self-sovereign identity [updating #5].
  • The original engagement model focused on an imaginary network called RISK, but in doing so it took some agency from Amira. In the model, her DID is something she creates within RISK. Instead, she should be able to create and control her self-sovereign identity herself, just lending its use to a network like RISK (if something like that is even necessary), while she remains the Principal Authority.
• Bootstrapping. Build your identity through progressive trust [expanding #7].
  • A lot of the interesting work in Amira occurs in a single step of the engagement model, #7 (Services). We really need more details there, as Amira needs to figure out how to bootstrap her empty pseudonymous identifier into a trusted identity. This can be done through offering proof of existing work, receiving multiple endorsements, and slowly creating trust through progressive steps.
• Recovery. Recover your identity without loss after compromise [updating #10].
  • Fundamentally, if the underlying key for an identity is compromised, you’re going to lose the identity, as happens in Amira 1.0.0. She has to create a new identity and get it re-endorsed after an attack. However, there are ways to lessen the likelihood of that happening, through hetergenous division of keys: keeping more-powerful identity management keys offline while using less-powerful operational keys on a day-to-day basis. In this situation, it’s the operational key that’s most likely to be compromised, and it can be replaced without having to reset the identity as happens in the Amira engagement model.
• Portability. Move your identity without loss [updating #12].
  • It’s a bit painful seeing Amira have to recreate her identity when she moves from RISK to CommonX. Though she “cryptographically links” the profiles, she still has to seek out new endorsements, which shouldn’t be required under the “Portability” principle of self-sovereign identity. If Amira is truly in *Control* of her identity (per above), then all she has to do is publish her identity on a new service or link it to a profile on the new service. She doesn’t cryptographically “link” to the old profile, she just cryptographically proves possession by signing with a private key. Afterward, she shouldn’t need new endorsements, because they’re all linked to the portable identity.
• Disclosure [expanding #7]. Selectively determine what information to release.
  • The Amira use case doesn’t focus much on how Amira releases the information in her pseudonymous identity. As a result, it misses out on the ideas of selective disclosure and data minimization: she should be able to release as little about her identity as she wants at any time.

Learning XIDs

XIDs were created to demonstarte a new, truly self-sovereign version of decentralized identifiers that did away with many of the compromises that had crept into DIDs, among them: the theft of agency from the holder; the disambiguation of a DID and its data; the lack of strong support for selective disclosure; and the ability for DIDs to “phone home”. Instead, XIDs are imagined as “autonomous cryptographic objects”, created by holders, modified by holders, and wholly self-contained and self-sufficient.

However, XIDs were also created to fulfill the requirements of both Amira 1.0.0 and the expanded requirements that we’ve laid out to make Amira more self-sovereign and stable. The Learning XIDs project, which is essentially fourth iteration of the Amira Use Case following the issue, advanced reading, and white paper, does so as part of a tutorial on how XIDs work. It does so by offering a real-world demo of Amira’s creation and use of a decentralized identifier that works today, fulfilling almost a decade worth of thought leading up to this point.

Here are some of the main points found in Learning XIDs and how they relate to the Amira requirements to date:

• Decentralization.
  • §1.1. XIDs are built as autonomous cryptographic objects that are self-contained.
• Control.
  • §1.3. Amira creates her XID on her own and so has complete control of it using her “inception key.”
• Pseudonymity.
  • §1.3. A XID is defined by a unique numerical identifier (which is controlled by the inception key) and can also have a nickname. None of these are related to Amira’s real name.
• Signing.
  • §1.3. Amira signs her XID with her inception key.
  • §2.1. Amira makes an attestation key, registers it in her XID, and uses it to sign attestations.
  • §4.1. Amira makes a contract key, registers it in her XID, and uses it to sign contracts.
• Publication.
  • §1.4. Amira publishes her XID to GitHub.
  • §2.2. Amira publishes commits of detached attestations.
  • §4.2. Ben publishes commits of contracts.
• Portability.
  • §1.4. Amira could choose to publish her XID to a different site. Provenance marks would show which publication was the most up-to-date.
• Attestations.
  • §2.1. Amira creates detached attestations.
  • §2.2. Amira elides and commits to detached attestations.
  • §2.3. Amira encrypts detached attestations.
  • §3.1. Amira creates embedded attestations (in her XID).
• Endorsements.
  • §3.3. Amira receives peer endorsements.
• Bootstrapping.
  • §2.2. Amira uses commitments to build trust over time.
  • §3.2. Amira creates verifiable self-attestations.
• Disclosure.
  • §4.3. Amira chooses what to reveal in views of her XID.
  • §4.4. Amira removes overly identifying information.
• Rotation.
  • §5.2. Amira rotates a laptop key.
• Recovery.
  • §5.5. Amira rotates keys and disavows endorsements after a compromise, but keeps her identity.
• Exit & Return.
  • §1.1. Amira could choose to stop or restart use of her XID at any time since it’s an autonomous cryptographic object.

We suggest reading through the entire tutorial and playing through it at bcts.dev, but the above links highlight the requirements derived from the Amira use case.

What’s Next?

Are there requirements we’re still missing for self-sovereign identity? Let us know for possible integration into a future iteration of Amira.

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!