Introducing Privana: A Deep Dive into Underlying Technology

In the world of privacy-first decentralized finance (DeFi), the upcoming Privana, built by and on Oasis, proposes a unique solution that deserves a deep dive.

In the first part of this exploratory series, I detailed the core concepts of this private DeFi application. In this part, we will go deeper and look into the underlying technology that makes Privana tick.

Oasis Sapphire and ROFL

In the core concepts, Sapphire was mentioned several times, but why is this such an integral part of the technology that drives Privana? How does the Runtime Off-chain Logic (ROFL) framework fit in?

The scope of Privana's functionality depends on both on-chain and off-chain components running in attested Trusted Execution Environments (TEEs). As the confidential EVM runtime, Sapphire utilizes Intel SGX enclaves to ensure smart contract logic and its state are confidential by default. As a result, transactions and contract storage are encrypted, while validators and node operators, even though they are crucial to running the network, cannot access or alter them.

Running Privana's on-chain functionalities with Sapphire has advantages that underpin the application's privacy and security.

EVM Compatibility

Sapphire is EVM-compatible, so the smart contracts are written in Solidity. There is no need for prior or specialized TEE knowledge, and the confidential smart contracts can be independently audited, as the code is public.

Anyone can thus verify whether the on-chain logic functions as claimed.

Confidential State

This is a critical property of Sapphire, as the encrypted contract storage stays on-chain and in memory. It guarantees that the state is accessible only to the executing TEE. This means that user balances, policies, and trade history are and remain private.

The diagram shows how each contract is encrypted with its own key, held by an isolated Key Manager. However, as it states, node operators are still able to view the access patterns.

Cross-chain signing

The core concepts highlight Privana as a multi-chain application. The architecture of Sapphire can help us understand how an EVM blockchain manages this.

A Sapphire contract holds the private key inside the enclave and signs cross-chain transactions on Oasis itself. The key thus never leaves the enclave, and the contract logic that decides what to sign remains confidential. So, the destination chain can only see the finished transaction, a regularly signed transaction made from the application's pooled vault address. As a result, there is no way to link the transaction back to the users.

ROFL

The chain-agnostic nature of Privana's vaults and the off-chain execution of application logic come from ROFL TEEs, attested on-chain by Oasis Sapphire. The application's functionalities that run inside a ROFL container are executed in an off-chain, attested, TEE-secured setting. In the subsequent stage, Sapphire verifies whether the EVM transactions originate from that specific ROFL instance.

In short, Sapphire holds the keys and handles accounting and signing, while the Privana service, running in ROFL, handles deposit verification, swaps, yield, and broadcasting.

Privana's Architecture

While discussing the core concepts of Privana, we briefly touched on the architecture. Let's look at it now in more detail. There are five components.

Integrators build with the Privana SDK, which then calls the service via the REST API. This service sits at the center of everything: it reads and writes the Oasis Sapphire contracts, which hold the keys and sign transactions confidentially, and it verifies and settles transactions on external chains, where deposits and pooled vaults sit.

Accounting block

Accounting here is the confidential ledger. The contract stays on Sapphire and holds a mapping of deposit addresses to asset balances. This is entirely encrypted.

The Privana service maintains this system with various functions:

• processing deposits on each source chain
• ensuring balance change management works smoothly
• implementing the Know Your Transaction (KYT) routine by screening transactions
• validating balances before any trades can take place
• ensuring finality reconciliation once execution has gone through
• handling withdrawals taking place in all the supported chains

Microservices block

Microservices implement the execution logic for DeFi operations. Privana has two microservices: swaps and yield. These will be covered in detail later.

Moreover, there is room to add new ones going forward if Privana decides to diversify its services in perpetuals or lending. This is possible because the core accounting logic stays the same for all microservices as they settle against the same wallet balance, using the same signature path.

Remote attestation

TEEs being the privacy-preserving core of both Sapphire (SGX) and ROFL (TDX), understanding how remote attestations work in Privana is important. The attestation reports are signed by Intel's hardware root of trust. As a result, anyone can remotely verify that the enclave is running exactly the code it claims to run.

The beauty of this verification engine is that it is all-encompassing, providing robust, in-depth auditability that regular audits could have missed. It covers the on-chain contracts, the off-chain Privana service, as well as the microservices running in attested ROFL containers. This means it is also possible to verify the swap and yield logic being executed by the application.

Not limited to DeFi

One of the core architectural strengths of Privana is that its SDK is composable. So, while Privana acts as the face of private DeFi, the applicability goes beyond it. As a result, any dApp that involves private balances or scoped, time-bounded access can use the underlying architecture of the vaults.

Fallback & Recovery

For the end users, there is a nagging question about any services, especially web3-related ones such as DeFi, given the crypto space has yet to achieve significant mass adoption. So, what happens if the enclave goes offline permanently, or if Privana stops its application and service?

A USP of Privana's architecture is that it has built-in fallback and recovery safeguards. This is not a run-of-the-mill service-level promise; it is embedded in the system and guaranteed by Oasis Sapphire. As mentioned, Sapphire runs and executes the Accounting contract, which means it is not dependent on Privana's off-chain service. Since the contract state is on-chain, even if Privana's application and service go offline, the exit option remains open.

Let's see how this works.

On-chain withdrawal

The Accounting contract allows two withdrawal paths independent of the downtime of the off-chain service in the ROFL container.

• User balance: The user can submit a withdrawal request signed by their wallet. The contract will return a signed transaction after a short time lapse on-chain. This results in the transaction paying out the user to their own address on the source chain. Anyone can broadcast it for the user, which also minimizes the risk of the funds being lost or stolen.
• Funds in user deposit address: This method is initiated if a deposit was never swept into the vault. The user can then call the contract directly to recover it. Following a short time lapse on-chain, the contract will return a signed transaction, the same as the first method. The difference here is that, in this case, the user can specify the destination in that call and will accordingly receive the payout.

The important aspect of both these methods is that the payout address is specified before the transaction is signed. So, it is fixed permanently, and even if there is an untrusted broadcaster, the funds will only route to the designated address.

Beyond service outage

A service outage is the easier case, since Sapphire stays live and the withdrawal paths above still work. A more serious scenario, like a permanently lost enclave, is where Privana's recovery model, informed by the sentinel-wallet design, comes into play.

Liquefaction, whose role in Privana is described later, outlines operator-independent recovery so that asset owners can reclaim control of their funds without needing to trust any single party. This is reassuring: user assets are not designed to be permanently lockable.

Trust Model

We glanced over this while discussing Privana's core concepts. Let's explore more here. No system is or can ever be absolutely trustless. Privana is built using technology that minimizes trust requirements as much as possible, but some assumptions still remain.

Note from the table screenshot: Research Basis: next section Sapphire docs

Two risks cannot be eliminated for Privana, even with the best of preparedness.

• Vulnerabilities in the TEE hardware itself, whether Intel SGX or TDX. This is inherent for all TEE platforms, although Sapphire, using SGX technology, has various mitigation steps added in the form of defense-in-depth design. Sapphire's SGX TEE resilience was demonstrated by its withstanding TEE attacks by Battering RAM and Wiretap.
• Smart contract bugs in the external yield protocols that the user might choose to interact with. Privana approaches this by mitigating potential fallout through conservative platform selection, audits, and protocol vetting.

Complete Knowledge proofs

Liquefaction is one of the crucial technologies on which Privana stands, as it introduces key encumbrance. The Liquefaction framework also discusses Complete Knowledge (CK) proofs, which are cryptographic proofs that a user has unencumbered access to a private key. They could become a valuable complement to Privana, for example, by letting centralized exchanges verify that a depositor's keys are not encumbered.

Research Basis

The groundwork behind Privana's architecture and technology is laid down by cryptographic research from Cornell Tech. Recommended reading starts with the Liquefaction paper as the primary research basis. This paper introduces key encumbrance as the core primitive, demonstrating that TEE-based key encumbrance can break the Single-Entity Address-Ownership (SEAO) assumption.

Let's now look at the four cornerstones of the research that help to understand how the Liquefaction framework is implemented by Oasis in Privana.

• Key Encumbrance: Generating a private key and securely holding it inside a TEE, governed by programmable access-control policies, enabling automation without custody transfer.
• SEAO Assumption: Challenging the assumption that one blockchain address can only be controlled by a single entity.
• Asset-Time Segmentation: Implementing exclusive asset control by one sub-policy at any given time, thereby ensuring multiple policies don't end up competing amongst themselves, which could result in deadlock and double-spend.
• Overlay Smart Contracts: Applying smart-contract-like logic to chains, such as Bitcoin, Litecoin, Dogecoin, etc., that don't support native smart contracts as an extension of the encumbered keys being managed off-chain in TEEs.

For interested readers, there are several references available in addition to the Liquefaction paper, if they want to do their own research on the security model.

• Kelkar et al. on Complete Knowledge proofs ( ACM CCS, 2024 )
• Jean-Louis et al. on privacy flaws in TEE-based platforms ( ePrint 2023/378 )
• Van Schaik et al. on SGX security ( IEEE S&P, 2024 )

Integrations

The components of Privana are assembled from public, auditable infrastructure, chosen because of their popular adoption and independent operation. These are the live integrations as of now. If any services become unavailable, they can be replaced by similar services with the same interface.

This concludes the deep dive into Privana’s underlying technology. 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 technological components that are the basis of Privana’s build.

Resources & references: Privana Oasis For specific questions or feedback, connect on the Oasis Discord’s Privana channel