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.

Without — repeated on every boundary
// 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
With Canopy — written once
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);
};
Generated
boundary glue derived from the contract, not duplicated by hand
1
interface definition shared across supported transports and bindings

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.

What one IDL definition generates One IDL feeds the Canopy generator, which produces supported language bindings and runtime reflection. Bindings run over configured transports into your service; reflection auto-generates the service configuration; and the running service exposes reflection through its RPC API for live introspection by editors, AI agents and browsers. Your IDL — one definition Canopy generator Language bindings each generated for a serialisation format C++ · JavaScript · broader runtimes planned YAS binary · JSON · Protobuf Pluggable transports in-process · TCP · TLS · WebSocket · SGX enclave Runtime reflection config schema · MCP schema · descriptors generated and retrievable through Canopy RPC Service configuration config schemas auto-generated from the IDL Your app exposes reflection via its RPC API Live introspection editors · AI agents (MCP) · browsers

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 →

See a full worked example →