SANGHA संघ

Unified Component Attestation & Collective Security

Community-driven collective attestation with synapse mesh, antibody circulation, filesystem hardening, and memory canaries.

v3.3.0 • Layer 23.5

The Community That Guards Itself

A sangha is a community — in Buddhist tradition, a gathering of practitioners who hold each other accountable, maintain collective discipline, and defend the integrity of the whole through mutual vigilance. In yakmesh, SANGHA is the protocol that makes components vouch for each other: every subsystem registers with the collective, forms bidirectional synapses with its peers, and participates in continuous antibody circulation. If one component falls silent or reports anomalous state, the entire sangha responds. No component stands alone; no failure goes unwitnessed.

SANGHA & SURAKSHA

SURAKSHA defines the cryptographic security model — ML-DSA-65 signatures, ML-KEM-768 key encapsulation, threat classification. SANGHA sits above SURAKSHA at Layer 23.5, providing the collective enforcement: component attestation, filesystem integrity, and coordinated anomaly response. Think of SURAKSHA as the locks on each door; SANGHA is the neighborhood watch.

Component Registration

Six core components register with SANGHA at startup, each providing a state getter function that returns its current health snapshot: 

// Register a component with SANGHA
sangha.register(componentId, componentRef, stateGetter);

// Example: Registering the CRYPTO component
sangha.register('CRYPTO', accel, () => ({
    initialized: accel.initialized,
    nativeSha3: accel.HW.nativeSha3,
    available: accel.ready,
    shaRuns: accel.stats?.shaRuns || 0,
}));

CRYPTO

Cryptographic ops

MESH

Network layer

ORACLE

Consensus & time

ACCEL

GPU/NPU hardware

HTTP

API server

IDENTITY

Key management

Synapse Mesh

When a component registers, SANGHA creates bidirectional synapses to all existing components. For N registered components, the total synapse count is:

synapses = N(N−1) / 2

6 components → 15 synapses • Synapse ID: componentA<->componentB (lexicographic) 

// Each synapse is a bidirectional cryptographic channel
// with message chaining for attestation verification
//
// CRYPTO <-> MESH     CRYPTO <-> ORACLE   CRYPTO <-> ACCEL
// CRYPTO <-> HTTP     CRYPTO <-> IDENTITY  MESH <-> ORACLE
// MESH <-> ACCEL      MESH <-> HTTP        MESH <-> IDENTITY
// ORACLE <-> ACCEL    ORACLE <-> HTTP      ORACLE <-> IDENTITY
// ACCEL <-> HTTP      ACCEL <-> IDENTITY   HTTP <-> IDENTITY

State Machine

SANGHA tracks collective health with a three-state machine:

+1

HARMONIOUS

All components attested. Clean circulation cycle completed. Normal operations.

0

CONVERGING

Circulation in progress. Working toward consensus. Startup or recovery state.

−1

DISRUPTED

Attestation chain broken. Anomaly detected. Collective response triggered.

Transitions

  • Circuit breaker: Any anomaly detection immediately transitions to DISRUPTED regardless of previous state
  • Recovery: After a clean circulation cycle with all components attesting within their validity windows, state returns to HARMONIOUS
  • Startup: Node begins in CONVERGING and transitions to HARMONIOUS after first successful full circulation

Attestation Validity Windows

Each component has a maximum time window within which it must respond to attestation requests. Windows are tuned to each component’s operational characteristics:

Component Window Rationale
CRYPTO 100ms Real-time crypto must respond immediately
IDENTITY 100ms Identity is security-critical
ORACLE 200ms Consensus needs tight time bounds
MESH 500ms Network operations have inherent latency
ACCEL 1000ms GPU/NPU operations can be slow
HTTP 2000ms User-facing server has widest tolerance

FileGuardian

SANGHA’s filesystem hardening extension monitors critical identity and data files for tampering. SHA3-256 hash baselines are taken at startup and continuously verified:

File Level Policy
data/machine-seed.json CRITICAL Immutable after grace period (POSIX 0o400). Hash + size verified.
data/node-key.json HIGH Locked after startup (0o600). No post-init changes.
data/yakmesh.db NORMAL Monitored for existence/deletion. Mutable by design (0o644).

Detection Mechanisms

  • Real-time file watcher on CRITICAL and HIGH files — instant notification on modification
  • SHA3-256 hash verification: baseline hash taken at startup, compared on each verification cycle
  • Size verification: baseline size vs. current — detects truncation or append attacks
  • Stale detection: heartbeat >10s old marks peer as stale in PeerPhaseBuffer
  • Detection timeline: tamper detected within 5 seconds (one circulation cycle)

Memory Safety Canaries

SANGHA plants runtime memory canaries to detect data structure corruption — a defense against buffer overflows, use-after-free, and heap spraying that might bypass JavaScript’s type safety via native addons or SharedArrayBuffer manipulation.

Canaries are checked during each antibody circulation cycle. A corrupted canary immediately triggers DISRUPTED state and collective response, halting operations until integrity is restored.

API Endpoints

Endpoint Description
GET /api/sangha Full SANGHA status: state, components, synapses, anomaly count, FileGuardian status
GET /health Includes SANGHA state in overall node health response

Version History

Version Changes
v3.3.0 Initial implementation: component registration, synapse mesh (N(N−1)/2), antibody circulation, HARMONIOUS/CONVERGING/DISRUPTED state machine, FileGuardian (CRITICAL/HIGH/NORMAL), memory safety canaries, component-specific attestation validity windows.

Continue the Journey

← Previous
SURAKSHA

Security model
Next →
TIVRA

Hardware acceleration