SovereignTEE Ltd
The API for your API
Canopy RPC: Your distributed application accelerator.
The IDL (Interface Definition Language) is THE type system — for remote function calling, for persistence, and for your business logic. Define your interfaces once and carry the same contract through the primary C++ runtime and generated browser/Node clients, with broader language runtimes on the roadmap. Built for a confidential-computing future.
Every service boundary across your distributed system costs you the same engineering time: serialisation, transport plumbing, authentication, lifetime management. None of it is your product. Canopy — the open-source library from SovereignTEE — generates the typed proxy, stub, serialisation, callback, and lifetime plumbing from a single interface definition. Bind it to the supplied or a custom transport, and add route security and hardware attestation where the deployment requires them.
// serialise the request buf.write_uint32(METHOD_GENERATE); buf.write_string(prompt); // open socket, handle reconnect… // reverse everything on the other end // add streaming callback channel // manage session lifetimes manually // redo for TCP, then JSON, then protobuf
interface i_inference_service { int create_session( const std::string& model, [out] rpc::shared_ptr<i_session>& s); }; interface i_session { [post] int on_token(const std::string& t); int generate(const std::string& prompt); };
The company
SovereignTEE Ltd
SovereignTEE Ltd was formed to democratise distributed development and to provide data sovereignty through the use of trusted execution environments (TEEs) and trustless technology. Its core technology, Canopy, gives an agnostic separation of concerns — serialisation formats, transports, transformations, C++ and generated client bindings, blocking and coroutine-based operation, one-way calls, and reflection — all centred on a single interface definition.
On that foundation, SovereignTEE delivers products around hardware-attested trust and protected multi-hop RPC across nodes and transports. Post-quantum suite agility is on the security roadmap.
The architecture keeps those security changes in the RPC and deployment layers wherever possible, preserving the application contract and the code that carries your business value.
What one interface definition generates
Write the contract once. Canopy generates C++ proxy/stub and serialisation code together with supported JavaScript clients. Bind the result to the transport and service needed at deploy time. The same definition also produces configuration and MCP-oriented JSON schemas and supports runtime schema retrieval through Canopy RPC.
The painful migration from standalone to distributed systems
Write a standalone app. It works. Then someone else needs to call it.
So you write a serialiser and a transport layer, then the reverse of both at the other end. Six months later the same service needs a new type of connection or format. You rewrite it. Then a mobile client wants JSON. Then a partner asks for Python support. Then the security team says the production deployment needs hardware attestation — callers must cryptographically verify they are talking to unmodified, trusted code before sharing sensitive data.
At this point, you have written thousands of lines of infrastructure that has nothing to do with what your service actually does. And every new boundary costs the same again.
This is not a niche problem. It is the default state of distributed systems development, because the infrastructure for crossing boundaries cleanly and securely does not exist in a usable form for most teams. The teams that solve it well either have proprietary platforms built over years, or the budget to hire specialists. Everyone else writes it by hand, again and again.
SovereignTEE was built by engineers who wrote that code for the fifth time and decided it should be the last.
How it works in practice
The Canopy technology at the core of SovereignTEE works because it treats the interface definition as the single source of truth for every downstream concern.
You write the service contract in IDL: the callable methods, the types they use, which parameters carry results back. No transport is baked into the contract. A build step generates the requested C++ serialisation paths and supported client bindings. Change a type in the IDL and those generated targets update consistently in the next build.
You then bind that generated code to a transport and a service at deployment time. Local in-process, inter-process, TCP, TLS, WebSocket, shared-memory queues, SGX enclave — these are constructor choices that do not touch the service implementation. Moving a service from a development local call to a production TLS endpoint, or into a hardware enclave for a sensitive workload changes deployment wiring and security policy rather than the application interface.
The same IDL also generates each service's configuration and drives runtime reflection. Generated configuration and MCP schema profiles support editors and agent tooling, while Canopy's built-in schema RPC carries live interface descriptors across supported transports.
When a caller needs to verify that the service is running unmodified, trusted code before sharing sensitive data, Canopy route security can verify DCAP evidence as part of a transcript-bound secure-session handshake and protect the resulting RPC route. The deployment supplies the trust policy, credentials, collateral, and trusted-time configuration.
Explore the remote-attestation architecture and deployment model →