Every key management tool we've collectively built in web3 shares the same constraints. Multi-sig, MPC, ERC-4337, smart wallets. Actions are visible onchain. Coordination between multiple parties is required. Solutions are chain-isolated and siloed. And intent privacy is not part of the equation.
Multi-sig is the easiest to unpack. You need a quorum to do anything. You're waiting for that last signature and it's not coming through. Want to add a temporary signer? Quorum to add, quorum again to remove. All of it visible on-chain, locked to one chain, not composable with anything else. It works, but it was never built for programmable infrastructure. None of these tools were.
From research to production
Cornell Tech released a research paper, originally utilising Oasis tech, Liquefaction: Privately Liquefying Blockchain Assets (Austgen, Fábrega, Kelkar et al.), that coins a new cryptographic primitive called key encumbrance. The concept is simple. A private key is generated inside a TEE enclave and never leaves it. Not to the owner, not to delegates, not to anyone. The only way to use this key is through programmable policies that gate access to its signature. You don't access the key. You access what the key can do, under conditions you define.
This changes the equation. With encumbrance, you don't need a quorum. You don't need multiple signers. You can have one wallet with multi-policy scoped actors, meaning different parties can interact with the same vault under different conditions, without the private key ever being shared or exposed. Delegation becomes a policy rule, not a signing ceremony. Time-bound access, spending limits, asset whitelists. All enforceable by the TEE, not by human coordination.
Encumbrance in practice
Privana SDK is the infrastructure utilizing Liquefaction’s theoretical model in practice. It runs on Oasis Sapphire, the confidential computing layer where the enclave lives. But the point is that even though Oasis is its own network, you are not depositing your assets to Oasis. Think of it as a confidential container. You generate wallets for target chains, Ethereum, Solana, whatever you need, and sign transactions through programmable policies. Oasis is the security layer, not the custody layer.
Here's how it works concretely. Users deposit into a shared vault. One vault per chain, multiple assets. The vault is Privana operated infrastructure, not a personal account. What each user holds inside that vault is an allowance, their attributed balance tracked by the TEE. When a user wants to act on their assets, the intent passes through the policy engine first. The policy engine checks: does this request fall within the allowance that was signed off by the user? Does it meet the conditions the user or the integrating application defined? If yes, the encumbered key signs the transaction. If not, nothing happens. The key never moves. The signature is the only thing that comes out.
The allowance model is where encumbrance becomes practical infrastructure instead of a research concept. A user sets their allowance, say $500 worth of ETH, and within that allowance the TEE signs according to whatever policies are attached. Spending limits, token restrictions, time windows, protocol whitelists, revocable delegation. All of it programmable, all of it enforced inside the enclave. No onchain governance, no quorum, no coordination overhead.
One vault, structural privacy
Because all users deposit into the same vault, there's an additional property. Onchain obfuscation. Individual transactions going out of the vault are visible post execution, but there's no clarity on which user initiated what, or how much any single user is actually moving. The vault is shared infrastructure. Privacy becomes structural, not a relay layer you bolt on after the fact.
Privana SDK will soon be available for integrators. Any application, trading terminals, DeFi protocols, games, will be able to plug in, accept deposits into Privana operated vaults, and let their users interact with assets through programmable policies. We're also building a user-facing interface on top, a direct way for users to interact with the infrastructure without going through a partner app. More on that when it's ready.
Access is an instruction, not a compromise. That's the line we're building on.
