# Qodoonect TRUST — Decentralized Identity System Documentation

> **Version:** 1.0.0-draft  
> **Date:** 2026-04-11  
> **Status:** Initial Draft  
> **Organization:** Qodoonect Family Group (qodoonect.com)  
> **Subsystem of:** finance.qodoonect.com (Automated Accounting Platform)  
> **Based on:** did:btc Method Specification (MicroStrategy/Strategy, August 2024)  
> **License:** CC BY 4.0  

---

## 1. Executive Summary

Qodoonect TRUST is a decentralized identity (DID) layer built on the Bitcoin blockchain, designed to provide tamper-proof, trustless, and long-lived digital identities for the Qodoonect ecosystem. The system adapts the `did:btc` method specification — originally developed by Daniel McNally at MicroStrategy (now Strategy) — to serve the identity and authentication needs of the Qodoonect automated accounting platform and its broader family of services.

TRUST stands for **T**rustless **R**egistry of **U**niversal **S**ecure **T**okens.

The system leverages Bitcoin's immutable ledger and Taproot-enabled inscription envelopes to store DID documents directly on-chain, eliminating external dependencies and ensuring data permanence, integrity, and provenance.

---

## 2. System Context

### 2.1 Qodoonect Family Group

The Qodoonect family group (qodoonect.com) operates a suite of interconnected services. The TRUST identity layer serves as the foundational authentication and identity infrastructure across all platforms:

- **qodoonect.com** — Parent organization and service hub
- **finance.qodoonect.com** — Automated accounting platform (primary integration target)
- **Future services** — Any Qodoonect ecosystem service requiring decentralized identity

### 2.2 Role of TRUST in the Ecosystem

TRUST provides:

- **Entity Identity:** Unique, verifiable, blockchain-anchored identifiers for users, organizations, and automated agents
- **Authentication:** Cryptographic proof of identity without centralized authorities
- **Accounting Integrity:** Tamper-proof identity chain for financial transactions and audit trails
- **Cross-Service Identity:** Single DID usable across all Qodoonect platforms
- **Regulatory Compliance:** Immutable identity records for KYC/AML audit trails

---

## 3. Technical Foundation — did:btc Method

### 3.1 Overview

The `did:btc` method uses the Bitcoin blockchain exclusively to store and retrieve DID information. UTXOs (Unspent Transaction Outputs) on-chain control DIDs. Data is inscribed in the witness of transactions using Taproot (SegWit v1) inscription envelopes, enabling greater extensibility while reducing fees and block space consumption.

### 3.2 Why Bitcoin?

- **Most secure blockchain:** Protected by the largest proof-of-work network
- **Immutable ledger:** Transactions cannot be modified or deleted after confirmation
- **Decentralized:** No governing body controls the network; thousands of nodes worldwide
- **Longevity:** Operational since 2009 with near 100% uptime
- **SegWit discount:** Witness data weighted at 25% rate, reducing costs for DID operations

### 3.3 Inscription Envelopes (Taproot)

Bitcoin's Taproot upgrade (SegWit v1, 2021) enabled inscription envelopes — a technique for storing arbitrary data in the witness of transactions. Key technical details:

- **SegWit v0 (2017):** Introduced witness data at 25% weight discount
- **Taproot (2021):** Removed 10,000-byte ScriptPubKey limit
- **Envelope technique:** Data stored in witness, deliberately ignored by script execution but extractable by inscription-aware software
- **Cost efficiency:** DID data benefits from the SegWit witness discount

### 3.4 DID Identifier Format

```
did:btc:<txref>
```

- **Method name:** `btc`
- **Method-specific identifier:** TxRef conforming to BIP-136
- **TxRef encodes:** Block height + transaction index (+ optional DID index for batches)
- **Testnet prefix:** `did:btc:test:<txref>`

**Example:**
```
did:btc:xg4x-ay5y-q5zq-232
```

### 3.5 Comparison with Other DID Methods

| Method | Data Storage | External Dependencies | Key Flexibility | Cost |
|---|---|---|---|---|
| **did:btc** | On-chain (witness) | Bitcoin only | Any curve/key type | Medium-High |
| did:btcr | URL reference | Web servers | secp256k1 only | Low |
| did:ion | IPFS pointer | Bitcoin + IPFS | Flexible | Medium |
| did:btco | Full doc inscribed | Bitcoin only | Limited | High |

**did:btc advantages over alternatives:**
- No external dependencies (unlike did:btcr, did:ion)
- Supports any key curve/type (unlike did:btcr)
- Minimizes block space by dynamic DID document rendering (unlike did:btco)
- Separates wallet keys from subject keys for enhanced security

---

## 4. DID Method Operations

### 4.1 Create

A DID creation transaction contains an OP_RETURN in its first output with:

| Byte Position | Length | Content |
|---|---|---|
| 0-2 | 3 bytes | ASCII `did` (human-readable flag) |
| 3 | 1 byte | Verification Relationship flags (bitwise) |
| 4+ | Up to 76 bytes | Subject public key in Multikey format |

**Verification Relationship Flags (bits, lowest to highest):**

| Bit | Relationship |
|---|---|
| 0 | Authentication |
| 1 | Assertion |
| 2 | Key Agreement |
| 3 | Capability Invocation |
| 4 | Capability Delegation |

**DID UTXO:** Optional Pay-To-Taproot (p2tr) second output for future updates/deactivation. Without it, the DID is final (immutable).

**Important:** Creators MUST wait at least 6 block confirmations before publishing the identifier (protection against chain reorganization).

#### 4.1.1 Batch Create

Multiple DIDs can be created in a single transaction to reduce overhead:

- Public keys are placed in the witness of a reveal transaction (commitment + reveal pattern)
- Fixed overhead regardless of batch size
- Cost per DID asymptotically approaches ~8 vBytes for ed25519 keys

| Batch Size | Total VBytes | VBytes/DID |
|---|---|---|
| 2 | 302 | 151 |
| 10 | 367 | 36.7 |
| 100 | 1,091 | 10.91 |
| 1,000 | 8,332 | 8.33 |
| 10,000 | 80,748 | 8.07 |

### 4.2 Read (Resolve)

Resolution process:

1. Decode TxRef → block height + transaction index
2. Fetch the block and extract the transaction
3. Verify OP_RETURN starts with ASCII `did`
4. Extract verification relationship flags (byte 4)
5. Decode remaining bytes as Multikey (key type + public key)
6. Extract controller key from DID UTXO ScriptPubKey (if present)
7. Construct DID document

**Follow update chain:** After initial resolution, check if DID UTXO is spent → follow spending transactions to apply updates until reaching an unspent UTXO or a final state.

#### 4.2.1 Example DID Document

```json
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1"
  ],
  "id": "did:btc:x20r-ayaz-qqtl-ljk",
  "controller": "did:key:z6DtNrvHVvvKHB7m8LrCmt131TGH7DbzvcPo9mZRoCt5rqms",
  "verificationMethod": [
    {
      "id": "did:btc:x20r-ayaz-qqtl-ljk#key-0",
      "controller": "did:btc:x20r-ayaz-qqtl-ljk",
      "type": "Multikey",
      "publicKeyMultibase": "z6MkfNwZ7ncwr54BVWA9taEJLaHAWYEuqMNQfBzrwLEoaoVB"
    }
  ],
  "authentication": ["x20r-ayaz-qqtl-ljk#key-0"],
  "assertion": ["x20r-ayaz-qqtl-ljk#key-0"]
}
```

### 4.3 Update

Updates are JSON documents inscribed in the witness of a transaction spending the DID UTXO. Four operation types:

| Key | Operation | Description |
|---|---|---|
| `vm` | Verification Methods | Add, update, or delete keys |
| `u` | Update | Modify existing DID document fields |
| `d` | Delete | Remove fields from DID document |
| `a` | Append | Add new fields to DID document |

**Verification Method operations (`vm` array):**

- **Delete:** `{"i": 0}` — remove key at index 0
- **Update key:** `{"i": 1, "k": "<multikey>"}` — replace key at index 1
- **Update relationships:** `{"i": 3, "vr": 7}` — change verification relationships of key at index 3
- **Append:** `{"k": "<multikey>", "vr": 3}` — add new key with specified relationships

**New DID UTXO:** Update transaction MAY create a new DID UTXO (first output) for future updates. Without it, the DID becomes final.

#### 4.3.1 Batch Update

For batched DIDs, updates are a JSON array with index specifiers:

```json
[
  {
    "i": 5,
    "p": { /* update payload */ }
  }
]
```

### 4.4 Deactivate (Revoke)

A DID is deactivated when its DID UTXO is spent with the first output being an OP_RETURN containing ASCII `d`. This is permanent and irreversible.

**Batch deactivation:** Use batch update format with index but no payload:
```json
[{"i": 4}]
```

---

## 5. Key Concepts and Terminology

| Term | Definition |
|---|---|
| **DID** | Decentralized Identifier — a globally unique, self-sovereign identifier |
| **DID Document** | JSON document describing the DID subject's public keys and services |
| **DID UTXO** | Unspent Bitcoin transaction output that controls a DID (must be p2tr) |
| **DID Index** | Position of a public key within a batch creation transaction |
| **Multikey** | Data model combining key type prefix + public key bytes in Multibase format |
| **TxRef** | Human-readable encoding of a confirmed Bitcoin transaction reference (BIP-136) |
| **Inscription Envelope** | Arbitrary data stored in the witness of a Taproot transaction |
| **Verification Relationship** | The purpose for which a key can be used (auth, assertion, etc.) |
| **ScriptPubKey** | Bitcoin script defining spending conditions for an output |
| **SegWit** | Segregated Witness — protocol upgrade enabling witness data discount |
| **Taproot** | SegWit v1 upgrade enabling inscription envelopes |

---

## 6. Security Considerations

### 6.1 Inherited Bitcoin Security

The did:btc method inherits Bitcoin's security framework:

| Attack Vector | Protection |
|---|---|
| **Eavesdropping** | N/A — transactions are public by design |
| **Replay** | Each transaction consumes UTXOs permanently; replays are rejected |
| **Message Insertion** | Signature validation fails on tampered transactions |
| **Man-in-the-Middle** | Transaction tampering invalidates signatures |
| **Deletion** | Transactions broadcast to thousands of nodes; deletion after confirmation is energetically infeasible |
| **Modification** | Immutable after signing/confirmation |
| **DoS/Amplification** | Bitcoin protocol has battle-tested countermeasures (since 2009) |

### 6.2 Key Management

- **Compromised wallet keys:** Attacker can permanently control, update, or revoke DIDs
- **Lost wallet keys:** Permanent loss of ability to update or revoke DIDs
- **Mitigations:** Multi-signature wallets, backup seed phrases, pre-created (unbroadcast) deactivation transactions

### 6.3 Qodoonect TRUST-Specific Security

- **Separation of concerns:** Wallet keys (Bitcoin transaction signing) are distinct from subject keys (DID authentication/assertion)
- **Third-party management:** Controllers can manage DIDs on behalf of subjects
- **Multi-sig requirements:** DID control can require multiple signatures via Bitcoin's scripting capabilities
- **Audit trail:** All identity operations are permanently recorded on the Bitcoin blockchain

---

## 7. Privacy Considerations

### 7.1 General Privacy

- All DID data and operations are public on the blockchain
- Real-world identities are NOT tied to Bitcoin addresses
- DIDs can be pseudonymous
- Personal information MUST be kept off-chain (DID best practices)

### 7.2 Surveillance Risks

- On-chain activity is public and may reveal information about the DID controller
- Transaction inputs can reveal Bitcoin holdings of the DID creator

### 7.3 Correlation Risks

- DIDs with the same controller key or within the same batch can be linked
- UTXO history analysis can link fund ownership to DID controllers
- Change outputs from DID creation transactions can be traced

---

## 8. Qodoonect TRUST Integration Architecture

### 8.1 System Components

```
┌─────────────────────────────────────────────────────┐
│                  Qodoonect Ecosystem                │
│                                                     │
│  ┌──────────────┐  ┌──────────────┐  ┌───────────┐ │
│  │ qodoonect.com│  │finance.qodo..│  │ Future    │ │
│  │ (Hub)        │  │ (Accounting) │  │ Services  │ │
│  └──────┬───────┘  └──────┬───────┘  └─────┬─────┘ │
│         │                 │                │        │
│         └────────┬────────┴────────────────┘        │
│                  │                                  │
│         ┌────────▼────────┐                         │
│         │  TRUST Layer    │                         │
│         │  (DID Manager)  │                         │
│         └────────┬────────┘                         │
│                  │                                  │
│         ┌────────▼────────┐                         │
│         │  Bitcoin Node   │                         │
│         │  (Indexer)      │                         │
│         └────────┬────────┘                         │
│                  │                                  │
└──────────────────┼──────────────────────────────────┘
                   │
          ┌────────▼────────┐
          │ Bitcoin Network │
          │ (Mainnet)       │
          └─────────────────┘
```

### 8.2 Integration with finance.qodoonect.com

The automated accounting platform uses TRUST for:

1. **User Identity:** Each user/organization gets a did:btc identifier
2. **Transaction Signing:** Financial transactions can be cryptographically tied to DID-authenticated entities
3. **Audit Trails:** Immutable identity chain for regulatory compliance
4. **Cross-Platform Auth:** Single DID for authentication across all Qodoonect services
5. **Agent Identity:** Automated accounting agents receive their own DIDs for accountability

### 8.3 Identity Lifecycle in Qodoonect TRUST

```
[Entity Registration] → [DID Creation on Bitcoin] → [6-block confirmation wait]
         ↓
[DID Published] → [Service Authentication via DID] → [Ongoing operations]
         ↓
[Key Rotation/Update] → [Update transaction on Bitcoin] → [DID Document updated]
         ↓
[Deactivation] → [Revocation transaction on Bitcoin] → [DID permanently deactivated]
```

---

## 9. Operational Considerations

### 9.1 Cost

- Bitcoin transaction fees fluctuate; DID operations are among the most expensive per byte
- Batch operations significantly reduce per-DID costs
- Cost provides inherent Sybil attack resistance

### 9.2 Speed

- DID operations are never instant (Bitcoin block time ~10 minutes)
- Minimum 6 confirmations required (~60 minutes)
- Urgent operations can be expedited with higher fees
- Operations may fail during high-fee periods

### 9.3 Infrastructure Requirements

- **Bitcoin node:** Required for trustless DID resolution
- **TRUST indexer:** Specialized software to index only DID-relevant transactions
- **Alternatives:** Public block explorers/Electrum servers (introduces some trust)

### 9.4 Key Custody

- Multiple Bitcoin keys (secp256k1) must be secured for non-final DIDs
- Associated UTXOs must be managed carefully
- Recommended: Multi-signature wallets, hardware security modules (HSM)

---

## 10. Standards Compliance

### 10.1 W3C DID Core

Qodoonect TRUST conforms to the W3C Decentralized Identifiers (DIDs) v1.0 specification (W3C Recommendation, 19 July 2022).

### 10.2 Bitcoin Standards

- **BIP-136:** TxRef encoding for transaction references
- **BIP-341:** Taproot (SegWit v1) for inscription envelopes
- **Multicodec/Multibase:** Key type encoding and representation

### 10.3 Referenced Specifications

| Standard | Purpose |
|---|---|
| W3C DID-CORE | Decentralized Identifier specification |
| BIP-136 | TxRef encoding |
| BIP-341 | Taproot / SegWit v1 |
| RFC 2119 / RFC 8174 | Requirement level keywords |
| Multibase | Key encoding format |
| VC Data Integrity | Multikey data model |

---

## 11. Roadmap and Future Development

### 11.1 Phase 1 — Foundation (Current)

- Specification documentation and review
- Bitcoin testnet implementation
- Core DID operations (create, read, update, deactivate)
- Integration design for finance.qodoonect.com

### 11.2 Phase 2 — Implementation

- TRUST indexer node development
- DID management SDK/API
- finance.qodoonect.com integration
- Batch DID operations for organizational onboarding

### 11.3 Phase 3 — Expansion

- Cross-service identity federation across Qodoonect ecosystem
- Verifiable Credentials (VC) support
- Automated agent identity management
- Advanced key management (multi-sig, HSM integration)

### 11.4 Phase 4 — Ecosystem

- Third-party service integration APIs
- DID resolver as a service
- Governance framework for Qodoonect TRUST network
- Compliance certification (KYC/AML integration patterns)

---

## 12. Source References

| Source | URL | Description |
|---|---|---|
| did:btc Specification | https://microstrategy.github.io/did-btc-spec/ | Full technical specification |
| Strategy Software | https://www.strategy.com/software | Strategy Mosaic platform |
| Strategy GitHub | https://github.com/MicroStrategy | Open source repositories |
| did-btc-spec Repo | https://github.com/MicroStrategy/did-btc-spec | Specification source (44 stars, 11 forks) |
| W3C DID Core | https://www.w3.org/TR/did-core/ | W3C DID specification |
| BIP-136 | https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki | TxRef encoding |
| BIP-341 | https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki | Taproot specification |

---

## Appendix A: Glossary for LLM/Algorithm Processing

```yaml
system_name: "Qodoonect TRUST"
full_name: "Trustless Registry of Universal Secure Tokens"
parent_org: "Qodoonect Family Group"
parent_url: "https://qodoonect.com"
primary_integration: "finance.qodoonect.com"
did_method: "did:btc"
blockchain: "Bitcoin (mainnet)"
specification_basis: "did:btc Method Specification v2024-08-22"
specification_author: "Daniel McNally (MicroStrategy/Strategy)"
key_types_supported: "Any (ed25519, secp256k1, etc.)"
encoding: "Multikey (Multicodec + Multibase)"
identifier_format: "did:btc:<txref>"
testnet_format: "did:btc:test:<txref>"
operations: ["create", "read", "update", "deactivate"]
batch_operations: true
min_confirmations: 6
consensus: "Proof of Work (Bitcoin)"
data_storage: "On-chain (witness inscription envelopes)"
external_dependencies: "None (Bitcoin only)"
w3c_compliance: "DID-CORE v1.0"
```

## Appendix B: Machine-Readable Operation Codes

```json
{
  "create": {
    "op_return_prefix": "646964",
    "verification_flags": {
      "authentication": 1,
      "assertion": 2,
      "key_agreement": 4,
      "capability_invocation": 8,
      "capability_delegation": 16
    },
    "key_format": "multikey",
    "did_utxo_type": "p2tr",
    "min_confirmations": 6
  },
  "update": {
    "payload_location": "witness",
    "json_keys": {
      "vm": "verification_method_changes",
      "u": "field_updates",
      "d": "field_deletions",
      "a": "field_additions"
    },
    "vm_operations": {
      "delete": {"required": ["i"]},
      "update_key": {"required": ["i", "k"]},
      "update_vr": {"required": ["i", "vr"]},
      "append": {"required": ["k", "vr"]}
    }
  },
  "deactivate": {
    "op_return_payload": "64",
    "ascii_value": "d",
    "reversible": false
  },
  "batch": {
    "create_method": "inscription_envelope",
    "update_format": [{"i": "did_index", "p": "update_payload"}],
    "deactivate_format": [{"i": "did_index"}]
  }
}
```

---

*Document generated: 2026-04-11 | Qodoonect TRUST v1.0.0-draft*  
*For human-readable version see: Qodoonect_TRUST_System_Documentation.pdf*  
*For editable version see: Qodoonect_TRUST_System_Documentation.docx*