Here we consider Stronghold's architecture and internals in regard to cryptographic soundness. Unclear purpose and declared features, no multiparty computation It's unclear the purpose of Stronghold besides a vague "secure key storage". One would expect it to support (provide API for) hardware storages or perform multi-party computation (such as multi-/threshold signature); both these features are not designed. In the end the main use-case is "long-term key storage in a snapshot -- password-encrypted file" which can be replaced by an encrypted database. Note, previously, Stronghold had p2p feature allowing it connect to remote "vaults", this feature was removed. Overcomplicated architecture Stronghold types Internally (in engine + runtime + client components) Stronghold implements the following types:

Aztec Intro Chronology: Aztec 1: basic private transfers; deprecated Aztec Connect: zk-rollup, smart contracts; deprecated Aztec (Aztec 3, A3): Noir lang + encrypted L2 zk-rollup Refs: