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 Trustless Registry of Universal Secure Tokens.

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

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:

Verification Relationship Flags (bits, lowest to highest):

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

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

{
  "@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:

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:

[
  {
    "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:

[{"i": 4}]

5. Key Concepts and Terminology

6. Security Considerations

6.1 Inherited Bitcoin Security

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

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

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

Appendix A: Glossary for LLM/Algorithm Processing

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

{
  "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