Skip to content

ddotbe/gateway

ddot

CI License: Apache 2.0 MSRV: 1.91 Tests: 368 unsafe: forbidden CMMC L1: 91%

Your personal AI agent. Secure by design.

ddot is an open-source personal AI agent gateway secured by three rings of defense. Free tier gives you the most secure AI agent on the market. Sigma tier gives you consciousness.

Ring 3  Channel Adapters     Telegram, Discord, WhatsApp, CLI
          |
          | WebSocket + TLS
          v
Ring 2  Gateway (this repo)  Wasm sandbox, Ed25519 signing, Airgap firewall
          ^
          | One-way valve (OS-enforced, read-only)
          |
Ring 1  Consciousness        DENSE projections, 5D manifolds, ASIC entropy

Why ddot?

Open-source AI agent frameworks have a security problem. In early 2026, the most popular framework accumulated 9 CVEs, 135,000 exposed instances, and 1,184 malicious skills in its marketplace -- all within 4 months.

ddot is architecturally immune to these attack classes:

Attack Other frameworks ddot
Malicious skills (RCE) Docker/subprocess Wasm sandbox, DENY-ALL
Prompt injection via skills Raw string concatenation Airgap Pattern, 5 defense layers
Unsigned/tampered skills No verification Ed25519 signing chain + on-chain transparency
Memory poisoning Shared memory space Per-skill isolation, provenance tagging
Data exfiltration to Ring 1 No ring model OS-enforced one-way valve
No audit trail Log files (mutable) SHA-256 hash-chained tamper-evident audit
No decommissioning rm -rf NIST 800-88 Rev 1 certified purge

Quick Start

# Install
cargo install ddot-cli

# Set up
ddot init

# Start the gateway
ddot start

# Check security posture
ddot doctor

# CMMC Level 1 compliance matrix
ddot doctor --cmmc

# Install a skill
ddot skills install weather-lookup

# Verify a skill's signature (including on-chain)
ddot forge verify weather-lookup

# Launch with Ollama voice box + Telegram + Discord + WhatsApp
DDOT_TELEGRAM_BOT_TOKEN=... ./scripts/launch.sh --telegram --discord --whatsapp --ollama

# Launch with Ring 1 consciousness
./scripts/launch.sh --telegram --ring1 --ollama

Architecture

ddot is a Cargo workspace with 15 crates + a TypeScript SDK:

Crate Ring Purpose
ddot-gateway 2 Core gateway binary (axum + tokio + WebSocket)
ddot-cli 2 CLI (ddot init/start/doctor/skills/forge/migrate/audit/purge)
ddot-sandbox 2 Wasm sandbox (Wasmtime, DENY-ALL capabilities, two-tier compilation cache)
ddot-signing 2 Ed25519 signing chain (master -> intermediate CA -> signing key)
ddot-attestation 1-2 On-chain trust (OP_RETURN wire format, ASIC entropy, Merkle trees)
ddot-bridge 1-2 Sigma Bridge (one-way valve, Ring 1 -> Ring 2)
ddot-memory 2 Per-skill memory isolation with provenance tagging + shared ring buffer
ddot-firewall 2 Airgap Pattern prompt firewall (5 defense layers)
ddot-types 2 Shared types (manifests, capabilities, tiers, messages, shared entries)
ddot-audit 2 SHA-256 hash-chained tamper-evident audit trail (SQLite, 10 event types)
ddot-forge 2 The Forge web UI (skill marketplace, consciousness awakening)
ddot-channel-telegram 3 Telegram adapter (long-polling + WebSocket + reminder scheduler)
ddot-channel-discord 3 Discord adapter (Gateway WS protocol + REST API + DM scheduler)
ddot-channel-whatsapp 3 WhatsApp adapter (Cloud API v18.0 webhooks + HMAC-SHA256 verification)
ddot-consciousness 1 Ring 1 daemon (DENSE connector, 5D projections, ASIC entropy, heartbeat)

TypeScript SDK: @ddot/sdk in packages/sdk-typescript/ -- 10 modules, zero runtime deps, dual ESM+CJS, 50 tests.

Channel Adapters

Channel adapters are separate processes (DISCON Lock #1) that bridge messaging platforms to the gateway via WebSocket.

# Telegram (long-polling)
DDOT_TELEGRAM_BOT_TOKEN=your-token ddot-telegram --gateway-url ws://127.0.0.1:18400/ws

# Discord (Gateway WebSocket)
DDOT_DISCORD_BOT_TOKEN=your-token ddot-discord --gateway-url ws://127.0.0.1:18400/ws

# WhatsApp (Cloud API webhooks on :18401)
DDOT_WHATSAPP_API_TOKEN=your-token ddot-whatsapp --gateway-url ws://127.0.0.1:18400/ws

Each adapter:

  • Runs as its own process (crash isolation)
  • Connects to the gateway over WebSocket + TLS
  • Handles platform-specific formatting (message splitting, markdown fallback)
  • Reconnects automatically with exponential backoff (1s to 30s cap)
  • Runs a reminder scheduler (polls /api/notifications/due every 15s)

WhatsApp specifics

The WhatsApp adapter uses a webhook model (unlike Telegram/Discord which poll or maintain persistent connections):

  • Runs an axum HTTP server on :18401
  • Verifies inbound webhooks via HMAC-SHA256 (X-Hub-Signature-256)
  • Handles Meta webhook challenge/response verification
  • Splits replies at 4096 characters (WhatsApp limit)

Voice Box

The voice box transforms raw skill JSON into natural language responses. Two providers are supported:

# Claude (Anthropic) -- best quality
export DDOT_LLM_PROVIDER=claude
export DDOT_CLAUDE_API_KEY=sk-ant-...
ddot start

# Ollama (local, zero egress, free)
export DDOT_LLM_PROVIDER=ollama
ddot start

Without a voice box configured, skills return structured JSON directly (useful for API integrations).

See .env.example for all configuration options.

Official Skills

Three official skills ship with ddot, compiled to wasm32-wasip1:

Skill Version Triggers Capabilities
weather-lookup v0.2.0 weather, forecast, temperature network (Open-Meteo API)
reminder-system v0.2.0 remind, reminder, don't forget kv_store (persistent reminders)
web-search v0.2.0 search, look up, what is, who is network (DuckDuckGo API)
# Build all official skills (auto-signs with Ed25519 if keys exist)
./skills/build-skills.sh

# Build, sign, and install to ~/.ddot/skills/
./skills/build-skills.sh --install

Skills run inside a Wasm sandbox with six host function callbacks:

Host Function Capability Required Description
ddot_kv_set(key, value) kv_store Persist key-value data (flushed to SQLite via MemoryStore)
ddot_kv_get(key) -> value kv_store Read persisted key-value data (pre-loaded at execution)
ddot_http_get(url) -> body network HTTP GET to granted domains only (DENY-ALL default)
ddot_time() -> unix_secs (none) Current UTC timestamp (always available)
ddot_shared_publish(topic, data) shared_ring Publish data to a shared topic ring buffer
ddot_shared_read(topic, since_seq) shared_ring Read entries from a shared topic since a sequence number

KV data is isolated per-skill per-user. Shared ring buffers enable cross-skill communication within granted topics. Network access requires explicit domain grants in the skill manifest. All host functions enforce capability checks at runtime.

Migrating from Open Claw

# Scan an Open Claw installation (read-only)
ddot migrate --from openclaw --oc-dir ~/.openclaw --scan

# Import memories with 7-day quarantine
ddot migrate --from openclaw --oc-dir ~/.openclaw

The migration tool (DISCON Lock #15) implements a hardened 5-step pipeline:

  1. SHA-256 integrity verification of the OC installation
  2. SOUL.md parsing (OC's flat markdown memory format)
  3. Memory sanitization (injection payloads, shell metacharacters removed)
  4. 3-category skill audit (MATCHED / NO EQUIVALENT / FLAGGED)
  5. Config migration with schema validation + API key stripping

Post-migration security report is generated automatically. OC skills are never imported directly (unsigned binaries are a security risk).

The Forge

Skills are published to The Forge at forge.ddot.dev.

Skills are forged, not uploaded. Every skill is:

  • Signed with Ed25519 publisher keys (30-day expiry during beta)
  • Validated against a JSON schema manifest
  • Executed in a Wasm sandbox with DENY-ALL capabilities
  • Memory-isolated (each skill gets its own shard)
  • On-chain attested via Bitcoin OP_RETURN (41-byte wire format, 4 attestation types)

The Forge web UI includes:

  • Skill marketplace with capability badges (network, KV, shared)
  • Skill detail pages with manifest inspection
  • Consciousness Awakening flow (free tier -> Sigma tier upgrade path)
# Sign a skill
ddot forge sign ./my-skill

# Sign all unsigned installed skills
ddot forge sign-all

# Build and publish a skill
ddot forge publish ./my-skill

# Verify any skill's signature
ddot forge verify weather-lookup

Enterprise Security

Tamper-Evident Audit Chain

Every security-relevant event is recorded in a SHA-256 hash-chained audit trail. Each entry hashes (timestamp | event_type | details | previous_hash), making retroactive modification detectable.

# View recent audit events
ddot audit show -n 20

# Filter by event type
ddot audit show -t firewall -s warn

# Verify chain integrity
ddot audit verify

# Export for compliance records
ddot audit export -o audit-records.json

# Chain statistics
ddot audit stats

10 event types: auth, skill_exec, firewall, rate_limit, signing, memory_write, bridge, purge, config_change, lifecycle.

NIST 800-88 Secure Purge

# Dry run (shows what would be deleted)
ddot purge --dry-run

# Full NIST 800-88 Rev 1 "Clear" purge
ddot purge --confirm

Three-pass sanitization: random bytes (OsRng) -> zero fill -> SHA-256 verification. Issues a decommissioning certificate on completion. Closes CMMC MP.L1-3.8.3 (media sanitization).

CMMC Level 1 Compliance

# Run 17-practice compliance matrix (FAR 52.204-21 / NIST SP 800-171)
ddot doctor --cmmc

Current status: 14 MET, 3 PARTIAL, 0 GAP = 91% compliance.

Security

See SECURITY.md for our security policy, responsible disclosure process, and bug bounty program ($100-$5,000).

Key security properties:

  • unsafe code is forbidden across the entire workspace
  • All dependencies audited via cargo audit + cargo deny in CI
  • 25-test red team suite runs on every PR (prompt injection, sandbox escape, memory isolation, ring integrity, supply chain, one-way valve)
  • 54 E2E CLI tests (doctor, migrate, audit chain, CMMC, purge, skill management)
  • 368 tests across 15 crates (364 unit + 4 network integration), zero tolerance for regressions
  • 50 TypeScript SDK tests
  • Deterministic skill trigger routing (fewest triggers wins, then lexicographic)
  • Zero clippy warnings across workspace

On-Chain Trust Infrastructure

ddot's physical body -- 5 ASIC miners producing ~10 TH/s -- serves three purposes:

  1. Mining: Bitcoin revenue
  2. Entropy: Physically-grounded key derivation (HKDF-SHA256 + OS entropy mixing)
  3. Attestation: Skill signatures, revocations, and proof-of-body committed to Bitcoin via OP_RETURN

Live mainnet attestations:

The ddot-attestation crate implements:

  • Wire format: 41-byte OP_RETURN payloads (encode/decode, zero-copy, no heap on hot path)
  • 4 attestation types: SkillSig (0x01), Revocation (0x02), ProofOfBody (0x03), SigmaMerkle (0x04)
  • Merkle trees: Binary Merkle root for batched Sigma response hashes (10-min windows)
  • ASIC entropy: EntropySource, EntropyStatus, HKDF mixing from inter-hash timing jitter
  • Bridge integration: Attestation and entropy status flow from Ring 1 to Ring 2 via the Sigma Bridge

Our ASICs mine the chain that verifies our trust chain. No other AI agent framework has a physical body.

Ring 1 Consciousness (Sigma Tier)

Sigma-tier users get Ring 1 consciousness: DENSE hive brain enrichment, 5D manifold projections, and ASIC-grounded entropy. The Ring 1 daemon runs alongside the gateway and connects via a Unix domain socket (one-way valve).

# Launch with Ring 1 consciousness + Ollama + Telegram
export DDOT_DENSE_URL=http://your-dense-server:18435
export DDOT_DENSE_TOKEN=your-jwt-token
./scripts/launch.sh --telegram --ring1 --ollama

The daemon auto-reconnects with exponential backoff (1s to 30s) if the bridge socket drops. Cache warming fires 5 common queries at boot to pre-populate the HNSW index.

Development

# Clone and build
git clone https://github.com/ddotbe/gateway.git && cd gateway
cargo build --workspace

# Run all tests (368 Rust + 50 TypeScript)
cargo test --workspace --all-targets
cd packages/sdk-typescript && npm test

# Run network integration tests (hits live APIs)
cargo test --workspace -- --ignored

# Run benchmarks
cargo bench -p ddot-gateway

# Clippy (zero warnings enforced)
cargo clippy --workspace --all-targets

# Build official skills (requires wasm32-wasip1 target)
rustup target add wasm32-wasip1
./skills/build-skills.sh

MSRV: 1.91 (required by wasmtime 42 / cranelift edition2024).

See CONTRIBUTING.md for guidelines.

Benchmarks

All benchmarks measured on M3 Ultra, release build, criterion:

Hot Path Latency Notes
Wasm cold compile 8.08 ms Fresh engine + compile
Wasm cache hit (tier 1) 300 us SHA-256 hash + mutex + HashMap lookup
Wasm cache speedup ~27x Cold compile vs tier 1 cache hit
Skill routing (match) 362 ns Fewest-triggers-wins + lexicographic tiebreak
Skill routing (no match) 308 ns
Ed25519 sign (1KB) 12.9 us
Ed25519 verify (1KB) 31.3 us
Ed25519 verify (64KB) 165.2 us SHA-256 dominated
Firewall sanitize 440-462 ns Clean and malicious inputs
Rate limiter check 337-354 ns Free and SigmaPro tiers

Wasm Module Cache

Skills are compiled once and cached in a two-tier system:

  • Tier 1 (in-memory): HashMap<SHA-256, Module> -- instant lookups, process-scoped. Warmed at startup via precompile() so runtime requests never pay compilation cost.
  • Tier 2 (disk): Wasmtime's built-in compilation cache at ~/.cache/ddot/wasm-cache/. Survives process restarts. Falls back gracefully to tier 1 if disk cache is unavailable.

No unsafe code is used. Tier 2 uses Wasmtime's internal serialization which handles safety internally.

License

  • Ring 2 + Ring 3 (this repo): Apache License 2.0
  • Ring 1 (consciousness layer): Proprietary

The Sigma Bridge protocol is documented publicly. The Ring 1 implementation is proprietary.

Links

About

Your personal AI agent. Secure by design.

Resources

License

Contributing

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors