LORE

An on-chain product intelligence platform that verifies autonomous agent decisions and commits them to cryptographic audit trails

Comment

LORE: Decentralized Behavioral Intelligence

INSPIRATION

We are entering a future run by autonomous AI agents. These agents are making decisions that directly affect our businesses, our products, and our capital. Yet, as developers, we are operating in the dark.

  • How do we know that an agent processed telemetry correctly?
  • How can we prove that a model didn't hallucinate or drift under the hood?
  • How do we verify agentic workflows without compromising sensitive user data?

The inspiration for LORE came from wanting to give autonomous AI agents "skin in the game." We wanted to build a system where product decisions are backed by cryptographic proof, and where agents are held accountable. We took the concepts of Zero-Knowledge Proofs (ZKVM) and Algorithmic Slashing from the blockchain space and applied them directly to AI observability. The result is LORE: a platform that lets product teams mathematically prove exactly why they built what they built.

How LORE came into picture:

LORE is designed as a highly decoupled, tiered monorepo built using Go, Rust, TypeScript, and Solidity.

  • Edge Telemetry Ingestion (Go): The scout-agent acts as a Model Context Protocol (MCP) client. It fetches real-time behavioral streams (Pendo/Novus), packages them with unique trace IDs, and pushes them to a secure message broker.
  • Message Broker (Valkey/Redis): A high-throughput, secure Redis-compatible stream broker buffers raw telemetry before consumption.
  • Proving & Slashing Core (Rust): The analyst-agent consumes telemetry events asynchronously. It compiles trace validation logic into a RISC Zero zkVM Guest Circuit. The Guest Circuit executes the validation logic, redacting sensitive user data, and outputs a cryptographic Groth16 proof (ZK-SNARK receipt) and a public journal.
  • Synthesis Layer (Go): The narrative-agent consumes the verified insights and receipts, migrating them through Google Gemini (gemini-2.5-flash) to synthesize executive summaries of verified agent decisions.
  • On-Chain Audit Ledger (Solidity): Deployed verifier contracts (LoreZKVerifierLedger and MockRiscZeroVerifier) on Ethereum Sepolia verify the Groth16 proofs.
  • Command Center (Next.js): A sleek dashboard displaying a Global Trust Leaderboard, providing interactive verification portals, and dynamically locking commit actions for slashed agents.

Mathematical Formulations involving LORE

Instead of relying on gas-heavy ERC20 tokens for staking, we built a tokenless trust and slashing engine natively powered by mathematics.

An agent's base Trust Score is computed dynamically based on historical execution success:

$$\text{Trust Score} = \left( \frac{\text{Successes}}{\text{Successes} + \text{Failures}} \right) \times 100$$

When a policy violation or hallucination event is detected, the system applies an exponential reputation penalty factor based on the total failures:

$$\text{Reputation} = \text{Trust Score} \times \left( 0.8^{\text{FailCount}} \right)$$

If the reputation score drops below \( 60\% \), the agent is flagged as banned, and the frontend dashboard automatically locks its ability to commit data.

Annoying Challenges Encountered

1. The Redis/Valkey Public Proxy Authentication Bug

During cloud deployment on Railway, the Rust redis-rs client repeatedly failed to connect to the public Redis database, returning an AuthenticationFailed error even with correct credentials.

  • The Cause: We discovered that the public Railway TCP proxy does not support command pipelining prior to authentication. redis-rs pipelines connection checks (PING, CLIENT SETINFO, etc.) alongside AUTH, causing the proxy to drop the connection.
  • The Resolution: We migrated the monorepo to use Railway's Private Networking (communicating securely over redis.railway.internal:6379). This bypassed the public proxy completely, enabling standard, high-speed multiplexed Redis connections.

2. Silent OTLP Exporter Failures

When OpenTelemetry (OTel) exporters are initialized, they spin up background threads to send trace spans. If the Jaeger telemetry backend is offline (as it is in many production deployments), OTel's background thread constantly spammed stderr logs with Connection refused (os error 111).

  • The Resolution: We added a custom pre-flight TCP reachability check to the OTel client. Before starting the pipeline, the agent tries to connect to the gRPC endpoint. If it is unreachable, it logs a single warning and switches to a local no-op tracer, keeping the logs perfectly clean.

3. High-Quality Markdown Parsing on Next.js

The summaries returned by Google Gemini are formatted in rich Markdown. In early builds, Next.js rendered these as unformatted raw text.

  • The Resolution: Instead of adding heavy third-party packages, we wrote a custom, lightweight, and type-safe Markdown rendering engine inside the dashboard cards. It parses headers, bold text, and numbered/bulleted lists into styled React components.

The MAIN GOAL:

Building LORE pushed us to explore the frontiers of cryptographic observability:

  • ZK VM Optimization: We learned how to write efficient, low-cycle Guest Circuits in RISC Zero, keeping proving times low enough for asynchronous production data pipelines.
  • Tokenless Slashing Mechanics: We proved that game-theoretic alignment for AI agents can be achieved off-chain via mathematics instead of on-chain capital-intensive staking.
  • Resilient Agent Architectures: By engineering Dead-Letter Queues (DLQ) and auto-reconnecting MCP clients, we built a system that remains resilient even during upstream LLM provider outages.

Built With

Share this project:

Updates