A few days ago, over dinner with a friend, he casually asked me, “How much do you still have in your bank account?” Without thinking, I immediately changed the subject.
It’s interesting—in real life, asking someone about their balance is considered intrusive. But on-chain, once you share a wallet address, your balance, transaction history, and DeFi positions are all laid bare for anyone to see. We constantly preach about transparency, yet few of us have seriously considered: To what extent should our wallets be transparent?
I’ve been pondering this question for days until I came across a tweet from @primus_labs that finally clicked. They used the analogy of an autumn tree—leaves gradually fall away, but the roots remain firmly buried underground. It struck me as perfectly apt. On-chain privacy works the same way: you need to decide which parts should fall like leaves for others to see, and which should stay buried like roots. Building on this metaphor, I connected several recent observations and distilled them into four layers.
First layer: What problem does “selective privacy” actually solve?
As institutional capital and corporate finances increasingly move on-chain, we can’t possibly expose every single transaction. A company seeking on-chain financing needs to prove to investors that it has sufficient assets or meets certain financial criteria. What investors truly care about is simply: “Has it met the threshold?” The exact amount in reserves or the origin of every income stream doesn’t need to be disclosed. Primus uses zkTLS to verify the origin and authenticity of off-chain data, and FHE to enable sensitive data to participate directly in computations while still encrypted. This way, financial applications can protect confidential information from casual窥探 while still delivering verifiable results—without compromising either side.
Second layer: How does this capability extend outward?
Recently, their collaboration with @CournotProtocol pushed this idea further in another direction. Prediction markets need to settle based on specific public data; Cournot can analyze and interpret evidence that has been verified for provenance. Primus ensures the data came from a legitimate source and hasn’t been tampered with; Cournot then interprets what that data implies. Trusted provenance doesn’t guarantee correct interpretation—but it eliminates countless unnecessary disputes arising from ambiguous or unverified evidence.
Third layer: The two most pressing fears in institutional use cases
When institutions move real money on-chain, they fear two things above all: their positions being fully exposed to the market, or their reserves and data lacking verifiable origins. Public blockchains assume full transparency—reveal your market-making, hedging, or treasury strategies, and you risk being front-run or targeted. Yet complete secrecy undermines auditing, compliance, and counterparty trust.
Primus’s approach separates these concerns and layers them atop existing chains. zkTLS proves that “data originated from a legitimate HTTPS source and hasn’t been altered,” without exposing original account details, private keys, or full statements. FHE allows balances, transfers, and yield calculations to be computed entirely in encrypted form—what appears on-chain is ciphertext; only authorized parties can decrypt it.
The result? Activities remain private, yet critical claims—such as sufficient reserves or strategy-compliant trade execution—can still be cryptographically verified by third parties. This isn’t theoretical; they’re already running real-time Proof-of-Reserve for stablecoins and RWA projects in production, while rolling out Confidential Vault on BNB Chain, allowing users to convert stablecoins into encrypted versions for transfers or yield generation—all without exposing personal positions. Institutions don’t want “all public or all private”—they want configurable privacy paired with verifiable integrity. Primus positions itself not as a new chain, but as an add-on layer integrated into existing financial infrastructure.
Fourth layer: How do you check your own balance after encryption?
Just because your balance is encrypted doesn’t mean you’re left guessing. If you receive a confidential transfer, you still need to know your updated balance. External confidentiality and personal access must both be possible simultaneously.
In Primus’s confidential transfer system, the on-chain record is an encrypted handle representing your balance. During transfers, computation nodes perform addition/subtraction directly on ciphertexts and write back new encrypted results—no need to decrypt amounts to update balances. When users want to check their balance, they request decryption authorization—typically via a wallet signature to verify identity. An access control layer determines who can request decryption of which data: by default, only the asset owner can decrypt their own balance; onlookers see only ciphertext handles. This distinction matters profoundly. A company needs to reconcile its internal fund movements—but doesn’t necessarily want outsiders seeing the scale of every adjustment. Whether confidential finance can truly function depends on these precise mechanics: protecting amounts while still allowing authorized parties to audit them smoothly.
One final note: The visibility of information varies across stages—entering a privacy system, transacting within it, and exiting back into standard ERC-20 tokens—all require distinct understanding. Actual product implementations must be checked against their supported workflows. I plan to first fully grasp how balance visibility and decryption permissions work before deciding how to use them.
To learn more about the product, consider exploring the current XP task alongside this.
#Primus @primus_labs @KaitoAI
