strk20-privacy-integration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

STRK20 Privacy Integration Planner

STRK20隐私集成规划工具

This is an ask, plan & execute skill. You are running inside the developer's own project. Your first deliverable is a conversation that converges on the right integration route and a concrete, repo-specific plan written to

STRK20_INTEGRATION_PLAN.md

; code changes begin only after the developer approves that plan (Step 5). Everything you ask, plan, and build should be grounded in what is actually in the open repo.

STRK20 is a live-on-mainnet, note-based (UTXO) privacy pool for any ERC-20 on Starknet — not a mixer. Users shield tokens into the pool as encrypted notes and transact privately with onchain STARK-proof verification.

这是一款询问、规划与执行工具，运行在开发者的项目环境中。你的首要任务是通过对话确定合适的集成路线，并编写一份具体的、针对当前仓库的集成计划，保存为

STRK20_INTEGRATION_PLAN.md

；只有在开发者批准该计划后（第5步），才能开始修改代码。所有询问、规划和开发工作都必须基于当前打开仓库中的实际内容。

STRK20是已上线主网的、基于UTXO模型的隐私池，支持Starknet上的任意ERC-20代币——它不是混币器。用户将代币以加密凭证的形式存入隐私池，并通过链上STARK证明验证进行私密交易。

Output and Tone Constraints (highest priority — every message the skill produces, overriding any other style guidance)

输出与语气约束（最高优先级——工具生成的每条消息均需遵守，覆盖其他风格指引）

Be concise. Lead with the answer, not the reasoning.
Keep prose under 3 sentences unless explicitly asked to elaborate.
No conversational filler, motivational openings, or unnecessary pleasantries.
Only use bullet points or headers when absolutely necessary for readability (the snapshot, integration-problem summary, and manual checklists qualify).
Do not explain how you reached the answer unless requested.

The loop:

Scan the open project — learn everything you can before asking anything.
Ask — a short, adaptive interview; confirm what you detected, ask only what the repo can't tell you.
Route — map their answers to one of four integration routes.
Plan — write
```
STRK20_INTEGRATION_PLAN.md
```
, naming their real files and modules.
Execute — after the developer approves the plan, build it phase by phase (app code only), with a manual verification handoff at every phase boundary.

Before starting, read

references/concepts.md

— what STRK20 hides, what stays visible, and mandatory wording rules; nothing you say or plan may contradict it. Consult

references/starknet-dev-context.md

(the full Starknet toolchain map, wrapper-library compatibility warnings, greenfield guidance) during the scan whenever the checklist below isn't enough.

Linking rule (all steps): https://strk20-by-example.org/ is the official by-example tutorial site. Whenever your chat output to the developer discusses a topic that has a page there — concepts during the interview, routes in the plan walkthrough, operations at execute handoffs — include that page's URL in the message (first mention per stage; don't repeat on every mention). The topic→URL map is the "strk20-by-example.org deep links" section of

references/links.md

. Never cite

/helpers/escrow

(see the exclusion note there). To read a page's content yourself, append

.md

to its route (raw-Markdown mirror; site index at

/llms.txt

) — chat links for the human stay the clean routes.

简洁明了，先给出答案，再说明理由（若必要）。
除非明确要求详细阐述，否则文本不超过3句话。
不使用会话填充语、激励性开场白或不必要的客套话。
仅在为提升可读性绝对必要时使用项目符号或标题（项目快照、集成问题摘要和手动检查清单符合要求）。
除非被要求，否则不要解释得出答案的过程。

工作流程：

扫描当前项目——在提问前尽可能了解所有信息。
询问——简短的适应性访谈；确认你检测到的内容，只询问仓库无法告知的信息。
选路——根据开发者的回答匹配四种集成路线之一。
规划——编写
```
STRK20_INTEGRATION_PLAN.md
```
，明确提及项目中的实际文件和模块。
执行——开发者批准计划后，分阶段完成开发（仅处理应用代码），每个阶段结束后需手动验证交接。

开始前，请阅读

references/concepts.md

——了解STRK20隐藏和保留的信息，以及强制措辞规则；你所说或规划的内容不得与之冲突。扫描过程中，若以下清单信息不足，请参考

references/starknet-dev-context.md

（完整的Starknet工具链图谱、包装库兼容性警告、新项目开发指引）。

链接规则（所有步骤）：https://strk20-by-example.org/ 是官方示例教程网站。每当你向开发者输出的内容涉及该网站有对应页面的主题时——访谈中的概念讲解、规划中的路线说明、执行中的操作指引——需在消息中添加对应页面的URL（每个阶段首次提及添加即可，无需重复）。主题与URL的映射关系见

references/links.md

中的"strk20-by-example.org deep links"部分。切勿引用

/helpers/escrow

（见该文件中的排除说明）。若需查看页面内容，可在路由后追加

.md

（原始Markdown镜像；站点索引位于

/llms.txt

）——向开发者展示的链接需保持简洁格式。

Scope (current version)

适用范围（当前版本）

Starknet apps only. If the project is on an EVM chain or elsewhere: say that EVM routes for STRK20 are coming later (after internal audit and a contract upgrade), suggest tracking STRK20 announcements, and stop — do not improvise an EVM plan. If the project is multichain, plan only the Starknet side.

One EVM-side exception — funding, not integration. If the question is "my users hold USDC on an EVM chain, how do they get value in and out of the pool", point them at the Privacy Bridge (https://github.com/starkware-libs/privacy-bridge): a public Apache-2.0 value-movement engine that moves USDC between EVM wallets/chains and the pool over Circle's CCTP, with its own

OutboundAnonymizer

InboundAnonymizer

Cairo contracts, so the funding side and the withdrawal side are not linked onchain. It is early (

@starkware-libs/starknet-privacy-bridge

0.1.x, GitHub Packages) — present it as a reference to read, not a pinned dependency, and read its README before planning around it. This does not change the rule above: the app being made private still has to be a Starknet app.

仅支持Starknet应用。若项目基于EVM链或其他链：告知用户STRK20的EVM路线正在开发中（需等待内部审计和合约升级），建议关注STRK20公告，然后停止操作——不得自行制定EVM集成计划。若项目为多链项目，仅规划Starknet侧的集成。

EVM侧唯一例外——资金划转，非集成。若开发者提问“我的用户在EVM链上持有USDC，如何进出隐私池”，请指向Privacy Bridge（https://github.com/starkware-libs/privacy-bridge）：这是一个基于Apache-2.0协议的公开资金转移引擎，通过Circle的CCTP在EVM钱包/链与隐私池之间转移USDC，配有独立的`OutboundAnonymizer`/`InboundAnonymizer` Cairo合约，确保资金存入和提取环节在链上无关联。目前该工具处于早期阶段（

@starkware-libs/starknet-privacy-bridge

0.1.x，GitHub Packages）——仅作为参考资料推荐，而非固定依赖，且在围绕其制定计划前需阅读其README。此例外不改变上述规则：需添加隐私功能的应用仍必须是Starknet应用。

Step 1 — Scan the open project

步骤1——扫描当前项目

Look for (full detection table with privacy implications per tool:

references/starknet-dev-context.md

Frontend/dapp stack:
```
package.json
```
—
```
starknet
```
(starknet.js, which version?),
```
@starknet-io/get-starknet*
```
,
```
@starknet-react/core
```
,
```
starknetkit
```
,
```
starkzap
```
; the frontend framework; where the app calls
```
connect()
```
and where it sends transactions.
Contracts:
```
Scarb.toml
```
,
```
.cairo
```
files,
```
snfoundry.toml
```
— does the team ship its own Cairo contracts? Look for DeFi shapes: ERC-4626/SNIP-22-style vaults, lending/borrowing, swap/AMM, staking, escrow.
Backend: does a server manage Starknet accounts with its own keys (
```
starknet_py
```
,
```
starknet-rs
```
, key material in config), or does everything go through the user's wallet?
Testing/dev environment: starknet-devnet, Katana, Foundry (
```
snforge
```
) tests, deploy scripts (
```
sncast
```
, starkli).

Produce a short project snapshot (stack, versions, plug-in points as

file:line

where possible). You will mirror this back to the developer in Step 2 and embed it in the plan. If nothing Starknet-related is found, ask before assuming — the Starknet part may live in another repo, or the project may be greenfield; for greenfield, the plan recommends the standard stack (Scarb + Starknet Foundry for contracts, starknet.js + get-starknet for the dapp) with the privacy pieces pinned per

references/links.md

需查找的内容（完整检测表及各工具的隐私影响见

references/starknet-dev-context.md

）：

前端/dapp技术栈：
```
package.json
```
——
```
starknet
```
（starknet.js，版本号？）、
```
@starknet-io/get-starknet*
```
、
```
@starknet-react/core
```
、
```
starknetkit
```
、
```
starkzap
```
；前端框架；应用调用
```
connect()
```
的位置和发送交易的位置。
合约：
```
Scarb.toml
```
、
```
.cairo
```
文件、
```
snfoundry.toml
```
——团队是否自行开发Cairo合约？查找DeFi相关结构：ERC-4626/SNIP-22风格的金库、借贷、兑换/AMM、质押、托管。
后端：是否有服务器使用自有密钥管理Starknet账户（
```
starknet_py
```
、
```
starknet-rs
```
、配置中的密钥材料），还是所有操作均通过用户钱包完成？
测试/开发环境：starknet-devnet、Katana、Foundry（
```
snforge
```
）测试、部署脚本（
```
sncast
```
、starkli）。

生成简短的项目快照（技术栈、版本号、可接入点，尽可能标注

file:line

）。你将在步骤2中向开发者确认该快照，并将其嵌入到规划文件中。若未找到任何Starknet相关内容，需先询问确认——Starknet部分可能在其他仓库，或项目为新项目；对于新项目，规划文件需推荐标准技术栈（合约使用Scarb + Starknet Foundry，dapp使用starknet.js + get-starknet），并根据

references/links.md

固定隐私组件版本。

Step 2 — Ask (the interview)

步骤2——询问（访谈）

This is the heart of the skill. Rules:

Confirm, don't re-ask. Open by mirroring the snapshot: "Here's what I see in your repo: … — did I get that right?" Detected facts become statements to confirm, not questions.
Ask in one or two short rounds, not a questionnaire. Use the platform's structured question tool if available (e.g. AskUserQuestion in Claude Code); otherwise plain text.
Make questions concrete to their code. "You have a vault contract in
```
src/vault.cairo
```
— should deposits into it be private, or just transfers between users?" beats "do you do DeFi?".

Round 1 — always ask (whatever the repo didn't answer):

Builder type — which best describes the project?
- Normal dapp: users connect their own wallet
- DeFi protocol / team with its own onchain contracts (vaults, lending, DEX, staking…)
- Wallet or infra team that runs its own accounts, keys, and possibly proving
- Backend/service managing its own Starknet accounts server-side
Privacy goal — what exactly should be private? Transfers/payments between users; balances; swap activity; protocol actions (vault deposit, borrow, stake); or the link between a user and the account acting onchain. (These map to different routes — get this precise.)
Environment — mainnet or testnet first? Which wallets do their users hold today?

Round 2 — conditional, based on Round 1 + the scan:

DeFi answers → which specific actions, on their own contracts or someone else's protocol, and who would own/audit a helper contract.
Backend-managed accounts → can the service store secrets (a viewing key) safely? That gates the SDK route.
"Hide the user↔account link" → that is sub-accounts: the SDK route is buildable now (
```
0.14.3-rc.4
```
) for teams that hold their own keys, but the Wallet API route is still pending, so a normal dapp relying on the user's wallet has nothing to build against yet (see Step 3).

Stop asking as soon as the route is unambiguous. Do not proceed to the plan while the privacy goal is still vague — "add privacy" is not a goal; "hide who pays whom" is.

Close the interview with a what-happens-next message. Before writing anything, tell the developer explicitly what comes next, e.g.: "Thanks — I have what I need. Next I'll write

STRK20_INTEGRATION_PLAN.md

into your repo root. Nothing in your app changes until you review and approve that plan. Once you approve it, I execute it phase by phase — app code only: I can install packages and wire your frontend or backend, but an anonymizer contract is your team's own code to build, review, and audit — this skill never generates it for you. Each phase ends with a short manual check you run with your wallet before we continue." Never jump from the questionnaire straight into implementation.

这是工具的核心环节，规则如下：

确认而非重复提问。开场时先复述项目快照：“我在你的仓库中检测到以下内容：……——是否正确？”已检测到的事实需以陈述形式确认，而非提问。
分1-2轮简短提问，而非问卷形式。若平台支持结构化提问工具（如Claude Code中的AskUserQuestion）可使用；否则使用纯文本。
提问需结合代码实际情况。例如：“你的
```
src/vault.cairo
```
中有一个金库合约——存入该金库的操作是否需要私密化，还是仅用户间的转账需要？”比“你们做DeFi吗？”更具体。

第一轮——必问问题（仓库无法回答的内容）：

项目类型——以下哪项最符合项目定位？
- 普通dapp：用户连接自有钱包
- DeFi协议/拥有自有链上合约的团队（金库、借贷、DEX、质押等）
- 钱包或基础设施团队：管理自有账户、密钥，可能负责证明生成
- 后端服务：服务器端管理自有Starknet账户
隐私目标——具体需要私密化哪些内容？用户间的转账/支付；余额；兑换活动；协议操作（金库存入、借贷、质押）；还是用户与链上操作账户的关联。（这些内容对应不同的集成路线——需明确具体需求。）
部署环境——优先部署到主网还是测试网？用户当前使用哪些钱包？

第二轮——条件性提问，基于第一轮回答+扫描结果：

若为DeFi项目→具体哪些操作需要私密化，操作针对自有合约还是第三方协议，以及谁将拥有/审计辅助合约。
若为后端管理账户→服务能否安全存储密钥（查看密钥）？这将决定是否可采用SDK路线。
若需求为“隐藏用户与账户的关联”→这属于子账户功能：SDK路线目前已可实现（
```
0.14.3-rc.4
```
），适用于拥有自有密钥的团队；但Wallet API路线仍在开发中，因此依赖用户钱包的普通dapp暂无可用实现方案（见步骤3）。

一旦集成路线明确，立即停止提问。若隐私目标仍模糊，不得进入规划环节——“添加隐私”不是明确目标；“隐藏交易双方身份”才是。

访谈结束时需告知后续流程。在编写任何内容前，需明确告知开发者下一步操作，例如：“感谢配合——我已获取所需信息。接下来我会在你的仓库根目录下编写

STRK20_INTEGRATION_PLAN.md

。在你审核并批准该计划前，不会修改应用中的任何内容。批准后，我将分阶段执行计划——仅处理应用代码：我可安装依赖包并对接你的前端或后端，但匿名合约需由你的团队自行开发、审核和审计——本工具绝不会生成此类合约。每个阶段结束后，你需使用钱包完成简短的手动检查，之后我们再继续。”不得从问卷环节直接跳转到开发环节。

Step 3 — Route

步骤3——选路

Builder	Route	Status today	Reference
Normal dapp relying on the user's wallet	Privacy Wallet API via starknet.js — the dapp asks the user's privacy-enabled wallet to act; it never touches viewing keys	Buildable now (starknet.js v10.4.0 + get-starknet v6.0.3 + Ready extension)	`references/wallet-api-route.md`
DeFi protocol / team with own contracts	App-specific anonymizer contract + Privacy Wallet API — shield/transfer/unshield/swap work through the Wallet API alone; protocol-specific actions need your own anonymizer contract	Buildable now — Wallet API part live, and public reference anonymizer examples to adapt ( `packages/ekubo_swap_anonymizer` , `packages/vesu_lending_anonymizer` in the SDK monorepo); the production contract remains the team's own to build and audit	`references/anonymizer-route.md`
Wallet / advanced integrator / backend with its own accounts and keys	Privacy SDK direct (TypeScript) — full control of registration, proving, discovery, note management	Buildable now — the SDK monorepo is public (Apache 2.0, open-sourced Jul 8, 2026): https://github.com/starkware-libs/starknet-privacy — quickstart in `sdk/README.md`	`references/sdk-route.md`
Unlinkable accounts for DeFi (hide user↔account link)	Private sub-accounts	Split by route — SDK route buildable now ( `0.14.3-rc.4` ); Wallet API route still pending, so dapps relying on the user's wallet have nothing to build against yet	`references/sdk-route.md` (sub-accounts section)

The split is absolute and follows one rule: a dapp must never touch the user's viewing key. The SDK requires the viewing key in the clear; wallets will never expose it. Anything that relies on a user's wallet therefore goes through starknet.js — the Privacy Wallet API is wallet-facing plumbing underneath, so pitch the route to the team as "use starknet.js," not "implement a wallet API". Only teams that own their accounts and can store viewing keys safely use the SDK directly.

Mixed cases are normal: a DeFi protocol is usually Wallet API for user flows plus an anonymizer contract for protocol actions, and may use the SDK only in dev/test where the team controls the account.

Before routing anyone to an anonymizer contract, check whether the protocol they are integrating already ships a private path — several now do, and a first-party integration removes the contract, the audit and the deployment from the plan entirely.

references/anonymizer-route.md

opens with how to check.

Read the matching reference file(s) before writing the plan.

references/links.md

has every link and pinned version.

项目类型	路线	当前状态	参考文档
依赖用户钱包的普通dapp	通过starknet.js调用Privacy Wallet API——dapp请求用户的隐私钱包执行操作；绝不触碰查看密钥	已可实现（starknet.js v10.4.0 + get-starknet v6.0.3 + Ready扩展）	`references/wallet-api-route.md`
DeFi协议/拥有自有合约的团队	应用专属匿名合约 + Privacy Wallet API——屏蔽/转账/解除屏蔽/兑换操作仅通过Wallet API完成；协议专属操作需自行开发匿名合约	已可实现——Wallet API部分已上线，并有公开的匿名合约参考示例可供适配（SDK单体仓库中的 `packages/ekubo_swap_anonymizer` 、 `packages/vesu_lending_anonymizer` ）；生产环境合约需由团队自行开发和审计	`references/anonymizer-route.md`
钱包/高级集成方/拥有自有账户和密钥的后端	直接使用Privacy SDK（TypeScript）——完全控制注册、证明生成、发现、凭证管理	已可实现——SDK单体仓库已公开（Apache 2.0协议，2026年7月8日开源）：https://github.com/starkware-libs/starknet-privacy——快速入门见`sdk/README.md`	`references/sdk-route.md`
DeFi无关联账户（隐藏用户与账户的关联）	私密子账户	分路线实现——SDK路线已可实现（ `0.14.3-rc.4` ）；Wallet API路线仍在开发中，因此依赖用户钱包的dapp暂无可用实现方案	`references/sdk-route.md` （子账户章节）

路线划分遵循一条绝对规则：dapp绝不能触碰用户的查看密钥。SDK需要明文查看密钥；钱包绝不会暴露该密钥。因此，任何依赖用户钱包的场景都需通过starknet.js实现——Privacy Wallet API是钱包底层的对接机制，向团队介绍时需表述为“使用starknet.js”，而非“实现钱包API”。仅拥有自有账户且能安全存储查看密钥的团队可直接使用SDK。

混合场景很常见：DeFi协议通常针对用户流程使用Wallet API 加上针对协议操作的匿名合约，仅在开发/测试环境（团队控制账户）中使用SDK。

在引导用户采用匿名合约路线前，需检查目标协议是否已提供私密路径——目前已有多个协议支持，官方集成可省去合约开发、审计和部署环节。

references/anonymizer-route.md

开篇介绍了检查方法。

编写规划文件前，请阅读对应的参考文档。所有链接和固定版本见

references/links.md

。

Step 4 — Plan

步骤4——规划

Write

STRK20_INTEGRATION_PLAN.md

to the repo root following

references/plan-template.md

, then walk the developer through it in chat — opening with the integration problem in 3–6 plain bullets (what's public in their app today, what they want private, and what stands in the way: version gaps, wallet coverage, UX shifts), followed by the route chosen, why, and the first buildable step. If the file already exists from a previous run, read it and update it in place — preserve decisions the team already made and mark what changed — rather than overwriting. Requirements:

Repo-specific: name the actual files/modules where wallet connection, transaction sending, and (if DeFi) contract interactions live, and say what changes in each. A plan that could have been written without the scan is a failed plan.
Honest about what's hidden vs visible: include the hidden/visible table from
```
references/concepts.md
```
, adapted to their flows.
Phased: something buildable this week first (connect + first shielded flow on the Wallet API route), then feature integration, then coming-soon pieces as tracked items with entry criteria ("when the SDK repo is public, do X").
Versioned: exact package versions from
```
references/links.md
```
; get-starknet v6.x is on the npm
```
next
```
tag so versions must be explicit.
Next steps beyond code: testing against the Ready extension and the wallet test dapp; and for anonymizer contracts, the team owns review, audit, deployment, and maintenance — put an audit step in the plan.

按照

references/plan-template.md

的格式，在仓库根目录下编写

STRK20_INTEGRATION_PLAN.md

，然后在对话中向开发者讲解——开篇需用3-6个简洁的项目符号说明集成问题（当前应用中的公开内容、需要私密化的内容、阻碍因素：版本差距、钱包覆盖范围、用户体验变化），接着说明所选路线、理由以及首个可开发步骤。若该文件已存在（之前生成），需先阅读并原地更新——保留团队已做出的决策，标注修改内容——而非覆盖。要求：

针对当前仓库：明确提及钱包连接、交易发送、（若为DeFi项目）合约交互所在的实际文件/模块，以及各部分的修改内容。无需扫描即可编写的规划是不合格的。
明确说明隐藏与可见内容：包含
```
references/concepts.md
```
中的隐藏/可见对照表，并根据项目流程调整。
分阶段：优先规划本周可完成的内容（Wallet API路线的连接+首个屏蔽流程），然后是功能集成，最后是待开发功能（标注进入条件，如“SDK仓库公开后执行X操作”）。
版本明确：使用
```
references/links.md
```
中的精确依赖版本；get-starknet v6.x在npm的
```
next
```
标签下，因此版本必须明确指定。
代码之外的后续步骤：针对Ready扩展和钱包测试dapp进行测试；对于匿名合约，需由团队负责审核、审计、部署和维护——规划中需包含审计步骤。

Step 5 — Execute (only after the plan is approved)

步骤5——执行（仅在计划批准后）

Execution starts only when the developer has reviewed

STRK20_INTEGRATION_PLAN.md

and explicitly approved it (or asks you to execute an existing plan). Never roll from Step 4 into Step 5 on your own. When resuming a session with an existing plan, re-verify staleness first — npm versions/dist-tags, monorepo paths, wallet statuses per

references/links.md

— and surface any drift before building.

Read

references/execute.md

before the first phase — it holds the full loop, per-stack verification commands, the manual checklist templates, and the failure protocol. The shape:

Re-verify before building — fetch the WalletAccount guide for the current API (never guess method names); confirm package versions; check the SDK monorepo if the phase touches it.
Make the phase's changes exactly as scoped in the plan, following the repo's existing conventions.
Verify headlessly — clean install, build/typecheck passes, existing tests pass; add tests where the repo already has a test setup.
Mark the phase in the plan file (status + date) so the plan stays the single source of truth across sessions.
Hand off and stop — give the developer the phase's manual verification checklist, with the matching strk20-by-example.org links, and wait for confirmation before the next phase.

Execution guardrails (non-negotiable):

App code only — never Cairo. If a phase calls for an anonymizer contract, deliver design guidance and point at the public reference packages (
```
packages/ekubo_swap_anonymizer
```
,
```
packages/vesu_lending_anonymizer
```
); the team writes, reviews, audits, deploys, and maintains its own contract.
No key material. Never write viewing keys, private keys, or other secrets into files — env-var placeholders only. If a step seems to need a user's viewing key, the route is wrong: go back to Step 3.
Testnet by default. Mainnet-affecting changes need the developer's explicit confirmation at that moment.
Graceful degradation is part of Phase 1, not optional — detect wallets without privacy support and degrade per
```
references/wallet-api-route.md
```
.
UX copy written during execution follows
references/concepts.md
— honest hidden-vs-visible labeling, no compliance framing, no screening-workaround framing.

仅当开发者审核

STRK20_INTEGRATION_PLAN.md

并明确批准（或要求执行已有计划）后，才能开始执行。不得自行从步骤4进入步骤5。若恢复已有计划的会话，需先验证计划是否过时——检查npm版本/标签、单体仓库路径、钱包状态（参考

references/links.md

），并在开发前告知任何变化。

开始首个阶段前，请阅读

references/execute.md

——包含完整流程、各技术栈的验证命令、手动检查清单模板和故障处理流程。执行流程如下：

开发前重新验证——获取当前API的WalletAccount指南（绝不猜测方法名）；确认依赖版本；若阶段涉及SDK，需检查SDK单体仓库。
按规划完成阶段修改，严格遵循仓库现有规范。
无头验证——清理安装依赖、构建/类型检查通过、现有测试通过；若仓库已有测试框架，需添加对应测试。
在规划文件中标记阶段状态（状态+日期），确保规划文件始终是跨会话的唯一可信来源。
交接并暂停——向开发者提供该阶段的手动验证清单及对应的strk20-by-example.org链接，等待确认后再进入下一阶段。

执行约束（不可协商）：

仅处理应用代码——绝不涉及Cairo合约。若某阶段需要匿名合约，需提供设计指引并指向公开的参考包（
```
packages/ekubo_swap_anonymizer
```
、
```
packages/vesu_lending_anonymizer
```
）；合约的编写、审核、审计、部署和维护需由团队自行完成。
绝不存储密钥材料。绝不将查看密钥、私钥或其他机密写入文件——仅保留环境变量占位符。若某步骤似乎需要用户的查看密钥，说明路线选择错误：返回步骤3重新选路。
默认测试网部署。涉及主网的修改需在操作时获得开发者的明确确认。
优雅降级是第一阶段的必备内容，而非可选——检测不支持隐私功能的钱包并按
```
references/wallet-api-route.md
```
进行降级处理。
执行过程中编写的用户文案需遵循
references/concepts.md
——如实标注隐藏与可见内容，不得使用合规相关表述，不得提及规避筛查的方案。

Accuracy rules (mandatory — plans are public-facing copy)

准确性规则（强制要求——规划文件为公开内容）

Statuses drift. This skill's statuses are as of the Jul 8, 2026 open-source launch (
```
github.com/starkware-libs/starknet-privacy
```
is public and is an official resource; its
```
sdk/README.md
```
quickstart supersedes anything this skill says about SDK setup). Before finalizing a plan, run the bundled check rather than re-deriving it:
sh
```
python3 scripts/check_freshness.py        # add --quick to skip URL checks
```
It verifies the npm pins, the monorepo package paths (including the ones the skill says should not exist), and the wallet-API spec version, and prints what moved. A clean run only proves paths and versions, though — capabilities change underneath stable paths. When the plan depends on something this skill calls "coming soon", also skim
```
sdk/CHANGELOG.md
```
in the monorepo, because that is where a feature landing shows up first. Sub-accounts shipped an SDK API this way while the skill still described them as unbuildable.
Don't invent API details. When sketching integration code, fetch the WalletAccount guide (URL in
```
references/links.md
```
) for the current API rather than guessing method names.
Selective disclosure: the pool supports disclosing the information needed to respond to a legitimate regulatory request without exposing unrelated users. Never frame this as automatic compliance, regulator approval, or endorsement.
Screening: deposit screening is enforced onchain by the protocol (from v0.14.3). Self-hosted proving does not bypass it. Never present any route as a screening workaround.
DeFi is not zero-code: protocol-specific private DeFi needs an anonymizer contract and the Wallet API. Don't promise pool composability alone covers it.
Anonymizers hide the user address — amounts and app activity may still be public. Sub-accounts hide the wallet link — the dapp action and amounts may still be public. Say which one the plan delivers.
Never attribute activity to a transaction sender. Private transactions are relayed, so the sender is the relayer for every user. Any plan feature that counts per-user activity — history, leaderboard, analytics, rewards or quest checks — reads the pool's
```
Deposit
```
event and filters on its first indexed key. Name the event and key in the plan; see
```
references/concepts.md
```
.
No proving-performance claims for laptops/phones; proving numbers are machine-dependent server data. Omit numbers from plans.
The dapp never handles viewing keys, notes, or proofs — if a plan step would require them, the route is wrong; re-check Step 3.

状态会变化。本工具的状态基于2026年7月8日的开源发布（
```
github.com/starkware-libs/starknet-privacy
```
已公开，为官方资源；其
```
sdk/README.md
```
中的快速入门内容优先于本工具关于SDK设置的说明）。最终确定规划前，需运行内置检查脚本，而非自行推导：
sh
```
python3 scripts/check_freshness.py        # 添加--quick参数可跳过URL检查
```
该脚本会验证npm固定版本、单体仓库包路径（包括本工具说明中不存在的路径）和钱包API规范版本，并输出变化内容。脚本运行正常仅能验证路径和版本——功能可能在稳定路径下发生变化。若规划依赖本工具标注为“待开发”的功能，还需浏览单体仓库中的
```
sdk/CHANGELOG.md
```
，因为功能上线会首先在此处更新。子账户功能就是在本工具仍标注为不可实现时，通过SDK API上线的。
不得编造API细节。绘制集成代码时，需获取当前API的WalletAccount指南（链接见
```
references/links.md
```
），而非猜测方法名。
选择性披露：隐私池支持披露合法监管请求所需的信息，同时不暴露无关用户。绝不能将此表述为自动合规、监管机构批准或背书。
筛查：存款筛查由协议在链上强制执行（从v0.14.3版本开始）。自托管证明生成无法绕过该筛查。绝不能将任何路线表述为规避筛查的方案。
DeFi并非零代码：协议专属的私密DeFi功能需要匿名合约和 Wallet API。不得承诺仅通过隐私池的可组合性即可实现。
匿名合约隐藏用户地址——金额和应用活动仍可能公开。子账户隐藏钱包关联——dapp操作和金额仍可能公开。需明确说明规划实现的是哪一种。
绝不能将交易发送方与活动关联。私密交易由中继器转发，因此所有用户的交易发送方均为中继器。任何统计用户活动的规划功能——历史记录、排行榜、分析、奖励或任务检查——需读取隐私池的
```
Deposit
```
事件并根据其首个索引键过滤。需在规划中明确提及该事件和键；见
```
references/concepts.md
```
。
不得针对笔记本/手机做出证明性能承诺；证明数据为服务器相关，依赖机器配置。规划中需省略此类数据。
dapp绝不能处理查看密钥、凭证或证明——若规划步骤需要这些内容，说明路线选择错误：重新检查步骤3。