---
robots: noindex, nofollow
---

# Gordian Seal Technical Details
###### tags: `article / in process`

Developers interested in acquiring a Gordian Seal should be aware of the Blockchain Commons' suggested best practices and its reference architecture and wallet.

## What are the 2021 Gordian Requirements?

To achieve a 2021 Gordian Seal of Approval requires meeting the following requirements:

* **Independence:**
- [ ] **1. Independent Authority:** User must hold sufficient private keys to either spend or recover funds without third-party intervention.
- [ ] **2. No Third-Party Authority:** There must by no individual third party who holds sufficient private keys to either spend or recover funds.
- [ ] **3. No Third-Party Collusion.** The wallet vendor must not know where enough keys are to be able to collude with entities other than the user to collect those keys and steal funds.
- [ ] **4. Supported Sweep:** User must be able to sweep their funds to another account with no third-party intervention and at no cost other than standard Bitcoin transaction costs.
- [ ] **5. Thoughtful Signing:** The UX for signing and verification must be explicit, not automatic.
* **Resilience:**
- [ ] **1. Adversarial Analysis:** Wallet vendor must conduct an adversarial analysis, such as the risk analysis of [#SmartCustody](https://www.smartcustody.com/), and publish the results.
- [ ] **2. Multisig Funds:** Funds must be protected by a multisig, not a single signature.
- [ ] **3. No Single Point of Failure for Funds:** The loss of a single private key, hardware device, software program, or account must not cause the loss of funds.
- [ ] **4. No Single Point of Failure for Recovery:** The loss of a single private key, hardware device, software program, or account must not cause the loss of the ability to recover funds.
- [ ] **5. No Third-Party Point of Failure for Recovery:** There must be a way to independently recover funds without the wallet vendor, even if the standard way to recover funds depends on that vendor.
- [ ] **6. No Single Point of Compromise:** The theft of a single private key, hardware device, software program, or account must not allow the theft of funds without also circumventing biometric protection (or stealing additional items).
- [ ] **7. Multifactor Authentication:** The release of key material must only be allowed following multiple factors for authentication. Some of these factor may be long-term, such as logging into an account, but at least one must be immediate, such as a thumbprint scan.
* **Openness:**
- [ ] **1. Open Transactions.** User must be able to send funds to and receive funds from standard addresses for the cryptocurrency of the wallet.
- [ ] **2. Open Transfer of Account.** User must be able to move their digital-asset account to a different platform using a descriptor, a UR, or some other standard, interoperable means.
- [ ] **3. Published Code:** Source code must be published online.
- [ ] **4. Compilable Code.** Source code must be compilable if it is written in a well-known language.
- [ ] **5. Open Patents.** Wallet vendor must have a published open patent strategy.

[Possible new criteria: SSKR, UR, other specifications]

### What are the 2022 Gordian Requirements?

The 2022 requirements are not yet set, but our curent expectation is that they will include the following new criteria:

* **Independence:**
- [ ] **Transaction Privacy:** User must able to use a privacy transaction method such as Coinjoin or Payjoin.
- [ ] **Usage Privacy:** Usage of all Bitcoin-related services, including watching, transacting, and pricing, must be protected by Tor.
* **Resilience:**
- [ ] **Incapacitation Resilience:** Wallet must support funds recovery in case of user incapication, though the user may have the option to enable this or not.
* **Openness:**
- [ ] **Partition of Services:** Auxiliary services such as pricing and storage must be partitioned from the wallet by airgaps or torgaps.

If the Speedy Trial of Taproot and Schnorr succeeds, we also expect to have Schnorr-related requirements.

### What are the Future Gordian Requirements?

We expect the following requirements to come on board in 2023 or later:

* **Openness:**
- [ ] **Interoperability of Services:** Users must be able to freely pick from partitioned services such as pricing and storage offered by other vendors.

## What is the Gordian Wallet?

The Gordian Wallet is a reference implementation of a wallet that adheres to the Gordian requirements. It can be used as a user wallet, but Blockchain Commons' main purpose is to offer it as an example and testing reference for wallet developers.

It fulfills the Gordian requirements by implementing a two-of-three multisig, with one key on the user's device, one key on a Bitcoin full node, and one key kept offline in at least two secure places per the [#SmartCustody procedure](https://www.smartcustody.com/). The Independence requirements and the third Openness requirement are met by the user being in total, self-sovereign control of funds. The Resilience requirements are met by the two-of-three multisig, the partition of the keys across multiple devices, and the backup of the offline key. The other Openness requirements are met by the publication of [Gordian Wallet at GitHub](https://github.com/BlockchainCommons/GordianWallet-iOS).

We would expect most wallets by third-parties to exercise more ability to support and intervene for a user, but still abiding by the Independence and Openness guidelines.

## What is the Gordian Architecture?

Blockchain Commons also offers a a minimum viable reference architecture to manifest the Gordian principles and requirements, primarily as an example for developers. Its usage is not a mandate, but rather a demonstration of the feasability of Gordian requirements and principles in an architectural design. Other architectural designs that similarly adopt Gordian best practices would be certified for the Gordian Seal of Approval.

The Gordian Architecture stands in contrast to classic cryptowallets, which were monolithic designs. Wallets often connected to nodes run by the same manufacturer and used pricing services and other utilities run or provided by the same manufacturer. It was a lazy architecture that created a single point of failure, a single point of compromise, and a single point of trust. It left users with no independence: the manufacturer of their wallet made all the decisions for them.

Gordian instead builds its reference architecture around a distributed philosophy. Major services like the [Gordian Wallet](https://github.com/BlockchainCommons/GordianWallet-iOS) and the [Gordian Server](https://github.com/BlockchainCommons/GordianServer-macOS) connect to microservices such as [Spotbit](https://github.com/BlockchainCommons/spotbit), reference software such as [Gordian Cosigner](https://github.com/BlockchainCommons/GordianCosigner-iOS) and [Gordian Guardian](https://github.com/BlockchainCommons/GordianGuardian-iOS), and reference hardware such as [LetheKit](https://github.com/BlockchainCommons/bc-lethekit) using standard specifications: airgaps, supported by [Universal Resources and animated QR codes](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md); and [torgaps](https://github.com/BlockchainCommons/torgap), created by Tor. This ensures that a wallet is distributed, not monolithic.


This architectural design is built to directly support Gordian's principles.
* **Independence.** Users get to decide which applications to use as part of their personal Gordian network. Torgaps and Airgaps in the system protect their privacy and pseudonymity.
* **Resilience.** Users know that the network is purposefully built to avoid single points of failure and single points of compromise. A partition of keys, including a recovery key, across devices in the architecture ensures that funds can't be easily stolen or lost.
* **Openness.** The use of standard specifications, such as the Uniform Resources, to interconnect elements of the Gordian architecture ensures that any company can offer up their products or services for fair competition and interoperability.

Blockchain Commons also provides tools to test and manifest this architecture, such as [bytewords CLI](https://github.com/BlockchainCommons/bc-bytewords-cli), [keytool CLI](https://github.com/BlockchainCommons/bc-keytool-cli), [LifeHashTool](https://github.com/BlockchainCommons/LifeHashTool), [seedtool CLI](https://github.com/BlockchainCommons/bc-seedtool-cli), and [URDemo](https://github.com/BlockchainCommons/URDemo). They focus on the interoperable elements used in the Gordian architecture, such as the bytewords format, the LifeHash imaging, and the Universal Resources encoding.

--

_From here down is no longer current._

# Best Practices (Archive)

This is the iteration of our best-practices that we wrote up prior to moving to a checklist.

## What are Gordian's Best Practices?

The core requirement for a Gordian-approved wallet is that it meet or exceed the current best practices of the industry as a whole.

However, we also present our own, more strict best practices for 2021, both to offer a checklist for success and to provide a listing of more stringent practices that we expect Gordian companies will _mostly_ meet.

Gordian-approved wallets can support the Gordian Principles by doing the following:

* **Independence:**
* ***Assure agency.*** The user ***must*** always be the principal authority for their digital transactions.
* ***Assure independence of operations.*** Control of assets ***must*** remain with the user, though third parties might offer support, for example by holding a minority of keys; centralized authorities ***must not*** be required for standard operations.
* ***Assure independence of recovery.*** Assets ***must*** be independently and fully recoverable by the users; external parties ***should not*** be able to steal funds, to coerce users, or to act as single-point-of-failure for recovering funds.
* ***Maintain partition of services.*** Core wallet services (such as managing multisig policies, signing multisig transactions, and even storing keys) ***should*** be partitioned from each other, to improve privacy and reduce correlation. Auxilliary wallet services (such as looking up prices and purchasing coins) ***should*** also be partitioned, to create market fairness and improve user choice.
* ***Maximize privacy.*** Blockchain queries and transactions ***must*** be privacy protected using features such as Tor.
* **Resilience:**
* ***Assure hardware resilience.*** Assets ***must*** remain safe and accessible even with the loss of a single computer or mobile device.
* ***Assure key resilience.*** Assets ***must*** remain safe and accessible even with the loss of a single key.
* ***Avoid SPOC.*** Wallets ***must*** be free of single-points-of-compromise (SPOC), where an attacker could steal assets if they stole a single key or compromised a single device.
* ***Avoid SPOF.*** Wallets ***must*** be free of single-points-of-failure (SPOF), where a user could lose assets if they lost a single key or where they could lose their recovery if they lost access to a single service.
* ***Balance security against vulnerability.*** The security of digital assets ***should*** be maximized, but that ***must*** be balanced against the problem of creating vulnerabilities (particularly through key fragility).
* ***Maintain separation of interests.*** Key material and recovery material ***should*** be separated among entities with different interests, to make collusion more difficult.
* **Openness:**
* ***Integrate with interoperable specifications.*** Key material ***should*** be freely exportable from a wallet, using specifications such as Bitcoin descriptors or Blockchain Commons Universal Resources; or at a minimum ***must*** be rotatable to allow the recovery of digital assets to new keys.
* ***Publish code and specifications.*** Wallet code ***must*** be freely available online so that anyone can review and verify the code. Preferrably, it ***can*** be open source. It also ***should*** be buildable if the code is written in a well-known language. Hardware and chip specifications similarly ***must*** be published.
* ***Reject lock-in.*** Wallets and services ***must*** be free from vendor lock-in; users ***must*** be able to freely, easily, and cheaply move assets to other platforms or use other services.
* ***Reject patent aggression.*** Wallet developer ***should*** adopt an [open patent strategy](https://www.opencrypto.org/about/).

We say that wallets must _mostly_ meet these more stringent requirements because we recognize that best practices can vary for different platforms and different products and services, and further that some applications might have to compromise one best practice in order to assure another. The Gordian Seal of Approval rests on a professional assessment from Blockchain Commons in large part so that it can consider how these individual elements impact any specific wallet.

As of 2021, Blockchain Commons suggests _multisig_ as a core element of wallet design to the Gordian best practices, but if a wallet company were to offer a different solution that similarly met these best practices, it would also receive the 2021 Gordian Seal of Approval. See our Smart Custody article on ["Designing Multisig for Independence and Resilience"](https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Multisig.md) for more information on the thoughtful design of a multisig.