Singularity Blockchain Key Management via non-custodial key management

Sumit Vohra

REVIEW 3 major objections 5 minor 1 references

Singularity Blockchain Key Management via non-custodial key management

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A wallet private key split across three independent stores can be recovered by signing in with an existing OAuth account, and no single store can unlock it.

desk verdict A concrete, commercially-motivated 2-of-3 sharding design for OAuth-based wallet recovery; the non-custodial claim fails as written because any two storages can reconstruct the key, but it is a legitimate design sketch worth refereeing. read the letter →

arxiv 2506.02282 v1 pith:FPKDQTOR submitted 2025-06-02 cs.CE cs.CR

Sumit Vohra This is my paper

classification cs.CEcs.CR

keywords non-custodialwalletskeymanagementShamirsecretsharingdistributedgenerationOAuthrecoveryblockchainsharedsecuritymodelweb3onboarding

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that blockchain wallets can be both secure and convenient if the private key is sharded into three pieces held by three independent parties—the Torus network, the user's device, and Singularity's server—so that any two pieces can rebuild the key. The user signs in with a familiar web2 OAuth provider such as Google, and the scheme generates a master entropy from all three parties to derive the wallet key. This would let mainstream users onboard to web3 without managing seed phrases, while keeping the key non-custodial because no single storage layer can reconstruct it. The paper further claims that this design combines low-latency signing using only the device and server shards with OAuth-based recovery and wallet interoperability.

What carries the argument

The load-bearing mechanism is the combination of 'double-sided DKG' with 2-of-3 Shamir secret sharing of an elliptic-curve encryption key (Ekp). Double-sided DKG means Torus network runs an async DKG to contribute one source of randomness, and the client combines that with server entropy and device entropy in a synchronous DKG step to form the master entropy that determines the private key. The separate Ekp, generated on the device and split via Shamir into three shares (E1, E2, E3) stored at Torus, the device, and the Singularity server respectively, is what lets any two storage layers cooperate to decrypt the private-key shards (s1', s2', s3'), recover the private key, or re-encrypt all shards under a fresh Ekp' during key rotation.

What would settle it

An auditor could take the encryption-key shares E1 from Torus storage and E3 from Singularity server storage, interpolate them to obtain Ekp, decrypt s1' and s2' with Ekp to get s1 and s2, and then interpolate s1 and s2 to get the private key. If that succeeds with only those two storages and no device shard, the claim that the scheme is non-custodial under single-party compromise is false.

Watch

Extended reading notes

Core claim

On its own terms, the central discovery is that a shared-security key management pattern can use ordinary social sign-in as the recovery mechanism without turning the provider into a custodian. During first sign-in, Singularity runs a double-sided distributed key generation: it fetches entropy from the Torus network's async DKG, adds server-provided entropy and device-generated entropy on the client, and combines them into a master entropy from which the wallet's private key is derived. The master entropy and key are then split into three shards, encrypted under an elliptic-curve key (Ekp) that is itself split into three Shamir shares and distributed to the same three storages. Any two shares of Ekp reconstruct the encryption key, which decrypts two key shards, which reconstruct the private key; the user can therefore recover on a new device by simply logging in again with the same OAuth provider.

Load-bearing premise

The scheme's security rests on the assumption that the three parties storing the shards are independent and never work together against the user; if even two of them combine what they hold, the paper's own reconstruction steps recover the private key without the user's device.

Editorial extensions

If this is right

A user who loses or changes their device can recover their wallet on a new device by signing in with the same social account, with no seed phrase required.
Transaction signing after the first login uses only the device shard and the Singularity server shard, cutting latency from about 10 seconds to about 100 milliseconds compared with blockchain-threshold models.
Because the master entropy is used to derive standard BIP-compatible keys, the user can export a seed phrase and migrate the wallet to any other wallet provider.
If one of the three storage layers is breached, the single captured shard does not reveal the private key, and the scheme's rotation procedure can re-encrypt all shards with a new Ekp'.
If Singularity's servers go offline, the device and Torus shards remain sufficient to reconstruct the private key through the IPFS-hosted death route.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The non-custodial claim is really a pairwise non-collusion assumption: the paper's own recovery algorithm shows that the Singularity server (holding E3 and s2') and the Torus network (holding E1 and s1') together can interpolate Ekp, decrypt both shards, and rebuild the private key without the user's device.
A natural testable extension is to model a malicious or subpoenaed Singularity server plus a compromised Torus subset as the adversary; under that model the scheme reduces to custodial security rather than user self-custody.
Because the wallet's private key is reconstructed in full on the user's device during each sign-in and recovery, the scheme offers no threshold-signing protection against a device compromise at that moment; a hardware-wallet or MPC signing extension would close that gap.
The 'hack-resistance of one storage' statement assumes the compromise is detected quickly enough to rotate the remaining shares; a silent compromise of two storages before detection would break the 2-of-3 guarantee.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Sumit's paper is an architecture whitepaper for a commercial wallet key-management product. The good news first: it identifies a real pain point (seed-phrase burden), gives a fair survey of shared-security models, and proposes a concrete configuration—2-of-3 Shamir split of the private key across device, Torus, and Singularity server, with an ECC-wrapped revocation step—that would give users Google-login recovery and sub-second signing. That is a plausible design direction, and the paper is honest that it is a sketch: the only security support is "We believe that, if done right..."

The soft spot is load-bearing. The paper's core claim is non-custodial: no single party controls the key, and compromise of one storage is harmless. But by the paper's own recipes, any two storages can reconstruct the private key without the user's device. The recovery algorithm uses E2 and E3 to reconstruct the wrapping key Ekp, then decrypts and combines s1 and s2. Meanwhile, Torus holds E1 and encrypted s1, and the server holds E3 and encrypted s3. Torus and Singularity together can compute Ekp from E1,E3, decrypt both encrypted shards, and then reconstruct the private key from s1 and s3. The paper never analyzes this two-provider collusion case, even though it criticizes Web3Auth for exactly this kind of threshold-node compromise. That's a real contradiction, not a nitpick.

There's also an internal consistency problem: the storage table assigns s1→Torus, s2→device, s3→server, but the recovery flow uses s1' and s2' with E2,E3, and the sign-in flow mentions fetching s1' from device and s2' from server in places. I can't pin down the exact mapping, and every consistent reading still leaves a two-party path.

That said, the paper is not incoherent. It's a design proposal with no implementation, no adversary model, and no benchmarks—the O(100ms) latency figure is asserted without measurement. If a formal threat model and a reference implementation were added, and the collusion case analyzed, this could become a real contribution. As it stands, the non-custodial claim is unsupported and, on the paper's own construction, false under two-storage collusion.

Who should read it: people thinking about web3 onboarding and threshold key management would find the UX reasoning and the survey useful, but not the security analysis. I'd send it to a serious referee, because the design is testable and the central flaw is fixable with a proper collusion analysis—and the paper's own cited prior art (Web3Auth/Torus) shows the configuration space is real. But I would not cite it as a security result.

Referee Report

3 major / 5 minor

Summary. The paper proposes 'Singularity KMS', a web2 sign-in based key backup scheme that claims to be non-custodial. The scheme splits a user's private key into three Shamir shares stored on the Torus network, the user's device, and a Singularity server, and also splits an elliptic wrapping key Ekp into three shares stored across the same three locations. The paper argues that because key reconstruction needs any two shares, compromise of one storage is harmless, and that the design achieves low latency, revocability, and wallet interoperability. The paper provides high-level pseudocode for key generation, recovery, and revocation, but no adversary model, no security proofs, and no experimental evaluation.

Significance. If the central claim were correct, the scheme would offer a concrete answer to the UX problem of seed-phrase recovery in web3 wallets. The paper is useful as a design sketch: it identifies a real pain point, builds on standard primitives (Shamir secret sharing, DKG, OAuth 2.0), and includes pseudocode that makes the intended data flow explicit. However, the main claim—non-custodial custody—is not merely unproven; it is contradicted by the paper's own algorithms, which permit any two of the three storage providers to reconstruct the private key without the user's device. The paper also lacks a threat model and presents unsupported performance figures. Thus, even if the design were implemented as described, it would not deliver the advertised property.

major comments (3)

[Section III, Recovery and Revocation] The central claim that Singularity is non-custodial and that compromise of one storage is harmless is contradicted by the paper's own construction. In 'Distributed Key Storage', E1, E2, E3 are 2-of-3 Shamir shares of Ekp, and the private-key shards s1, s2, s3 are encrypted under Ekp and stored at Torus, device, and server. Any two storage providers can reconstruct Ekp from their E shares, then decrypt their two s shares and reconstruct the private key. For example, Torus (holding E1 and s1') and the Singularity server (holding E3 and s3') can compute Ekp = Shamir_Lagrange(E1, E3), decrypt s1' and s3', and then compute private_key = Shamir_Generate(s1, s3), all without the user's device. This is exactly the two-party collusion case the paper never analyzes, even though Section II.B.1 criticizes Web3Auth for the analogous threshold-node compromise. The 'hack-resistance of one storage' claim therefore holds only if no two of the three storages ever collude, an assumption that is neither stated nor justified.
[Section III, Key Generation Flow] The shard-to-storage mapping is internally inconsistent, making the scheme's guarantees impossible to pin down. The storage table maps s1 to Torus, s2 to device, and s3 to server, and E1 to Torus, E2 to device, E3 to server. The recovery algorithm, however, reads E2 from device and E3 from server, reconstructs Ekp, then decrypts s1' and s2' to compute private_key = Shamir_Generate(s1, s2). On a new device, s2' is unavailable, and if s1' is at Torus, the algorithm as written mixes storages in a way that does not match the table. The sign-in flow text similarly says it fetches 'E2,S2’ and E3,S3’' but then uses s1' and s2'. Every consistent reading still leads to a two-provider collusion path: even if the intended flow uses Torus and server shares for recovery, those two providers can reconstruct the key alone. The paper needs to correct the mapping and then re-analyze the custody property under that corrected mapping.
[Section III, point 6] The paper does not provide an adversary model or security proof for any of its load-bearing claims. It asserts that the double-sided DKG and 'master entropy' ensure that 'no single party has logical control over the key generation', but it does not define the DKG protocol, the adversary capabilities, or what 'logical control' means. The signing latency claim of O(100ms) in Section III point 6 is presented without measurements, a system model, or a comparison baseline. These are not presentation issues: without a threat model and a formal treatment of the custody property, the paper cannot substantiate that the scheme is non-custodial or that it resists storage compromise.

minor comments (5)

[Section II.A.2] The phrase '3P oAuth' should be '3rd-party OAuth', and 'looses' in Section II.A.2 should be 'loses'.
[Torus Storage paragraph] The notation is inconsistent: the text uses S1, S2, and S3 while the pseudocode uses s1, s2, and s3, and the variable s1' is used for two different quantities in the Torus Storage description. Please standardize the notation throughout.
[Section III, Key Concepts] The term 'double sided DKG' is not a standard term and is not defined. The paper should either provide a formal specification or cite a reference that defines it.
[Section III, point 8] The description of the death route via IPFS is too vague to be evaluated: it is unclear how a decentralized UI client can 'seamlessly combine the two shards' in a disaster while preserving security. Please provide a concrete protocol description.
[References] Many references are to self-published or non-archival sources (Medium posts, blog entries, Wikipedia, and Torus documentation). Please cite peer-reviewed or formally published sources for correctness and reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: no fitted inputs, no author self-citations, and the one construction-derived claim (2-of-3 'hack-resistance of one storage') follows validly from Shamir thresholding; the non-custodial claim's collusion flaw is a correctness gap, not a circular reduction.

full rationale

Singularity KMS is an architecture/design paper: it contains no fitted parameters, no quantitative predictions, and no derived quantity whose output is fixed by its inputs by construction. It also contains no references to prior work by the author (Sumit Vohra), so no self-citation chain exists under patterns 3-5; the citations to Torus/Web3Auth documentation describe an externally deployed, audited threshold network and standard protocols (Shamir's paper, Lindell's MPC survey, Google's OIDC spec), which the reviewing rules treat as independent evidence rather than circular support. The one statement that is actually inferred from the construction, 'we have hack-resistance of one storage, so if one storage gets compromised, we have sufficient time to rotate the other storage keys' (Section III.2), is a valid consequence of the 2-of-3 Shamir split and is not a reduction-to-input. The paper's load-bearing label 'non-custodial' is asserted ('By sharding the keys into 3 separate independent data stores with independent user verification and access, the Singularity solution is non-custodial', Section IV), not derived; on the paper's own reconstruction equations (Ekp = Shamir_Lagrange_Generate(E2,E3); private_key = Shamir_Generate(s1,s2)), any two of the three storages - for example Torus and the Singularity server, holding E1+E3 and s1'+s3' - can recover Ekp and then the private key without the user's device, contradicting the Abstract's definition of non-custodial ('keys are in custody of the user') and reproducing the validator-compromise scenario the paper levels at Web3Auth in Section II.B.1. That is a correctness/security-model gap (unanalyzed pairwise collusion and an inconsistent shard-to-storage mapping between the storage table and the recovery flow), not circularity: the claim fails by counterexample from the paper's own algorithms rather than being equivalent to its inputs. A proportionate circularity finding is therefore 0, with the security-model concerns noted as correctness risk.

Assumptions & free parameters 3 free parameters · 5 assumptions · 3 invented entities

The paper contributes no new cryptographic primitive; its claims rest entirely on standard threshold secret sharing, on third-party infrastructure (Torus nodes, OAuth providers, AWS), and on an unstated non-collusion assumption between the three storage parties. The design parameters (2-of-3 threshold, 9 inner Torus shards, claimed latencies) are chosen by hand and no security analysis tests them. There are no invented physical entities, but the paper attaches new names (master entropy, double-sided DKG) to compositions of existing entropy sources.

free parameters (3)

reconstruction threshold = 2 of 3 shards
Design choice: any two of device/Torus/Singularity shards reconstruct the private key. The security consequences of 2-of-3 collusion are never analyzed.
Torus inner shard count = 9 shards
The user's Torus shard is further split into 9 shards (Section III point 2) with no node/threshold analysis provided.
signing latency claim = O(100 ms)
Asserted in Section III point 6 as a reduction from O(10s), with no measurement, methodology, or benchmark.

assumptions (5)

standard math Shamir secret sharing provides the claimed 2-of-3 threshold reconstruction and secrecy properties
Invoked in Key Concepts 6 and in the sharding pseudo-code. Correct as a primitive, but the paper does not analyze the security of the specific composition.
domain assumption The Torus network's async DKG, postbox key, and node storage are secure and available
The entire scheme depends on Torus infrastructure ([10], [12], [13], [16]); the paper cites Torus's own documentation as evidence.
domain assumption OAuth2.0/OIDC providers such as Google are trusted identity roots
Key recovery is gated on the user's SSO identity token; compromise or suspension of the Google account is treated as out of scope although SSO is the sole recovery trigger.
ad hoc to paper The three shard holders do not collude
The non-custodial claim and the 'hack-resistance of one storage' statement (Section III point 2) implicitly require that no two of device, Torus, and Singularity cooperate against the user; the paper never states or justifies this.
domain assumption http-only cookie plus domain-isolated iframe defeats XSS/CSRF and JS tampering
Asserted in Section III points 5 and 7 with no adversarial analysis of cookie exfiltration or iframe origin binding.

invented entities (3)

master entropy
purpose: A conceptual entropy source defined as syncDKG(server entropy, device entropy, asyncDKG(Torus)) used to derive blockchain private keys
A name for a composition of existing randomness sources; no new falsifiable property is attached to it.
double sided DKG
purpose: Combines async DKG (Torus) with a runtime sync DKG on the client to generate master entropy
Presented as novel, but no protocol specification or security analysis distinguishes it from sequential DKG and entropy combination.
postbox key
purpose: Key derived from Torus async DKG shards, used to encrypt the Torus-stored share s1
Terminology borrowed from Torus documentation [13]; not independently introduced or verified by this paper.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Singularity Blockchain Key Management via non-custodial key management." pith.science (2026). https://pith.science/paper/FPKDQTOR

@misc{pith2026250602282,
  author       = {Pith},
  title        = {Pith review of: Singularity Blockchain Key Management via non-custodial key management},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FPKDQTOR}},
  note         = {Machine review of arXiv:2506.02282}
}

read the original abstract

web3 wallets are key to managing user identity on blockchain. The main purpose of a web3 wallet application is to manage the private key for the user and provide an interface to interact with the blockchain. The key management scheme ( KMS ) used by the wallet to store and recover the private key can be either custodial, where the keys are permissioned and in custody of the wallet provider or noncustodial where the keys are in custody of the user. The existing non-custodial key management schemes tend to offset the burden of storing and recovering the key entirely on the user by asking them to remember seed-phrases. This creates onboarding hassles for the user and introduces the risk that the user may lose their assets if they forget or lose their seedphrase/private key. In this paper, we propose a novel method of backing up user keys using a non-custodial key management technique that allows users to save and recover a backup of their private key using any independent sign-in method such as google-oAuth or other 3P oAuth.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

1 extracted references

[1]

Singularity Server Storage S2 is generated on client side using random entropy generated from singularity’s server

SKALE, Torus. Singularity Server Storage S2 is generated on client side using random entropy generated from singularity’s server. S2 is encrypted using Ekp and stored inside a private subnet of AWS-Aurora cluster. This is further encrypted with a rotating salt stored in AWS-secret manager. Device Storage S3 is generated using random-entropy on client side...

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Singularity Server Storage S2 is generated on client side using random entropy generated from singularity’s server

SKALE, Torus. Singularity Server Storage S2 is generated on client side using random entropy generated from singularity’s server. S2 is encrypted using Ekp and stored inside a private subnet of AWS-Aurora cluster. This is further encrypted with a rotating salt stored in AWS-secret manager. Device Storage S3 is generated using random-entropy on client side...