Self-hosted endpoint defense for Web3 operators.

Joaquim Azevedo · Tamandua Security · v0.5 · May 2026 · 14-min read

Web3 operators sit on a contradiction. The most valuable signing material in the world flows through the least defended perimeter: the endpoint.

The endpoint is the perimeter for any Web3 operator, but legacy EDR vendors are not designed for this audience. They want to ingest your full process tree into their multi-tenant cloud — exactly the data your custody desk most needs to keep private.

At the same time, counterparties have no way to verify that an operator's endpoints are actually monitored.

One infostealer on a treasury workstation rewrites your week. Browser cookies, session tokens, signing scripts, RPC keys and seed phrases all converge in the same userland. The blast radius of a single compromised laptop in 2026 is meaningfully measured in basis points of TVL.

Custody operators are increasingly remote, low-headcount, and asymmetric vs. attackers.
Validators run from edge data centers with operator-class threat profiles.
Market-making desks tolerate microsecond-class latency but routinely tolerate weeks-stale endpoint posture.

CUSTOMER PERIMETER · SELF-HOSTED · PRIVATE

endpoint-1

endpoint-2

endpoint-3

Backend manifest + signer ed25519 per tenant

manifest_hash + sig

PUBLIC · SOLANA

Solana attest program

The agent runs on Windows and Linux with no inbound management port. It ships endpoint telemetry over an outbound authenticated channel to the customer's self-hosted backend. The backend normalizes process, DNS, network, and detection evidence, computes redacted incident manifests, and can submit a bounded proof to Solana when attestation is enabled. Health and remediation attestations use the same model and remain part of the public roadmap until validated in production environments.

The agent and backend never expose:

Hostnames, usernames, or AD identities
Internal IP addresses, MAC addresses, or device fingerprints
File paths, command-lines or registry values (they are hashed locally)
Wallet addresses, transaction history, or trading data
Customer identity or any tenant-correlatable identifier on-chain

What we do publish is a fixed-shape struct: incident hash, manifest hash, severity, MITRE technique IDs, IOC count, IOC type bitmap, timestamp, tenant pubkey, and signature.

Proof Model

We define three classes of attestation:

Proof of Incident

Records that Tamandua generated an incident attestation from configured detection evidence with redacted manifest hash, rule hash, MITRE context, severity, IOC count, timestamp, and Solana transaction signature.

Proof of Health

Roadmap: would attest a bounded health window after posture workflows are production-validated, including policy version and pseudonymous endpoint identity.

Proof of Remediation

Roadmap/validated deployments only: records a response-action result and metadata, not proof that remediation fully removed the threat.

Why Solana

We chose Solana for three operational reasons: cost (future continuous health attestation has to be cheap at fleet scale), throughput (we anchor small proofs, not raw telemetry), and verification (Solscan is already where Web3 operators verify public state during incidents).

The on-chain footprint is bounded and predictable. Solana is treated as a bulletin board, not a database.

Operators who cannot accept any direct on-chain RPC dependency from their backend can run in relay mode, where a separate relay service submits attestations on their behalf.

Bounty Governance

Validated defensive value, not noise

The bounty model targets a dangerous failure mode: contributors writing detections for malware they wrote themselves. The planned mitigation is benchmark evidence, reviewer consensus on payouts above a threshold, external IOC correlation, and penalties for plagiarism or self-generated malware.

Detection packs are the unit of distribution. Every pack is signed, reproducibly built, and tested against the public benchmark suite before listing. Reputation accrues to the maintainer pubkey, not the username.

Open Source Approach

Public component mirrors are available under Apache 2.0 through treant-lab/tamandua-community and the focused agent, server, validation, GUI, CLI, browser extension, and core-library repositories. The internal monorepo remains the source of truth.

Open-sourcing an EDR opens real risks: signature evasion, anti-forensic hooks, and supply-chain abuse on rule packs. We mitigate via signed releases, reproducible builds, scoped mirrors, review gates, validation artifacts, and rate-limited remote configuration so a compromised maintainer cannot push a kill-switch ruleset.

Security-sensitive operational material still stays out of public repos: credentials, signing keys, customer telemetry, private deployment automation, and unpublished exploit or malware samples.

Current Maturity

See the roadmap section on the homepage for implementation status.

This is advanced alpha software. Detection and response coverage targets Windows and Linux endpoints, including process telemetry, file signals, DNS and network context, Network Insight, local response actions, and server-side NDR. Packet-level TLS, JA3, and certificate fields depend on available OS or packet sensors. Bounty validation, marketplace, health attestations, remediation attestations, and oracle integrations remain roadmap items until validated as production surfaces.

Illustrative data on public pages is separate from production attestations. Production deployments anchor against mainnet only after a tenant-signed go-live ceremony.

Citation

Azevedo, J. (2026). Tamandua Sentinel: self-hosted endpoint defense for Web3 operators. v0.5.