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
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 |
# 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 --ollamaddot 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 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/wsEach 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/dueevery 15s)
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)
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 startWithout a voice box configured, skills return structured JSON directly (useful for API integrations).
See .env.example for all configuration options.
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 --installSkills 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.
# 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 ~/.openclawThe migration tool (DISCON Lock #15) implements a hardened 5-step pipeline:
- SHA-256 integrity verification of the OC installation
- SOUL.md parsing (OC's flat markdown memory format)
- Memory sanitization (injection payloads, shell metacharacters removed)
- 3-category skill audit (MATCHED / NO EQUIVALENT / FLAGGED)
- 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).
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-lookupEvery 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 stats10 event types: auth, skill_exec, firewall, rate_limit, signing, memory_write, bridge, purge, config_change, lifecycle.
# Dry run (shows what would be deleted)
ddot purge --dry-run
# Full NIST 800-88 Rev 1 "Clear" purge
ddot purge --confirmThree-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).
# Run 17-practice compliance matrix (FAR 52.204-21 / NIST SP 800-171)
ddot doctor --cmmcCurrent status: 14 MET, 3 PARTIAL, 0 GAP = 91% compliance.
See SECURITY.md for our security policy, responsible disclosure process, and bug bounty program ($100-$5,000).
Key security properties:
unsafecode is forbidden across the entire workspace- All dependencies audited via
cargo audit+cargo denyin 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
ddot's physical body -- 5 ASIC miners producing ~10 TH/s -- serves three purposes:
- Mining: Bitcoin revenue
- Entropy: Physically-grounded key derivation (HKDF-SHA256 + OS entropy mixing)
- Attestation: Skill signatures, revocations, and proof-of-body committed to Bitcoin via
OP_RETURN
Live mainnet attestations:
- SigmaMerkle:
27d638d2... - ProofOfBody:
6f2ea696...
The ddot-attestation crate implements:
- Wire format: 41-byte
OP_RETURNpayloads (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.
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 --ollamaThe 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.
# 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.shMSRV: 1.91 (required by wasmtime 42 / cranelift edition2024).
See CONTRIBUTING.md for guidelines.
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 |
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 viaprecompile()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.
- 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.
- Website: ddot.build
- The Forge: forge.ddot.dev
- Security: SECURITY.md
- Contributing: CONTRIBUTING.md
- Bug Bounty: security@ddot.build