Three main takeaways
- Telos Privacy gives EVM developers infrastructure for shielded payments without requiring every developer to build a ZK system from scratch.
- Smart contracts can send assets directly into shielded accounts, creating practical private payment, payroll and DeFi flows.
- The bigger opportunity isn’t simply private transfers. It’s applications that can verify activity without exposing unnecessary user or business data.
Building on a public blockchain comes with an awkward default:
Your application can be decentralised, verifiable and programmable, but almost everything it does may also be visible.
For some applications that’s fine.
For payments, payroll, treasury management, business activity and many consumer products, it creates a problem.
Telos Privacy gives EVM developers another option.
Instead of choosing between an entirely public application and building a new privacy network from scratch, developers can use a zero-knowledge privacy layer running on Telos EVM.
What does Telos Privacy give developers?
At its core, Telos Privacy provides a shielded pool.
Think of this as the private part of the system.
Users deposit assets into the pool. Inside it, balances and transfers are represented using encrypted data rather than ordinary publicly readable wallet balances.
Zero-knowledge proofs then allow Telos EVM smart contracts to verify that each state change is legitimate without exposing the underlying private information.
Developers don’t have to ask users to trust a private database somewhere.
The verification still happens on-chain.
That difference is important.
The architecture in plain English
There are a few moving parts.
zkWallet or your application creates the user’s transaction.
The shielded pool stores the private state.
Zero-knowledge verifier contracts check that transactions follow the rules.
The relayer submits transactions to Telos EVM for the user.
The user’s wallet generates the ZK proof locally. The relayer receives the transaction, helps manage the pool state and submits it to the pool contract. Telos EVM then verifies the proof before accepting the state change.
Critically, the relayer cannot simply decrypt the private transaction or take the user’s funds. Invalid changes fail the zero-knowledge verification process.
For developers, much of that complexity can sit underneath the application experience.
Developers can integrate through an SDK
Telos documents zkbob-client-js as the client SDK for interacting with the privacy pools.
It can be used for custom wallets, DeFi integrations and applications that need to deposit, transfer or withdraw shielded assets.
There are read-only and full account modes, meaning an application can query pool information without a user’s credentials or attach a spending key when private transaction functionality is required.
That matters because privacy infrastructure is notoriously complicated.
Most product teams shouldn’t have to become cryptographers before they can give users a private payment option.
Direct deposits make more interesting applications possible
One of the most useful parts of the Telos architecture is its DirectDepositQueue.
Normally a user could deposit into the privacy pool themselves.
Direct deposits allow another smart contract to send supported assets directly into a user’s shielded account.
That creates some obvious product possibilities.
Private payroll
A payroll application could send payment directly to an employee’s shielded address instead of putting their ongoing account activity into public view.
Private DeFi withdrawals
A DeFi protocol could let a user route funds into the privacy pool rather than sending everything back to a publicly visible destination wallet.
Private contributor payments
DAOs, projects and online organisations could pay contributors without creating a public directory of who received what.
Consumer applications
Applications could begin designing experiences where financial information doesn’t automatically become part of a user’s permanent public profile.
Those aren’t theoretical architecture diagrams. Telos’ direct-deposit documentation specifically identifies payroll, payments, DeFi and privacy-native applications as intended use cases.
What information is actually private?
This is important when designing the UX.
Telos Privacy doesn’t make every interaction disappear.
A public deposit still exposes the depositing address and amount.
A withdrawal exposes its destination address and amount.
Inside the shielded pool, however, transfer values, recipients and internal balances are hidden, and observers cannot simply connect an individual deposit to a later withdrawal.
Developers should explain that distinction clearly instead of displaying a vague “100% private” label.
Better privacy UX tells users exactly what is private and when.
Why is this important for Web3 developers?
The early blockchain design question was usually:
What can we put on-chain?
Privacy changes the question to:
What actually needs to be public?
Those are very different product decisions.
A game may need to prove a player owns an item without exposing every asset they own.
A business application may need to prove a payment occurred without making an entire supplier relationship public.
A financial application may need verifiable settlement without exposing a user’s complete financial history.
A treasury may need blockchain settlement without broadcasting every operational decision.
Once privacy becomes part of the application layer, public verification no longer has to mean indiscriminate public disclosure.
Telos Privacy isn’t just a wallet feature
It’s easy to look at zkWallet and assume Telos Privacy is simply a private payment wallet.
The more interesting developer proposition is the infrastructure underneath it.
Telos has a shielded pool, verifier contracts, relayer infrastructure, direct-deposit functionality and an SDK that developers can build around today.
Telos has also described a broader direction toward confidential EVM application flows where applications can prove outcomes without exposing every balance, counterparty or user action publicly.
That creates a much larger opportunity than hiding individual transfers.
It means building blockchain applications around a new assumption:
Public verification does not require public everything.
And for developers trying to build Web3 products that feel more like products people already use every day, that could be one of the most important changes privacy technology brings.
Telos Privacy developer FAQ
Can developers add private payments to Telos EVM apps?
Yes. Telos provides privacy contracts, direct-deposit infrastructure and a client SDK for applications that need to interact with its shielded pools.
What SDK does Telos Privacy use?
The Telos documentation identifies zkbob-client-js as the official client SDK for interacting with Telos Privacy pools.
Does a developer need to build their own zero-knowledge system?
Not for standard interactions with Telos Privacy. Developers can integrate with the existing pool contracts, relayer infrastructure and client SDK rather than implementing the underlying privacy protocol themselves.
What can developers build using Telos Privacy?
Current infrastructure supports use cases including shielded payments, private payroll flows, privacy-aware DeFi integrations, direct deposits and custom wallets. Telos is also positioning the privacy layer as infrastructure for broader confidential EVM application flows.
Is Telos Privacy non-custodial?
Yes. Transactions are controlled by the user’s spending key. Telos states that neither its Foundation nor the relayer can access, freeze or independently move shielded funds.