Archon Protocol

Technical Architecture

System Overview

Archon is built around a separation of concerns architecture. Each Archon node contains three main layers:

Data Flow

A typical DID operation flow follows this sequence:

1. Client Request: User requests a DID operation (create, update, delete)
2. Keymaster Signs: Keymaster creates the operation and signs it with the private key
3. Gatekeeper Validates: Gatekeeper validates the signed operation and queues it
4. IPFS Storage: Operation is stored in IPFS and CID is returned
5. Registry Confirms: Selected registry confirms and orders the operation

The did:cid Method

Method Specification

The did:cid method leverages Content Identifiers (CIDs) from IPFS to create self-certifying, content-addressed DIDs:

did:cid:<cid>[;service][/path][?query][#fragment]

Example: did:cid:bafkreig6rjxbv2aopv47dgxhnxepqpb4yrxf2nvzrhmhdqthojfdxuxjbe

DID Types

Archon supports two fundamental DID types:

• Agent DIDs: Possess cryptographic keys, can sign operations, controlled by a private key holder. Used for users, organizations, services, IoT devices
• Asset DIDs: No cryptographic keys, controlled by an owning Agent DID. Used for credentials, schemas, documents, data

DID Document Structure

Archon DID documents are W3C-compliant with Archon-specific extensions:

{
  "@context": "https://w3id.org/did-resolution/v1",
  "didDocument": {
    "id": "did:cid:bafkrei...",
    "verificationMethod": [{
      "id": "#key-1",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "publicKeyJwk": { /* JWK format */ }
    }],
    "authentication": ["#key-1"],
    "assertionMethod": ["#key-1"]
  },
  "didDocumentMetadata": {
    "created": "2024-01-15T10:30:00Z",
    "versionId": 1
  },
  "didDocumentData": {},
  "didDocumentRegistration": {
    "registry": "hyperswarm",
    "type": "agent",
    "version": 1
  }
}

Operations

All DID state changes occur through signed operations. Three operation types are supported:

• Create: Establishes a new DID with initial public key and registration details
• Update: Modifies DID document fields, creates a new version with previd linking
• Delete: Deactivates a DID, preventing future operations

The didDocumentData Extension

Purpose and Design

The didDocumentData field is an extension to the W3C DID specification that allows arbitrary application data to be stored alongside the DID. This transforms DIDs from static identifier containers into rich, self-sovereign data repositories.

Key Properties

• Schema-Free: No predefined structure—applications define their own schemas
• Cryptographically Signed: All data is signed by the DID controller, ensuring authenticity
• Version-Controlled: Every change creates a new version with full audit trail
• Decentrally Stored: Distributed via IPFS and synchronized across registries
• Controller-Owned: Only the DID controller can modify the data

Use Cases Enabled

• Credential Manifests: Users publish verified credentials to their DID, creating a decentralized professional profile
• Identity Vaults: Encrypted backup storage tied directly to an identity for recovery
• Digital Assets: Images, documents, and structured data become first-class citizens with their own DIDs
• Encrypted Communications: End-to-end encrypted messages stored with DIDs
• Organizational Structures: Groups and hierarchies with membership data
• Notices and Announcements: Time-sensitive communications to specific recipients
• Polls and Governance: Decentralized voting with cryptographic integrity

W3C Compatibility

The W3C DID Core specification explicitly supports extensibility. Archon's didDocumentData is an additive extension that follows W3C guidance, ensuring graceful degradation for systems unaware of it.

Registry System

Registry Abstraction

Archon provides a unified interface across different consensus mechanisms. This abstraction allows users to choose their preferred security/cost trade-offs at DID creation time.

Hyperswarm Registry

The Hyperswarm registry provides fast, peer-to-peer operation distribution using a gossip protocol. Operations are broadcast to connected peers, validated locally, and ordered by timestamp with cryptographic tiebreakers for eventual consistency across the network.

Blockchain Registries

Bitcoin and Feathercoin registries anchor operation batches to the blockchain via OP_RETURN outputs. The mechanism:

1. Operations accumulate in a queue
2. Mediator batches operations and computes batch CID
3. Batch CID is embedded in OP_RETURN output (60 bytes)
4. Transaction is broadcast and confirmed
5. All nodes independently verify and import

Blockchain Timestamping

Operations confirmed on blockchain automatically receive cryptographic timestamping:

• Lower Bound (optional): Block referenced in operation's blockid field, proving creation after that block
• Upper Bound (always): Block containing the anchored operation with full block metadata
• Legal Use: Timestamped operations provide court-admissible proof of existence at specific times
• Use Cases: IP registration, credential validity windows, audit compliance, version control

Verifiable Credentials

W3C Compliance

Archon implements the full W3C Verifiable Credentials Data Model, enabling compatibility with the broader identity ecosystem. Credentials follow the standard structure with issuer, holder, verifier, and optional revocation support.

Credential Lifecycle

1. Issuer: Creates and cryptographically signs a credential
2. Holder: Accepts the credential and stores it securely
3. Verifier: Validates the credential against the issuer's DID
4. Revocation: Issuer can revoke with full audit trail maintained

Privacy Features

• Encryption: Credentials can be encrypted for specific recipients
• Selective Disclosure: Holders present only necessary credentials and attributes
• Bound Credentials: Credentials cryptographically bound to subjects prevent credential transfer

Cryptographic Foundation

Key Management (BIP-32/BIP-39)

Archon uses industry-standard key derivation:

• BIP-39: Mnemonic seed phrase generation for user backup and recovery
• BIP-32: Hierarchical deterministic wallet enabling key derivation for multiple identities
• Key Derivation: Separate paths for Bitcoin keys, SegWit, Taproot, and DID signing

Signature Scheme

All operations are signed using ECDSA over secp256k1:

signature = ECDSA_sign(
  private_key,
  SHA256(canonical_json(operation))
)

Content Addressing

DIDs are derived from content addresses, making them self-certifying:

operation = create_operation(public_key, registry, ...)
canonical = json_canonicalize(operation)
cid = IPFS_add(canonical)  // CIDv1, base32
did = "did:cid:" + cid

The DID itself proves the integrity of the creation operation through cryptographic hashing.

Encryption

• AES-256-GCM: Symmetric encryption for at-rest credential and message protection
• Selective Disclosure: Cryptographic commitments enable revealing only necessary data

Advanced Features

Time-Travel Resolution

Archon enables resolving DIDs at any point in their history through operation chaining:

resolveDID(did, { versionTime: "2024-01-15T10:00:00Z" })
resolveDID(did, { versionSequence: 3 })
resolveDID(did, { versionId: "bafkrei..." })

Use Cases: Audit trails, dispute resolution, compliance verification, historical analysis

Decentralized Messaging (D-Mail)

A complete email system built on the DID infrastructure supporting folder organization, CC with individual encryption, file attachments as asset DIDs, read tracking, and dual encryption.

Privacy-Preserving Voting

Two-phase voting protocol with ballot collection (private), optional result revelation, spoil ballots for plausible deniability, and anonymous tallying.

Group Vaults with Secret Membership

Multi-party encrypted storage where members can share data without knowing each other's identities, ideal for whistleblower systems and anonymous committees.

Challenge-Response Authentication

Flexible authentication supporting simple identity challenges, credential type challenges, and issuer-specific challenges with Verifiable Presentations.

Key Rotation

Secure key rotation without changing the DID. Old keys cannot sign new operations (enforced by previd chain), but historical signatures remain verifiable.

Network Topology

Node Types

• Full Nodes: Run complete Gatekeeper with local database, participate in all supported registries, validate and store all operations
• Light Clients: Connect to trusted full nodes, perform wallet operations locally, delegate resolution
• Registry Nodes: Specialized mediator nodes focused on specific registry synchronization

Peer Discovery

• Hyperswarm DHT: Topic-based DHT for node discovery with encrypted noise protocol connections
• IPFS Network: Global content retrieval ensuring availability of DID operations

Synchronization

Nodes synchronize through multiple channels: Hyperswarm for fast gossip-based distribution, IPFS for content availability, and blockchain nodes for finality confirmation. This multi-layer approach ensures both speed and security.