Pith. sign in

REVIEW 4 major objections 5 minor 74 references

Towards an identity management solution on Arweave

T0 review · 4 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Pith's one-line read The paper proposes the first identity-management system built on Arweave, using DIDs, verifiable credentials, and BBS(+) proofs for selective disclosure.

desk verdict A clear Arweave SSI design proposal that overclaims novelty and GDPR compliance; useful as a tutorial, not as a verified system. read the letter →

arxiv 2412.13865 v3 pith:QBHPBUUG submitted 2024-12-18 cs.CR cs.ET

classification cs.CRcs.ET
keywords Arweaveidentitymanagementself-sovereigndecentralizedidentifiersverifiablecredentialsBBS+signaturesselectivedisclosureGDPR
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

This paper argues that Arweave's permanent storage can host a self-sovereign identity management solution. It proposes storing DID documents on Arweave, resolving them through ArNS, issuing verifiable credentials with BBS(+) signatures, and using BBS(+) zero-knowledge proofs for selective disclosure. The authors claim to be the first to investigate identity management on Arweave and present sample JavaScript code for setup, credential issuance, and verification. They further argue that the design supports GDPR compliance by keeping sensitive data out of DID documents, and that the security of the solution reduces to the security of BBS(+).

What carries the argument

The load-bearing mechanism is the BBS(+) signature scheme combined with Arweave's permanent storage. BBS(+) signs multiple identity claims into a single credential, and its zero-knowledge proofs let a holder disclose a chosen subset while proving that the disclosed values were part of the originally signed set. Arweave stores the DID document permanently, and ArNS resolves human-readable names to the transaction ID, so a verifier can retrieve the public key and check a proof without a central registry.

What would settle it

A concrete test would be to store a DID document containing a public key linked to a named natural person, then invoke the GDPR right to erasure by attempting to delete or update that transaction; if the original bytes remain retrievable on Arweave, the proposed architecture has no erasure mechanism, which would falsify the GDPR-by-design claim as stated.

Watch

Extended reading notes

Core claim

The central claim is that Arweave's permanent, immutable storage can serve as the resolution layer for a self-sovereign identity system. Concretely, each entity stores a DID document containing only public keys and service endpoints as an Arweave transaction, maps an ArNS name to that transaction ID, and receives verifiable credentials signed by a trusted issuer using BBS(+). A holder later presents an ArNS name and a BBS(+) zero-knowledge proof that reveals only the claims needed for a given interaction. Because DID documents contain no sensitive data and BBS(+) hides undisclosed claims, the paper concludes that data protection is achieved by construction and that the scheme's security reduces to the security of BBS(+), assuming a trusted issuer and secure channels.

Load-bearing premise

The load-bearing assumption is that storing identity data on Arweave's permanent, immutable ledger can still satisfy GDPR's data minimization, rectification, and erasure requirements, even though the regulation grants individuals the right to have personal data deleted.

Editorial extensions

If this is right

  • If the proposal holds, identity verification can run without a central identity provider: issuers certify claims, holders store credentials locally, and verifiers check proofs against DID documents fetched from Arweave.
  • Selective disclosure becomes a property of the credential itself, because BBS(+) proofs reveal only the chosen claims and hide all others.
  • The claim that security reduces to BBS(+) means that breaking the scheme requires breaking the underlying signing assumptions, assuming a trusted issuer and secure issuance channels.
  • Unlinkability is not automatic: the public key in the DID document can be used to track a user, so the design leaves a privacy-versus-efficiency trade-off for key refreshment.
  • The two minimal-disclosure variants show that finer-grained privacy is possible, but only at the cost of issuer-side flexibility or a full zk-SNARK setup.

Reading between the lines

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

  • Editorial inference: the permanence that makes Arweave attractive for identity records is in direct tension with GDPR erasure; a workable solution would likely need off-ledger pointers, time-limited DID documents, or a legal deletion layer that the paper does not specify.
  • Editorial inference: per-verification key refresh, suggested to restore unlinkability, would multiply Arweave transactions and re-issuance events, so a cost model based on bundling and storage fees could determine whether the design is practical.
  • Editorial inference: the paper's second minimal-disclosure variant replaces BBS(+) with a general zk-SNARK, adding a trusted setup and a new proof system to the trusted base; one could test this variant on Arweave's smart-contract execution layers and compare proof-generation costs.
  • Editorial inference: a natural next step is to benchmark the proposed flow against the other Arweave-based naming and identity protocols the paper cites, since those are the closest competitors rather than the non-Arweave solutions used for comparison.
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.

Referee Report

4 major / 5 minor

Summary. The paper proposes a Self-Sovereign Identity (SSI) framework on the Arweave permanent-storage network, combining W3C Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), the Arweave Name System (ArNS), and BBS(+) signatures to enable selective disclosure. It gives a phase-wise design (DID creation, VC issuance, identity verification) with illustrative JavaScript, discusses two minimal-disclosure variants using zk-proofs, and compares the proposal with Sovrin, Veramo, Civic, ION, and SelfKey. The paper claims to be the first IdM solution on Arweave and asserts both GDPR compliance by design and that the security of the proposal reduces to the security of BBS(+).

Significance. If the design were rigorously supported, this would be a useful early contribution to identity management on decentralized permanent storage, and the tutorial material on Arweave is informative. The paper is transparent about many design choices (e.g., the trade-off between unlinkability and efficiency, the minimal-disclosure variants, the reliance on trusted issuers). However, the central regulatory claim, GDPR compliance by design, is not established and is in tension with the paper's own description of Arweave immutability; the security reduction to BBS(+) is asserted without proof; and the novelty claim is questioned by the paper's own related-work discussion. These issues affect the paper's core contributions and need to be resolved.

major comments (4)
  1. [§6.1, 'Self-sovereignty' paragraph; §4.5] The claim that the proposal achieves 'compliance with the GDPR by design' is not supported and is internally inconsistent. Section 6.1 states that 'the DID documents persist and cannot be altered or deleted,' and Section 4.5 says data on the Permaweb 'cannot be deleted or modified,' yet the same subsection claims that users can ask for corrections and deletion of their identities and that 'data update and identity removal are performed by a trusted, certified authority. This complies with EU regulations.' No mechanism is described that would allow a certified authority to alter or erase a DID document once written to Arweave; removing an ArNS pointer or rotating keys would leave the original transaction and the public-key-to-user association permanently retrievable. Since Section 6.1 also concedes that 'the public key maintained in the DID uniquely identifies the user and permits tracking of his/her actions,' the DID document contains personal data under the GDPR, and GDPR Articles 16 and 17 require rectification and erasure that the described architecture cannot provide. The footnote that 'the DID document contains no sensitive data' does not resolve the issue, because non-sensitive but identifying data still falls within the scope of the GDPR.
  2. [§6.1, 'Privacy and security' paragraph; §6.5] The statement that 'the data security in our proposal, as described in Subsection 5.4, reduces to the security of the BBS(+) scheme' is an unproven assertion. The construction includes components outside BBS(+): Arweave storage and ArNS resolution, DID document creation and public-key management, VC issuance with JWT-based signing and secure transmission, key management via ArConnect/ArDrive, and, for Variant 2, an additional zk-SNARK with a fresh proving/verification key pair. No adversary model, security game, or reduction argument is given for the full protocol; the phrase 'holds directly from the construction' does not constitute a proof. This is especially problematic because Section 6.5 defers 'a more in-depth analysis of the security and privacy of such a solution' to future work. Either provide a formal security statement and proof sketch for the whole design, or revise the claim to describe the precise trust assumptions for each component.
  3. [§2 and §6.4] The novelty claim, stated in the Introduction as 'we are the first to look into IdM solutions on Arweave' and echoed in Section 6.4 as 'We did not identify any other IdM solution built on Arweave except our current proposal,' is in tension with the paper's own description of the Ark Protocol in Section 2 as 'a decentralized IdM framework, designed to facilitate the creation, management, and verification of digital identities, which integrates with the broader blockchain and Web3 ecosystems' and as providing 'standards and frameworks for DIDs, verifiable credentials, and interoperability.' If Ark Protocol qualifies as an IdM solution on Arweave, the novelty claim should be qualified or clarified; if it does not, the paper should state the distinguishing criteria explicitly.
  4. [§5.2 vs §6.1] The requirements list in Section 5.2 includes 'Anonymization' and 'Unlinkability' as privacy and security requirements, but Section 6.1 acknowledges that 'the public key maintained in the DID uniquely identifies the user and permits tracking of his/her actions,' and the only proposed remedy is refreshing the holder's keys after each verification, described as a considerable complexity trade-off. As written, the proposal does not meet its own stated requirements, and the analysis does not present a concrete mechanism to achieve unlinkability. The paper should either revise the requirements analysis to acknowledge partial fulfillment or add a mechanism (e.g., ephemeral DIDs or per-verifier DIDs) that actually provides unlinkability.
minor comments (5)
  1. [§3.4; §6.1] There are typographical errors: 'back-and-four' should be 'back-and-forth' in Section 3.4, and 'discard the necessary claims only' should be 'disclose the necessary claims only' in Section 6.1.
  2. [Table 1] The acronym table lists 'GRPD' instead of 'GDPR'; please correct the spelling.
  3. [§6.2] The text refers to 'Figure 6.2 illustrates these changes,' but the figure is labeled 'Figure 4' in the manuscript.
  4. [§5.4] The JavaScript snippets are presented in a confusing order and contain undefined functions (e.g., `createVerifiableCredential`) and duplicate declarations of `signedVC`; the code should be cleaned, completed, and referenced consistently so that the phases are reproducible.
  5. [References [32] and [68]] Reference [32] and the duplicate entry [68] both contain the title misspelling 'Dillemma' (should be 'Dilemma'), and [68] appears incomplete without a venue or URL.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is a design proposal whose security and privacy claims reduce to external primitives, not to its own inputs.

full rationale

The manuscript is an architectural proposal rather than a derivation, so the circularity patterns (fitted parameters, definitions that presume the target, load-bearing self-citation chains) do not apply. The central claim that the security of the construction reduces to BBS(+) is a compositional reduction: BBS(+) is an externally analyzed signature scheme, and the paper explicitly states the assumptions (trusted issuer, secure channels) under which the reduction holds (§6.1). The GDPR-related assertions are internally inconsistent — §4.5 and §6.1 state on-chain data 'cannot be altered or deleted' while §6.1 also claims deletion by a trusted authority — but that is a correctness/design tension, not circularity, because the claim does not reduce to its own inputs by construction. The self-citations ([16], [34], [72]) are background surveys, a prior uPort analysis, and an optional implementation pointer for the zk-SNARK variant in §6.2; none is invoked as the sole justification of a core result. The 'first to look into IdM on Arweave' claim is an assertion and is in tension with the paper's own discussion of Ark Protocol and Namespace.gg, but a novelty dispute is not a circular-reasoning defect.

Assumptions & free parameters 0 free parameters · 4 assumptions · 1 invented entities

The proposal contains no fitted parameters. Its load-bearing assumptions are: Arweave's permanence is compatible with GDPR erasure rights (ad_hoc, asserted but unresolved); trusted issuers and secure channels exist (ad_hoc, stated in §6.1); BBS(+) security as a background building block (standard_math); and a workable 'did:arweave' DID method (domain_assumption, not specified). The only invented entity is the 'did:arweave' method placeholder, which has no independent evidence.

assumptions (4)
  • domain assumption Arweave provides permanent, immutable, available storage for DID documents.
    The design stores DID documents on Arweave and relies on their permanence; invoked throughout §4 and §5.4, but the GDPR compatibility of that permanence is not shown.
  • ad hoc to paper A trusted VC issuer exists that does not disclose sensitive information, and secure channels exist between issuer and holder.
    Stated in §6.1 as the assumptions under which 'data security reduces to the security of BBS(+)'.
  • ad hoc to paper DID documents containing public keys and service endpoints are not sensitive personal data under GDPR.
    The paper asserts 'the DID document contains no sensitive data' (§6.1) while admitting public keys uniquely identify the user; this unproven premise underlies the GDPR-by-design claim.
  • standard math BBS(+) signatures are secure under DDH and q-SDH and support selective disclosure.
    Background from [10]; used as the core privacy primitive in Phase 2.
invented entities (1)
  • did:arweave DID method
    purpose: To make DIDs resolvable via Arweave transactions and ArNS names.
    The paper gives an example DID document with 'did:arweave:...' IDs (§5.4) but never specifies the DID method, its resolution rules, privacy properties, or governance; no implementation is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards an identity management solution on Arweave." pith.science (2026). https://pith.science/paper/QBHPBUUG

@misc{pith2026241213865,
  author       = {Pith},
  title        = {Pith review of: Towards an identity management solution on Arweave},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QBHPBUUG}},
  note         = {Machine review of arXiv:2412.13865}
}
read the original abstract

Traditional identity management systems, often centralized, face challenges around privacy, data security, and user control, leaving users vulnerable to data breaches and misuse. This paper explores the potential of using the Arweave network to develop an identity management solution. By harnessing Arweave's permanent storage, our solution offers the users a Self-Sovereign Identity (SSI) framework, that uses Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) to allow individuals and other entities to create, own, and manage their digital identities. Further, the solution integrates privacy-preserving technologies, including zero-knowledge proofs and the BBS(+) signature scheme, enabling selective disclosure. This approach ultimately enhances user privacy and supports compliance with European Union legislation and regulatory standards like the General Data Protection Regulation (GDPR) by design.

Figures

Figures reproduced from arXiv: 2412.13865 by the authors.

Figure 6
Figure 6. illustrates these changes [PITH_FULL_IMAGE:figures/full_fig_p027_6.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

74 extracted references · 72 canonical work pages

  1. [1]

    Last Accessed: August 2024

    Arweave, Meet Arweave: Permanent information storage, https://arweave.org. Last Accessed: August 2024

  2. [2]

    URL https://ec.europa.eu/digital -building-blocks/ sites/display/EUDIGITALIDENTITYWAL LET/The+Digital+Identity+ Regulation+Enters+into+Force

    European Commission, The EU Digital Identity Framework Regulation Enters into Force (2024). URL https://ec.europa.eu/digital -building-blocks/ sites/display/EUDIGITALIDENTITYWAL LET/The+Digital+Identity+ Regulation+Enters+into+Force. Last Accessed: November 2024

  3. [3]

    Last Accessed: August 2024 (2023)

    eIDAS Technical Sub-group, eIDAS Cryptographic Requirements for the Interoperability Framework, https://ec.europa.eu/digital-building-blocks/sites/display /DIGITAL/eIDAS+eID+Profile. Last Accessed: August 2024 (2023)

  4. [4]

    Last Accessed: September 2024 (2023)

    European Union, Regulations of the European Parliament and of the Council amending Regulation (EU) No.910/2014 as re- gards establishing the European Digital Identity Framework, https://data.consilium.europa.eu/doc/document/ PE-68-2023-REV-1/en/pdf. Last Accessed: September 2024 (2023)

  5. [5]

    Last Accessed: October 2024

    Regulation (EU) 2016/679, General Data Protection Regulation GDPR, https://gdpr-info.eu/. Last Accessed: October 2024

  6. [6]

    Last Accessed: November 2024

    Christopher Allen, The Path to Self-Sovereign Identity, https://www.lifewithalacrity.com/article/the-path-to-self -soverereign -identity. Last Accessed: November 2024

  7. [7]

    Last Accessed: Novem - ber 2024

    W3C, Verifiable Credentials Data Model v2, https://www.w3.org/TR/vc -data-model-2.0. Last Accessed: Novem - ber 2024

  8. [8]

    Core architecture, data model, and representations, 32 https://www.w3.org/TR/did -core

    W3C Recommendation, Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations, 32 https://www.w3.org/TR/did -core. Last Accessed: August 2024 (2022)

Show all 74 references
  1. [9]

    Last Accessed: August 2024

    ar.io Docs, Arweave Name System (ArNS), https://docs.ar.io/arns. Last Accessed: August 2024

  2. [10]

    Tessaro, C

    S. Tessaro, C. Zhu, Revisiting bbs signatures, in: Annual International Conference on the Theory and Applications of Cryptographic Tech - niques, Springer, 2023, pp. 691–721

  3. [11]

    URL https://sovrin.org

    Sovrin Foundation, Global public registry for DIDs, Trust anchor for Verifiable Credentials (2024). URL https://sovrin.org. Last Accessed: November 2024

  4. [12]

    URL https://veramo.io

    Sovrin Foundation, Performant and modular APIs for Verifiable Data and SSI (2024). URL https://veramo.io. Last Accessed: November 2024

  5. [13]

    URL https://www.civic.com

    Control Safety Trust for Digital Identities, Civic Technologies (2024). URL https://www.civic.com. Last Accessed: November 2024

  6. [14]

    URL https://identity.foundation/ion

    DIF Organization, ION (2024). URL https://identity.foundation/ion. Last Accessed: November 2024

  7. [15]

    URL https://selfkey.org

    SelfKey, Community Vote Proposed Merger With SingularityDAO and Cogito Finance to form Singularity Finance(SFI) AI Fi Layer 2 (2024). URL https://selfkey.org. Last Accessed: November 2024

  8. [16]

    Panait, R

    A.-E. Panait, R. F. Olimid, A. Stefanescu, Identity management on blockchain – privacy and security aspects (2020). arXiv:2004.13107. URL https://arxiv.org/abs/2004.13107

  9. [17]

    Nokhbeh Zaeem, K

    R. Nokhbeh Zaeem, K. C. Chang, T.-C. Huang, D. Liau, W. Song, A. Tyagi, M. Khalil, M. Lamison, S. Pandey, K. S. Barber, Blockchain - based self-sovereign identity: Survey, requirements, use-cases, and com- parative study, in: IEEE/WIC/ACM International Conference on Web Intell...

  10. [18]

    M. R. Ahmed, A. K. M. M. Islam, S. Shatabda, S. Islam, Blockchain - based identity management system and self -sovereign identity ecosys - tem: A comprehensive survey, IEEE Access 10 (2022) 113436 –113481. doi:10.1109/ACCESS.2022.3216643

  11. [19]

    M. M. Merlec, H. P. In, Blockchain-based decentralized storage systems for sustainable data self-sovereignty: A comparative study, Sustainabil- ity 16 (17) (2024). doi:10.3390/su16177671. URL https://www.mdpi.com/2071-1050/16/17/7671

  12. [20]

    Last Accessed: August 2024

    decent.land, Ark Protocol, https:/arkprotocol.xyz. Last Accessed: August 2024

  13. [21]

    Last Accessed: August 2024

    decent.land, namespace.gg, https://www.namespace.gg. Last Accessed: August 2024

  14. [22]

    Last Accessed: August 2024

    decent.land, decent.land, https://www.decent.land. Last Accessed: August 2024

  15. [23]

    Last Accessed: August 2024 (2023)

    European Commission, electronic IDentification (eID), https://ec.europa.eu/digital -building-blocks/sites/display /DIGITAL/What+is+eID. Last Accessed: August 2024 (2023)

  16. [24]

    Last Accessed: October 2024

    European Commission, A digital ID and personal dig- ital wallet for EU citizens, residents and businesses, https://ec.europa.eu/digital-building-blocks/sites/display/ EUDIGITALIDENTITYWALLET/EU+Digital+Identity+Wallet+Home. Last Accessed: October 2024

  17. [25]

    Last Accessed: November 2024 (2024)

    European Commission, EU Digital Identity Wallet Technical specifica- tions, https://ec.europa.eu/digit al-building-blocks/sites/ display/EUDIGITALIDENTITYWALLET/Technical+Specifications. Last Accessed: November 2024 (2024)

  18. [26]

    et al., Cryptographers’ Feedback on the EU Digital Identity’s ARF, https://github.com/eu -digital-identity-wallet/ eudi-doc-architecture -and-reference-framework/discussions /211

    Baum, C. et al., Cryptographers’ Feedback on the EU Digital Identity’s ARF, https://github.com/eu -digital-identity-wallet/ eudi-doc-architecture -and-reference-framework/discussions /211. Last Accessed: November 2024

  19. [27]

    URL https://www.euaiact.com

    European Parliament, The EU AI Act (2024). URL https://www.euaiact.com. Last Accessed: November 2024 34

  20. [28]

    Last Accessed: August 2024

    Arweave community, Arweave Permaweb Cookbook, https://cookbook.arweave.dev. Last Accessed: August 2024

  21. [29]

    Boneh, X

    D. Boneh, X. Boyen, H. Shacham, Short group signatures, in: Annual international cryptology conference, Springer, 2004, pp. 41 –55

  22. [30]

    M. H. Au, W. Susilo, Y. Mu, Constant -size dynamic k -taa, in: Security and Cryptography for Networks: 5th International Conference, SCN 2006, Maiori, Italy, September 6-8, 2006. Proceedings 5, Springer, 2006, pp. 111–125

  23. [31]

    Camenisch, M

    J. Camenisch, M. Drijvers, A. Lehmann, Anonymous attestation using the strong diffie hellman assumption revisited, in: Trust and Trustwor - thy Computing: 9th International Conference, TRUST 2016, Vienna, Austria, August 29-30, 2016, Proceedings 9, Springer, 2016, pp. 1–20

  24. [32]

    Søren Eller Thomsen, On the eu digital identity wallets dillemma: Un - linkability or loa high?

  25. [33]

    Looker, V

    T. Looker, V. Kalos, A. Whitehead, M. Lodder, The BBS Signature Scheme (2024). URL https://identity.foundation/bbs-signature/draft-irtf- cfrg-bbs-signatures.htmlname-generators-calculation. Last Accessed: December 2024

  26. [34]

    Panait, R

    A.-E. Panait, R. F. Olimid, On using zk -snarks and zk -starks in blockchain-based identity management, in: D. Maimut, A.-G. Oprina, D. Sauveron (Eds.), Innovative Security Solutions for Information Tech - nology and Communication s, Springer International Publishing, Cham, 20...

  27. [35]

    Last Accessed: August 2024

    Ryan Sproule, A Developer’s Guide to the zkGalaxy, https://www.blockchaincapital.com/blog/a -developers -guide-to -the-zkgalaxy. Last Accessed: August 2024

  28. [36]

    Last Accessed: September 2024

    Manta Network, Manta Network, https://github.com/Manta-Network. Last Accessed: September 2024

  29. [37]

    Last Accessed: September 2024

    Ethereum Foundation, What is Semaphore, https://docs.semaphore.pse.dev. Last Accessed: September 2024. 35

  30. [38]

    Last Accessed: August 2024

    ident3, Circom 2 Documentation, https://docs.circom.io/ getting-started/proving -circuits. Last Accessed: August 2024

  31. [39]

    Last Accessed: September 2024

    Aztec Labs, Noir - The universal language of zero-knowledge, https://aztec.network/noir. Last Accessed: September 2024

  32. [40]

    Last Accessed: September 2024

    Starkware, Cairo, https://starkware.co/cairo. Last Accessed: September 2024

  33. [41]

    Last Accessed: December 2024

    Jacob Eberhardt, Zokrates GitHub, https://github.com/Zokrates /ZoKrates. Last Accessed: December 2024

  34. [42]

    Last Accessed: September 2024

    Aleo, Leo, https://www.leo -lang.org. Last Accessed: September 2024

  35. [43]

    Last Accessed: August 2024

    ident3, snarkjs GitHub, https://github.com/iden3/snarkjs. Last Accessed: August 2024

  36. [44]

    Last Accessed: August 2024

    Electric Coin Company (ECC), halo2 GitHub, https://zcash.github.io/halo2. Last Accessed: August 2024

  37. [45]

    URL https://arkworks.rs

    arkworks contributors, arkworks zksnark ecosystem (2022). URL https://arkworks.rs

  38. [46]

    Last Accessed: August 2024

    NilFoundation, Zero -Knowledge Proof Systems Circuit Compiler, https://github.com/NilFoundation/zkllvm. Last Accessed: August 2024

  39. [47]

    Last Accessed: September 2024

    ZKsync, ZKsync, https://zksync.io. Last Accessed: September 2024

  40. [48]

    Last Accessed: September 2024

    Polygon, Polygon zkEVM, https://polygon.technology/ polygon-zkevm. Last Accessed: September 2024

  41. [49]

    Last Ac - cessed: September 2024

    Scroll Ltd, Scroll - Ethereum, Extended., https://scroll.io. Last Ac - cessed: September 2024

  42. [50]

    Last Accessed: September 2024

    Starknet Community, Starknet Docs, https://docs.starknet.io. Last Accessed: September 2024

  43. [51]

    Last Accessed: November 2024

    RiscZero, Universal Zero Knowledge, https://risczero.com. Last Accessed: November 2024. 36

  44. [52]

    S. Gao, G. Li, H. Fu, Zkwasm: A zksnark wasm emulator, IEEE Trans- actions on Services Computing (2024)

  45. [53]

    Last Accessed: September 2024

    Community Labs, Incubate Elevate on Arweave and AO, https://www.communitylabs.com. Last Accessed: September 2024

  46. [54]

    URL https://www.arweave.org/yellow -paper.pdf

    Sam Williams, Viktor Diordiiev, Lev Berman, India Raybould, Ivan Uemlianin, Arweave: The Permanent Information Storage Protocol (2024). URL https://www.arweave.org/yellow -paper.pdf

  47. [55]

    URL https://www.arweave.org/files/arweave -lightpaper.pdf

    Sam Williams, Abhav Kedia, Lev Berman, Sebastian Campos -Groth, Arweave: The Permanent Information Storage Protocol (2024). URL https://www.arweave.org/files/arweave -lightpaper.pdf

  48. [56]

    Last Accessed: October 2024

    Sam Williams, Lev Berman, ANS- 103: Succinct Proofs of Random Access, https://github.com/ArweaveTeam/arweave -standards/blob/master /ans/ANS-103.md. Last Accessed: October 2024

  49. [57]

    Last Accessed: August 2024

    Arweave community, SmartWeave, https://cookbook.arweave.dev/ concepts/smartweave.html. Last Accessed: August 2024

  50. [58]

    Last Accessed: August 2024

    Warp by RedStone, Smart contracts on Arweave, https://warp.cc. Last Accessed: August 2024

  51. [59]

    Last Accessed: August 2024

    Decent Land Labs, MEM: Lightning-fast serverless functions for web3, https://www.mem.tech. Last Accessed: August 2024

  52. [60]

    Last Accessed: October 2024

    Arweave, WeaveVM, https://docs.wvm.dev. Last Accessed: October 2024

  53. [61]

    WeaveVM, Read and write to arweave from solidity smart contracts: Introducing weavevm precompiles

  54. [62]

    Last Accessed: October 2024

    decent.land, ANS, https://github.com/decentldotland/ANS. Last Accessed: October 2024

  55. [63]

    Last Accessed: Au- gust 2024

    AR.IO, AR.IO is a network of decentralized gateways and permanent domains that power the permaweb, https://ar.io. Last Accessed: Au- gust 2024. 37

  56. [64]

    Last Accessed: August 2024

    Arweave community, ArNS, https://cookbook.arweave.dev/concepts /arns.html. Last Accessed: August 2024

  57. [65]

    Last Ac- cessed: November 2024

    Maurice E Mu¨ller, Robert Schneider, Hans Willenegger, Martin Allg o¨wer, and Walter Bandi, The AO Protocol: A Decentral - ized Open-Access Supercomputer, https://ao.ar.io//read. Last Ac- cessed: November 2024

  58. [66]

    Last Accessed: September 2024

    Partisia, Partisia Decentralised Identity, https://www.partisia.com/docs/partisia -decentralised -identity. Last Accessed: September 2024

  59. [67]

    Standard, Personal identification — ISO-compliant driving licence (2024)

    I. Standard, Personal identification — ISO-compliant driving licence (2024). URL https://www.iso.org/standard/69084.html. Last Accessed: November 2024

  60. [68]

    Søren Eller Thomsen, On the EU Digital Identity Wallets Dillemma: Unlinkability or LoA High?,

  61. [69]

    URL https://digital -strategy.ec.europa.eu/en/policies /data-act

    European Commission, Data Act (2024). URL https://digital -strategy.ec.europa.eu/en/policies /data-act. Last Accessed: November 2024

  62. [70]

    Last Accessed: October 2024

    ArConnect, ArConnect, https://www.arconnect.io. Last Accessed: October 2024

  63. [71]

    Last Accessed: Octo - ber 2024

    ArDrive, ArDrive, https://ardrive.io/mobile. Last Accessed: Octo - ber 2024

  64. [72]

    Panait, R

    A.-E. Panait, R. F. Olimid, A. Stefanescu, Analysis of uPort Open, an Identity Management Blockchain-Based Solution, in: S. Gritzalis, E. R. Weippl, G. Kotsis, A. M. Tjoa, I. Khalil (Eds.), Trust, Privacy and Security in Digital Business, Springer International Publishing, Cha...

  65. [73]

    Vlasov, K

    A. Vlasov, K. Kelly Olson, A. Stokes, A. Sanso, EIP-2537: Precompile for BLS12-381 curve operations (2024). URL https://eips.ethereum.org/EIPS/eip -2537. Last Accessed: December 2024 38

  66. [74]

    Last Accessed: November 2024 (2024)

    ArweaveTeam, ANS-104: Bundled Data v2.0 - Binary Serialization, https://github.com/ArweaveTeam/arweave-standards/blob/master/ ans/ANS-104.md. Last Accessed: November 2024 (2024)

Pith tools

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