Privacy in blockchain and web3 is not a default setting. Because privacy must be designed in, decentralized applications (dApps), including decentralized finance (DeFi) solutions, often lack it. As a private, non-custodial DeFi interface, Privana aims to answer this need.
Built by the Oasis team, Privana runs on Sapphire’s confidential EVM runtime inside hardware-secured enclaves, better known as Trusted Execution Environments (TEEs). This setup enables the features of privacy, automation, and self-custody to coexist without trade-offs.
Before understanding in detail the core concepts behind Privana, it is useful to examine the privacy problem and how it is intended to be solved.
Finding the missing piece of the privacy puzzle
What users can do with Privana underscores this application's privacy-first commitment: swap tokens, earn yield on stablecoins, and automate trading strategies. At the same time, users have self-custody, and none of their activities are revealed on-chain. This is in contrast to any standard decentralized exchange (DEX), where trades are always public; transactions are visible to anyone, including bots, who can also intervene with sandwich attacks and front-running; and full transparency dictates that user wallet history is always accessible. Privana is designed to solve these problems.
Privana and Oasis combine to deliver the application’s multi-chain feature while maintaining the privacy setup.
Each layer has to play only its own part. Oasis takes on the responsibility for privacy and security with Sapphire's confidential smart contracts and encrypted contract storage. The external chains just enjoy the benefits, and they only see what they need to – signed transactions in final state. Privana’s contribution is the user interface: wallet connection, asset deposit, execution of swaps, rule setup for automation, and portfolio management.
It is crucial that privacy and security guarantees come from Oasis rather than from Privana because the assurances are backed by core hardware and blockchain levels instead of merely the application level.
An overview of Privana’s core functionality
Privana's core functionality can be stated in a single sentence. It operates pooled, policy-governed vaults that hold assets inside hardware enclaves and execute DeFi actions privately. Let’s see how this tracks.
Pooled vault model
When users deposit tokens in Privana, the funds are kept in a vault, a smart contract on Oasis Sapphire inside an Intel SGX enclave (more on this, rather than in individual wallets as usual. This model moves away from the system of individual wallet users holding their private keys and instead uses a single vault per chain to hold assets for multiple users. The obvious next question is how individual token holdings are then managed. The answer lies in a confidential accounting layer tracking the user balances. This layer is a set of encrypted smart contracts that privately map and maintain individual token holdings.
This design choice is deliberate and comes with several benefits.
• Privacy amplification – Every transaction originating from Privana has the same address – that of its pooled vault. Since any user’s personal wallet activity is not broadcast, no specific trade can be attributed to a specific person.
• Liquidity efficiency – The Privana vaults hold an inventory of commonly traded assets. As a result, internal liquidity can settle user trades instantly within the vault, eliminating the need for external transactions. This also augments privacy while being fast and cheap.
• Lower costs – Being a pooled model, there is no need for individual smart contracts for the users. This results in low complexity of the application, lower gas fees, and higher cost-efficiency.
The confidential accounting layer in Privana’s pooled vault model is unique to DeFi solutions but follows the same logic as traditional institutions where, for example, users keeping their gold would all be stored in a single secure vault while the ledger records will maintain individual holdings. Privana’s use of this accounting layer thus serves 4 purposes.
• When users deposit their tokens, this system verifies the deposit on the source chain and registers it to the balance in the user's name in the confidential ledger.
• When users initiate a trade or yield activity, the system does a quick balance check for fund sufficiency before processing any transactions.
• For every incoming deposit, the system runs Know Your Transaction (KYT) checks to verify that funds don’t originate from sanctioned sources. This filter is a compliance mechanism adding another layer of security to the vault without compromising its privacy mandate.
• After every successful trade execution, there is immediate balance reconciliation so that the latest state of the user's holdings remains updated in vault records.
A great advantage of Privana’s vaults is that they are chain-agnostic. The keys stay and run inside TEEs, while from the target blockchain's perspective, all logic is enforced off-chain. So, even a network like Bitcoin, without native smart contract support, can benefit from the model.
The three pillars of Privana’s core concepts
TEEs, key encumbrance, and the non-custodial model encapsulate the core concepts behind Privana’s build, so it is important to delve a little deeper into each of them.
TEEs
TEEs sit at the center of Privana's privacy and security architecture. It is hardware running code inside, like a locked room enforcing rules so that no one can view, access, or modify what’s inside. It keeps everybody out, even the operating system and the server operator. As mentioned before, for Privana, this locked room is an Intel SGX enclave on Oasis Sapphire.
The TEE protects vault keys, user balances, policy rules, and transaction history. Everything stays encrypted within the TEE, only gets decrypted during the duration of processing, and is re-encrypted when processing is complete.
There is never any exposure to external systems. So, the TEE prevents access to or reading of private keys or any attempts to bypass user policies. Moreover, no unauthorized transactions can get through or get signed. Not even an engineer with full server access can extract or alter what is inside the enclave.
Most users will be satisfied with guarantees, but anyone who is tech-savvy and wants to verify for themselves can use remote attestation to check that the code running inside the enclave is the one that was promised and whether it is really untampered.
From an applicability point of view, enterprise custody platforms often utilize TEEs for institutional users. Privana aims to provide the same security model for DeFi users.
Key encumbrance
In a standard wallet, users must manually approve every transaction by signing with their private keys, which increases the risk of exposure or compromise. With key encumbrance, users can pre-define rules and let automation take care of the rest. This is the practical application of the concept laid down in the Liquefaction research paper by Austgen et al. at Cornell Tech.
Key encumbrance thus lets the enclave execute on the user's behalf, bound or encumbered by user-defined policy that can be updated or revoked at any time at the user’s discretion.
Take this example.
// Example policy: delegate yield routing, keep direct swap control
{
asset: "USDC",
spend_limit: 1000 USDC/day, // max automated spend
destination_lock: ["aave-v3"], // only this protocol
expires: 30 days, // time-bound — auto-expires
revocable: true // you can always cancel
}
// The enclave enforces these limits in hardware.
// No one — including Privana — can execute outside these rules.
Privana takes key encumbrance utility forward by introducing the principle of asset-time segmentation. It means that at any given time, only a single entity can exclusively control any specific asset position, and this entity can either be the user themselves or the user’s delegate. As a result, two policies cannot simultaneously claim the same asset, thereby preventing conflicts and ensuring user exit as and when they want.
The benefit of key encumbrance is best understood from how it counteracts the SEAO assumption model. Single-Entity Address-Ownership, or SEAO, dictates that one address must mean one corresponding user controlling it absolutely. In contrast, key encumbrance espouses programmable access-control policies that can function with complex rules, multiple delegations, time bounds, and asset limits. Everything is enforceable inside hardware without custody transference. This is the essence of automated, private DeFi without having to give up control.
Non-custodial model
The term “custody” is used often but not always clearly understood in DeFi. Let’s compare Privana with other prevalent custody models regarding their attributes to understand the difference.
This redefines the concept of non-custodial. Before, in standard wallets, users had to either manually sign every transaction for safety or give up control to bots for automation, leading to potential security risks. Now, with Privana, automation and self-custody are simultaneous, with privacy ensured throughout the whole experience.
This does not mean that there are no trust assumptions in Privana; it only means that the trust requirements are as minimal as possible. As long as Intel SGX hardware works as designed and Sapphire’s confidential smart contracts function as built and deployed, no one from Privana or Oasis’s side can access or tamper with the vault's private key or override the user’s policy rules. It may be useful to check out the Trust Model page in Privana’s docs for details on every assumption and its mitigation.
This concludes the deep dive into Privana’s core concepts. Next time, I will discuss Privana’s features in detail. In the meantime, let’s continue the discussion in the comments section about what you think of these concepts that are the pillars of Privana’s build.
Resources & references:
• Privana
• Oasis
• For specific questions or feedback, connect on the Oasis Discord’s Privana channel
Top comments (0)