Extensible Trusted Homeserver Operating System. Seven components — same design principles, same cryptographic discipline — composing into an alternative digital sovereignty infrastructure for people and organizations.
Most attempts at decentralization build one piece — the cryptography, or the storage, or the application — and then borrow everything else from the centralized stack they were trying to escape. ETHOS takes the harder path: one architect, fifteen years, every layer built against the same set of principles. The pieces compose because they were designed against the same constraints.
This document explains the components of ETHOS and how they fit together: seven layers in the stack proper, plus Intercoin (the sister ecosystem of EVM smart contracts that ETHOS bridges to). It assumes no background in cryptography but defines standard terms as they come up. The technical content is real; the framing prioritizes what each piece does for the user over what makes it clever for the engineer.
The components sit in layers. Each layer trusts the layer below as little as it has to, and exposes a narrow, auditable interface to the layer above. Read it bottom-up: hardware first, then the substrate, then governance, then applications.
The acronym is descriptive rather than aspirational: Extensible — every layer is meant to be extended by third parties, not replaced. Trusted — trust is grounded in cryptographic proof and hardware attestation, not in vendor promises. Homeserver — the deployment unit is "one box you control," not "an account on someone else's service." Operating System — what you'd call something that gives you a coherent way to install applications, manage data, and connect to the world. Plus the Greek word ethos, which means "the characteristic spirit of a culture or community" — appropriate for an infrastructure stack whose whole premise is that communities deserve their own.
The cryptographic backbone of ETHOS is a single conceptual structure used in two directions. The same tree is built downward for keys and upward for hashes. The two-directional pattern is what makes the rest of the stack tractable.
Start with one root secret. Derive children from the parent. Children cannot derive parents or siblings.
Whoever holds the Marketing key can derive every Marketing subtree. They cannot derive Engineering. This is how access control works in ETHOS.
Hash the leaves. Hash the pairs of leaf-hashes. Hash the pairs of those. The top hash commits to everything below.
Anyone with the root hash can verify "B is in this tree" by checking three other hashes. This is how integrity verification works in ETHOS.
The two trees are the same tree, traversed in opposite directions. The position in the tree decides both who can decrypt (via HKDF, top-down) and what can be verified (via Merkle, bottom-up). Every layer of ETHOS uses this composition: the position-in-the-tree determines the encryption key, and the same position determines where in the integrity commitment that piece of data sits.
The practical consequence: an organization can hand someone the "Marketing" key and that person automatically gets to decrypt everything Marketing — past, present, and future — without anyone needing to maintain a permissions database. To remove access, you derive a sibling subtree ("Marketing-v2") and stop using the old one. The removed person still has the old key but new content uses the new key, so they're locked out from anything new without any expensive global rekeying. Single operation, no coordination needed.
The "T" in ETHOS stands for Trusted, but trust here is not a feeling. It is a specific cryptographic property: the ability to prove that a piece of code is running in a known, locked-down environment, with no possibility of network access or hidden side effects, and that the inputs and outputs can be hashed for later verification.
This pattern recurs at every layer. The same discipline, slightly different implementation:
The Infrastructure component runs on AWS Nitro Enclaves (or any TEE — Trusted Execution Environment). Before any code runs, the hardware produces an attestation document signed by the manufacturer's root key, certifying which firmware, which kernel, which initramfs, and which root filesystem are running. Anyone — including a customer who has never met the operator — can verify that the running instance matches the AMI hash they pinned. If the operator tries to substitute different code, the attestation document signatures won't match. The chain of trust runs from the manufacturer's hardware all the way up to the application.
Inside Safebox, every tool the system runs (whether the code came from the operator, a user, or an AI agent) runs in a Node.js sandbox with the network capability removed. The methods available to the code are declared up front. The execution produces a hash that covers the code, the inputs, the available methods, and the outputs. Two runs that should produce the same result produce the same hash. If they don't, something changed, and the audit log makes it obvious.
The Groups app and DSL extension run their cryptographic code inside Web Workers with fetch, XMLHttpRequest, WebSocket, and importScripts made unreachable. The Object prototypes are frozen so user code cannot pollute them. An optional deterministic mode replaces Math.random with a seeded generator and Date.now with a fixed value, so the same code with the same inputs produces byte-identical outputs every time. The execution hash recipe is the same as on the server. The browser cannot offer hardware attestation, but it offers the next-best thing: a verifiable execution discipline that produces evidence anyone can check.
When a website wants to show a Groups contact picker or a Safebox approval prompt, it embeds an iframe pointing at embed.groups.app. The DSL extension intercepts that load before it touches the network, redirects to an extension-local resource, parses the website's declarative request through a whitelist parser (no JavaScript executes from the website's side), verifies the signature on the request, and renders the UI from inside the extension. The website sees only the user's eventual selection — never the underlying contact data. The user's data never leaves the extension's sandbox.
The same shape four times. Different hardware, different code, but the discipline is identical: execute known code in a known environment, hash the execution, declare the I/O surface in advance. The recipe for the execution hash is identical between the server-side Safebox sandbox and the client-side Groups sandbox. The same recipe means the same audit guarantees compose across the layer boundary.
Each component below is described in enough depth to understand its job, what makes it different from the obvious alternative, and what it lets the layer above assume.
A hardened operating system you can prove was built correctly.
Infrastructure is a complete Linux build pipeline that produces two AMIs (Amazon Machine Images) from a single source tree. The "audit AMI" has SSH enabled so a third-party auditor can inspect every file. The "production AMI" is identical except SSH has been removed — and a separate verification step proves that no file changed between the two, only files were removed.
The build produces a cascade hash: a SHA-256 commitment over every component manifest installed onto the image. Customers select an AMI by pinning this cascade hash. When their instance boots, the hardware attestation chain signs over the cascade hash, and a verification script confirms that the running instance matches what was pinned. If anything has been swapped between the audit and the deployment, the signature breaks.
The privileged surface is intentionally tiny: 64 lines of sudoers configuration plus a small Node.js daemon that mediates between Safebox (the application) and the operating system. An auditor can read the whole privileged surface in an afternoon. Compare to a typical cloud-hosted application with thousands of lines of Ansible scripts, Docker configurations, and runtime modifications that nobody has audited end-to-end.
What it lets the layer above assume: the operating system is exactly the operating system you pinned, the encryption key for the storage volume is sealed to this specific hardware configuration, and any code running on this box is doing so in a known environment.
Federated state and access control, in production since 2011.
Qbix is the application substrate that everything in ETHOS runs on top of. The core idea is that every piece of state in the system — a chat message, a user's contact list, a financial transaction, a vote in a DAO — is a stream: a publisher identifier (who owns it), a stream name (what it is), a list of attributes (current state), a list of messages (history), and a list of relations (what it's connected to). Streams are signed, append-only, and have access control built in.
Different applications agree on stream types. A photo-sharing app and a chat app and a forum can all use Streams/text for messages, Streams/image for pictures, Streams/chat for conversation threads. The substrate handles storage, access control, federation, and synchronization. Applications just define their stream types and their views.
Underneath, the streams substrate is a graph database. Every stream is a node, identified globally by (publisherId, streamName). Every relation between streams is a labeled directed edge. Whenever a stream's attributes change, the substrate auto-recomputes edges so the graph stays consistent. Queries run as plain SQL with strong indexes — no separate query language to learn, no proprietary runtime. SQL-speed faceted search, history, forks, and access control come built in. Full explanation at community.qbix.com/t/qbix-streams-as-a-graph-database/769.
The economics are designed for a three-role marketplace: App Developers build reusable widgets, Hosting Companies run them, and Communities embed them on their sites. The QBUX utility token, plus per-app vouchers, plus pairwise trustlines between Communities and Hosting Companies, settle the micropayments without any of the parties needing to trust each other. Full economic model documented at qbix.com/ecosystem.
Qbix is the layer most people don't notice because it has been deployed quietly at scale for over a decade. The Groups app — over 5 million users across 100+ countries — runs on it. So do dozens of smaller deployments. Source at github.com/Qbix. The conventions are battle-tested in a way most decentralization projects can only aspire to.
What it lets the layer above assume: there is a substrate where signed, federated, access-controlled state already exists, where applications cooperate via shared stream types, and where the substrate handles the boring problems (storage layout, relation indexing, file uploads) so applications don't have to reinvent them.
Workflows that propose, governance that decides, sandboxes that verify.
Safebox is a Qbix plugin that adds a governance pipeline for executing actions. The structure is:
Action.propose — they never write directly to state.The discipline is "tools propose, substrate decides." A tool can suggest "transfer $100 from account A to account B" but cannot make it happen. The proposal goes through governance: a configured set of approvers must each sign an approval claim (using the OpenClaiming Protocol, described below), and only after the threshold is reached does the action execute. Every execution produces an execution hash recorded in the audit log.
This solves a problem that has plagued every attempt to use AI agents for real work: how do you let an agent do useful things without giving it the keys to the kingdom? Safebox's answer: the agent proposes, humans (or other agents, or smart contracts) approve, the substrate executes. The agent's authority is bounded by the approvers it can convince and the capabilities it has access to.
Source for the Safebox plugin and the broader Safebots stack is at github.com/Safebots.
What it lets the layer above assume: any action that has happened was approved according to the configured governance, any execution can be replayed and verified against its execution hash, and no tool — including AI tools — can do anything outside its declared capability set.
Encrypted messages between substrates, cached blobs anyone can serve.
SafeCloud is an encrypted, content-addressed storage and routing fabric. Files are split into encrypted chunks before they leave the owner's device, distributed across willing storage nodes, and routed through federated servers — with the property that nobody in the middle ever sees plaintext. There are three roles:
A file moves through the system like this: the Cloud SDK splits it into chunks, encrypts each with an HKDF-derived per-chunk key, computes a content identifier from the ciphertext, and uploads the encrypted chunks via a Jet to a set of Drops. The file's public manifest records the Merkle root over all chunk identifiers plus the public keys needed to verify the binding — and contains nothing that could decrypt anything. The owner keeps the root secret; everyone else only ever sees encrypted bytes.
Access delegation is OpenClaim-signed: when the owner grants someone access to a chunk range, they derive a subtree key for that range via HKDF and produce a signed delegation proof. The grantee presents the proof to Jets when fetching; Jets verify the signature and the range coverage before routing the request. Payment is OpenClaim too — EIP-712-signed payment claims that the Jets verify on-chain against the payer's balance before billing for the work.
Encryption is convergent: same content plus same root secret produces the same chunk identifiers. Identical files get deduplicated automatically. Cache hits earn the Drop a Safebux payment, half of which goes back to whoever paid for the chunk's creation in the first place — so popular content propagates naturally because replicas earn fees.
What it lets the layer above assume: there is a way to move data between ETHOS instances without anyone in the middle being able to read it, store it on machines belonging to people who have no business reading the contents (because they cannot), and pay for the work in a way that anyone can audit.
The smart contract suite that gives ETHOS a financial vocabulary.
Intercoin is a sister company to Qbix, spun out specifically to handle the on-chain financial primitives that communities need. The work product is twelve audited Solidity smart contracts deployed across eight or more EVM-compatible mainnets — Ethereum, Polygon, Base, Optimism, Arbitrum, BNB Chain, Avalanche, and others. The contracts compose like LEGO bricks: a community can pick the ones it needs and assemble its own financial layer without writing custom Solidity.
The twelve contract types: Community DAO (membership and roles), NFTs (membership tokens, art, certificates), Currencies (community-issued utility tokens), Subscriptions (recurring payments), Income (disbursements including Universal Basic Income), Stats (price discovery from on-chain activity), Contests (judge-rewarded community problem-solving), Fundraising (multi-round funding), Auctions (price discovery for limited resources), Escrow (multi-party settlement), Control (collective account management), and Voting (cryptographically secured elections).
All twelve have been audited by external security firms (including CertiK) over five years of hardening. The source is open at github.com/Intercoin and the full catalog with documentation is at intercoin.org/applications.
For ETHOS, Intercoin is the financial vocabulary that lets the substrate interact with real economic value. When an organization running on ETHOS wants to issue a community currency, run a vote, pay a subscription, or hold funds in escrow, the underlying mechanism is an Intercoin contract — instantiated by that organization, controlled by their governance, deployed to whichever chain they prefer. The composition with Intercloud is what makes this practical: Intercloud's SafeBoxes hold the keys to those contracts, the workflow logic lives in ETHOS streams, and the actual settlement runs on the EVM mainnet of choice.
What it lets the layer above assume: the building blocks for community-scale financial logic already exist, are audited, and can be reused without reinventing Solidity contracts that have already been written and battle-tested.
Where ETHOS meets the rest of the financial world.
Intercloud is the bridge between SafeCloud and external blockchains, including the Intercoin contracts described above. It does two things, both hard.
Outbound: ETHOS streams can hold private keys for addresses on Bitcoin, Ethereum, and other chains. The keys are generated inside a Trusted Execution Environment and never leave it. When an ETHOS workflow needs to pay someone in actual Bitcoin or Ethereum, the workflow's governance pipeline produces an approval claim, the TEE verifies the claim and constructs the transaction, signs it with the enclave-held key, and broadcasts it. The key never appears in plaintext anywhere; the conditions for signing are entirely governed by ETHOS-level rules.
Inbound: ETHOS reads blockchain state by actually verifying the consensus proofs. For Bitcoin, that means checking that block headers meet the difficulty target and chain back to a known checkpoint. For Ethereum, that means verifying validator signatures meet the finality threshold. This is the same logic a "light client" runs, but executed inside the TEE so the verification result itself carries hardware attestation. No trusted oracle is required.
What's distinctive about Intercloud is how it handles the oracle problem. The oracle problem in blockchain is: how do you trustlessly bring outside data onto the chain? Existing solutions (Chainlink, Pyth) use voting among economically staked oracle nodes. Intercloud uses the same chilling-effect consensus that secures the rest of the substrate: multiple oracle nodes report a value, any node that reports inconsistently produces signed evidence of its own equivocation, and that evidence triggers automatic removal and stake forfeiture. The deterrent is strong because a single provable inconsistency triggers permanent removal, so the rational strategy is honesty regardless of whether the node thinks it's being monitored.
What it lets the layer above assume: ETHOS applications can pay and be paid in real-world cryptocurrencies, can read verified blockchain state, and can do all of this without trusting any centralized bridge operator or oracle network.
The reference application — 7M users, encrypted by design.
Groups is a messaging and contact-organizing app. It is also the proof that the cryptography described in this document works at scale.
End-to-end encryption in Groups uses a pair of hash chains derived from a conversation key. One chain runs forward (each link is the hash of the previous one); one runs backward. The per-message encryption key is HKDF-derived from the corresponding forward and backward chain values. Compromising any single message key reveals nothing about other messages: you cannot recover earlier messages because forward chain links are one-way, and you cannot derive future messages because backward chain links require knowing the chain's end. Adding or removing participants is a single operation that does not require re-encrypting any existing messages.
The conversation key itself is bootstrapped through a one-time elliptic curve Diffie-Hellman exchange between the two participants' devices. Once the conversation key exists, every subsequent message uses symmetric cryptography — the same speed as unencrypted messaging, just with fast in-memory key derivations. There is no per-message public-key operation, no global server-side state, no key escrow.
A first-contact flow that requires nothing of the recipient. Sending an encrypted message to someone who doesn't have Groups installed is the hardest case for any messaging system. Most either fail (you can't message someone who hasn't signed up) or compromise (the server brokers the introduction and learns the social graph). Groups handles it with a capability-based onboarding flow that uses two independent channels and an OS-verified ephemeral execution environment. The sender encrypts the message locally and uploads the ciphertext to a storage server, receiving a URL like https://groups.app/msg/abc123…. The URL travels through one channel (SMS, email, any messaging app the recipient already uses); the secret unlock material (a short passphrase or QR code) travels through a different channel (voice, NFC, in-person). Neither piece alone is sufficient. The server holds only ciphertext and cannot decrypt.
The pristine execution at the receiving end. When the recipient taps the URL on their phone, the operating system recognizes the URL pattern and invokes an app clip: an ephemeral application downloaded just-in-time, signed by the developer's identity, code-signature-verified by Apple, and sandboxed for the duration of use. The user sees the verified developer name before the app clip shows anything. The app clip prompts for the secret material, derives the decryption key via K = HKDF(URL_token, secret), fetches the ciphertext, decrypts locally, and renders the plaintext. The recipient never installed Groups; never created an account; never trusted the storage server. This is the pristine-execution pattern from the cryptographic core applied to a phone-side use case: the OS verifies the code, the code declares its I/O surface, decryption happens inside the verified boundary. After successful decryption, the app clip can offer to migrate keys into a full installation through the OS keychain — turning an ephemeral session into a persistent identity only if the user chooses to.
Safebox generalizes this trust pattern beyond a single vendor. The "platform-attested, signed, sandboxed pristine environment serving known code on demand" pattern currently has one widely-deployed consumer instance: iOS app clips. Android Instant Apps cover similar ground with different constraints; web extensions cover it again with different constraints. Safebox extends the same pattern to server-side compute. Instead of an Apple-signed app clip running on the recipient's phone, a TEE-attested cloud instance runs a deterministically-built image, and any party can verify the attestation the same way iOS verifies an app clip signature. The cryptographic shape of the guarantee is the same: known code in a known environment, with platform-issued proof. App clips put pristine execution on the recipient's own phone; Safebox puts it on a server the recipient can verify. Both work because the platform attests to the code. Unlike app clips, Safebox attestation isn't tied to a single vendor's ecosystem; the same mechanism works on AWS, Azure, GCP, Oracle, and on-premise hardware, and on devices running any operating system.
Groups has been deployed for several years to over 5 million users across more than 100 countries. The encryption stack described here is not theoretical; it is running in production on every device that has the app installed. The Q.Sandbox primitive (locked-down Web Workers with deterministic execution and audit hashes) is the same primitive that runs server-side in Safebox — different platform, identical discipline.
What it demonstrates: the cryptography composes. End-to-end encryption with O(1) membership changes, hierarchical access control via HKDF trees, sandboxed execution with audit hashes, and capability-based UI integration via the DSL extension all work together in production.
A way for websites to access your data without seeing your data.
The problem the DSL extension solves: how do you let a website (any website) show a "pick a contact" or "approve this payment" or "share this file" interface, using data that lives in the user's Groups account, without the website being able to read that data or impersonate the user?
The current solutions are all bad. Browser extensions inject scripts into pages that can be hijacked. OAuth flows hand over scoped access tokens that websites can leak or exfiltrate. Native pickers (like the iOS contact picker) only work for built-in apps and tie users to whichever ecosystem they happen to be in.
The DSL extension's solution: a website embeds an iframe pointing at a known origin (like embed.groups.app). The extension intercepts that load before any network request happens and redirects the iframe to an extension-local HTML resource. The website's "request" — a declarative description of what it wants the user to do — is passed through the URL hash fragment, which never leaves the browser. The extension parses the declarative request through a strict whitelist parser (no JavaScript executes from the website's side, no <script> tags allowed, no javascript: URLs), verifies a signature on the request against the website's origin's pinned public key, and renders the UI from inside the extension.
The user sees their contacts, their messages, their files — decrypted locally inside the extension. The website never gets that data. When the user makes a selection or clicks "approve," the extension sends only an opaque identifier back to the website. The website never had the underlying personal data; it just gets to know which contact the user picked.
The result is that Groups (or any ETHOS app) can be embedded as a native-feeling part of the web rather than an isolated silo. A website can integrate with the user's data; the website cannot read that data, and cannot inject code into the integration.
What it lets the user assume: when they see a familiar Groups or Safebox UI embedded in a website, the UI is the real thing, the website cannot read what's inside it, and any selection they make sends only what they meant to send.
Two layers compose directly on top of the seven-layer stack: a knowledge layer that pre-computes structured understanding, and an agent layer that uses Safebox governance plus that knowledge to do useful work.
Grokers ingests a codebase (or any structured corpus) and stores the result as queryable streams and relations. For source code, that means parsing every file with tree-sitter, building a call graph and dependency graph, dispatching LLM agents to analyze each function bottom-up — callees comprehended first, then callers — and writing the result as Grokers/symbol streams and Grokers/calls / Grokers/reads / Grokers/writes relations.
This amortizes the cost of understanding. Today's AI coding tools re-infer the dependency graph on every turn: read files, extract imports, reason about which symbols reference which, discard. Next turn, the same work happens again. Grokers pays the comprehension cost once, then "what depends on this symbol?" is a single indexed SQL query against the graph, not an LLM inference.
Because the streams substrate is already a graph database (nodes, relations, faceted search, history, federation, access control), it is a natural fit for the knowledge layer. Grokers does not invent its own storage — it stores understanding as streams, the same way Groups stores messages or SafeCloud stores manifests.
A practical consequence: refactoring across the dependency graph in parallel. Given a change to a symbol, Grokers can compute the set of all affected symbols, topologically sort them so callees update first, and dispatch parallel workers at each depth. Two hundred affected symbols across six dependency levels become six waves of thirty-three workers instead of two hundred sequential LLM calls. Source at github.com/Qbix under the Grokers plugin.
Safebots is the agent product that runs on top of Safebox (governance), Grokers (knowledge), and the substrate (state). Where Safebox provides the rails — workflows, approval pipelines, sandboxed execution, audit hashes — Safebots provides the agents that ride those rails: autonomous workflows that read the graph, propose actions, get them approved, and execute them under attested-runtime constraints.
The discipline at every level is the same as the rest of the stack. An agent cannot do anything outside its declared capability set. Every action is an OpenClaim-signed proposal, governed by the same M-of-N approval primitives that govern human actions. Every execution produces a hash committed to the audit log. The agent's authority is bounded by the approvers it can convince and the capabilities it has been granted, not by trust in the agent's intentions.
Project at github.com/Safebots; commercial product at safebots.ai.
The layered architecture pushes encryption work to the edges. A typical operation moves through several keys, each scoped to its job.
Each user's device has a long-lived identity keypair stored in the secure enclave (Apple's Secure Enclave on iOS, Android's StrongBox, the equivalent on desktop). The private key never leaves the enclave; it is generated inside and used inside.
When the user opens a conversation with a new contact, the device performs a one-time Diffie-Hellman exchange with the contact's device. This produces a shared secret. The shared secret is HKDF-extended into a conversation root, which seeds the forward and backward hash chains for that conversation. From this point onward, every message uses symmetric cryptography.
For the user's own data — their contacts, their notes, their files — there is a personal HKDF tree rooted at a key derived (via ECDH-with-self, a deterministic trick using the secure enclave) from the device's identity keypair. Different folders are different subtrees. Different time periods are different subtrees. The user can grant access to specific subtrees by handing out the corresponding HKDF root, without ever exposing the personal root.
An organization runs its homeserver on the Infrastructure layer — a Nitro Enclave or equivalent TEE. The encrypted storage volume's key is sealed to the hardware: the key can only be unsealed by an enclave whose attestation report matches the pinned configuration. Move the disk to another machine, the key cannot be unsealed. Substitute different code on the same machine, the key cannot be unsealed.
Inside the homeserver, an organizational HKDF tree mirrors the org structure: a root, then departments, then sub-teams, then time periods or projects. A new employee joining the marketing team in Q2 2026 receives the key for "Marketing / 2026-Q2 onward" — they can decrypt everything Marketing from that point forward, automatically, with no other configuration. An employee leaving has their key revoked by deriving a sibling subtree; the cost is constant regardless of org size.
External communication — between this organization's homeserver and another organization, or between the organization and an external customer — uses SafeCloud's Jets primitive. Each Jet is encrypted under a key derived from the destination's published key, sent through whatever network path is available, and reassembled on the other side. Drops cache encrypted blobs across willing nodes; the holders cannot read the contents because the encryption key is derived from a different HKDF tree they have no access to.
An ETHOS workflow that needs to make an actual blockchain payment goes through the governance pipeline. A workflow step generates a proposed transaction. The proposal goes to the configured approver set — say, three of five organization signers. Each signer sees the proposed transaction, verifies it against the workflow's declared policy, and produces a signed approval claim. Once three claims are collected, the proposal is delivered to the TEE-resident signing service.
Inside the TEE, the signing service verifies the M-of-N threshold, verifies the workflow's policy was followed, constructs the actual blockchain transaction, signs it with the enclave-held key, and broadcasts it. The private key is never visible outside the enclave; the signing conditions are governed entirely by the ETHOS-level workflow logic. Confirmation of the transaction's inclusion comes back through an Intercloud chain oracle stream — verified by independently running the chain's consensus proof inside the same enclave — and updates the workflow's state.
No piece of this architecture relies on "trust us." Every claim is grounded in either a hardware signature (the TEE attestation), a cryptographic proof (the HKDF derivation, the Merkle commitment, the M-of-N signature aggregation), or a verifiable execution (the sandbox execution hash). Every layer can be audited independently. Every layer fails closed: if anything is wrong, the operation does not proceed.
Your messages, your contacts, your photos, your notes are stored encrypted on your device. The encryption keys live in your device's secure hardware and never leave. When you want to share something with someone, the cryptography handles it — they get the key for what you shared, and only that. Removing someone's access is a single click and works immediately.
Apps you use can integrate with your personal data without seeing it. When a website wants to know which contact you'd like to invite to its service, it can ask through the DSL extension: you see a familiar contact picker, you make a choice, the website gets only the identifier you selected. The website never sees your address book.
Your homeserver — if you choose to run one — holds anything too important to leave on a phone. It runs on hardware whose configuration you can prove to anyone. Anyone you give the right keys to can collaborate with you; nobody else can see anything.
Your organization's data lives in your infrastructure, not in a vendor's. The infrastructure is auditable: an external party can read the entire stack, sign off on the configuration, and verify that the production deployment matches what they audited.
Access control is structural, not procedural. There is no permissions database that someone might forget to update; access is determined by which subtree of the HKDF tree each user holds the root key to. Adding employees, removing employees, sharing with contractors, granting time-limited audit access — all of these are single cryptographic operations.
AI agents and automation can do real work without doing dangerous things. Every action proposed by an agent goes through the same governance pipeline as a human action. The agent can suggest, but cannot act. M-of-N approval is the substrate-level rule; no agent, no tool, no piece of code bypasses it.
Payments to external parties — in any cryptocurrency you have set up — flow through the same governance pipeline. The keys to your treasury are held in hardware that nobody can extract them from, including the operator of the hardware. The conditions for signing are the conditions your organization configured. Compliance and audit happen as a consequence of how the system runs, rather than as a separate layer bolted on top.
Communities can run their own homeservers and federate with each other through SafeCloud. A community's internal data stays internal. A community's public-facing data (a website, a forum, a marketplace) reaches the outside world through gateways that translate ETHOS protocols into ordinary HTTPS, so anyone can read it without installing anything special.
Community governance — voting, treasury management, membership — runs on Safebox's M-of-N approval primitives. A community of any size can be self-governing without trusting any single administrator. The same primitives that secure a Fortune 500 company's operations also secure a neighborhood association's email list, because the architecture does not care about size.
The unifying observation, after fifteen years of building this: the same cryptographic discipline applied consistently at every trust boundary in the stack produces a system that composes.
Most stacks have one trust boundary (say, the OAuth handshake between an application and its identity provider) and bolt other boundaries on as afterthoughts. The result is that the security of the whole depends on the weakest seam. ETHOS instead applies the same primitive set — HKDF trees, Merkle commitments, ECDSA-signed claims, pristine execution environments with audit hashes — at every boundary.
The hardware boundary uses TEE attestation. The server boundary uses Node sandbox + execution hash. The browser boundary uses Worker sandbox + execution hash. The trust between substrates uses signed Jets with capability bootstrap. The trust between organizations uses signed claims in OpenClaiming Protocol format — the same envelope across every layer, so a signature from a hardware attester, a corporate signer, and a community voter all verify with the same code. The trust between blockchains and the substrate uses TEE-verified consensus proofs. The mechanics vary with the layer; the shape — known code, known environment, hashed execution, declared I/O — does not.
The HKDF top-down / Merkle bottom-up symmetry is the cryptographic core. The pristine-environment-recurs-at-every-layer pattern is the architectural core. Between them they produce a stack where security is achieved through the design itself rather than added at the end. Layers fail closed by default, every operation produces evidence, and any layer can be audited without trusting the others.
Each layer expresses the same design principle in different materials. Hardware, server, browser, fabric, settlement, application, integration — each gets the same discipline applied with the constraints appropriate to that layer.
The architecture this document describes is real and deployed at the layers where deployment matters most. The Groups app has been live for years to several million users. The Intercoin contracts have been audited and run on eight blockchains. The Qbix substrate has powered hundreds of community apps since 2011. The newer pieces — Safebox, SafeCloud, Intercloud, and the DSL extension — are at earlier stages, some shipped to specific customers, some in private use, some still being implemented.
Four entry points let you engage with ETHOS today. Each one is useful on its own; you do not have to commit to the whole stack to use any single piece.
Available on the Apple App Store and Google Play. Groups runs the end-to-end encryption described above on every message, every contact, every shared file. Your private key lives in your phone's secure enclave; nobody at Qbix can read what's inside. As Safebox and SafeCloud reach wider public availability, the same Groups app is the natural interface for driving them from your phone.
Open groups.app →The simplest way to participate in the SafeCloud network is to open safebox.org in a browser tab and leave it open. Your browser becomes a Drop: it volunteers some of its IndexedDB capacity to hold encrypted chunks (which it cannot read), serves them when asked, and earns Safebux for the work. Closing the tab takes the Drop offline gracefully; reopening later reconnects with the same identity.
Open safebox.org →The Qbix Platform's reusable widgets — chat, events, payments, profiles, video calls, group management — can be embedded in any website with a few lines of code. The same substrate that powers the Groups app powers anything you build on top of it. Source at github.com/Qbix.
Open qbix.org →The twelve audited Solidity contracts — Community DAO, Currencies, Voting, Subscriptions, Income, Escrow, and the rest — can be deployed by any organization onto any of the eight supported EVM mainnets. The contracts compose like LEGO bricks. Full catalog at intercoin.org/applications, source at github.com/Intercoin.
Open intercoin.org →Each entry point is useful on its own. Composed, they form the practical face of the architecture this document describes — a Groups user invites their community, the community runs widgets from Qbix and contracts from Intercoin, the substrate caches encrypted state across SafeCloud Drops, and the whole thing sits on Infrastructure that anyone can audit. The same cryptographic discipline carries someone from their first secure message through to running their own community's economy.