Transmute Integrates Bitcoin Support

Karyl Fowler
Transmute
Published in
3 min readFeb 28, 2020

Today, I am proud to announce that Transmute supports anchoring to the Bitcoin blockchain. We’ve integrated Bitcoin in a way that maximally supports both our customers and the Sidetree community at large by enabling use of ION-based DIDs in our existing javascript libraries, currently used to power our implementation of Element — a core component of our product.

Both Element and ION are open source implementations of the Sidetree protocol. ION is a DID method that implements Sidetree using Bitcoin as the decentralized ledger with IPFS as the content addressable layer for storing operation data, whereas Element uses Ethereum.

Today’s announcement means that anyone using Transmute can now choose to anchor hashlinks to the Bitcoin blockchain without giving up the benefits that Element has to offer. These benefits include maximum scalability, instantaneous resolution of DIDs, and most importantly, support for JSON-LD — a notable requirement in recent innovation solicitations from both the U.S. and Canadian governments with whom our supply chain customers must comply.

Sidetree is a layer 2 ledger-agnostic protocol for scaling DPKI (Decentralized Public Key Infrastructure) operations. Housed under the DIF (Decentralized Identity Foundation) where Transmute co-chairs this work with Microsoft, Sidetree adheres to the emerging DID (Decentralized Identifier) standard. A Sidetree DID method is public, permissionless and will inherit the security properties of the underlying blockchain it uses. Anyone can run a Sidetree node to resolve their DID or perform updates to their DID document.

Scalability is achieved by anchoring batches of operations on the chosen ledger [instead of anchoring each operation individually], and storing the operation data on a separate content addressable storage solution — unlocking thousands of operations per second in capacity.

Technical Flexibility Drives Value for Customers

Transmute is committed to providing customers with maximum optionality when it comes to integrating with existing infrastructure and anchoring to distributed ledgers or blockchains. This commitment is driven as much by market demand as by our core belief that going where the users are accelerates adoption.

For example, today’s enterprise identities are locked in OpenID Connect and Active Directory-based systems, so existing IDPs were an important early point of integration for our product.

Likewise, the data our customers manage is already stored somewhere — typically in an existing cloud-based database with companies increasingly migrating to a multi-cloud environment [and prioritizing strategies for avoiding vendor lock-in]. Transmute integrated support for the top public cloud providers early on.

When it comes to the secure audit-ability layer provided by anchoring critical reference identifiers to a blockchain, the customer demands are no different. Customers want the added traceability benefits, but they demand choices when it comes to which blockchain to use. Unique to this component, customers face the existential uncertainty inherent in adopting emerging technologies in addition to evaluating the business values and tradeoffs of each protocol. This is why we continue integrating optionality at the blockchain layer.

Our customers won’t be penalized if future predictions about which protocol will win their industry don’t pan out because they can easily switch at that time.

Transmute’s modular architecture and flexible integration options mean customers can drive quickly to production value without fear of future unknowns. We believe this added confidence will mean significant business advantages for innovative organizations leading adoption of this technology.

Relevant Links:

--

--