Until now, wallet infrastructure companies have offered policy engines that can’t express all the policies that users need. Some let you choose from a set menu of policies: “don’t sign transactions over 1 ETH”; “only transfer funds to allowlisted addresses”; “require three approvals before signing.” Other, more advanced engines expose a limited language (i.e., Domain Specific Language, or DSL) in which to write custom policies. DSLs are great until you learn that anything sophisticated is outside of their domain—“oh no, I can’t control approve actions for ERC20s”—and there is no community writing the libraries you need.
As more regulated entities move on-chain—and bring their (and their customers’) assets with them—these cookie-cutter policy engines will no longer cut it. Sophisticated teams need wallet policies that express their specific, complex risk-management strategies: auditable, enforceable controls that satisfy both internal compliance teams and external regulators.
We’re thrilled to announce our Programmable Policy Engine, an execution engine that runs normal programs as policies within a Trusted Execution Environment (TEE). To control what actions a key can take, developers write code in a standard programming language, with (optional) access to a network connection, a key value store, and storage and encryption for secrets. The policy executes every time the API receives a signing request with the relevant key—and the key will only sign the transaction if the policy engine says “yes”.
The Programmable Policy Engine lets developers customize policies—and because code executes in a TEE, it provides both strong isolation and cryptographic proof that the policy governing your key(s) is the code you wrote. Beyond customizability and authenticity, the Programmable Policy Engine has subtler benefits, too. It makes it possible to bring on-chain computation off-chain, which lets organizations compute privately, cheaply, and in an inherently cross-chain way.
Sophisticated risk management requires customizable policies
The Programmable Policy Engine lets organizations craft complex policy logic tailored precisely to their needs. Organizations can implement intricate custody arrangements, advanced compliance checks, and robust risk management processes entirely off-chain; developers can write complex approval rules, query oracles for trading, or integrate external data sources to inform signing decisions.
The Programmable Policy Engine makes this possible because it runs user code. Specifically, it executes WebAssembly (Wasm), and lets developers write policies in any language that compiles to Wasm. We chose Wasm, a portable bytecode format, because it offers isolation and memory safety by design. Our deep expertise in Wasm security is reflected in our leadership: our co-founder, Deian, serves on the Board of Directors for the Bytecode Alliance. Fraser (co-founder and CTO), and John Renner (founding engineer) have also worked on verifying that Wasm compilers and runtimes give the guarantees they’re supposed to, and on extensions to Wasm that make it possible for developers to write safe cryptographic code.
Proof-of-policy makes new applications possible
Policies are only good if they’re enforced correctly, every time. CubeSigner uses the type system to guarantee that keys can only sign transactions once the policies associated with those keys approve the transaction. There’s one type for keys with unchecked policies, and another type for keys whose policies have been checked—and signing functions take checked keys (and only checked keys!) as arguments. If we, the CubeSigner developers, skip a policy check, the code simply won’t compile.
Now, we go a step further and prove that the user’s exact code is executing in the policy engine TEE. Developers can request an attestation, which provides cryptographic proof of what’s running in the enclave. They can use this attestation for their own peace of mind—or they can share it (and their policy code) with interested parties, proving, say, that if their customers deposit funds at an address, those funds will only be used to execute a specific trading strategy, stake to a particular protocol, etc.
This kind of cryptographic assurance isn’t just theoretical. DogeOS, for example, is using CubeSigner and its Programmable Policy Engine to protect cross-chain withdrawals within their Dogecoin App Layer. Their custom policy verifies attestations to make sure that only validator nodes running DogeOS’s code can approve transactions—so withdrawals can only be signed by software they control. That means even if a node is compromised, it can’t authorize malicious withdrawals. The result: a secure, bridge-aware signing workflow that resists many of the most common cross-chain attack vectors.
More generally, this opens the door to externally verifiable guarantees in settings like custody, fund management, or on-chain compliance—without sacrificing privacy or control. It also makes it possible to build new kinds of protocols that are natively cross-chain without the complexity, slowdown, and security implications of traditional bridges and oracles.
Organizations need confidential policies
Traditional policy engines aren’t sophisticated enough to enforce complex logic, but smart contracts are; after all, they’re just programs. But often, exposing approval logic on-chain won’t fly. Complex approval policies, for example, expose organizational structure in a way that’s nerve-wracking for financial institutions; other policies expose sensitive information about proprietary investment strategies. Unlike traditional smart contracts, the Programmable Policy Engine lets users control the flow of funds without revealing details on-chain. And if anyone actually needs the policy details, organizations can always share the code and TEE attestation as proof of what’s executing.
Moving computation off-chain cuts costs—and operational headaches
Moving on-chain logic into the Programmable Policy Engine also cuts costs (and operational issues!) associated with smart contract execution and maintenance. Instead of incurring transaction fees for complex on-chain operations, code instead runs as a policy in the TEE. A policy is also inherently cross-chain: it can be attached to any key type, and thus used—unaltered—from one chain to another. This speeds up development and gives teams unparalleled flexibility as blockchain platforms evolve.
By running off-chain, the Programmable Policy Engine unlocks a fundamentally more powerful programming model. Unlike traditional smart contracts, policies can make network requests to, for example, get real-time prices on a CEX (e.g., when implementing a trading strategy), query RPC nodes for the state on different chains (e.g., when settling payments), track state to prevent unauthorized spending, verify signatures over any curve—and really anything you can write in a language like Rust and compile to Wasm.
A new era for key management security
The Programmable Policy Engine transforms wallet policy enforcement: it addresses the critical limitations of out-of-the-box policies, and makes it possible to move on-chain enforcement logic off-chain. Organizations need customizable, tamper-proof, private, and operationally efficient policies. By adopting this new technology, they can enforce sophisticated risk management strategies—and fundamentally reshape the landscape of programmable finance.
