SilentSwap: Enabling Compliant, Execution-Layer Privacy for STRK20 & Institutional Treasury Flows

With the recent mainnet launch of STRK20, Starknet has established a robust standard for confidential token balances. However, for institutional adoption, specifically regarding Private Payroll, Vendor Settlement, and Treasury Rebalancing confidential balances are only the foundation. The “Execution Gap” remains, the ability to execute complex, multi address distributions without metadata leakage or the creation of traceable on chain clusters.

SilentSwap serves as the execution layer. By utilizing a TEE shielded architecture (Trusted Execution Environment) that interfaces natively with Starknet’s privacy pools, we enable “Invisible Execution” for high velocity enterprise workflows.

Strategic Synergies for the Starknet Ecosystem:

• Advanced Payroll Engine: Move beyond simple 1-to-1 private transfers. SilentSwap allows DAOs and enterprises to execute batch payouts in STRK or USDC/USDT where the total treasury size, individual salaries, and recipient identities remain cryptographically shielded from public view.

• Compliance-First “View Key” Architecture: Aligning with Starknet’s “Programmable Privacy” ethos, SilentSwap utilizes a one time facilitator model combined with an institutional grade Audit Ready View Key system. This allows for selective disclosure to regulators without compromising the privacy of the broader pool.

• MEV-Resistant Treasury Rebalancing: By wrapping execution in TEEs, we mitigate the risk of sophisticated front-running bots that monitor STRK20 pool entry/exit points, ensuring institutional trades achieve optimal execution.

We are looking to sync with the StarkWare protocol team or the Starknet Foundation to discuss technical alignment with the S-two recursive proving roadmap and how SilentSwap can serve as a primary execution partner for the STRK20 standard.

Who is the best technical lead to discuss integration standards and potential inclusion in the Starknet Institutional Privacy pilot?

Interesting approach. TEE-based privacy as an alternative to ZK has a specific tradeoff worth naming: even with TEE, regulated flows (KYC, sanctions screening, selective disclosure) still need some form of verifiable attestation that can be checked without trusting the TEE operator.

I am building Sigillo, which focuses on the audit layer: hosted STWO proving, SNIP-36 submission, and ZK compliance templates (selective disclosure, authorized view, audit logging) for STRK20 applications. The audit templates would work alongside any privacy layer, TEE or ZK, because they prove that a given disclosure rule was respected without revealing the data itself.

If there is overlap or tension worth discussing (especially around the “Audit Ready View Key” system you mention), happy to discuss on telegram

Not a pitch, evaluating whether Sigillo’s audit layer complements or competes with TEE-based approaches.

Backend: GitHub - gabrielrondon/sigillo-backend: Zero-Knowledge Proof as a Service - Stripe for ZK Proofs · GitHub
Threat model: SNIP 36 Phase 1: threat model sketch · GitHub