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 share them across every language and every system. Built for a confidential-computing and quantum-ready 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 all of it from a single interface definition, across any language, any transport, and hardware-attested security where you need it.
// 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, languages, blocking and coroutine-based operation, one-way calls, and reflection — all from a single interface definition.
On that foundation, SovereignTEE delivers the harder guarantees as products: hardware-attested trust, post-quantum encryption, and multi-hop encryption across several nodes on different transports.
The migration from conventional cryptography to attested or post-quantum security is designed to be a clear, simple path: the change is made in the RPC subsystems, not in your application logic. As your requirements evolve, you follow a defined roadmap rather than rewriting the code that carries your business value.
What one interface definition generates
Write the contract once. Canopy generates a language binding for each serialisation format you need, then you bind that generated code to whichever transport and service you need at deploy time. The same definition also drives runtime reflection: it auto-generates each service's configuration, and every running service exposes that reflection through its own RPC API — so any language can introspect it live.
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. No language. A single build step generates type-safe bindings in every language you need, targeting every serialisation format you need. Change a type in the IDL and every generated target updates consistently in the next build. Nothing can drift out of sync because nothing is defined twice.
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, is a one-line change in the startup configuration.
The same IDL also generates each service's configuration and drives runtime reflection. A running service describes its own interfaces through its RPC API — exported as JSON schema, Protobuf, IDL, or other formats — so editors, AI agents, and browsers can introspect it from any language without prior knowledge of its contract.
When a caller needs to verify that the service is running unmodified, trusted code before sharing sensitive data, the enclave transport handles the attestation as part of the connection handshake. No separate attestation infrastructure to build or operate.