Cowrie Research

entropy-primary-sources-2026-05-13

5 min read

Entropy primary-source snapshot

Fetched: 2026-05-13 UTC

1) Official docs homepage

Source: https://docs.entropy.xyz/

Selected framing from the docs homepage:

Build programs. Get signatures. Free users.

Entropy enables users to generate cryptographic signatures without directly interacting with their private key.

Notes:

  • Even the landing-page framing is helpful because it presents Entropy as a programmable signing system rather than as a generic wallet.
  • The product claim centers on signature generation under mediated policy, which is the right lower-layer lens for the corpus.

2) Entrosplainer overview

Source: https://docs.entropy.xyz/basics/entrosplainer/

Selected excerpts/signals from the overview:

The Entropy network provides threshold signing as a service. It consists of a proof of stake application chain built with Substrate where each validator node deploys a threshold signing client which holds secret key-shares.

The decision as to whether the network will collectively sign a particular message is determined by a predefined program.

Programs are stored on chain as WebAssembly (WASM).

Once a user is registered with an account, signing a message with Entropy does not require submitting a transaction to the Entropy chain.

Additional signals:

  • This is the single most useful conceptual page because it makes the architecture explicit: appchain coordination plus offchain keyshare custody plus onchain program policy.
  • It also makes clear that Entropy is chain-agnostic outbound signing infrastructure, not merely a chain-local smart-contract wallet.
  • The docs explicitly position custody, multi-user permissions, and arbitrary signing constraints as the main use case surface.

3) Signing-process docs

Source: https://docs.entropy.xyz/concepts/signing/

Selected excerpts/signals from the signing docs:

The relayer nodes does some checks, then randomly selects T of the signing commitee to pass the message to.

The Threshold server retrieves the latest version of the associated program from the entropy chain, and executes it with the message to be signed as input. Only on getting successful program output do they continue to the next step.

If the signing process fails, nodes broadcast who the malicious/faulty signer was, which is included in the next block.

Additional signals:

  • The relayer/program/signer split is explicit in the docs rather than inferred.
  • Policy evaluation happens independently at signing time, which makes the current onchain program state a live control surface for every signature request.
  • Fault attribution and committee replacement are built into the workflow, not added later as operational tooling.

4) Threshold-signature-scheme docs

Source: https://docs.entropy.xyz/concepts/threshold-signature-scheme/

Selected excerpts/signals from the cryptography page:

The TSS Implementation used by Entropy is Synedrion.

The threshold signature scheme used is the 2021 Canetti-Gennaro-Goldfeder-Makriyannis-Peled scheme from the paper ‘UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts’.

Entropy currently uses n-of-n … However … Entropy has ‘signing subgroups’ of nodes, of which all members hold identical keyshares.

Entropy uses five rounds.

Additional signals:

  • This page matters because it links Entropy’s higher-level control plane to a concrete cryptographic substrate rather than vague MPC branding.
  • Identifiable aborts, key refresh, and proactive security are especially relevant because they shape how slashing or committee churn can work.

5) Program-system docs

Source: https://docs.entropy.xyz/concepts/programs/

Selected excerpts/signals from the programs page:

The purpose of an Entropy program is to determine whether a group of nodes should generate a signature or not.

Programs are WebAssembly (WASM) components used by signing nodes to determine whether they should generate a signature and how to generate that signature.

Programs can include a custom_hash function …

Programs must be deterministic and cannot currently call other chains or directly access external data.

Additional signals:

  • This is the clearest lower-layer source for the signing-policy surface.
  • The docs show exactly how much authority the program layer has: allow/deny logic, custom hashing, auxiliary data, and limited oracle-fed chain data, but not arbitrary offchain I/O.
  • The device-proxy example is especially useful because it hints at composable policy stacks like key allowlists and message-type validation.

6) synedrion repository

Sources:

Selected excerpts/signals from the repo README:

This library is an implementation of a scheme described in “UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts”.

The library implements … ECDSA Key-Generation … Auxiliary Info. & Key Refresh … ECDSA Presigning … ECDSA Signing … Threshold Key Resharing.

where possible, a self-contained malicious behavior evidence will be returned, so that it can be published.

Additional signals:

  • The repo is the best source for how the cryptographic substrate maps into an evidence-producing operational system.
  • It shows Entropy as more than a product shell around outside MPC: key generation, refresh, presigning, and resharing are all part of the explicit mechanism.

Main takeaways from this pass

  • Entropy is best understood as programmable signer middleware coordinated by its own chain, not merely an MPC wallet.
  • The most important split is between onchain program authorship/state, relayer routing, threshold-key custody, and target-chain execution.
  • The program model is analytically strong because it exposes a clear lower-bound policy surface: deterministic WASM checks over signature requests, auxiliary data, and limited chain-fed oracle data.
  • The Synedrion materials keep the cryptographic substrate legible enough to compare Entropy with threshold-signature custody and chain-abstraction systems without collapsing everything into generic MPC branding.

Graph View