Skip to content


The Simple Secret Sharing Server (SSSS) is the next-generation first-party secret management system used by all kinds of workers in the Escrin ecosystem. The name describes the function:

  • Simple: the SSSS eschews as much complexity as possible to increase efficiency and decentralizability
  • Secret Sharing: secrets are split and stored among distributed, non-colluding shareholders, which ensure that only authorized parties can reveal the secret
  • Server: the SSSS stores encrypted secrets and serves them to authorized requesters

The SSSS, via the Escrin identity framework, securely holds secrets in a decentralized manner. When an Escrin Worker begins its life, it will authenticate to the SSSSs holding its OmniKey secret shares, fetch the secret shares, reconstruct the secret, and unwrap its OmniKey.

Compared to the other key management mechanisms supported by Escrin, the SSSS is designed to be more flexible, secure, and reliable than third party secret management networks.


SSSS NodeSync TaskBlobStorepolicy  SecretStoresecret shareAPI TaskPOST ../permitsGET ../sharesPolicy Engineverify requestpermit   policysecret shareEscrinSmart Workeracquire_identityget_keyConsensus Network(e.g., Ethereum)distribute sharespolicy,secret shareApp Devset policy
Figure 1. SSSS architecture overview


  • implement the Escrin Identity interface (acquire_identity, get_omni_key)
  • run efficiently on practically any hardware
  • connect to any chain where users are found
  • be straightforward to self-host or deploy in a permissioned setting
  • scale to meet the needs of a large public network
  • NOT implement yet another consensus layer
  • NOT support programmable identity access policies (the Escrin Runner can be used for that)

The SSSS has four main components: the API task, the sync task, the policy engine, and the storage backend. The storage backend can be implemented against any cloud or local host, which gives the SSSS portability.

The sync task watches the SSSSHub contract on any EVM-compatible consensus network for policy configuration changes and new secret shares. When it receives either, it unpacks the transaction data and stores it in the backend. Policies are posted as Brotli-compressed CBOR documents, and each share is encrypted under the SSSS's public key and bundled with a cryptographic commitment. All are sent gas-efficiently as calldata or blobs (depending on availability) to enable deployment on as many networks as possible.

The policy engine executes the policies received by the sync task against worker requests for identity permits. Currently the only policy available is the one that verifies AWS Nitro Enclave attestations, which is prohibitively expensive to do on most chains. Support for arbitrary JavaScript and Python policies can easily be added in the future by executing them in the Escrin Runner, which keeps the SSSS simple and easy to deploy.

The API task is a simple HTTP server that listens on a public network interface and is reachable over TLS. Compared to a P2P network interface, this simple mechanism is highly robust and benefits from decades of work on internet security, performance, and interoperability including DDoS prevention, certificate transparency, and accessibility from web browsers.

Knitting these components together is state-of-the-art cryptography, memory-safe code, and meticulous attention to detail. All combined, the SSSS is a secure, fault-tolerant system for storing secrets in a cloud and L1-agnostic manner, leaving the power of choice in the hands of developers and their users.


The SSSS is currently in the alpha stages and, although fully functional, is missing several highly desirable features and security enhancements.

The following roadmap items are in order, as each one is required by the next. All are towards the smooth function of the public SSSS network. Private deployments of the SSSS are pretty much good to go already.

Phase I: Public Network Payments

  1. Enable verifiable secret sharing to pinpoint which SSSS/Worker sent faulty shares
  2. Add automatic trust-minimized batch payment settlement
  3. Track per-node reliability metrics to allow participants to stop/continue payments.
    As a stretch goal, create the SSSSScan web app to track SSSSs and their metrics.

Phase II: Greater Decentralization

The goal of this phase is to allow secrets to be shared on a rotating basis with all nodes that an application trusts. This will allow for conveniently increasing the size of the set of shareholders, as well as give smaller SSSS operators a greater opportunity to participate in the public network.

  1. Provide auto-configuration of SSSS nodes using P2P gossip network
  2. Enable proactive secret sharing for greater resilience to adaptive attacks

Phase III: Trustless Payments

  1. Enable publicly verifiable secret sharing for on-chain verification of shares
  2. Add automatic trustless payment settlement via smart contract using HE, and ZKP


The following models assume the use of the SSSS in a public network configuration. If operated as part of a permissioned Escrin deployment, users must trust the app dev to have properly deployed their SSSSs to non-colluding entities.


The security of the SSSS is derived from the use of Shamir's secret sharing, which itself is information-theoretically secure. Practically, this means that as long as the cost to breach a threshold of SSSSs is higher than the value obtained by doing so, an attack is unlikely occur.

Accordingly, the most important property for a set of SSSS shareholders is to be non-colluding–essentially that they are operated by independent entities, each with different motives, and ideally different deployment strategies.

A useful analogy is to the utility of genetic diversity of a population when assailed by a pathogen. The pathogen's ability to proliferate and destroy the population greatly reduced by each organism having its own genome-specific defenses that the pathogen must evolve to bypass. Similarly, a large and motley group of SSSSs is more likely to be secure than a group operated in the same way or by the same entity.

All this being said, assuming non-collusion and a sufficiently diverse attack surface such that only fewer than the configured threshold of shares are missing or faulty, there are no risks to security*.

* Currently secret shares are not verifiable, so a faulty share would likely result in the wrong secret being reconstructed. However, Escrin OmniKeys are wrapped using authenticated encryption, so an incorrect shared secret would cause an irrecoverable error rather than silently proceed. This problem will go away once Phase I of the roadmap is complete.


The trust model for liveness can be summarized by the following table.

⬇️ trusts ➡️?UserApp DevWorkerSSSS Node
App Dev-🤝/✅1
SSSS Node🤝/❔1🤝/✅2-

❔ represents trust that is not established by the protocol, and 🤝 represents trust through economic collaboration: an SSSS node will hold on to a worker's secrets as long as the worker pays more than the cost to store them, and the worker will pay the SSSS node as long as the Worker's application is worth the cost to maintain.

After Phase I of the roadmap is implemented, this model can be enforced automatically: SSSS nodes and workers will maintain metrics of which workers/SSSS are unreliable on payments and drop them as customers/service providers. And if an SSSS node goes down or becomes too expensive, the Worker can re-share its secret with its new preferred set of secret shareholders. the SSSS.

1 After Phase III of the roadmap, payments will be made by the worker directly without the app dev in the loop.
2 After Phase III of the roadmap, payments for valid shares are guaranteed, and faulty participants punished.

Operating requirements

The SSSS is a lightweight program that can run on even the most resource-constrained hardware, although it also benefits from the features provided by more powerful hardware. Accordingly, the only hard requirements of the SSSS are:

  • to be operated under security best-practices to minimize the risk of compromise
  • a machine with 1 CPU and 0.5GB of memory
  • a stable internet connection
  • a domain name at which to host the SSSS API
  • to rarely lose, delete, or otherwise corrupt the SSSS infrastructure

However, for greater security, an operator may choose to do any of the following:

  • run replicas of the SSSS and load balance amongst them
  • use multiple high-reliability Web3 gateway services for each blockchain
  • run your own full/light nodes and Web3 gateways
  • run the SSSS and blockchain nodes inside of TEE
  • and generally do all of the things a Web2 API service provider would do


The security of secret sharing improves with the number of non-colluding shareholders, so more SSSSs with decent deployment security (and non-overlapping vulnerabilities) is better than a smaller number of locked down SSSSs, so these extras are truly only nice-to-have.

The SSSS can be deployed on AWS, Azure, or locally at very low cost, or even completely free under free tiers. The most basic configuration on the clouds is about $6/month before free tier incentives, so everyone who wants to run an SSSS should be able to. But do expect competition on the public network from operators who invested in higher reliability and defenses!


For deployment scripts and detailed instructions, please refer to the deployments README.

If you want to run the latest versioned release of the SSSS for testing, you can execute the following command:

docker run --init --rm --name ssss -p 1075:1075 --help

To obtain the latest "nightly" release, you can grab it (and s4) from the latest main branch build of the SSSS CI workflow.

To create a lighter build of the SSSS that only targets on the particular host that you plan to use, either ask in the community chat or be a Rust developer and build the SSSS from source with the appropriate feature flag and target:

export target={x86_64,aarch64}-unknown-linux-musl
rustup target add $target
cargo build -p ssss --locked --release --target $target \
    --no-default-features --feature {aws,azure,local}


The s4 CLI tool has several commands that enable convenient debugging and testing of your SSSS. When running against a local SSSS and fresh anvil testnet, commands can be run with few or no arguments.


  set-policy        Write a new policy to the blockchain for retrieval by the listening SSSSs
  acquire-identity  Acquire an Escrin identity from an SSSS
  deal              Split a secret into shares and deal it to the requested SSSSs
  reconstruct       Reconstructs a secret from shares requested by the requested SSSSs
  help              Print this message or the help of the given subcommand(s)

  -v, --verbosity...
  -h, --help          Print help
  -V, --version       Print version