English: Fides is a trust layer between humans and AI agents. It sits in the execution path of agent actions, records what the agent actually did, enforces user-defined intent constraints before risky actions happen, and produces cryptographic evidence that important behavior stayed within scope. The goal is simple: let users enjoy agent-native productivity without having to blindly trust opaque automation.
中文： Fides 是位于人类与 AI agent 之间的一层信任基础设施。它插入 agent 的执行路径，记录 agent 实际做了什么，在高风险动作发生前执行用户定义的意图约束，并为关键行为生成可验证的密码学证明。目标很直接：让用户获得 agent 带来的效率，同时不必把信任建立在“黑箱自动化”之上。
English: Fides has three core capabilities: behavior logging, intent constraints, and ZKP verification. Together, these three parts answer three different trust questions: “What happened?”, “Was it allowed?”, and “Can this be verified without exposing private context?” Architecturally, Fides follows a pragmatic philosophy: Web2 UX, Web3 trust, invisible blockchain.
中文： Fides 的三项核心能力是：behavior logging、intent constraints 和 ZKP verification。它们分别回答三类信任问题：“发生了什么？”、“这是否被允许？”以及“能否在不暴露隐私上下文的前提下完成验证？”在架构哲学上，Fides 追求的是务实路线：Web2 UX，Web3 trust，invisible blockchain。
English: Fides is designed for the emerging world where agents do real work on behalf of users: reading files, calling tools, touching APIs, and making decisions across long-lived workflows. In that world, traditional app permissions are too coarse and chat history is too weak as an accountability primitive. Fides adds a programmable trust layer that can intercept operations, evaluate intent rules, and anchor verifiable evidence into an open protocol.
中文： Fides 面向的是这样一个正在到来的世界：agent 代表用户执行真实工作，例如读取文件、调用工具、访问 API，并在长链路工作流中持续做决策。在这个世界里，传统 app 权限模型太粗，聊天记录又不足以成为真正的问责机制。Fides 为此增加了一层可编程的信任层，用来拦截操作、评估意图规则，并把可验证证据锚定到开放协议上。
English: The product vision is not to put blockchain in front of the user, but to make agent systems auditable, constraint-aware, and provable by default. Users should feel protected even when the blockchain is invisible. Developers should be able to build agent products with familiar interfaces while inheriting stronger guarantees underneath.
中文： Fides 的产品愿景不是把 blockchain 直接暴露给用户，而是让 agent 系统默认具备可审计、具备约束意识、并且可证明的能力。即使用户完全感知不到链的存在，也应该能获得被保护的体验。开发者则可以继续使用熟悉的产品界面，同时在底层继承更强的可信保证。
┌─────────────────────────────────────────────────┐
│ Experience Layer / 用户体验层（闭源） │
│ app/web — Dashboard UI │
│ app/proxy — MCP Proxy Server │
├─────────────────────────────────────────────────┤
│ Fides Protocol / 核心协议层（开源） │
│ protocol/circuits — ZKP Circuits │
│ protocol/sdk — Rust SDK │
│ protocol/contracts — Solana Programs │
└─────────────────────────────────────────────────┘
English: The top layer is the product-facing experience layer. It is where agents are intercepted in real time and where users see logs, status, and system health. Today that layer includes the MCP proxy and the web dashboard.
中文： 顶层是面向产品的体验层。它负责在运行时拦截 agent 操作，也负责向用户展示日志、状态与系统健康信息。目前这一层包含 MCP proxy 和 web dashboard。
English: The lower layer is the protocol layer. It contains the circuits that define what can be proven, the SDK that converts runtime behavior into proof-friendly inputs, and the Solana programs that make critical state tamper-evident and community-auditable.
中文： 下层是协议层。它包含定义“能证明什么”的 circuits、把运行时行为转换为 proof 输入的 SDK，以及把关键状态做成不可篡改且可社区审计记录的 Solana programs。
fides/
├── protocol/
│ ├── circuits/
│ │ ├── access_scope/
│ │ │ ├── access_scope.circom # ZKP circuit for tool+content scope proof
│ │ │ └── build/ # Compiled artifacts (r1cs, wasm, zkey, proof)
│ │ ├── frequency_bound/
│ │ │ ├── frequency_bound.circom # ZKP circuit for operation frequency proof
│ │ │ └── build/
│ │ └── common/
│ │ └── utils.circom # Shared: MerkleInclusionProof, HashTwo, BoolCheck
│ ├── contracts/
│ │ └── programs/
│ │ ├── fides_registry/ # Stores user intent constraints on-chain
│ │ ├── fides_verifier/ # Stores ZKP verification results on-chain
│ │ └── fides_log/ # Stores behavior summary logs on-chain
│ └── sdk/
│ └── src/
│ ├── lib.rs # Module declarations
│ ├── hook.rs # Intercepts tool calls, computes hashes
│ ├── prover.rs # Converts witness to circuit inputs (BN128)
│ ├── intent.rs # Intent constraint engine
│ └── adapters/
│ └── mcp.rs # MCP protocol adapter
├── app/
│ ├── proxy/
│ │ └── src/
│ │ └── index.ts # MCP proxy server — the agent interception layer
│ └── web/
│ ├── src/
│ │ └── App.tsx # Dashboard UI
│ └── server.ts # Express API reading ~/.fides/logs/
└── docs/
├── whitepaper.md
└── protocol-spec.md
English: The repository root combines two layers: product-facing applications under app/ and protocol-facing primitives under protocol/. It exists as a monorepo so that interception logic, proof generation, and on-chain anchoring can evolve together without losing conceptual alignment.
中文： 仓库根目录同时容纳两层：app/ 下是面向产品的应用层，protocol/ 下是面向协议的基础设施。使用 monorepo 的原因是让拦截逻辑、proof 生成和链上锚定协同演进，避免它们在实现上彼此脱节。
English: protocol/ is the open-core heart of Fides. It defines the trust semantics that matter even if the user interface changes completely in the future.
中文： protocol/ 是 Fides 的 open-core 核心。即使未来前端形态完全变化，这一层依然定义了最重要的 trust semantics。
English: This folder contains the Circom circuits and build artifacts used to prove agent behavior properties. It exists so behavior claims can be expressed as math, not just application logs or screenshots.
中文： 这个目录存放 Circom circuits 以及相关 build 产物，用于证明 agent 行为满足某些性质。它存在的意义，是让行为声明变成数学约束，而不只是应用日志或截图。
English: access_scope/ contains the circuit used to prove that a tool invocation and content access both stayed within a user-approved Merkle authorization set. This is the most direct bridge between runtime agent behavior and privacy-preserving verification.
中文： access_scope/ 存放用于证明“工具调用与内容访问都位于用户批准的 Merkle 授权集合中”的电路。它是运行时 agent 行为与隐私保护验证之间最直接的连接点。
English: This file defines the AccessScope circuit. It recomputes two Merkle roots, checks them against public allowed roots, and binds operation_id plus timestamp into a public meta_hash so the proof is tied to a concrete action context. It exists because a trust layer needs more than logging; it needs a formal statement that can be verified independently.
中文： 这个文件定义了 AccessScope 电路。它会重算两个 Merkle root，将它们与公开的 allowed roots 对比，并把 operation_id 与 timestamp 绑定进公开的 meta_hash，从而让 proof 对应到一个具体动作上下文。它存在的原因是：信任层不能只做 logging，还需要一个可被独立验证的形式化声明。
English: This build directory stores compiled artifacts such as .r1cs, .wasm, .sym, .zkey, verification_key.json, witness files, and generated proofs. It exists so the circuit can move from source-level constraints into operational proving assets used by snarkjs.
中文： 这个 build 目录保存 .r1cs、.wasm、.sym、.zkey、verification_key.json、witness 文件以及生成出的 proofs 等编译产物。它的作用是把源码级约束转化为 snarkjs 可直接使用的实际 proving assets。
English: frequency_bound/ holds the second circuit family focused on operation limits over time windows. It complements access_scope by answering not “was this operation allowed?” but “did the system remain within a bounded frequency policy?”
中文： frequency_bound/ 保存第二类电路，关注的是时间窗口内的操作频率限制。它与 access_scope 形成互补，回答的问题不再是“这次操作是否被允许”，而是“系统是否仍然处于某个频率上限策略之内”。
English: This file defines the FrequencyBound circuit. It proves that a private actual_count is less than or equal to a private user_limit while exposing only hashed public context such as operation type and time window metadata. It exists to support rate-limit style trust guarantees without revealing sensitive usage details.
中文： 这个文件定义了 FrequencyBound 电路。它证明私有的 actual_count 小于等于私有的 user_limit，同时只公开 operation type 和 time window 元数据的哈希化上下文。它存在是为了支持类似 rate-limit 的信任保证，同时不泄露敏感使用细节。
English: This directory is the intended home for compiled frequency-bound artifacts. It fits the system by mirroring the access_scope/build/ workflow so multiple proof types can share one operational toolchain.
中文： 这个目录是 frequency-bound 电路编译产物的预期存放位置。它在系统中的意义，是与 access_scope/build/ 保持一致流程，让多种 proof 类型共享同一条 operational toolchain。
English: common/ stores reusable circuit helpers that multiple proof systems can depend on. It exists to keep hashing, boolean checks, and Merkle utilities consistent across different trust statements.
中文： common/ 存放可被多个 proof system 复用的电路工具。它的存在是为了让 hashing、boolean 检查和 Merkle 工具在不同信任声明之间保持一致。
English: This shared utility file defines BoolCheck, HashTwo, and MerkleInclusionProof. It exists because both current and future circuits need a canonical way to validate binary indices, compute Poseidon-based parent nodes, and reconstruct Merkle roots inside Circom.
中文： 这个共享工具文件定义了 BoolCheck、HashTwo 和 MerkleInclusionProof。它之所以存在，是因为当前与未来的电路都需要一套统一方式，在 Circom 内完成二值索引校验、基于 Poseidon 的父节点计算，以及 Merkle root 重建。
English: contracts/ contains the Anchor-based Solana programs that store durable protocol state and summaries. It exists so critical trust metadata can be anchored to a public chain without forcing every raw agent action to be stored on-chain.
中文： contracts/ 包含基于 Anchor 的 Solana programs，用于存储持久化协议状态与摘要。它存在的意义，是把关键的 trust 元数据锚定到公链，同时避免把每一条原始 agent 行为都直接写上链。
English: This directory groups the three on-chain programs by responsibility: registry, verifier, and log. It keeps the on-chain trust model modular so each program can evolve around a focused data model and cost profile.
中文： 这个目录按职责划分了三个链上程序：registry、verifier 和 log。这样做让链上 trust model 保持模块化，每个 program 都能围绕自己专注的数据模型和成本边界独立演进。
English: This program stores user intent constraints as canonical on-chain records. It exists so the system can anchor “what the user allowed” separately from “what the agent later did.”
中文： 这个 program 负责把用户的 intent constraints 存成链上的规范记录。它存在，是为了让系统能把“用户允许了什么”与“agent 之后实际做了什么”分开锚定。
English: This program stores the result of proof verification as a tamper-evident log. It exists because the most cost-efficient design is to verify proofs off-chain and only publish compact verification outcomes plus hashes on-chain.
中文： 这个 program 负责把 proof verification 的结果存成不可篡改日志。它存在的原因是：最具成本效率的设计，不是在链上完整验证 proof，而是在链下验证后只把紧凑的结果与相关哈希写上链。
English: This program stores behavior summary windows, not individual raw tool traces. It exists to give users and auditors a compact, time-bounded accountability layer with lower storage and compute cost.
中文： 这个 program 存储的是行为摘要窗口，而不是每一条原始工具调用轨迹。它存在的意义，是以更低的存储和计算成本，为用户和审计方提供一个紧凑、按时间窗口组织的问责层。
English: sdk/ is the Rust layer that turns real tool activity into proof-friendly and policy-aware data. It exists so interception, hashing, intent evaluation, and witness preparation can be embedded in agent runtimes in a typed, auditable way.
中文： sdk/ 是 Rust 实现的一层，用于把真实工具活动转化为适合 proof 和 policy 处理的数据。它存在，是为了让拦截、哈希、意图评估与 witness 准备能够以类型化、可审计的方式嵌入 agent runtime。
English: This source directory contains the SDK’s core modules. Each file maps to one trust-layer responsibility so the runtime data path remains legible and testable.
中文： 这个源码目录包含 SDK 的核心模块。每个文件对应一种信任层职责，从而让运行时数据路径保持清晰并易于测试。
English: lib.rs declares the public SDK modules and forms the crate’s entry point. It exists so consumers can import hook logic, proving helpers, and intent evaluation from one coherent package boundary.
中文： lib.rs 声明了 SDK 对外暴露的模块，是整个 crate 的入口。它存在的意义，是让使用方能够从统一的包边界导入 hook 逻辑、proving 工具和 intent evaluation。
English: hook.rs defines the runtime interception types such as ToolCall, ToolResult, and WitnessInputs, plus a default FidesHook implementation. It computes stable SHA-256 based hashes and encodes metadata into fields that later feed the proving layer. It exists because trust starts at the exact moment a tool call crosses the execution boundary.
中文： hook.rs 定义了运行时拦截相关类型，例如 ToolCall、ToolResult 和 WitnessInputs，并提供默认的 FidesHook 实现。它负责计算稳定的 SHA-256 哈希，并把元数据编码成后续 proving 层需要的字段。它存在，因为信任的起点正是工具调用穿越执行边界的那一刻。
English: prover.rs converts intercepted witness material into BN128 field elements and assembles full circuit input payloads. It exists because Circom and snarkjs expect decimal field values, while runtime systems naturally work with hashes, bytes, UUIDs, and timestamps.
中文： prover.rs 负责把拦截得到的 witness 数据转换成 BN128 field elements，并组装出完整的 circuit input payload。它存在，是因为 Circom 与 snarkjs 需要十进制 field 值，而运行时系统天然处理的是哈希、字节、UUID 和时间戳。
English: intent.rs defines the SDK-side IntentConstraint model and evaluators for ToolBlacklist, ContentKeywordBlacklist, and FrequencyLimit. It exists so policy logic can be expressed in a structured, reusable form rather than being hard-coded inside one product surface.
中文： intent.rs 定义了 SDK 侧的 IntentConstraint 模型，以及 ToolBlacklist、ContentKeywordBlacklist 和 FrequencyLimit 的评估逻辑。它的存在让 policy logic 能以结构化、可复用的方式表达，而不是硬编码在某一个产品表层中。
English: adapters/ is the intended location for runtime-specific integrations such as MCP. It fits the system by separating protocol-generic trust logic from transport- or agent-framework-specific glue code.
中文： adapters/ 是运行时适配层的预留位置，例如 MCP 适配器就应当放在这里。它在系统中的作用，是把协议通用的 trust logic 与特定传输层或 agent framework 的 glue code 分离开来。
English: mcp.rs is the planned MCP protocol adapter described by the architecture, but it is not yet present in the current repository snapshot. It exists in the README structure because Fides is designed around MCP-compatible agent interception, and this file is the natural long-term home for Rust-side MCP bindings.
中文： mcp.rs 是架构上预留的 MCP protocol adapter，但在当前仓库快照里还没有落地。README 仍然保留它，是因为 Fides 的核心设计本就围绕 MCP-compatible agent interception 展开，而这个文件会是 Rust 侧 MCP 绑定的自然归宿。
English: app/ contains the product-facing surfaces built around the protocol. It exists so users and developers can interact with Fides through familiar software rather than raw cryptographic tooling or on-chain calls.
中文： app/ 包含围绕协议层构建的产品界面。它存在，是为了让用户和开发者通过熟悉的软件界面来使用 Fides，而不是直接面对原始密码学工具或链上调用。
English: proxy/ is the Node.js MCP proxy layer that sits directly between an MCP client and an upstream MCP server. It exists because the cleanest place to enforce policy, emit logs, and later trigger proofs is the tool-call boundary itself.
中文： proxy/ 是 Node.js 实现的 MCP proxy 层，直接位于 MCP client 与上游 MCP server 之间。它存在，因为最适合执行 policy、产生日志并在未来触发 proofs 的位置，就是工具调用边界本身。
English: This source directory contains the proxy runtime. It keeps interception behavior isolated from package metadata and TypeScript configuration.
中文： 这个源码目录包含 proxy 的运行时实现。它把拦截行为与包配置、TypeScript 配置隔离开来，方便维护和扩展。
English: index.ts implements the MCP proxy server itself. It launches an upstream MCP server over stdio, mirrors the upstream tool list, intercepts every tools/call, checks the call against local intent rules from ~/.fides/config/intents.json, and writes structured JSONL logs under ~/.fides/logs/. It exists because this is the live enforcement point where abstract trust policy becomes real runtime protection.
中文： index.ts 实现了 MCP proxy server 本身。它通过 stdio 启动上游 MCP server，镜像上游工具列表，拦截每一次 tools/call，依据 ~/.fides/config/intents.json 中的本地意图规则进行检查，并把结构化 JSONL 日志写入 ~/.fides/logs/。它存在，因为这里就是抽象 trust policy 转化为真实运行时保护的执行点。
English: web/ contains the dashboard and its local API server. It exists so operators can inspect recent operations, blocked events, and system status in a lightweight interface rather than reading raw JSONL files.
中文： web/ 包含 dashboard 以及它的本地 API server。它存在，是为了让操作者通过轻量界面查看最近操作、被拦截事件和系统状态，而不必直接阅读原始 JSONL 文件。
English: This directory contains the React client application. It fits the system by translating logs and verification-oriented metadata into an interface that feels more like an operations console than a developer debug tool.
中文： 这个目录包含 React 客户端应用。它在系统中的作用，是把日志和验证相关元数据转换成接近运维控制台的界面，而不只是开发调试工具。
English: App.tsx renders the main dashboard UI. It periodically fetches /api/operations and /api/stats, displays a black-and-white status header, summary cards, and a newspaper-style operations table, and highlights blocked rows without visual noise. It exists to make trust state legible at a glance.
中文： App.tsx 负责渲染主 dashboard UI。它会周期性请求 /api/operations 与 /api/stats，展示黑白极简状态头部、摘要卡片和报纸风格的操作表格，并以克制方式强调被拦截行。它的存在是为了让 trust state 一眼可读。
English: server.ts is a tiny Express API that reads ~/.fides/logs/operations.jsonl, parses it, sorts it, and exposes operations plus aggregate statistics over HTTP. It exists to decouple the dashboard from direct filesystem access and to keep the UI runtime simple.
中文： server.ts 是一个很小的 Express API，用来读取 ~/.fides/logs/operations.jsonl，完成解析、排序，并通过 HTTP 暴露操作记录与聚合统计。它存在，是为了让 dashboard 不必直接访问文件系统，并保持 UI runtime 简洁。
English: docs/ stores the conceptual documentation layer for the project. It exists because trust infrastructure needs both executable code and narrative explanation if it is going to be audited, adopted, and extended by others.
中文： docs/ 保存项目的概念性文档层。它存在，因为信任基础设施若想被审计、采用与扩展，不仅需要可执行代码，也需要足够清晰的叙事说明。
English: whitepaper.md is the long-form product and protocol narrative. It exists to explain why Fides should exist, what trust problem it solves, and how the open-core architecture fits broader agent ecosystems.
中文： whitepaper.md 是面向产品与协议的长文档叙事。它存在，是为了说明为什么 Fides 应该存在、它解决了什么 trust problem，以及 open-core 架构如何嵌入更广泛的 agent 生态。
English: protocol-spec.md is the more implementation-oriented specification. It exists to make protocol data models, proving flows, and contract boundaries precise enough for builders and auditors to reason about.
中文： protocol-spec.md 是更偏实现导向的规范文档。它存在，是为了让协议数据模型、proving 流程和合约边界足够精确，便于开发者和审计者进行推理。
-
English: The user configures intents in
~/.fides/config/intents.json. These intents express concrete machine-enforceable policies such asToolBlacklistorContentKeywordBlacklist. 中文： 用户在~/.fides/config/intents.json中配置 intents。这些 intents 表达的是可被机器强制执行的具体策略，例如ToolBlacklist或ContentKeywordBlacklist。 -
English:
fides-proxysits between the agent and the real MCP server. To the agent it looks like a normal MCP server; to the upstream system it behaves like a normal MCP client. 中文：fides-proxy位于 agent 与真实 MCP server 之间。对 agent 来说，它看起来像一个普通 MCP server；对上游系统来说，它又像一个普通 MCP client。 -
English: Every tool call is intercepted, assigned an
operation_id, logged, and checked against the active intents. This is the runtime trust checkpoint where Fides turns static policy into live enforcement. 中文： 每一次工具调用都会被拦截、分配operation_id、写入日志，并与当前激活的 intents 做比对。这里就是 Fides 把静态 policy 变成实时 enforcement 的关键检查点。 -
English: If a call is blocked, the proxy returns an MCP tool error response and writes the reason into
operations.jsonl. The agent sees a normal protocol-level failure path instead of an out-of-band crash. 中文： 如果调用被阻断，proxy 会返回一个 MCP tool error response，并把阻断原因写入operations.jsonl。对 agent 而言，这表现为正常的协议失败路径，而不是系统外的崩溃。 -
English: The SDK converts tool-call metadata into hashes and witness-friendly field elements. This includes transforming tool names, content, timestamps, and identifiers into data that Circom/
snarkjscan consume. 中文： SDK 会把工具调用元数据转换成哈希值和适合 witness 的 field elements。这里包括将 tool names、content、timestamps 和 identifiers 转换成 Circom/snarkjs可消费的数据。 -
English: A proof is generated and the result can be submitted to Solana devnet through
fides_verifier. In the current architecture, proof verification is intentionally performed off-chain first, and only compact verification evidence is logged on-chain for cost efficiency. 中文： 接着会生成 proof，并可通过fides_verifier把结果提交到 Solana devnet。在当前架构里，proof verification 被有意放在链下优先完成，链上只记录紧凑的验证证据，以控制成本。 -
English: The dashboard reads local logs and displays system status, blocked operations, and verification-oriented summaries. This makes the trust layer visible to operators while keeping blockchain details largely invisible to end users. 中文： 最后，dashboard 读取本地日志并展示系统状态、被拦截操作和面向验证的摘要。这让 trust layer 对操作者可见，同时又让 blockchain 细节基本对终端用户保持隐形。
English: access_scope.circom proves that two private facts are consistent with two public authorization commitments: the actual tool hash belongs to an allowed tools Merkle tree, and the actual content hash belongs to an allowed content Merkle tree. In plain language, it proves “this action stayed inside the approved scope” without revealing the full rule set or all surrounding runtime context.
中文： access_scope.circom 证明两项私有事实与两项公开授权承诺保持一致：实际 tool hash 属于允许的工具 Merkle tree，实际 content hash 属于允许的内容 Merkle tree。用更直白的话说，它证明的是“这次行为仍在批准范围内”，而不需要暴露完整规则集或全部运行时上下文。
English: frequency_bound.circom proves that an actual operation count is within a user-configured upper bound. The important privacy property is that the verifier learns the bounded context, not the raw count itself, so usage intensity can remain private while policy compliance is still provable.
中文： frequency_bound.circom 证明实际操作次数处于用户配置的上限之内。它的重要隐私属性在于：验证者看到的是被约束的上下文，而不是原始计数本身，因此使用强度可以保持私密，同时策略合规性仍然可证明。
English: Fides currently uses Groth16 over BN128 because the toolchain is mature, circom + snarkjs work smoothly with it, proofs are compact, and verification is operationally practical. For an MVP trust layer, those trade-offs matter more than adopting a more exotic proving system too early.
中文： Fides 当前选择在 BN128 上使用 Groth16，原因是工具链成熟，circom + snarkjs 与它配合顺畅，proof 体积小，而且验证在操作上更实用。对于 MVP 阶段的 trust layer 来说，这些权衡比过早引入更复杂的 proving system 更重要。
English: The Merkle tree structure used by access_scope is depth 4 and uses Poseidon hashing inside the circuit. Depth 4 is intentionally small for development simplicity, while Poseidon is chosen because it is efficient inside arithmetic circuits compared with general-purpose hashes such as SHA-256.
中文： access_scope 使用的 Merkle tree 深度为 4，并在电路内采用 Poseidon hash。深度 4 是为了开发阶段的简洁性而有意保持较小，而选择 Poseidon 是因为它在算术电路内比 SHA-256 这类通用哈希更高效。
English: Private inputs stay on the proving device: actual tool hash, actual content hash, Merkle paths, Merkle indices, counts, and other witness material. Public inputs are the minimum verifiable commitments: allowed roots, operation metadata, time-window context, and public output flags like verified or within_bound. On-chain, Fides only needs compact hashes and verification summaries, not raw behavioral payloads.
中文： 私有输入保留在生成 proof 的设备上：实际 tool hash、实际 content hash、Merkle paths、Merkle indices、计数值以及其他 witness 材料都属于这一类。公开输入则是最小化的可验证承诺，例如 allowed roots、operation metadata、time-window context，以及像 verified 或 within_bound 这样的公开输出标记。在链上，Fides 只需要紧凑哈希和验证摘要，而不需要原始行为载荷。
English: Devnet program ID: DKcmggxS55cdVT74gNuv2oVrNnAxW3iyDV1noaccQGF5. This program stores canonical user intent records in a UserIntent PDA keyed by owner + intent_id. The account stores owner, intent_id, constraint_hash, constraint_type, is_active, timestamps, and a PDA bump so the chain can represent what the user meant to allow.
中文： Devnet program ID：DKcmggxS55cdVT74gNuv2oVrNnAxW3iyDV1noaccQGF5。这个 program 把规范化的用户 intent 记录存进由 owner + intent_id 派生的 UserIntent PDA。该账户保存 owner、intent_id、constraint_hash、constraint_type、is_active、时间戳和 bump，使链上能表达“用户原本允许了什么”。
English: It currently exposes three instructions: register_intent, update_intent, and deactivate_intent. The design is intentionally minimal: the chain stores hashed constraint metadata, while richer human-readable policy content can remain off-chain and still be tied back through hashes.
中文： 它当前暴露三条 instructions：register_intent、update_intent 和 deactivate_intent。这个设计刻意保持简洁：链上保存的是哈希化约束元数据，而更丰富的人类可读 policy 内容可以留在链下，再通过哈希回连。
English: Devnet program ID: DRBUAuhbynAjt1e7aFEANtTBWHTP3see8Gzu3WBUDoVk. This program stores VerificationLog PDAs that capture the result of an off-chain proof verification. Each log includes owner, operation_id, intent_id, verified, proof_hash, public_signals_hash, circuit_type, timestamp, and bump.
中文： Devnet program ID：DRBUAuhbynAjt1e7aFEANtTBWHTP3see8Gzu3WBUDoVk。这个 program 存储 VerificationLog PDA，用于记录链下 proof verification 的结果。每条日志包含 owner、operation_id、intent_id、verified、proof_hash、public_signals_hash、circuit_type、时间戳和 bump。
English: Fides deliberately chooses off-chain verify + on-chain log because full on-chain proof verification is more expensive than the product needs today. The chain’s role here is to make the result tamper-evident and portable, while heavy cryptographic work remains off-chain.
中文： Fides 有意采用 off-chain verify + on-chain log 的方式，因为完整链上 proof verification 的成本高于当前产品真正需要承担的成本。这里链的角色是让结果不可篡改且可移植，而重型密码学计算仍留在链下完成。
English: Devnet program ID: DndWiSHXwnznUW4oTYf1vAvHkpTkzcTccJSc4RjPPsYz. This program stores BehaviorLog PDAs for summarized behavior windows rather than raw traces. Each log contains owner, agent_id, summary_hash, operation_count, violation_count, window_start, window_end, timestamp, and bump.
中文： Devnet program ID：DndWiSHXwnznUW4oTYf1vAvHkpTkzcTccJSc4RjPPsYz。这个 program 存储的是 BehaviorLog PDA，用于记录按时间窗口聚合的行为摘要，而不是原始行为轨迹。每条日志包含 owner、agent_id、summary_hash、operation_count、violation_count、window_start、window_end、时间戳和 bump。
English: The time-window design exists because trust analysis often cares more about bounded periods than isolated events: a minute, an hour, a day, or a policy epoch. This structure makes frequency proofs and summary-level auditing much easier than storing every single low-level action on-chain.
中文： 时间窗口设计存在的理由是：trust analysis 往往更关心有界时间段，而不是孤立事件本身，例如一分钟、一小时、一天或某个 policy epoch。这样的结构使 frequency proofs 与摘要级审计都比把每一条低层动作逐条上链更容易实现。
cd app/proxy
npm install
npx tsx src/index.ts -- npx @modelcontextprotocol/server-filesystem /private/tmpEnglish: This launches the interception layer and wraps a real MCP filesystem server. From this point on, every tool call can be observed, checked, blocked, and logged by Fides.
中文： 这会启动拦截层，并包裹一个真实的 MCP filesystem server。从这一刻开始，每一次工具调用都可以被 Fides 观察、检查、阻断并记录。
cd app/web
npm install
npm run dev
# Open http://localhost:5173English: This starts the Vite frontend and the Express API together. The dashboard reads local log state and presents a human-friendly view of operations and violations.
中文： 这会同时启动 Vite 前端与 Express API。dashboard 会读取本地日志状态，并以对人更友好的方式展示操作记录与违规情况。
cd protocol/circuits
npm install
circom access_scope/access_scope.circom --r1cs --wasm --sym -l node_modules -o access_scope/build
snarkjs groth16 setup ...English: The first command compiles the circuit into proving artifacts. The second command begins the Groth16 setup flow, which eventually produces .zkey and verification material.
中文： 第一条命令把电路编译成 proving artifacts。第二条命令开始 Groth16 setup 流程，最终会产出 .zkey 与 verification material。
Edit ~/.fides/config/intents.json:
{
"intents": [
{
"intent_id": "my-001",
"constraint_type": "ToolBlacklist",
"blacklisted_tools": ["write_file"],
"is_active": true
}
]
}English: This example blocks write_file regardless of upstream tool implementation. In practice, richer policies can combine tool scopes, keyword matching, and later historical frequency checks.
中文： 这个例子会阻止 write_file，无论上游工具如何实现都一样。实际使用中，更丰富的策略还可以叠加 tool scopes、keyword matching，以及未来的历史频率检查。
-
English: ZKP proof auto-generation on every tool call.
中文： 在每一次工具调用上自动生成 ZKP proof。 -
English: Solana compressed accounts for cheap on-chain logging.
中文： 使用 Solana compressed accounts 降低链上日志成本。 -
English: Mobile app.
中文： 移动端应用。 -
English: Multi-agent support.
中文： 多 agent 支持。 -
English: Community trust registry (open protocol).
中文： 社区化 trust registry（开放协议）。
English: Fides follows an open-core model. The protocol layer — circuits, SDK, and Solana contracts — is the part that matters most for trust, because it defines what can be enforced, what can be proved, and what can be audited by the community.
中文： Fides 采用 open-core 模式。协议层——circuits、SDK 与 Solana contracts——是最需要开源的部分，因为它定义了什么可以被强制执行、什么可以被证明，以及社区究竟能够审计什么。
English: The experience layer — dashboard UI and proxy product surface — is closed source for now. The reason is not that UX is unimportant; it is that trust fundamentally depends on auditability of the protocol, not on whether every product shell is public. Fides wants to keep the verifiable core open while still iterating quickly on the user-facing product.
中文： 体验层——dashboard UI 与 proxy 产品表层——目前暂时闭源。原因并不是 UX 不重要，而是 trust 的根本前提在于协议是否可审计，而不在于每一层产品外壳都必须公开。Fides 希望保持可验证核心开放，同时继续快速迭代面向用户的产品部分。
English: MIT for the protocol layer.
中文： 协议层采用 MIT 许可证。